1. Metodologías de Análisis y Diseño Unidad VII Diseño O.O – Diagramas de Interacción “ Patrones de Diseño” Sergio Sánchez Rios. Ingeniero en Informática – Licenciado en Informática Docente Jornada Parcial Universidad Viña del Mar

2. Diagramas de Interacción GRASP – Patrones de asignación de Responsabilidades Patrones Los diseñadores expertos en orientación a objetos, van formando un amplio repertorio de principios generales que los guían al crear software. Estos principios son llamados Patrones. Los patrones se codifican en un formato estructurado que describe el problema y su solución . Cada patrón tiene un nombre. Los patrones no se proponen descubrir ni expresar principios nuevos en Ingeniería de Software. Todo lo contrario, intentan codificar el conocimiento y los principios ya existentes: cuanto más generalizados y usados mejor.

3. Diagramas de Interacción Patrones En consecuencia, los patrones GRASP no establecen nuevas ideas: son una codificación de principios básicos ampliamente utilizados. Para un experto en objetos, los patrones GRASP – por su idea y por su nombre – parecerán muy elementales y familiares. ¡Eso es lo importante!. GRASP – Patrones de asignación de Responsabilidades

5. Diagramas de Interacción GRASP Es importante entender y ser capaz de aplicar estos principios durante la creación de los diagramas de interacción porque un desarrollador de software con poca experiencia en la tecnología de objetos necesita dominar estos principios tan rápido como sea posible; constituyen la base de cómo diseñara el sistema. GRASP es un acrónimo de G eneral R esponsibility A ssignment S oftware P atterns (patrones generales de software para asignar responsabilidades). GRASP – Patrones de asignación de Responsabilidades

6. Diagramas de Interacción El patrón Experto [Larman 98] Principales Patrones - GRASP Experto Nombre Asignar una responsabilidad al experto en información: la clase que cuenta con la información necesaria para cumplir la responsabilidad. Solución ¿Cuál es el principio fundamental en virtud del cual se asignan las responsabilidades en el diseño O.O? Un modelo de clases puede definir n clases de software, y una aplicación tal vez requiera el cumplimiento de n responsabilidades. Durante el Diseño O.O, cuando se definen las interacciones entre los objetos se toman decisiones sobre la asignación de responsabilidades a clases. Si se hacen en forma adecuada, los sistemas tienden a ser más fáciles de entender, mantener y ampliar, y nos presentan la oportunidad de reutilizar componentes en futuras aplicaciones. Problema

7. Diagramas de Interacción El patrón Experto [Larman 98] Principales Patrones - GRASP En la aplicación del punto de venta, alguna clase necesita conocer el gran total de venta. Ejemplo -Se conserva el encapsulamiento , ya que los objetos se valen de su propia información para hacer lo que se les pide. Esto provee un bajo nivel acoplamiento , lo que favorece al hecho de tener sistemas mas robustos y fáciles de mantener. -El comportamiento se distribuye entre las clases que cuentan con la información requerida, lo que ayuda a definir “clases sencillas” y más cohesivas , que son mas faciles de comprender y mantener. Beneficios

8. Diagramas de Interacción El patrón Experto [Larman 98] (Ejemplo) Para el ejemplo del Punto de Venta. ¿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. Por ejemplo: Principales Patrones - GRASP

9. Diagramas de Interacción El patrón Experto [Larman 98] (Ejemplo) ¿Qué información hace falta para calcular el gran total?. Hay que conocer todas las instancias VentaLineadeProducto de una venta, y la suma de sus subtotales, y esto lo conoce únicamente la instancia Venta. Por tanto, desde el punto de vista del Experto, Venta es la clase de objetos correcta para asumir esta responsabilidad. Venta es el experto de información. Principales Patrones - GRASP

10. Diagramas de Interacción El patrón Experto [Larman 98] (Ejemplo) Todavía no terminamos. ¿Qué información hace falta para determinar el subtotal de la línea de productos?. Se necesitan VentasLineasProducto.cantidad y EspecificacióndeProductos.precio . VentasLineaProducto conoce su cantidad y su correspondiente EspecificaciondeProducto . Por tanto, desde la perspectiva patrón experto, VentasLineaProducto debería calcular el subtotal Principales Patrones - GRASP

11. Diagramas de Interacción El patrón Experto [Larman 98] (Ejemplo) VentasLineaProducto no puede cumplir la responsabilidad de conocer y dar el subtotal, si no conoce el precio del producto. EspecificaciondeProducto es un Experto de información para contestar su precio. Por tanto, habrá que enviarle un mensaje preguntándole el precio. Principales Patrones - GRASP

