Uso de patrones de arquitectura

Profesor Pedro Veloso Hernndez Master Ingeniera de Software UPM

 que es un Patrn de diseo?

Los patrones de diseo (design patterns) son la base para la bsqueda de soluciones a problemas comunes en el desarrollo de software y otros mbitos referentes al diseo de interaccin o interfaces. Un patrn de diseo es una solucin a un problema de diseo. Para que una solucin sea considerada un patrn debe poseer ciertas caractersticas. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reusable, lo que significa que es aplicable a diferentes problemas de diseo en distintas circunstancias.
"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice" [AIS+77].
Desing Patterns, Christopher Alexander E-book Version

Fuente Wikipedia

Los escaladores usan a menudo patrones de diseo, usado Arneses, cuerdas, mosquetones, que usan dadas ciertas Condiciones de soporte, forma, y para situaciones que deben Resolver como : salvataje, cruzar dos personas en un solo Intento, saltarse una gran roca, etc.

 que es un patrn UML?

Los patrones UML son colaboraciones parametrizadas , esto es , son un grupo de clases/objetos colaborando entre s que se pueden abstraer de un conjunto de escenarios general. Los patrones son un medio excelente para lograr reutilizacin y desarrollo robusto. A medida que los patrones se descubren en todo nuevo proyecto, se puede reutilizar la plantilla bsica del patrn desde modelos previos con los nombres de las variables apropiadas modificados para el proyecto en curso.

"Cada patrn describe un problema que ocurre infinidad de veces en nuestro entorno , as como la solucin al mismo, de tal modo que podemos utilizar esta solucin un milln de veces ms adelante sin tener que volver a pensarla otra vez."

Condiciones para usar un patrn UML

Los patrones generalmente describen cmo resolver un problema abstracto y la tarea del usuario del patrn consiste en modificar los elementos del patrn para cumplir las demandas del compromiso actual. Antes de comenzar a usar un patrn primero debe ser creado como un diagrama estndar de UML o existir como tal en algn repositorio

Vamos a un ejemplo

Este es un ejemplo de patrones de diseo propuesto en GOF Abstract Factory

patrones descriptos en el libro "Design Patterns - Elements of Reusable Object-Oriented Software" de Gamma et al., ms conocidos como 'La Banda de los Cuatro', 'Gang of Four o GoF en forma abreviada.

Cuando no usar patrones de diseo

Del mismo modo que no es aconsejable optimizar prematuramente, no se deben utilizar patrones de diseo antes de tiempo. Seguramente sea mejor implementar algo primero y asegurarse de que funciona, para luego utilizar el patrn de diseo para mejorar las flaquezas; esto es cierto, sobre todo, cuando an no ha identificado todos los detalles del proyecto ( comprensin del dominio del problema) Los patrones de diseo pueden incrementar o disminuir la capacidad de comprensin de un diseo o de una implementacin,

 que familias de patrones de diseo utilizaremos?

Para este curso, usaremos dos familias de patrones de diseo propuestos en la bibliografa sugerida. Cabe destacar que existen muchas familias de patrones de diseo, por lo que nos basaremos en los mas usados, en funcin del objetivo que nos hemos planteado en este curso. Las familias sern GRASP Y GAO

Descripcin de familias de patrones

GRASP : son patrones generales de software para asignacin de responsabilidades, es el acrnimo de "General Responsibility Assignment Software Patterns" . son una serie de "buenas prcticas" de aplicacin recomendable en el diseo de software. Patrones GRASP; Experto , Creador , Bajo Acoplamiento ,Alta Cohesin ,Controlador

Descripcin de familias de patrones

GOF: Es la abreviacin del grupo Gang of Four, compuesto por Erich Gamma, Richard Helm, Ralph Jhonson y John Vlisides, quienes en su publicacin Design Patterns ( dcada de los 90s), describen 23 patrones de diseo comnmente utilizados y de gran aplicabilidad en problemas de diseo usando modelamiento UML. Estos patrones se agrupan en las siguientes categoras : Creacionales, estructurales y de comportamiento.

Relacin de familias de patrones de diseo

Experto Creador GRASP
Bajo acoplamiento

Alta Cohesin

PATRONES

Controlador

Creacionales
GOF Estructurales
Comportamiento

Fabrica, constructor, mtodo de fabricacin, prototipo , instancia nica

Adaptador, puente, objeto Compuesto, envoltorio, fachada, Peso ligero, proxy
Cadena responsabilidad, orden, Intrprete, iterador, mediador, recuerdo, Observador, estado, estrategia, mtodo plantilla, visitante

Patrones GRASP

