Explique los problemas de diseo que resuelven los patrones GAMMA A continuacion se muestran algunos de los problemas que

resuelven los patrones GAMMA: 1. Encontrar los objetos apropiados: Lo mas complicado de un sistemas orientado a objetos es descomponer el sistema en objetos, porque entran en juego muchos factores: encapsulamiento, granularidad, dependencia, flexibilidad, reutilizacion, etc. Muchos objetos de un diseo provienen del modelo de anlisis. Pero los diseos orientados a objetos suelen acabar teniendo clases que no tiene su equivalente en el mundo real. Algunas de ellas son clases de bajo nivel como los arreglos. Otras son de mucho mas alto nivel. Por ejemplo, el patrn composite introduce una abstraccion para tratar unifomemente objetos que no tienen un equivalente fsico. Las abstracciones que surgen durante el diseo son fundamentales para lograr un diseo flexible. Los patrones de diseo ayudan a identificar abstracciones menos obvias y los objetos que las expresan. Estos objetos rara vez se encuentran durante el anlisis o incluso en las primeras etapas del diseo; son descubiertas mas tarde, cuando se trata de hacer al diseo mas flexible y reutilizable. 2. Determinar la granularidad de los objetos: los objetos pueden varias enormemente en tamao y numero. Como decidir entonces que debera ser un objeto? Los patrones de diseo se encargan tambin de esta cuestin. 3. Especificar las interfaces de los objetos: cada operacin declarada por un objeto especifica el nombre de la operacin, los objetos que toma como parametros y el valor de retorno de la operacin. Esto es lo que se conoce como la firma de la operacin. Al conjunto de todas las firmas definidas por las operacines de un objeto se le denomina la interfaz del objeto. Un tipo es un nombre que se usa para denotar una determinada interfaz. Decimos que un objeto tiene el tipo ventana si acepta todas las peticiones definidas en una interfaz llamada Ventana. Las interfaces son fundamentales en los sistemas orientados a objetos. Los objetos solo se conocen a traves de su interfaz. Los partrones de diseo ayudan a identificar interfaces indentificando sus elementos claves y los tipos de datos que se envian a la inteerfaz. Los patrones de diseo tambien especifican relaciones entre interfaces. En concreto muchas veces requieren que algunas clases tengas interfaces parecidas, o imponen restricciones a las interfaces de algunas clases. 4. Especificar las implementaciones de los objetos: La implementacion de un objeto queda definida por su clase, la cual especifica los datos, la representacion interna del objeto y define las operaciones que puede realizar 4.1. Herencia de clases frente a herencia de interfaces: La clase de un objeto define como se implementa un objeto. La clase define el estado interno de un objeto y la implementacion de sus operaciones . Por el contrario, el tipo de un objeto solo se refiere a su interfaz el conjunto de peticiones a las que puede responder - . Por supuesto hay una estrecha relacion entre clase y tipo, puesto que una clase define las operaciones que puede realizar un objeto, tambien define el tipo del objeto. Tambien es importante comprender la diferencia entre la herencia de clases y de interfaces. La herencia de clases define la implementacion de un objeto de terminos de la implementacion de otro objeto. En resumen, es un mecanismo para compartir codigo y representacion. Por el contrario, la herencia de interfaces describe cuando se puede usar un objeto en el lugar de otro. 4.2. Programar para interfaces, no para una implementacion: la herencia de clases no es mas que un mecanismo para extender la funcionalidad de una aplicacin reutilizando la funcionalidad de clases padres. Permite definir rpidamente un nuevo tipo de objetos basndose en otros, y obtener

