Uso de patrones de arquitectura

1. Uso de patrones de arquitectura Profesor Pedro Veloso Hernández Master Ingeniería de Software UPM

2. ¿ que es un Patrón de diseño? • Los patrones de diseño (design patterns) son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces. • Un patrón de diseño es una solución a un problema de diseño. • Para que una solución sea considerada un patrón debe poseer ciertas características. 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 diseño en distintas circunstancias. Fuente Wikipedia "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 Los escaladores usan a menudo patrones de diseño, 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.

3. ¿ que es un patrón 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 reutilización y desarrollo robusto. • A medida que los patrones se descubren en todo nuevo proyecto, se puede reutilizar la plantilla básica del patrón desde modelos previos con los nombres de las variables apropiadas modificados para el proyecto en curso. "Cada patrón describe un problema que ocurre infinidad de veces en nuestro entorno , así como la solución al mismo, de tal modo que podemos utilizar esta solución un millón de veces más adelante sin tener que volver a pensarla otra vez."

4. Condiciones para usar un patrón UML • Los patrones generalmente describen cómo resolver un problema abstracto y la tarea del usuario del patrón consiste en modificar los elementos del patrón para cumplir las demandas del compromiso actual. • Antes de comenzar a usar un patrón primero debe ser creado como un diagrama estándar de  UML o existir como tal en algún repositorio

5. Vamos a un ejemplo Este es un ejemplo de patrones de diseño propuesto en GOF “ Abstract Factory” patrones descriptos en el libro "Design Patterns - Elements of Reusable Object-Oriented Software" de Gamma et al., más conocidos como 'La Banda de los Cuatro', 'Gang of Four‘ o GoF en forma abreviada.

6. Cuando “ no” usar patrones de diseño • Del mismo modo que no es aconsejable optimizar prematuramente, no se deben utilizar patrones de diseño antes de tiempo. • Seguramente sea mejor implementar algo primero y asegurarse de que funciona, para luego utilizar el patrón de diseño para mejorar las flaquezas; esto es cierto, sobre todo, cuando aún no ha identificado todos los detalles del proyecto ( comprensión del dominio del problema) • Los patrones de diseño pueden incrementar o disminuir la capacidad de comprensión de un diseño o de una implementación,

7. ¿ que familias de patrones de diseño utilizaremos? • Para este curso, usaremos dos familias de patrones de diseño propuestos en la bibliografía sugerida. Cabe destacar que existen muchas familias de patrones de diseño, por lo que nos basaremos en los mas usados, en función del objetivo que nos hemos planteado en este curso. • Las familias serán GRASP Y GAO

8. Descripción de familias de patrones • GRASP :son patrones generales de software para asignación de responsabilidades, es el acrónimo de "General Responsibility Assignment Software Patterns" . • son una serie de "buenas prácticas" de aplicación recomendable en el diseño de software. • Patrones GRASP; Experto , Creador , Bajo Acoplamiento ,Alta Cohesión ,Controlador

9. Descripción de familias de patrones • GOF: Es la abreviación del grupo Gang of Four, compuesto por Erich Gamma, Richard Helm, Ralph Jhonson y John Vlisides, quienes en su publicación “ Design Patterns” ( década de los 90s), describen 23 patrones de diseño comúnmente utilizados y de gran aplicabilidad en problemas de diseño usando modelamiento UML. • Estos patrones se agrupan en las siguientes categorías : Creacionales, estructurales y de comportamiento.

10. Relación de familias de patrones de diseño Experto Creador GRASP Bajo acoplamiento Alta Cohesión PATRONES Controlador Fabrica, constructor, método de fabricación, prototipo , instancia única Creacionales GOF Estructurales Adaptador, puente, objeto Compuesto, envoltorio, fachada, Peso ligero, proxy Cadena responsabilidad, orden, Intérprete, iterador, mediador, recuerdo, Observador, estado, estrategia, método plantilla, visitante Comportamiento

11. Patrones GRASP

12. Experto • El GRASP de experto en información es el principio básico de asignación de responsabilidades en diseño O.O. • Nos indica que la responsabilidad de la creación de un objeto debe recaer sobre la clase que conoce toda la información necesaria para crearlo. • Nótese, que el cumplimiento de una responsabilidad requiere a menudo información distribuida en varias clases de objetos.

13. Ejemplo del patrón experto Ejemplo En la aplicación del punto de venta, alguna clase necesita conocer el gran total de la venta. Comience asignando las responsabilidades con una definición clara de ellas. A partir de esta recomendación se plantea la pregunta: ¿Quién es el responsable de conocer el gran total de la venta? Desde el punto de vista del patrón Experto, deberíamos buscar la clase De objetos que posee la información necesaria para calcular el total. En conclusión, 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)

14. Creador • El patrón creador nos ayuda a identificar quién debe ser el responsable de la creación (o instanciación) de nuevos objetos o clases. • El patrón Creador guía la asignación de responsabilidades relacionadas con la creación de objetos, tarea muy frecuente en los sistemas orientados a objetos. • El propósito fundamental de este patrón es encontrar un creador que debemos conectar con el objeto producido en cualquier evento. • Al escogerlo como creador, se da soporte al bajo acoplamiento.

15. Ejemplo patrón creador Ejemplo En la aplicación del punto de venta, ¿quién Debería encargarse de crear una Instancia VentasLineadeProducto? Desde el punto de vista del patrón Creador, deberíamos 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 patrón Creador sugiere que Venta es idónea para asumir la responsabilidad de crear las instancias VentasLineadeProducto. Esta asignación de responsabilidades requiere definir en Venta un método de hacer-LineadeProducto.