Experto
El GRASP de experto en informacin es el principio bsico de asignacin de responsabilidades en diseo O.O. Nos indica que la responsabilidad de la creacin de un objeto debe recaer sobre la clase que conoce toda la informacin necesaria para crearlo. Ntese, que el cumplimiento de una responsabilidad requiere a menudo informacin distribuida en varias clases de objetos.

Ejemplo del patrn experto

Ejemplo En la aplicacin del punto de venta, alguna clase necesita conocer el gran total de la venta. Comience asignando las responsabilidades con una definicin clara de ellas. A partir de esta recomendacin se plantea la pregunta: Quin es el responsable de conocer el gran total de la venta? Desde el punto de vista del patrn Experto, deberamos buscar la clase De objetos que posee la informacin necesaria para calcular el total. En conclusin, para cumplir con la responsabilidad de conocer y dar el total de la venta, se asignaron tres responsabilidades a las tres clases de objeto as: Venta ( conoce total de la venta) Ventaslineaproductos ( conoce subtotal de la linea de productos) Especificaciondeproducto (conoce el precio del producto)

Creador
El patrn creador nos ayuda a identificar quin debe ser el responsable de la creacin (o instanciacin) de nuevos objetos o clases. El patrn Creador gua la asignacin de responsabilidades relacionadas con la creacin de objetos, tarea muy frecuente en los sistemas orientados a objetos. El propsito fundamental de este patrn es encontrar un creador que debemos conectar con el objeto producido en cualquier evento. Al escogerlo como creador, se da soporte al bajo acoplamiento.

Ejemplo patrn creador

Ejemplo En la aplicacin del punto de venta, quin Debera encargarse de crear una Instancia VentasLineadeProducto? Desde el punto de vista del patrn Creador, deberamos buscar una clase que agregue, contenga y realice otras operaciones sobre este tipo de instancias
Una Venta contiene (en realidad, agrega) muchos objetos VentasLineadeProducto; por ello, el patrn Creador sugiere que Venta es idnea para asumir la responsabilidad de crear las instancias VentasLineadeProducto. Esta asignacin de responsabilidades requiere definir en Venta un mtodo de hacer-LineadeProducto.

Bajo acoplamiento
Es la idea de tener las clases lo menos ligadas entre s que se pueda. De tal forma que en caso de producirse una modificacin en alguna de ellas, se tenga la mnima repercusin posible en el resto de clases, potenciando la reutilizacin, y disminuyendo la dependencia entre las clases Los beneficios de este factor es que no se afectan por cambios de otros componentes, son fciles de entender por separado y fciles de reutilizar.

Ejemplo bajo acoplamiento

Ejemplo: En el caso del punto de Ventas se tienen tres clases Pago, TPDV y Venta y se quiere crear una instancia de Pago y asociarla a Venta. Que clase es la responsable de realizarlo? Segn el patrn de Bajo Acoplamiento la relacin debera ser a travs de TPDV.
Esta ltima asociacin es mejor Dado que Venta realiza la creacin del Pago y no TPDV por lo tanto se reduce la dependencia

de este ltimo con el resto de las clases.

Alta Cohesin
Nos dice que la informacin que almacena una clase debe de ser coherente y est en la mayor medida de lo posible relacionada con la clase. La cohesin es una medida de cun relacionadas y enfocadas estn las responsabilidades de una clase. Una clase con alta cohesin, compartir la responsabilidad de una operacin, con otras clases Una clase con baja cohesin, concentrar las responsabilidades de una o muchas operaciones .

Ejemplo alta cohesin

Ejemplo: En el caso del punto de ventas se tienen tres clases Pago, TPDV y Venta y se quiere crear una instancia de Pago y asociarla a Venta.
Este diseo delega a Venta la responsabilidad de crear el pago. Este diseo es conveniente ya que da soporte a una alta cohesin y a un bajo acoplamiento.

Qu pasa si el sistema tiene 50 operaciones, todas recibidas por la clase TPDV ? La clase se ira saturando con tareas y terminara perdiendo la cohesin

Controlador
El patrn controlador es un patrn que sirve como intermediario entre una determinada interfaz y el algoritmo que la implementa, de tal forma que es la que recibe los datos del usuario y la que los enva a las distintas clases segn el mtodo llamado. Este patrn sugiere que la lgica de negocios debe estar separada de la capa de presentacin, esto para aumentar la reutilizacin de cdigo y a la vez tener un mayor control. Un Controlador es un objeto de interfaz no destinada al usuario que se encarga de manejar un evento del sistema. Define adems el mtodo de su operacin.

Ejemplo de controlador
Por ejemplo, cuando un cajero que usa un sistema de Terminal en el punto de venta oprime el botn "Terminar Venta, est generando un evento sistmico que indica que la venta ha terminado
Ntese que la clase TPDVApplet - parte de la capa de presentacin - transmite un mensaje introducirProducto al objeto TPDV. ?No intervino en el proceso de la operacin, ni la decisin de cmo manejarla, el applet se limit a delegarla a la capa del dominio.