12. Diagramas de Interacción El patrón Experto [Larman 98] (Ejemplo) En conclusión, para cumplir con la responsabilidad de conocer y dar el total de venta, se asignaron responsabilidades a tres clases de objetos: El cumplimiento de una responsabilidad requiere a menudo información distribuida en varias clases de objetos. (“Expertos Parciales” que colaboran en la tarea). Principales Patrones - GRASP Conoce el precio del producto EspecificacióndeProducto Conoce subtotal de la línea de producto VentasLineadeProducto Conocer Total de la Venta Venta Responsabilidad Clase

13. Diagramas de Interacción El patrón Creador [Larman 98] 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 objetivo de este patrón es encontrar un creador que debemos conectar con el objeto producido en cualquier evento. Principales Patrones - GRASP

14. Diagramas de Interacción El patrón Creador [Larman 98] Principales Patrones - GRASP Creador Nombre Asignar a la clase B la responsabilidad de crear una instancia de la clase A en uno de los siguientes casos: Solución ¿Quién debería ser responsable de crear una nueva instancia de alguna clase? La creación de objetos es una de las actividades más frecuentes en un sistema orientado a objetos. En consecuencia, conviene contar con un principio general para asignar las responsabilidades concernientes a ella. El diseño, bien asignado, puede apoyar un bajo acoplamiento, una mayor claridad, el encapsulamiento y la reutilización. Problema

16. Diagramas de Interacción El patrón Creador [Larman 98] (Ejemplo) En la aplicación del punto de venta ¿quién debería encargarse de crear una instancia de 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 (en realidad, agrega) muchos objetos VentasLIneadeProducto. Es por esto que Venta es la clase idónea para asumir la responsabilidad de crear las instancias de VentaLineadeProducto. Esta asignación de responsabilidad requiere definir en Venta un método para hacerLineadeProducto. Principales Patrones - GRASP

17. Diagramas de Interacción El patrón Creador [Larman 98] (Ejemplo) Principales Patrones - GRASP

18. Diagramas de Interacción El patrón Controlador Principales Patrones - GRASP Controlador Nombre ¿Quién debería encargarse de atender un nuevo evento del sistema? Un evento del sistema es un evento de alto nivel generado por un actor externo. Es un evento de entrada externa. Se asocia a operaciones del sistema: las que se emiten en respuesta a los eventos del sistema. Por ejemplo: cuando un cajero que usa una terminal de punto de venta oprime el botón “terminar Venta”, está generando un evento sistematico que indica que la “venta a terminado”. Un controlador es un objeto de interfaz que se encarga de manejar un evento del sistema. Define además el método de su operación. Problema

19. Diagramas de Interacción El patrón Controlador Principales Patrones - GRASP En la aplicación del punto de venta se dan varias operaciones del sistema, como terminarVenta(), pasarProducto(), efectuarPago(). Ejemplo Asignar la responsabilidad del manejo de mensajes de los eventos del sistema a una clase que represente alguna de las siguientes opciones: -El “sistema” global (controlador de fachada) -La empresa u organización global (controlador de fachada) -Algo en el mundo real que es activo (por ejemplo el rol de una persona) y que puede participar en la tarea (controlador de tareas). -Un manejador artificial de todos los eventos del sistema de un caso de uso (controlador de casos de uso). Utilice la misma clase controlador con todos los eventos del sistema en el mismo caso de uso. Solución Garantiza que la empresa o los procesos de dominio sean manejados por la capa de los objetos del dominio y no por la interfaz. Beneficios

20. El patrón Controlador (Ejemplo) Durante el análisis del comportamiento del sistema, sus operaciones son asignada al tipo de Sistema, para indicar que son operaciones del Sistema. Pero esto no significa que una clase llamada Sistema las ejecute durante el diseño. Durante el diseño, a la clase Controlador se le asigna la responsabilidad de las operaciones del sistema. Diagramas de Interacción Principales Patrones - GRASP

21. Diagramas de Interacción El patrón Controlador (Ejemplo) ¿Quien debería ser el Controlador de eventos sistemáticos como pasarProducto y terminarVenta? Según el patrón Controlador, disponemos de las siguientes opciones: Principales Patrones - GRASP Representa un manejador artificial de todas las operaciones del sistema de un caso de uso. ManejadordeComprarProducto Representa algo en el mundo real que está activo y que puede intervenir en la tarea Cajero Representa la empresa u organización Tienda Representa al “sistema” global TPDV (Registro)

22. Diagramas de Interacción El patrón Controlador (Ejemplo) Mensaje de evento del sistema Principales Patrones - GRASP :Cajero Articulo ID Cantidad Introducir Articulo Etc... Presiona Botón : JFrameVenta actionPerfomed(actionEvent) Capa Interfaz :??????? Capa Dominio introducirArticulo(articuloID,cant)