16. 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 modificación en alguna de ellas, se tenga la mínima repercusión posible en el resto de clases, potenciando la reutilización, y disminuyendo la dependencia entre las clases • Los beneficios de este factor es que no se afectan por cambios de otros componentes, son fáciles de entender por separado y fáciles de reutilizar.

17. 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? Según el patrón de Bajo Acoplamiento la relación debería ser a través de TPDV. Esta última asociación es mejor Dado que Venta realiza la creación del Pago y no TPDV por lo tanto se reduce la dependencia de este último con el resto de las clases.

18. Alta Cohesión • Nos dice que la información que almacena una clase debe de ser coherente y está en la mayor medida de lo posible relacionada con la clase. • La cohesión es una medida de cuán relacionadas y enfocadas están las responsabilidades de una clase. • Una clase con alta cohesión, compartirá la responsabilidad de una operación, con otras clases • Una clase con baja cohesión, concentrará las responsabilidades de una o muchas operaciones .

19. Ejemplo alta cohesión 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. ¿Qué pasa si el sistema tiene 50 operaciones, todas recibidas por la clase TPDV ? La clase se iría saturando con tareas y terminaría perdiendo la cohesión Este diseño delega a Venta la responsabilidad de crear el pago. Este diseño es conveniente ya que da soporte a una alta cohesión y a un bajo acoplamiento.

20. Controlador • El patrón controlador es un patrón 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 envía a las distintas clases según el método llamado. • Este patrón sugiere que la lógica de negocios debe estar separada de la capa de presentación, esto para aumentar la reutilización de código 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 además el método de su operación.

21. Ejemplo de controlador Por ejemplo, cuando un cajero que usa un sistema de Terminal en el punto de venta oprime el botón "Terminar Venta”, está generando un evento sistémico que indica que “la venta ha terminado Nótese que la clase TPDVApplet - parte de la capa de presentación - transmite un mensaje introducirProducto al objeto TPDV. ?No intervino en el proceso de la operación, ni la decisión de cómo manejarla, el applet se limitó a delegarla a la capa del dominio.

22. Patrones GOF

23. 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 construcción de un objeto complejo de su representación , de modo que el mismo proceso de construcción pueda crear representaciones diferentes. • 3.-Método fabricación(Factory Method) : Define un interfaz para crear un objeto, pero dejar a subclases decidir sus instancias . El Método De la fábrica deja a una clase la creación de ejemplares o copias a subclases. • 4.-Prototipo(Prototype) : Crea nuevos objetos creándolos de una instancia ya existente. • 5.-Instancia única (Singleton) : Asegure que una clase sólo tiene una instancia , y proporcionarle un punto global de acceso a dicha instancia

24. 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 abstracción de su implementación de modo que los dos puedan variar por separado. • 8.-Peso ligero (Flyweight ) :Reduce la redundancia cuando gran cantidad de objetos poseen idéntica información. • 9.-Fachada (Facade) : Proporciona un interfaz unificada a un juego de interfaces en un subsistema. La fachada define un interfaz de nivel más alto que hace el subsistema fácil de usar. • 10.-Envoltorio (Decorator) :Adjunta responsabilidades adicionales a un objeto dinámicamente. Los decoradores proporcionan una alternativa flexible a la subclasificación para ampliar la funcionalidad. • 11.-Objeto compuesto (Composite) :El objeto compuesto permite tratar a jerarquías de objetos en individuales y composiciones de objetos uniformemente como si se tratase de objetos simples • 12.-Proxy : Mantiene un representante de un objeto

25. Comportamiento • 13.-Cadena responsabilidad (Chain of Responsibility ):Encadena los objetos de encubrimiento y pasa la petición a lo largo de la cadena hasta que un objeto la maneja. Permite establecer la línea que deben llevar los mensajes para que los objetos realicen la tarea indicada. • 14.-Orden (Command) :Encapsula una operación en un objeto, permitiendo ejecutar dicha operación sin necesidad de conocer el contenido de la misma. • 15.-Intérprete (Interpreter) :Considerando un lenguaje , define un representación para su gramática con un intérprete que usa la representación 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 representación subyacente. • 17.-Mediador (Mediator) :Define un objeto que coordine la comunicación entre objetos de distintas clases, pero que funcionan como un conjunto. • 18.-Recuerdo (Memento) : Sin violar encapsulación, captura y externaliza el estado interno de un objeto de modo que el objeto pueda ser restaurado a este estado más tarde.

26. 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 día automáticamente. • 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 ( métodos ), encapsula cada uno, y los hace permutables. La estrategia deja al algoritmo ( método ) variar por separado de los clientes ( objetos ) que lo usan o invocan . • 22.-método plantilla ( template method) :Define el esqueleto de un algoritmo en una operación, aplazando algunos pasos a subclases. El Método 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 jerarquía de clases sin modificar las clases sobre las que opera.

27. Patrones gof constructor Fabrica abstracta

28. Patrones gof prototipo Método de fabricación

29. Patrones gof adaptador Instancia única

30. Patrones gof Peso ligero Puente

31. Patrones gof decorador Fachada

32. Patrones gof proxy Objeto compuesto

33. Patrones gof Orden Cadena de responsabilidad

34. Patrones gof mediador iterador

35. Patrones gof observador plantilla

36. Patrones gof Visitador

37. Bibliografía • UML y patrones ;Craig Larman. • Desingn Patterns; Gamma, Helm,johnson,vlissides. • Wikipedia, Internet.