Patrones GOF

Creacionales
1.-Fabrica abstracta (Abstract Factory) : Proporciona un interfaz para crear las familias de objetos relacionados o dependientes sin especificar sus clases concretas. 2.-Constructor (Builder): Separa la construccin de un objeto complejo de su representacin , de modo que el mismo proceso de construccin pueda crear representaciones diferentes. 3.-Mtodo fabricacin(Factory Method) : Define un interfaz para crear un objeto, pero dejar a subclases decidir sus instancias . El Mtodo De la fbrica deja a una clase la creacin de ejemplares o copias a subclases. 4.-Prototipo(Prototype) : Crea nuevos objetos crendolos de una instancia ya existente. 5.-Instancia nica (Singleton) : Asegure que una clase slo tiene una instancia , y proporcionarle un punto global de acceso a dicha instancia

Estructurales
6.-Adaptador (adapter) :Convierte la interfaz de una clase en otra interfaz que otra clase puede usar . debido a que la interfaces es incompatibles con dicha clase 7.-Puente ( bridge) :Desacopla una abstraccin de su implementacin de modo que los dos puedan variar por separado. 8.-Peso ligero (Flyweight ) :Reduce la redundancia cuando gran cantidad de objetos poseen idntica informacin. 9.-Fachada (Facade) : Proporciona un interfaz unificada a un juego de interfaces en un subsistema. La fachada define un interfaz de nivel ms alto que hace el subsistema fcil de usar. 10.-Envoltorio (Decorator) :Adjunta responsabilidades adicionales a un objeto dinmicamente. Los decoradores proporcionan una alternativa flexible a la subclasificacin para ampliar la funcionalidad. 11.-Objeto compuesto (Composite) :El objeto compuesto permite tratar a jerarquas de objetos en individuales y composiciones de objetos uniformemente como si se tratase de objetos simples 12.-Proxy : Mantiene un representante de un objeto

Comportamiento
13.-Cadena responsabilidad (Chain of Responsibility ): Encadena los objetos de encubrimiento y pasa la peticin a lo largo de la cadena hasta que un objeto la maneja. Permite establecer la lnea que deben llevar los mensajes para que los objetos realicen la tarea indicada. 14.-Orden (Command) : Encapsula una operacin en un objeto, permitiendo ejecutar dicha operacin sin necesidad de conocer el contenido de la misma. 15.-Intrprete (Interpreter) :Considerando un lenguaje , define un representacin para su gramtica con un intrprete que usa la representacin para interpretar sentencias en el mismo lenguaje. 16.-Iterador (Iterator) :Proporciona un modo de tener acceso a los elementos de un objeto agregado secuencialmente sin exponer su representacin subyacente. 17.-Mediador (Mediator) :Define un objeto que coordine la comunicacin entre objetos de distintas clases, pero que funcionan como un conjunto. 18.-Recuerdo (Memento) : Sin violar encapsulacin, captura y externaliza el estado interno de un objeto de modo que el objeto pueda ser restaurado a este estado ms tarde.

Comportamiento
19.-Observador (Observer) : Define de uno a varios la dependencia entre objetos de modo que cuando se produce un cambio de estado del objeto, todos sus dependientes sean notificados y puestos al da automticamente. 20-Estado (State) :Permite que un objeto modifique su comportamiento cada vez que cambie su estado interno 21.-estrategia (Strategy) : Define una familia de algoritmos ( mtodos ), encapsula cada uno, y los hace permutables. La estrategia deja al algoritmo ( mtodo ) variar por separado de los clientes ( objetos ) que lo usan o invocan . 22.-mtodo plantilla ( template method) :Define el esqueleto de un algoritmo en una operacin, aplazando algunos pasos a subclases. El Mtodo de Plantilla deja a subclases redefinir los ciertos pasos de un algoritmo sin cambiar la estructura del algoritmo. 23.-Visitante (Visitor) :Permite definir nuevas operaciones sobre una jerarqua de clases sin modificar las clases sobre las que opera.

Patrones gof

Fabrica abstracta

constructor

Patrones gof

Mtodo de fabricacin

prototipo

Patrones gof

Instancia nica

adaptador

Patrones gof

Puente

Peso ligero

Patrones gof

decorador

Fachada

Patrones gof

proxy

Objeto compuesto

Patrones gof

Cadena de responsabilidad

Orden

Patrones gof

iterador

mediador

Patrones gof

observador

plantilla

Patrones gof

Visitador

Bibliografa
UML y patrones ;Craig Larman. Desingn Patterns; Gamma, Helm,johnson,vlissides. Wikipedia, Internet.