Diseño de patrones

CLASE 9: DISEÑO CON PATRONES

Universidad Simón Bolívar. Ing. de Software. Prof. Ivette C. Martínez

Diseño de Objetos

  Identificar requerimientos, crear un modelo del dominio, agregar métodos a las clases de software, definir mensajes para cumplir los requerimientos…

  Simple?!?  Qué métodos pertenecen a cada clase?  Como asignamos responsabilidades a las clases

  La herramienta crítica de diseño de software es una mente bien educada en los principios de diseño y en patrones de diseño

Diseño de Objetos: entradas

  PDV entradas al proyecto:  Texto del Caso de Uso Procesar Venta

 Definir el comportamiento  Diagrama de Secuencia del Sistema

 Identificar los mensajes del sistema  Los contratos de las operaciones

 Establecer los eventos a diseñar y detallar las post-condiciones a satisfacer

Diseño de Objetos: entradas

  PDV entradas al proyecto:  Especificaciones adicionales

 Define objetivos no-funcionales

 Glosario  Formato de los datos, datos relacionados con la interfaz de

usuario y la base de datos.  Modelo del Dominio

 Esquema inicial de los objetos de software en la capa del dominio de la arquitectura del software

Diseño Dirigido por Responsabilidades

  Una responsabilidad es un contrato u obligación de una clase.   Qué debe “conocer” una clase? [responsabilidad de

conocimiento]   Datos encapsulados privados   Objetos relacionados   Cosas que puede derivar o calcular

  Qué debe “hacer” una clase? [responsabilidad de acción]   Realizar una acción (crear un objeto, realizar un cálculo)   Iniciar una acción en otros objetos   Controlar/coordinar acciones en otros objetos

  Las responsabilidades se le asignan a los objetos durante el diseño de objetos

Ejemplos de Responsabilidades

  “Una venta es responsable de crear una VentaLineaDeProducto” (hacer)

  “Una venta es responsable de conoces su total” (conocer)   Las responsabilidades de conocimiento están relacionadas con

los atributos y las asociaciones en el modelo del dominio.   Las responsabilidades de acción pueden ser expresadas en

diferentes granularidades.   Las responsabilidades de acción son implementadas mediante

métodos.

Modelo del Dominio y Responsabilidades

  El modelo del Dominio ilustra los atributos y las asociaciones => inspira las responsabilidades de “conocimiento”

  Los métodos cumplen las responsabilidades  Solo (dentro del objeto mismo)  Mediante la colaboración con otros objetos y métodos

Patrones de Aprendizaje

  Las soluciones exitosas en muchas áreas del esfuerzo humano tienen sus raices en patrones.

 Un objetivo importante de la educación es transmitir patrones de aprendizaje de generación en generación.

  Ejemplos: Patrones usados para aprender ajedrez   Aprende a desarrollar buen software es parecido

a aprender a jugar bien ajedrez.

Qué es un patrón ?

•  Cada Patrón describe un problema que ocurre una y otra vez en nuestro ambiente, y luego describe el núcleo de la solución a ese problema, de forma tal que esa solución puede ser usada un millón de veces, sin hacerlo de la misma manera dos veces.

C. Alexander, “The Timeless Way of Building”, 1979

Visión de patrones de Alexander

  Regla de tres partes que expresa una relación entre cierto contexto, un problema y una solución.

  Elemento del mundo – una relación entre  un contexto  un sistema de fuerzas que ocurren repetidamente

en el contexto  una configuración espacial que permite que las

fuerzas se resuelvan ellas mismas

Visión de patrones de Alexander

  Elemento de lenguaje ��� – una instrucción  Describe como la configuración espacial puede se

usada repetitivamente.  para resolver el sistema de fuerzas dado  en cualquier lugar en que el contexto la hace

relevante   La dualidad “objeto – proceso”

 Un objeto que ocurre en el mundo  Un proceso (regla) que genera ese objeto

Por qué usar patrones ?

 “Los patrones te ayudan a aprender de los éxitos de otros en lugar de aprender de tus errores”

Mark Johnson (citado por B. Eckel)

Por qué usar patrones ?

 Una capa de abstracción adicional  Separar las cosas que cambian de las cosas que

permanecen iguales  Extraer los factores comunes entre una familia de

problemas similares  Una forma inteligente y profunda de resolver

una clase particular de problemas  Soluciones más generales y flexibles

Patrones de diseño

  Los patrones de diseño representan soluciones a problemas que surgen cuando se desarrolla software en un contexto particular.  Patrones = par Problema/Solución dentro de

un Contexto

Patrones de Diseño

  Capturan la estructura estática y dinámica, y la colaboración entre los participantes claves del diseño del software  participante clave – abstracción principal que ocurre

en un problema de diseño  Útil para articular el cómo y el por qué resolver las

