Gonzalorojas 12 Uml, Patrones De Diseno

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()



2: tot := total()

-total() : int

-fecha-hora

Venta

-subtotal() : int

-cantidad


-precio() : int


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


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


:Tienda


:Cajero


:ManejadorComprarProductos


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


:Catálogo

:DescripcióndeProducto


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


1: terminar()2: tot := total()

2.1*: [para cada] vlp := siguiente()

2.2 st := subtotal()



-crear(in dp, in cantidad)-subtotal() : int

-cantidad


-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óndeProducto

-introducirArtículo(in artID, in cantidad)-finalizarVenta()

Caja

Gonzalorojas 12 Uml, Patrones De Diseno

Documents

Transcript of Gonzalorojas 12 Uml, Patrones De Diseno