CLASE 9: DISEÑO CON PATRONES. Universidad Simón Bolívar. Ing. de Software. Prof. Ivette C. Martínez

Transcripción

1 CLASE 9: DISEÑO CON PATRONES Universidad Simón Bolívar. Ing. de Software. Prof. Ivette C. Martínez

2 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

3 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 postcondiciones a satisfacer

4 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

5 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

6 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.

7 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

8 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.

9 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

10 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

11 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

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

13 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

14 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

15 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

16 Ejemplo: Vistas de datos, problema de consistencia

17 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.

18 Estructura del patrón Observer

19 Colaboración en el patrón Observer

20 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.

21 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

22 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,

23 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

24 Diseño con patrones Patrones de diseño GRASP Patrones de diseño GoF Enterprise patterns

25 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

26 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.

27 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

28 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

29 Patrones GRASP Experto en información

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

31 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.

32 Patrones GRASP Creador

33 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.

34 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

35 Patrones GRASP Bajo Acoplamiento Qué diseño, basado en la asignación de responsabilidades, soporta Bajo Acoplamiento?

36 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.

37 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.

38 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.

39 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.

40 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

41 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

42 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.

43 Patrones GRASP

44 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.

45 Patrones GRASP Controlador Ventajas: Aumenta el potencial para reutilizar las interfaces; Razonamiento sobre el estado (secuencia de pasos) de los casos de uso.

46 Patrones GRASP Controlador