fuerzas no funcionales.

  Facilita la reutilización de arquitecturas y diseños de software exitoso

Ejemplo: Vistas de datos, problema de consistencia

El patrón Observer

  Propósito  Definir una dependencia de uno-a-muchos entre objetos

de manera que cuando un objeto cambia de estado, todas sus dependencias son notificadas y actualizadas automáticamente.

  Fuerzas  Puede haber muchos observadores  Cada observador puede reaccionar de forma diferente

a la misma notificación  La fuente de datos (sujeto) debe estar tan desacoplada

como sea posible del observador.

Estructura del patrón Observer

Colaboración en el patrón Observer

Qué lo hace un patrón?

  Un patrón debe:  Resolver un problema, i.e., debe ser útil  Tener un contexto, i.e., describir cuando la solución puede

ser utilizada  Reutilizarse, i.e., debe ser relevante en otras situaciones  Enseñar, i.e, debe proporcionar suficiente información

para la elaboración de la solución  Tener un nombre, para referirse a él de forma

consistente.

Formato GoF de un Patrón de Diseño

Nombre del patrón y clasificación Propósito qué hace el patrón También conocido como

otros nombres del patrón (opcional) Motivación el problema de diseño Aplicabilidad situaciones donde el patrón puede

ser aplicado

Formato GoF de un Patrón de Diseño

Estructura Una representación gráfica de las clases dentro del patrón

Participantes Las clases y objetos participantes y sus responsabilidades

Colaboraciones De los participantes para llevar a cabo sus responsabilidades

Consecuencias trade-offs, preocupaciones, …

Formato GoF de un Patrón de Diseño

Implementación Hints, Técnicas

Código de Ejemplo Fragmento de código que muestra una implementación posible

Usos conocidos Patrones que se encuentran en sistemas reales

Patrones relacionados Patrones estrechamente relacionados

Diseño con patrones

 Patrones de diseño GRASP  Patrones de diseño GoF  Enterprise patterns

Diseño con patrones

 Patrones de diseño GRASP  General Responsability Assignment Software

Patterns.  Patrones de Principios Generales para Asignar

Responsabilidades  “Describen los principios fundamentales de diseño

de objetos y la asignación de responsabilidades, expresados como patrones”. Craig Larman.

 Constituyen la base del CÓMO se diseñará el sistema.

 Se aplican en los primeros momentos del diseño

Patrones GRASP

  Responsabilidades  UML define una responsabilidad como “un contrato u

obligación de un clasificador”.  Las responsabilidades están relacionadas con las obligaciones

de un objeto en cuanto a su comportamiento.  Básicamente, estas responsabilidades son de los siguientes

dos tipos:  Conocer:

  Conocer los datos privados encapsulados;   Conocer los objetos relacionados   Conocer las cosas que puede derivar o calcular.

 Hacer:   Hacer algo él mismo, como crear un objeto o hacer un cálculo;   Iniciar una acción en otros objetos;   Controlar y coordinar actividades en otros objetos.

Patrones GRASP

  Patrones de diseño GRASP  Experto en información  Creador  Alta cohesión  Bajo Acoplamiento  Controlador  Polimorfismo  Fabricación Pura   Indirección  Variaciones Protegidas

Patrones GRASP

 Experto en información  Problema:

¿ Cuál es el principio general para asignar responsabilidades a los objetos ?

 Solución : Asignar una responsabilidad al experto en información – la clase que tiene la información necesaria para realizar la responsabilidad. Un Experto es una clase que tiene toda la información necesaria para implementar una responsabilidad.

 Ventajas:  Encapsulamiento de la información;  Distribución del comportamiento del manejo de la

información

Patrones GRASP

  Experto en información

Patrones GRASP

  Creador  Problema:

¿Quién debería ser el responsable de la creación de una nueva instancia de alguna clase?

 Solución: B es un Creador de A si se asigna a la clase B la responsabilidad de crear una instancia de la clase A y si se cumple uno o más de los casos siguientes:  B agrega objetos de A;  B contiene objetos de A;  B registra instancias de objetos de A;  B utiliza más estrechamente objetos de A;  B tiene los datos de inicialización que se pasarán a un objeto de A

cuando sea creado( por lo tanto, B es un Experto con respecto a la creación de A)

Patrones GRASP

  Creador  El patrón Creador guía la asignación de responsabilidades

relacionadas con la creación de objetos (una tarea muy común). La intención básica del patrón es encontrar un creador que necesite conectarse al objeto creado en alguna situación.

 Ventajas:  Bajo acoplamiento logrando mayor mantenibilidad y

reutilización.  Desventajas:

 Puede ser muy compleja la operación de creación de instancia. Se puede aplicar el patrón de diseño Factory.

Patrones GRASP

  Creador

Patrones GRASP

 Bajo Acoplamiento  Problema:

¿Cómo soportar bajas dependencias, bajo impacto del cambio e incremento de la reutilización?

 Solución: Asignar una responsabilidad de manera que el acoplamiento permanezca bajo.

 El acoplamiento es una medida de la fuerza con que un elemento está conectado a, tiene conocimiento de, confía en, otros elementos.

Un elemento con bajo (o débil) acoplamiento no depende demasiado de otros elementos.

Patrones GRASP

 Bajo Acoplamiento  El patrón Bajo Acoplamiento es un principio a tener

en mente en todas las decisiones de diseño. Es un principio evaluativo que aplica un diseñador mientras evalúa todas las decisiones de diseño.

 El Bajo Acoplamiento soporta clases más independientes

 Ventajas:  No afectan los cambios en otros componentes;  Fácil de entender de manera aislada;  Conveniente para reutilizar

Patrones GRASP

  Bajo Acoplamiento  ¿Qué diseño, basado en la asignación de

responsabilidades, soporta Bajo Acoplamiento?

Patrones GRASP

  Bajo Acoplamiento  ¿Qué diseño, basado en la asignación de

responsabilidades, soporta Bajo Acoplamiento?  Desde el punto de vista puramente del acoplamiento, es

preferible el segundo diseño porque mantiene el acoplamiento global más bajo.

 Este es un ejemplo en el que dos patrones- Bajo Acoplamiento y Creador – podrían sugerir soluciones diferentes.

Patrones GRASP

 Alta cohesion  Problema:

¿Cómo mantener la complejidad manejable?  Solución:

Asignar una responsabilidad de manera que la cohesión permanezca alta.

 En cuanto al diseño de objetos, la cohesión (cohesión funcional) es una medida de la fuerza con la que se relacionan y del grado de focalización de las responsabilidades de un elemento.

Patrones GRASP

 Alta cohesion

 Una clase con baja cohesión hace muchas cosas no relacionadas, o hace demasiado trabajo:  Clases difíciles de entender;  Difíciles de reutilizar;  Difíciles de mantener;  Delicadas, constantemente afectadas por los

cambios.

Patrones GRASP

 Alta cohesion  Como regla empírica, una clase con alta cohesión

tiene:  Un número relativamente pequeño de métodos, con

funcionalidad altamente relacionada,  No realiza mucho trabajo.  Colabora con otros objetos para compartir el esfuerzo si

la tarea es extensa.

 No es conveniente recargar el trabajo o incluir funcionalidad en la clase que responde a los eventos del sistema.

Patrones GRASP

 Alta cohesion  Ventajas:

 Incrementa la claridad y facilita la comprensión del diseño;

 Simplifica el mantenimiento y las mejoras;  Soporta a menudo bajo acoplamiento  Incrementa la reutilización

Patrones GRASP

 Controlador  Problema:

¿Quién debe ser el responsable de gestionar un evento de entrada del sistema?

 Solución: Asignar la responsabilidad de recibir o manejar un mensaje de evento del sistema a una clase que representa una de las siguientes operaciones:  Representa el sistema global, dispositivo o subsistema (Controlador

de Fachada);  Representa un escenario de caso de uso en el que tiene lugar el

evento del sistema (controlador de Sesión de Caso de Uso).   Utilizar la misma clase controlador para todos los eventos del sistema

en el mismo escenario de caso de uso;   Una sesión es una instancia de una conversación con un actor

Patrones GRASP

  Controlador  Las clases “ventana”, “applet”, “vista”, etc., no están en la

lista debido a que tales clases no deben abordar las tareas asociadas con los eventos del sistema, sino que, reciben estos eventos y los delegan a un controlador.

 Evento del sistema de entrada   Es un evento generado por un actor externo. Se asocian con

operaciones del sistema – operaciones del sistema como respuesta a los eventos del sistema -, tal como se relacionan los mensajes y los métodos.

 Un Controlador   Es un objeto que no pertenece a la interfaz de usuario, responsable

de recibir o manejar un evento del sistema. Un Controlador define los métodos para las operaciones del sistema.

Patrones GRASP

Patrones GRASP

 Controlador  Normalmente un controlador delega en otros

objetos el trabajo que se necesita hacer; coordina o controla la actividad. No realiza mucho trabajo por sí mismo.

 Tipos de controladores:  Controlador de Fachada:

 Representa al sistema global, dispositivo o subsistema.

 Controlador de casos de uso:  Construcción artificial para dar soporte al sistema.

Se utilizan cuando los Controladores de Fachada conduce a diseños con baja cohesión o alto acoplamiento.

Patrones GRASP

 Controlador  Ventajas:

 Aumenta el potencial para reutilizar las interfaces;  Razonamiento sobre el estado (secuencia de pasos) de los

casos de uso.

Patrones GRASP

 Controlador