gonzalorojas 12 uml, patrones de diseno
Post on 12-Jun-2015
4.128 Views
Preview:
DESCRIPTION
TRANSCRIPT
UML: Patrones para asignación de responsabilidades
Gonzalo Rojas D.
Introducción
• Funcionalidad de Sistemas Orientados a Objetos está definida por los mensajes entre objetos para realizar operaciones
• Una adecuada asignación de responsabilidades entre objetos contribuye al desarrollo de sistemas robustos
• Se vela por el cumplimiento de los conceptos fundamentales de la Orientación a Objetos.
What are patterns?
• Principles and solutions codified in a structured format describing a problem and a solution
• A named problem/solution pair that can be applied in new contexts
• It is advice from previous designers to help designers in new situations
Some definitions of design patterns
• “Design patterns constitute a set of rules describing how to accomplish certain tasks in the realm of software development.” (Pree, 1994)
• “Design patterns focus more on reuse of recurring architectural design themes, while frameworks focus on detailed design… and implementation.” (Coplien & Schmidt, 1995).
• “A pattern addresses a recurring design problem that arises in specific design situations and presents a solution to it” (Buschmann, et. al. 1996)
• “Patterns identify and specify abstractions that are above the level of single classes and instances, or of components.” (Gamma, et al., 1993)
GRASP patternsGeneral Responsibility Assignment Software Patterns
• Expert• Creator• Low Coupling• High Cohesion• Controller• Polymorphism• Pure Fabrication• Indirection• Law of Demeter
Experto en Información Problema:
¿Cuál es el principio general para asignar responsabilidades a los objetos?¿Quién debiera ser el responsable de conocer la información?
Solución:Asignar una responsabilidad a la clase que tiene la información necesaria para cumplir la responsabilidad (experto)
-cantidad
VentaLíneadeProducto
-fecha-hora
Venta
1..*
1..1
-descripción-precio-artID
Descripción de Producto
0..* 1..1
Experto: Ejemplo
• ¿Quién es el responsable de conocer el monto total de la venta?
Experto: Ejemplo
• ¿Qué información necesito?– Todas las Líneas de Producto de la Venta y
sus respectivos subtotales
• ¿De qué clase del Esquema Conceptual puedo obtener esa información?
:Venta2: tot := total()
Experto: Ejemplo
• ¿Y los respectivos subtotales (cantidad x precio) de cada Línea de Producto?
• ¿Y el precio de cada Producto?
vlp :VentaLíneadeProducto2.2 st := subtotal()
dp:DescripcióndeProducto
2.2.1 precio := precio()
:Venta vlp :VentaLíneadeProducto
:VentaLíneadeProducto
2.1*: [para cada] vlp := siguiente()
2.2 st := subtotal()
dp:DescripcióndeProducto
2.2.1 precio := precio()
2: tot := total()
-total() : int
-fecha-hora
Venta
-subtotal() : int
-cantidad
VentaLíneadeProducto
-precio() : int
-descripción-precio-artID
DescripcióndeProducto
Experto
• Mantiene el encapsulamiento de la información
• Favorece el bajo acoplamiento
• Puede originar clases excesivamente complejas
CreadorProblema:
¿Quién debiera ser el responsable de la creación de una nueva instancia de alguna clase?
Solución:B es un Creador de A si se cumple uno o más de las siguientes condiciones:– B agrega objetos de A– B contiene objetos de A– B registra objetos de A– B utiliza intensivamente objetos de A– B tiene los datos de inicialización de objetos de A (B es
Experto en la creación de A)
Creador: Ejemplo
:Caja :Venta v :VentaLíneadeProducto
introducirProducto (artID, cantidad)
1: [nueva venta] crear() 3.1: crear (dp, cantidad)3: añadirLíneadeProducto (p, cantidad)
-crear()-total() : int
-fecha-hora
Venta
-crear(in dp, in cantidad)-subtotal() : int
-cantidad
VentaLíneadeProducto
Creador
• La intención básica del patrón es encontrar un Creador que necesite conectarse al objeto creado en alguna situación
• Promueve el bajo acoplamiento, al hacer responsable a una clase de la creación de objetos que necesita referenciar
Bajo AcoplamientoProblema:
¿Cómo promover una baja dependencia y una alta reutilización de clases?
Solución:Asignar responsabilidades manteniendo bajo el acoplamiento
Bajo Acoplamiento: Ejemplo
:Caja p:Pago1: crear()
2: agregarPago(p)
efectuarPago()
:Venta
:Caja :Venta1: efectuarPago()
1.1 crear()
efectuarPago()
:Pago
Deseamos crear un Pago y asociarlo a Venta
¿Qué alternativa de diseño soporta el patrón Bajo Acoplamiento?
Bajo Acoplamiento
• Formas de acoplamiento– Clase A posee un atributo que refiere a una
Clase B– Clase A posee un método que referencia a
Clase B, mediante parámetro o retorno– Clase A es subclase de B
• Soporta el diseño de clases más independientes, que reducen el impacto de cambios y acrecientan la reutilización
Alta CohesiónProblema:
¿Cómo promover una complejidad manejable de clases?
Solución:Asignar responsabilidades manteniendo alta la cohesión
Alta Cohesión: Ejemplo
:Caja p:Pago1: crear()
2: agregarPago(p)
efectuarPago()
:Venta
:Caja :Venta1: efectuarPago()
1.1 crear()
efectuarPago()
:Pago
Deseamos crear un Pago y asociarlo a Venta
¿Qué alternativa de diseño soporta el patrón Alta Cohesión?
Alta Cohesión
• Muy Baja Cohesión: una Clase, única responsable de muchas cosas en áreas funcionales muy diversas
• Baja Cohesión: una Clase, única responsable de una tarea compleja en un área funcional
• 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.
ControladorProblema:
¿Quién debe ser el responsable de gestionar un evento de entrada del sistema?
Solución:Una clase que represente una de las siguientes opciones:– El sistema global– Empresa u organización global– Un rol controlador del mundo real– Un manejador artificial de los eventos del sistema
:Caja
introducirProducto (artID, cantidad)
:Tienda
introducirProducto (artID, cantidad)
:Cajero
introducirProducto (artID, cantidad)
:ManejadorComprarProductos
introducirProducto (artID, cantidad)
Controlador: Ejemplo
Controlador
• Aspectos a considerar en la elección del Controlador:
• La misma clase para todos los eventos de un caso de uso
• No asignar demasiada responsabilidad a un solo controlador
• Desaturar controladores
• Minimizar controladores humanos
Diagrama Colaboración
:Caja :Venta v :VentaLíneadeProducto
:VentaLíneadeProducto
:Catálogo
:DescripcióndeProducto
introducirProducto (artID, cantidad)
1: [nueva venta] crear()3: añadirLíneadeProducto (p, cantidad)
2: dp := encontrarDP(artID)
2.1: dp := encontrar(artID)
1.1: crear()
3.2: agregar (v)
3.1: crear (dp, cantidad)
(Otro) Diagrama Colaboración
:Caja :Venta vlp :VentaLíneadeProducto
:VentaLíneadeProducto
1: terminar()2: tot := total()
2.1*: [para cada] vlp := siguiente()
2.2 st := subtotal()
dp:DescripcióndeProducto
2.2.1 precio := precio()
-crear(in dp, in cantidad)-subtotal() : int
-cantidad
VentaLíneadeProducto
-dirección-nombre
Tienda
-encontrarDP(in artID) : DescripcióndeProducto
Catálogo
Cajero
-crear()-terminar()-total() : int-añadirLíneadeProducto(in dp, in cantidad)
-fecha-hora-estado: {en progreso, terminada}
Venta
-monto
Pago Cliente
1..*
1..1
1..1
1..*
1..1
1..1
1..1
1..1
1..1 1..1
0..*
1..11..1
0..*
1..1 1..*
0..*
0..1
1..1
1..1
1..1
0..*
Producto
-precio() : int
-descripción-precio-artID
DescripcióndeProducto
-introducirArtículo(in artID, in cantidad)-finalizarVenta()
Caja
top related