*Proyecto Final
*Lizbeth Treviño
*Materia: Programación Orientada a Objetos** *Dra. Sara Elena Garza** *Hora: Jueves m1 - m3** *Salón 4212**
viernes, 18 de noviembre de 2011
martes, 15 de noviembre de 2011
~Ligas de Entradas de Puntos Extra
Materia: Programación Orientada a Objetos
Hora: Jueves m1 - m3
*Ligas Puntos Extra
- Casos de Sistema Fallidos
- Metodologías de análisis y Diseño de Software
- Patrones de Diseño
- Casos de Uso
- Diagramas UML
- Diagrama de clases Umbrello
- Conceptos
- Interfaz Gráfica de Usuario
- Diagramas de Secuencia
- Diseño de Pruebas Unitarias
- Anti patrones
- Sistemas Distribuidos
- Eventos, Errores y Excepciones
Hora: Jueves m1 - m3
*Ligas Puntos Extra
- Casos de Sistema Fallidos
- Metodologías de análisis y Diseño de Software
- Patrones de Diseño
- Casos de Uso
- Diagramas UML
- Diagrama de clases Umbrello
- Conceptos
- Interfaz Gráfica de Usuario
- Diagramas de Secuencia
- Diseño de Pruebas Unitarias
- Anti patrones
- Sistemas Distribuidos
- Eventos, Errores y Excepciones
~Eventos, Errores y Excepciones - PUNTOS EXTRA
Materia: Programación Orientada a Objetos
Hora: Jueves m1 - m3
Hora: Jueves m1 - m3
~Sistemas Distribuidos - PUNTOS EXTRA
Materia: Programación Orientada a Objetos
Hora: Jueves m1 - m3
*Sistemas Distribuidos
Se puede decir que un sistema distribuido es una colección de computadoras separadas físicamente y conectadas entre sí por una red de comunicaciones distribuida; cada máquina tiene componentes de hardware y software que el usuario percibe como un solo sistema. El usuario accede a los recursos remotos (RPC) de la misma manera en que accede a recursos locales, o un grupo de computadores que usan un software para conseguir un objetivo en común.
Los sistemas distribuidos cumplen las siguientes características:
* Los interfaces software clave del sistema están claramente especificados y se ponen a disposición de los desarrolladores.
* Los sistemas distribuidos abiertos se basan en la provisión de un mecanismo uniforme de comunicación entre procesos e interfaces publicados para acceder a recursos compartidos.
* Los sistemas distribuidos abiertos pueden construirse a partir de hardware y software heterogéneo, posiblemente proveniente de vendedores diferentes.
1.- Muchos usuarios interactúan simultáneamente con programas de aplicación.
Los sistemas distribuidos también proveen un alto grado de disponibilidad en la vertiente de fallos hardware. La disponibilidad de un sistema es una medida de la proporción de tiempo que está disponible para su uso. Un fallo simple en una maquina multiusuario resulta en la no disponibilidad del sistema para todos los usuarios.
La transparencia se define como la ocultación al usuario y al programador de aplicaciones de la separación de los componentes de un sistema distribuido, de manera que el sistema se percibe como un todo, en vez de una colección de componentes independientes.
Hora: Jueves m1 - m3
*Sistemas Distribuidos
Se puede decir que un sistema distribuido es una colección de computadoras separadas físicamente y conectadas entre sí por una red de comunicaciones distribuida; cada máquina tiene componentes de hardware y software que el usuario percibe como un solo sistema. El usuario accede a los recursos remotos (RPC) de la misma manera en que accede a recursos locales, o un grupo de computadores que usan un software para conseguir un objetivo en común.
Los recursos en un sistema distribuido están físicamente encapsulados en una de las computadoras y sólo pueden ser accedidos por otras computadoras mediante las comunicaciones. Para que la compartición de recursos sea efectiva, ésta debe ser manejada por un programa que ofrezca un interfaz de comunicación permitiendo que el recurso sea accedido, manipulado y actualizado de una manera fiable y consistente.
* Los interfaces software clave del sistema están claramente especificados y se ponen a disposición de los desarrolladores.
* Los sistemas distribuidos abiertos se basan en la provisión de un mecanismo uniforme de comunicación entre procesos e interfaces publicados para acceder a recursos compartidos.
* Los sistemas distribuidos abiertos pueden construirse a partir de hardware y software heterogéneo, posiblemente proveniente de vendedores diferentes.
En un sistema distribuido que está basado en el modelo de compartición de recursos, la posibilidad de ejecución paralela ocurre por dos razones:
2.- Muchos procesos servidores se ejecutan concurrentemente, cada uno respondiendo a diferentes peticiones de los procesos clientes.
Los sistemas distribuidos operan de manera efectiva y eficiente a muchas escalas diferentes. La escala más pequeña consiste en dos estaciones de trabajo y un servidor de ficheros, mientras que un sistema distribuido construido alrededor de una red de área local simple podría contener varios cientos de estaciones de trabajo, varios servidores de ficheros, servidores de impresión y otros servidores de propósito específico.* Ventajas
- Procesadores más poderosos y a menos costos
- Avances en la Tecnología de Comunicaciones.
- Procesadores más poderosos y a menos costos
- Avances en la Tecnología de Comunicaciones.
- Compartición de Recursos.
- Eficiencia y Flexibilidad.
- Disponibilidad y Confiabilidad.
- Crecimiento Modular.
*Desventajas
- Requerimientos de mayores controles de procesamiento.
- Velocidad de propagación de información (es lenta a veces).
- Servicios de replicación de datos y servicios con posibilidades de fallas.
- Mayores controles de acceso y proceso (Commit).
- Administración más compleja.
- Costos.
- Disponibilidad y Confiabilidad.
- Crecimiento Modular.
*Desventajas
- Requerimientos de mayores controles de procesamiento.
- Velocidad de propagación de información (es lenta a veces).
- Servicios de replicación de datos y servicios con posibilidades de fallas.
- Mayores controles de acceso y proceso (Commit).
- Administración más compleja.
- Costos.
* Bibliografia:
~Antipatrones - PUNTOS EXTRA
Materia: Programación Orientada a Objetos
Hora: Jueves m1 - m3
*Anti patrones
En desarrollo de software un antipatrón es una mala práctica, que aunque puede solucionar un problema en nuestra aplicación, también puede generar problemas de mantenimiento, diseño o comportamiento en el software.
Se puede decir que un antipatrón es, como su nombre lo indica, lo opuesto a un patrón de diseño, sin embargo el saber identificar esosbad smells en nuestros proyectos se considera una buena práctica, ya que así podremos implementar una mejor solución y hacer más eficientes nuestras aplicaciones.
Algunos ejemplos de anti patrones son:
*God - Objetc: es también conocido como The Blob, Winnebago o monster object. El Objeto todo poderoso es un objeto que hace mucho más de lo que debería osea no cumple con el principio de única responsabilidad, crece de manera descontrolada (como the blob) y se encarga de tantas cosas diferentes que todo el sistema termina dependiendo de él.
Este tipo de anti patrón es malo porque:
- Lo primero es que una clase tan grande seguramente será muy difícil de testear y de mantener debido a su complejidad.
- Una clase con tantas responsabilidades no será reusable en ningún otro proyecto.
- Clases muy grandes pueden cargar mucha información innecesaria en memoria degradando el rendimiento de nuestra aplicación.
Un god object no permite usar de buena manera los principios de orientación a objetos, por tanto no es fácil realizar cambios en la implementación de las clases sin afectar la funcionalidad de la aplicación.
*God - Objetc: es también conocido como The Blob, Winnebago o monster object. El Objeto todo poderoso es un objeto que hace mucho más de lo que debería osea no cumple con el principio de única responsabilidad, crece de manera descontrolada (como the blob) y se encarga de tantas cosas diferentes que todo el sistema termina dependiendo de él.
Este tipo de anti patrón es malo porque:
- Lo primero es que una clase tan grande seguramente será muy difícil de testear y de mantener debido a su complejidad.
- Una clase con tantas responsabilidades no será reusable en ningún otro proyecto.
- Clases muy grandes pueden cargar mucha información innecesaria en memoria degradando el rendimiento de nuestra aplicación.
Un god object no permite usar de buena manera los principios de orientación a objetos, por tanto no es fácil realizar cambios en la implementación de las clases sin afectar la funcionalidad de la aplicación.
Para saber si tienes clases con God- Objetc tienes que checar los siguientes puntos:
- Cuando encuentren una clase con muchos atributos o muchas operaciones o ambas. Una clase con más de 60 atributos y operaciones habitualmente es un god object.
- Atributos y operaciones diversas y sin conexión lógica entre ellas contenidas en una misma clase, una falta de cohesión de los atributos y operaciones es otro síntoma del God-Object.
- Una ausencia de un diseño orientado a objetos, una única clase que se encarga de controlar y encapsular toda la funcionalidad de la aplicación es más un diseñoprocedimental que orientado a objetos.
* Lava Flow o Dead Code aparece principalmente en aquellos sistemas que comenzaron como investigación o pruebas de concepto y luego llegaron a producción. La principal característica de este anti patrón es la presencia de distintos flujos o corrientes de previos desarrollos que quedaron diseminados, y se hicieron inservibles. Estos desarrollos anteriores (a modo de investigación) a menudo probaban distintos enfoques para resolver distintos problemas, usualmente apresurados para entregar a término para una demostración, omitiendo documentación.
* Poltergeists, o Gipsy, o Proliferation of Classes, o Big DoIt Controller Class. Las clases poltergeists (fantasmas) se caracterizan por tener pocas responsabilidades dentro del sistema y un ciclo de vida bastante breve, ya que “aparecen” solamente para iniciar algún método en alguna clase, a menudo en un determinado orden. Son de relativa facilidad de encuentro ya que sus nombres suelen llevar el sufijo “controller” o “manager”. Estas clases desordenan el diseño ya que agregan abstracciones innecesarias, son excesivamente complejas, difíciles de mantener y comprender.
- Cuando encuentren una clase con muchos atributos o muchas operaciones o ambas. Una clase con más de 60 atributos y operaciones habitualmente es un god object.
- Atributos y operaciones diversas y sin conexión lógica entre ellas contenidas en una misma clase, una falta de cohesión de los atributos y operaciones es otro síntoma del God-Object.
- Una ausencia de un diseño orientado a objetos, una única clase que se encarga de controlar y encapsular toda la funcionalidad de la aplicación es más un diseñoprocedimental que orientado a objetos.
* Lava Flow o Dead Code aparece principalmente en aquellos sistemas que comenzaron como investigación o pruebas de concepto y luego llegaron a producción. La principal característica de este anti patrón es la presencia de distintos flujos o corrientes de previos desarrollos que quedaron diseminados, y se hicieron inservibles. Estos desarrollos anteriores (a modo de investigación) a menudo probaban distintos enfoques para resolver distintos problemas, usualmente apresurados para entregar a término para una demostración, omitiendo documentación.
* Poltergeists, o Gipsy, o Proliferation of Classes, o Big DoIt Controller Class. Las clases poltergeists (fantasmas) se caracterizan por tener pocas responsabilidades dentro del sistema y un ciclo de vida bastante breve, ya que “aparecen” solamente para iniciar algún método en alguna clase, a menudo en un determinado orden. Son de relativa facilidad de encuentro ya que sus nombres suelen llevar el sufijo “controller” o “manager”. Estas clases desordenan el diseño ya que agregan abstracciones innecesarias, son excesivamente complejas, difíciles de mantener y comprender.
jueves, 10 de noviembre de 2011
~Sistemas Distribuidos
Materia: Programación Orientada a Objetos
Hora: Jueves m1 - m3
Hora: Jueves m1 - m3
*La manera en la que tengo pensado distribuir mi juego es la siguiente:
Quiero que mi juego sea en línea. Por lo pronto lo manejare solamente que sea jugador contra la computadora, ya que todavía no estoy pensando en poner la opción de que se pueda jugar entre usuarios, otra de las cosas que pensé para mi juego es que solamente se podrá utilizar en una computadora normal, una laptop o una iPad y esto lo pensé así porque para poder jugarlo se necesita que el juego aparezca un poco grande porque si no, no se podrán distinguir las palabras ni nada entonces por eso opte por que no se pueda jugar en celulares ya que tienen una pantalla muy pequeña y eso dificultará mucho la vista del juego. Tampoco se puede poner mi juego en consolas o algo por el estilo ya que como lo mencione para jugar fastwords se necesita un teclado y estas consolas no tienen los controles adecuados para llevar a cabo el juego entonces esa es otra opción descartada.
Pero básicamente esta es la manera de distribuir mi juego.
Quiero que mi juego sea en línea. Por lo pronto lo manejare solamente que sea jugador contra la computadora, ya que todavía no estoy pensando en poner la opción de que se pueda jugar entre usuarios, otra de las cosas que pensé para mi juego es que solamente se podrá utilizar en una computadora normal, una laptop o una iPad y esto lo pensé así porque para poder jugarlo se necesita que el juego aparezca un poco grande porque si no, no se podrán distinguir las palabras ni nada entonces por eso opte por que no se pueda jugar en celulares ya que tienen una pantalla muy pequeña y eso dificultará mucho la vista del juego. Tampoco se puede poner mi juego en consolas o algo por el estilo ya que como lo mencione para jugar fastwords se necesita un teclado y estas consolas no tienen los controles adecuados para llevar a cabo el juego entonces esa es otra opción descartada.
Pero básicamente esta es la manera de distribuir mi juego.
Suscribirse a:
Entradas (Atom)