asi nuevas implementaciones casi sin esfuerzo, al heredar la mayoria de lo que se necesita de otras clases que ya existen. En cualquier caso, reutilizar la implementacion es solo la mitad de la historia. Tambien es importante la capacidad de la herencia para definir familias de objetos con interfaces identicas, al ser justamente en lo que se base el polimorfismo. Manipular los objetos solamente en terminos de la interfaz definidad por clases abstractas tiene dos ventajas: Primero, los clientes no tienen que conocer los tipos especificos de los objetos que usan, basta con que estos se adhieran a la interfaz que esperan los clientes. Segundo, los clientes desconocen las clases que implementan dichos objetos; solo conocen las clases abstractas que definen la interfaz. Esto reduce de tal manera las dependencias de implementacion entre subsistemas que lleva al siguiente principio de diseo orientado a objetos reutilizable: Programe para una interfaz, no para una implementacion. Es decir, no se deben declarar las variables como instancias de clases concretas. En vez de eso, se ajustaran simplemente a la interfaz definida por una clase abstracta. No obstante, es evidente que en algun lugar del sistema habra que crear instancias de clases concretas, y los patrones de creacion, se encargan de ello. Al abstraer el proceso de creacion de objetos, estos patrones ofrecen diferentes modos de asociar una interfaz con su implementacion de manera transparente. Los patrones de creacion aseguran que el sistema se escriba en terminos de interfaces, no de implementaciones. 5. Poner a funcionar los mecanismos de reutilizacion: La mayoria de la gente conoce conceptos como objetos, clases, interface y herencia. La dificultad radica en aplicarlos para construir software flexible y reutilizable, y los patrones de diseo pueden mostar como hacerlo: 5.1. Herencia frente a composicion: Las dos tecnicas mas comunes para reutrilizar funcionalidad en un sistema orientado a objetos son la herencia de clases y la composicion de objetos. Como ya hemos visto, la herencia de clases permiti definir una implementacion en terminos de otra. La composicion de objetos es una alternativa a la herencia de clases, en la que la nueva funcionalidad se obtiene ensamblando o componiendo objetos para obtener funcionalidad mas compleja. La composicion de objetos requiere que los objetos a componer tengan interfaces bien definidas. Tanto la herencia como la composicion tienen sus ventajas e inconvenientes. Herencia de clases (+) Se define estaticamente en tiempo de ejecucion y es facil de utilizar, al estar permitida directamente por el lenguaje de programacion.. (-) No se pueden cambiar las implementaciones heredadas de las clases padre en tiempo de ejecucion, porque la herencia se define en tiempo de compilacion. (-) Las clases padres suelen definir al menos parte de la representacion fisica de las subclases. Como la herencia expone a una subclase detalles de la implementacion de la clase padre, suele decirse que la herencia rompe el encapsulamiento. La implementacion de una subclase se liga de tal forma a la implementacion de su clase padre que cualquier cambio en el padre obligara a cambiar la subclase. Composicion de Objetos (+) No se rompe el encapsulamiento, ya que la composicion requiere que los objetos tengan en cuenta las interfaces de los otros objetos. (+) Como la implementacion de un objeto se define en termino de interfaces de objetos, las dependencias de implementacion son notablemente menores.

5.2. Delegacion: 5.3. Herencia frente a tipos parametrizados:

PRUEBA ESTRATEGIAS DE CAMBIOS Son formas de realizar cambios en el software. Porque es necesario: Gran parte del software grande tiene entre 15 y 20 aos. Aunque hayan estado bien analizados y diseados se crearon cuando el tamao de los programas y el espacio de almacenamiento eran las principales preocupaciones. Luego se trasladaron a nuevas plataformas, maquinas, sistemas operativos y se mejoraron para satisfacer las necesidades de los usuarios Y todo esto sin tener en cuenta la arquitectura global!! Como consecuencia: Mala codificacin Arquitecturas mal diseadas Lgicas inadecuadas Escasa documentacin Estrategias para el cambio: Mantenimiento Evolucin Arquitectnica Reingenieria de Software Mantenimiento de Software Es la modificacin de un un sistema una vez que este ya fue implementado. La administracin del cambio trata con la planificacin y prediccin del proceso de cambio. Porque el mantenimiento es inevitable? Los requerimientos del sistema cambiaran seguramente mientras el sistemas esta desarrollndose. Los sistemas estn fuertemente acoplados con su ambiente, por lo tanto cambios en el mismo implicaran cambios en el software. Los sistemas deben ser mantenidos si se espera que sigan sirviendo a sus propsitos. Mala codificacin. Mala gestin de la configuracin. Que tipos de mantenimiento existen? Mantenimiento para reparar fallas de software Mantenimiento para adaptar el software a diferentes entornos operativos Mantenimiento para agregar o modificar funcionalidad del sistema.

Que encarece el mantenimiento? El personal que realiza el mantenimiento generalmente es inexperto y no esta familiarizado con el dominio de la aplicacin. Los programas pueden estar mal estructurados y ser difciles de comprender. Los cambios pueden introducir nuevos errores. La estructura puede ser degradada debido a los cambios continuos Puede no existir documentacin suficiente para entender el programa. El proceso del mantenimiento. Varia dependiendo del tipo de software, el ciclo de vida utilizado y las personas involucradas. Pasos: 1. Peticiones de cambio: Asignacin de nmeros de cambio, clasificar, aceptacin o rechazo del cambio, estimacin preliminar. 2. Anlisis de impacto: Anlisis de factibilidad, anlisis detallado, re documentacin si hiciese falta. 3. Diseo: Crear casos de pruebas, revisar requerimientos, revisar plan de implementacin. 4. Implementacion de cambios: codificar, realizar pruebas de unidad, revisar pruebas de legibilidad. 5. Prueba del sistema: Realizar pruebas funcionales, pruebas de interfaz, pruebas de regresin, pruebas de legibilidad. 6. Prueba de aceptacin: 7. Liberacin del sistema: instalar, capacitar.