23. Diagramas de Interacción El patrón Controlador (Ejemplo) Durante el diseño, se asignan a una o más clases controlador las operaciones del sistema que se identificaron durante el análisis del comportamiento del sistema, como Registro Principales Patrones - GRASP :ProcesarVentaManejador IntroduccirArticulo(id,cantidad) : Registro IntroduccirArticulo(id,cantidad)

24. Diagramas de Interacción El patrón Controlador (Ejemplo) La primera categoría de controladores es un controlador de Fachada, que representa al “sistema” global. Es un clase, que para el diseñador, representa de alguna manera el diseño completo. Si se recurre a la cuarta categoría de controlador (un “manejador artificial de casos de uso”), habrá entonces un controlador para cada caso. Este no es un objeto del dominio, es un concepto artificial. Por ejemplo, si la aplicación de punto de venta contiene casos como “Comprar Productos” y “Devolver Productos”, habrá un ManejadordeComprarProductos y una clase ManejadordeDevolverProductos. Principales Patrones - GRASP

25. Diagramas de Interacción El patrón Controlador (Ejemplo) Un controlador de casos de uso es una buena alternativa cuando hay muchos eventos de sistema entre varios procesos: asigna su manejo a clases individuales controlables. Principales Patrones - GRASP

26. Diagramas de Interacción El patrón Bajo Acoplamiento [Larman 98] Principales Patrones - GRASP ¿Cómo dar soporte a una mínima dependencia y aún aumento en la reutilización? El acoplamiento mide qué tan fuerte está una clase conectada con otras (es decir, cuántas clases conoce y necesita). Una clase con bajo o débil acoplamiento no depende de muchas otras clases. Una clase con alto (o fuerte) acoplamiento recurre a muchas otras clases. Este tipo de clase no es conveniente, pues: cambios en las clases relacionadas ocasionan cambios en la clase local; son más difíciles de entender; son más difíciles de reutilizar. Problema Bajo Acoplamiento Nombre Asignar una responsabilidad para mantener bajo acoplamiento. Solución

27. Diagramas de Interacción El patrón Bajo Acoplamiento [Larman 98] Principales Patrones - GRASP -No afecta los cambios en otros componentes. -Fácil de entender de manera aislada. -Conveniente para reutilizar. Beneficios

28. Diagramas de Interacción El patrón Bajo Acoplamiento [Larman 98] (Ejemplo) Tres de las clases de aplicación de punto de venta era: Pago, TPV y Venta. Supongamos que necesitamos crear una instancia de Pago y asociarla a Venta. Como TPV “registra” un pago en el mundo real, es un buen candidato para crearlo. Está asignación de responsabilidades acopla la clase TPV al conocimiento de la clase Pago. Principales Patrones - GRASP

29. Diagramas de Interacción El patrón Bajo Acoplamiento [Larman 98] (Ejemplo) Una solución alterna sería crear Pago y asociarlo a la Venta. Este último diseño es mejor porque conserva un menor acoplamiento global. El ejemplo es una situación donde patrones distintos (Bajo Acoplamiento y Creador) pueden surgir decisiones distintas. Principales Patrones - GRASP

31. Diagramas de Interacción El patrón Bajo Acoplamiento [Larman 98] (Ejemplo) El bajo acoplamiento apoya al diseño de clases mas independientes, que reduce el impacto de los cambios, así como clases más reutilizables. El acoplamiento no es importante sino se busca la reutilización. Principales Patrones - GRASP

32. Diagramas de Interacción El patrón Alta Cohesión Principales Patrones - GRASP ¿Cómo mantener la complejidad manejable? En cuanto al diseño de objetos, la cohesión (o de manera más especifica la cohesión funcional) es una medida de fuerza con la que se relacionan y del grado de focalización de las responsabilidades de un elemento. Un elemento con responsabilidad altamente relacionada, y que no hace una gran cantidad de trabajo, tiene alta cohesión. A menudo, las clases con baja cohesión representan un “grano grande” de abstracción, o se les ha asignado responsabilidades que debería haberse delegado en otros objetos. Problema Alta Cohesión Nombre Asignar una responsabilidad de manera que la cohesión permanezca alta. Solución

33. Diagramas de Interacción El patrón Alta Cohesión Como regla empírica, una clase con alta cohesión tiene un número relativamente pequeño de métodos, con funcionalidades altamente relacionada, y no realiza mucho trabajo. Colabora con otros objetos para compartir el esfuerzo si la tarea es extensa. Principales Patrones - GRASP -Se incrementa la claridad y facilita la comprensión del diseño. -Se simplifica el mantenimiento y las mejoras. -Se soporta a menudo bajo acoplamiento. -El grano fino de funcionalidad altamente relacionada incrementa la reutilización porque una clase cohesiva se puede utilizar para un propósito muy especifico. Beneficios