Gonzalorojas 12 Uml, Patrones De Diseno

4,763 views
4,417 views

Published on

Realizadas por Gonzalo Rojas

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
4,763
On SlideShare
0
From Embeds
0
Number of Embeds
67
Actions
Shares
0
Downloads
256
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Gonzalorojas 12 Uml, Patrones De Diseno

    1. 1. UML: Patrones para asignación de responsabilidades Gonzalo Rojas D.
    2. 2. Introducción <ul><li>Funcionalidad de Sistemas Orientados a Objetos está definida por los mensajes entre objetos para realizar operaciones </li></ul><ul><li>Una adecuada asignación de responsabilidades entre objetos contribuye al desarrollo de sistemas robustos </li></ul><ul><li>Se vela por el cumplimiento de los conceptos fundamentales de la Orientación a Objetos. </li></ul>
    3. 3. What are patterns? <ul><li>Principles and solutions codified in a structured format describing a problem and a solution </li></ul><ul><li>A named problem/solution pair that can be applied in new contexts </li></ul><ul><li>It is advice from previous designers to help designers in new situations </li></ul>
    4. 4. Some definitions of design patterns <ul><li>“ Design patterns constitute a set of rules describing how to accomplish certain tasks in the realm of software development.” (Pree, 1994) </li></ul><ul><li>“ Design patterns focus more on reuse of recurring architectural design themes, while frameworks focus on detailed design… and implementation.” (Coplien & Schmidt, 1995). </li></ul><ul><li>“ A pattern addresses a recurring design problem that arises in specific design situations and presents a solution to it” (Buschmann, et. al. 1996) </li></ul><ul><li>“ Patterns identify and specify abstractions that are above the level of single classes and instances , or of components.” (Gamma, et al., 1993) </li></ul>
    5. 5. GRASP patterns General Responsibility Assignment Software Patterns <ul><li>Expert </li></ul><ul><li>Creator </li></ul><ul><li>Low Coupling </li></ul><ul><li>High Cohesion </li></ul><ul><li>Controller </li></ul><ul><li>Polymorphism </li></ul><ul><li>Pure Fabrication </li></ul><ul><li>Indirection </li></ul><ul><li>Law of Demeter </li></ul>
    6. 6. Experto en Información <ul><li>Problema : </li></ul><ul><li>¿Cuál es el principio general para asignar responsabilidades a los objetos? </li></ul><ul><li>¿Quién debiera ser el responsable de conocer la información? </li></ul><ul><li>Solución : </li></ul><ul><li>Asignar una responsabilidad a la clase que tiene la información necesaria para cumplir la responsabilidad (experto) </li></ul>
    7. 7. Experto: Ejemplo <ul><li>¿Quién es el responsable de conocer el monto total de la venta? </li></ul>
    8. 8. Experto: Ejemplo <ul><li>¿Qué información necesito? </li></ul><ul><ul><li>Todas las Líneas de Producto de la Venta y sus respectivos subtotales </li></ul></ul><ul><li>¿De qué clase del Esquema Conceptual puedo obtener esa información? </li></ul>
    9. 9. Experto: Ejemplo <ul><li>¿Y los respectivos subtotales (cantidad x precio) de cada Línea de Producto? </li></ul><ul><li>¿Y el precio de cada Producto? </li></ul>
    10. 11. Experto <ul><li>Mantiene el encapsulamiento de la información </li></ul><ul><li>Favorece el bajo acoplamiento </li></ul><ul><li>Puede originar clases excesivamente complejas </li></ul>
    11. 12. Creador <ul><li>Problema : </li></ul><ul><li>¿Quién debiera ser el responsable de la creación de una nueva instancia de alguna clase? </li></ul><ul><li>Solución : </li></ul><ul><li>B es un Creador de A si se cumple uno o más de las siguientes condiciones: </li></ul><ul><ul><li>B agrega objetos de A </li></ul></ul><ul><ul><li>B contiene objetos de A </li></ul></ul><ul><ul><li>B registra objetos de A </li></ul></ul><ul><ul><li>B utiliza intensivamente objetos de A </li></ul></ul><ul><ul><li>B tiene los datos de inicialización de objetos de A (B es Experto en la creación de A) </li></ul></ul>
    12. 13. Creador: Ejemplo
    13. 14. Creador <ul><li>La intención básica del patrón es encontrar un Creador que necesite conectarse al objeto creado en alguna situación </li></ul><ul><li>Promueve el bajo acoplamiento, al hacer responsable a una clase de la creación de objetos que necesita referenciar </li></ul>
    14. 15. Bajo Acoplamiento <ul><li>Problema : </li></ul><ul><li>¿Cómo promover una baja dependencia y una alta reutilización de clases? </li></ul><ul><li>Solución : </li></ul><ul><li>Asignar responsabilidades manteniendo bajo el acoplamiento </li></ul>
    15. 16. Bajo Acoplamiento: Ejemplo Deseamos crear un Pago y asociarlo a Venta ¿Qué alternativa de diseño soporta el patrón Bajo Acoplamiento?
    16. 17. Bajo Acoplamiento <ul><li>Formas de acoplamiento </li></ul><ul><ul><li>Clase A posee un atributo que refiere a una Clase B </li></ul></ul><ul><ul><li>Clase A posee un método que referencia a Clase B, mediante parámetro o retorno </li></ul></ul><ul><ul><li>Clase A es subclase de B </li></ul></ul><ul><li>Soporta el diseño de clases más independientes, que reducen el impacto de cambios y acrecientan la reutilización </li></ul>
    17. 18. Alta Cohesión <ul><li>Problema : </li></ul><ul><li>¿Cómo promover una complejidad manejable de clases? </li></ul><ul><li>Solución : </li></ul><ul><li>Asignar responsabilidades manteniendo alta la cohesión </li></ul>
    18. 19. Alta Cohesión: Ejemplo Deseamos crear un Pago y asociarlo a Venta ¿Qué alternativa de diseño soporta el patrón Alta Cohesión?
    19. 20. Alta Cohesión <ul><li>Muy Baja Cohesión : una Clase, única responsable de muchas cosas en áreas funcionales muy diversas </li></ul><ul><li>Baja Cohesión : una Clase, única responsable de una tarea compleja en un área funcional </li></ul><ul><li>Alta Cohesión : una Clase con responsabilidades moderadas en un área funcional, colaborando con otras para concretar tareas. Diseño más claro y comprensible. </li></ul>
    20. 21. Controlador <ul><li>Problema : </li></ul><ul><li>¿Quién debe ser el responsable de gestionar un evento de entrada del sistema? </li></ul><ul><li>Solución : </li></ul><ul><li>Una clase que represente una de las siguientes opciones: </li></ul><ul><ul><li>El sistema global </li></ul></ul><ul><ul><li>Empresa u organización global </li></ul></ul><ul><ul><li>Un rol controlador del mundo real </li></ul></ul><ul><ul><li>Un manejador artificial de los eventos del sistema </li></ul></ul>
    21. 22. Controlador: Ejemplo
    22. 23. Controlador <ul><li>Aspectos a considerar en la elección del Controlador: </li></ul><ul><li>La misma clase para todos los eventos de un caso de uso </li></ul><ul><li>No asignar demasiada responsabilidad a un solo controlador </li></ul><ul><li>Desaturar controladores </li></ul><ul><li>Minimizar controladores humanos </li></ul>
    23. 24. Diagrama Colaboración
    24. 25. (Otro) Diagrama Colaboración

    ×