Diagramas de Interacción

GRASP: Patrones de Principios Generales para la Asignación de Responsabilidades.

(Mas información: http://www.lsi.us.es/docencia/get.php?id=906)

1. Patrón Experto en Información. (Pág. 207)

Responsabilidad que asigna: información que debe conocer un objeto.

1º Determinar la información a conocer.

2º Buscar los objetos responsables en el Modelo de Diseño.

3º Si no se encuentran crear nuevas clases software.

Una necesidad de información puede requerir nuevas necesidades de información ➔ nuevas responsabilidades ➔ nuevos expertos.

Por ejemplo, una Venta necesita conocer el total y para conocerlo es necesario el Subtotal de todas las LineaDeVenta. Para calcular cada Subtotal se deberá conocer la cantidad y precio del artículo. Esta última información es responsabilidad de DetallesDeArticulo.

En este ejemplo un experto partícular ha generado información esparcida por otros objetos. ➔ Iteración entre objetos.

Patrones relacionados: Bajo Acoplamiento y Alta Cohesión.

A veces la solución propuesta por el experto no satisface el bajo acoplamiento y la alta cohesión ➔ buscar alternativas de asignación de responsabiliades.

Patrón Creador. (Pág. 211)

¿Quién es el responsable de crear una instancia de alguna clase?

Por ejemplo una Venta crea varias LineaDeVenta.

Si un objeto A necesita conectarse a otro B, A crea a B.

Agregado agrega partes.

Contenedor contiene Contenido.

Registro registra Registros.

Tanto Contenedor como Registro tienen la responsabilidad de crear lo que contienen o registran luego ambos deberán contener información para crear el contenido o los registros.

Si la creación sugiere usar instancias recicladas, crear una instancia condicionalmente, ... Se recomienda usar Factoria.

Patrón Bajo Acoplamiento. (Pág. 214)

Los elementos deben depender poco unos de otros.

Se debe considerar junto al Experto y a la Alta cohesión.

Por ejemplo a una Venta se le debe asociar un Pago ➔ 2 posibles diseños:

A ) El Registro crea Pago y le asocia a la Venta. Venta y Pago dependen de Registro.

B ) El Registro realiza Venta y Venta crea Pago ➔ diseño mejor acoplamiento

Formas comunes de acoplamiento:

• TipoX tiene atributo de TipoY.
• TipoX hereda directa o transitivamente de TipoY.
• TipoX invoca servicios de TipoY.
• TipoX hace referencia a una instancia de TipoY.
• TipoY es interfaz y Tipos la implementa.

Herencia ➔ Alto acoplamiento ➔ usarla sólo cuando la superclase sea un opjeto persistente (estable en el tiempo).

Patrón Alta Cohesión. (Pág. 217)

Un elemento con alta cohesión es aquel cuya funcionalidad está relacionada y que no hace gran cantidad de trabajo ➔ Función bien definida.

Por ejemplo Venta pagada en efectivo. Si al Registro se le asignan operaciones no relacionadas como la paga en efectivo, la cohesión es baja. Lo ideal es Registro crea Venta y Venta se asocia a Pago.

Grados de cohesión funcional:

• Muy baja cohesión: una única clase es responsable de muchas cosas en áreas funcionales diferentes.
• Baja cohesión: una única clase es responsable de una tarea compleja en un área funcional.
• Alta cohesión: una clase tiene una responsabilidad en un área funcional y colabora con otras clases para llevarla a cabo. Tiene pocos métodos y relacionados.
• Moderada cohesión: una clase tiene responsabilidades ligeras y únicas a unas pocas áreas diferentes pero lógicamente relacionadas con el concepto de la clase.

DISEÑO MODULAR: consiste en descomponer el sistema en módulos cohesivos y débilmente acoplados.

Baja cohesión ➔ alto acoplamiento y viceversa.

Patrón Controlador. (Pág. 221)

Asigna la responsabilidad de recibir o manejar un mensaje de evento del sistema a una clase controladora.

Tipos:

• Contenedor de Fachada: representa al sistema global, dispositivo o subsistema. Útil cuando se manejan pocos eventos.
• Contenedor de sesión o de caso de uso: representa un escenario de caso de uso en que tiene lugar el evento del sistema. Se nombra:

<NombreCasoUso>Manejador

<NombreCasoUso>Coordinador

<NombreCasoUso>Sesion

Una sesión es una conversación de duración fija con un actor.

Hay un controlador por cada caso de uso.

Un actor al interactuar con el sistema genera un evento de entrada al mismo. Esto provoca la ejecución de operaciones en el sistema asociadas al evento.

¿Quién es el responsable de gestionar el evento?

Un controlador (independiente de la interfaz de comunicación con el usuario) define una operación que maneje el evento. En el mismo controlador se deberán definir las operaciones relacionadas con el mismo tipo de evento ➔ Mayor cohesión.

Cuando el tratamiento del evento sea complejo, el controlador delega el trabajo que se necesite hacer, coordina o controla la actividad. No realiza mucho trabajo.

• Si la UI es una GUI de Swing de Java, el controlador de caso de uso será local, es decir, una clase del lado del cliente (local al mismo).
• Si la UI pertenece a una aplicación Cliente / Servidor, uso de un navegador, el controlador de caso de uso estará en el lado del servidor (servlet o bean de sesión (Enterprise JavaBeans)).

LAS UI NO MANEJAN EVENTOS.