Patrones. Patrones GRASP GRASP GRASP. Curso de Arquitecturas de Software. Programación Orientada a Objetos Patrones GRASP

Transcripción

1 Curso de Arquitecturas de Software Programación Orientada a Objetos Patrones GRASP Patrones Es una solución a un problema recurrente Capturan las mejores prácticas establecidas para diseño Describen un problema que ocurre repetidas veces en algún contexto determinado de desarrollo de software y entregan una buena solución ya probada Está definido por su nombre, un resumen de la solución y una descripción del problema que resuelve 2 Patrones Los patrones no son siempre la mejor solución Beneficios: Diseño correcto en menos tiempo Facilita la documentación y comunicación con otros miembros del equipo de desarrollo. No se necesita reinventar soluciones para problemas comunes Mantenibilidad (disminuye errores), extensibilidad (adicionar nuevas características), reestructuración (reorganización de componentes), portabilidad. GRASP GRASP: General Responsabilities Assignment Software Patterns (Patrones de Asignación de Responsabilidades). Son principios fundamentales de asignación de responsabilidades expresados como patrones La responsabilidad consiste de obligaciones o contratos de una clase describe que comportamiento necesita satisfacer Existen dos tipos de responsabilidades: Conocer conocer la información privada del objeto, conocer acerca de los objetos relacionados, conocer acerca de lo que se puede calcular ó derivar Hacer realizar algo él mismo, ejecutar un cálculo, crear un objeto, iniciar acciones en otros objetos, controlar o coordinar actividades en otros objetos 3 4 GRASP Los métodos son implementados para satisfacer las responsabilidades Las responsabilidades se asignan en las fases de análisis y diseño Análisis: Definición de atributos de las clases del modelo conceptual del mundo Definición de diagramas de interacción, para refinar el modelo conceptual del mundo. Diseño: Definición de métodos GRASP Los métodos Analizadores (get) tienen una responsabilidad de conocimiento Los métodos Modificadores (set) tienen una responsabilidad de hacer 5 6

2 Problema: Cuál es el principio fundamental en virtud del cual se asignan las responsabilidades en el diseño orientado a objetos? Solución: Asignar la responsabilidad al experto en la información, la clase que tiene la información necesaria para satisfacer la responsabilidad. Cada objeto es responsable por mantener su propia información, principio de encapsulamiento Conoce y puede informar el valor de sus atributos Puede modificar el valor de sus atributos Cuando el objeto tiene relaciones de agregación o composición con otros objetos, también será responsable de conocer la información de ellos, de crearlos (patrón creador) y de delegarles las operaciones. 7 8 Caso de Uso: Calcular Total de Venta -date:string -time:string 1 1..* -quantity:int 0..* 1 ProductEspecification -description:string -price:float -itemid:int Actores: Cajero Flujo Normal: 1. El cajero solicita al sistema el total de la venta 2. el sistema procede a calcular el subtotal de cada línea de producto multiplicando la cantidad por el precio del producto 3. El sistema acumula cada subtotal y retorna el total de la venta 9 10 Quién es el experto en calcular el total de la venta? Quién es el experto en calcular el subtotal? Quién es el experto en informar el precio del producto? -date:string -time:string +calctotal:float 1 a adetail aproduct ProductEspecifica... abtn 1..* ProductEspecification 1: calctotal():float 1.1: calsubtotal():float 1.1.1: getprice():float -quantity:int 0..* 1 -description:string -price:float -itemid:int +calsubtotal:float +getprice:float Expert Pattern 11 12

3 GRASP Patrón Creador (Creator) Problema: Quién es el responsable de crear una nueva instancia de una clase? Solución: El objeto B tiene la responsabilidad de crear objetos de la Clase A si: B agrega objetos A B contiene objetos A B registra objetos A B usa exhaustivamente objetos A B posee la información necesaria para inicializar a A GRASP Patrón Creador (Creator)- Por ejemplo agrega (contiene) muchas LineItem, por lo tanto debe ser el creador de instancias de LineItem. Por lo tanto una responsabilidad del sistema es que necesita un método makelineitem abtn a 1: makelineitem(productespecification,int):void 1.1: <constructor>(productespecification,int) adetail GRASP Patrón Bajo Acoplamiento es la medida de cuanto una clase está conectada (tiene conocimiento) a otras clases Problema: Cómo podemos soportar baja dependencia a través de las clases, bajo impacto de cambios, e incremento en la reutilización de clases? Solución: asignar responsabilidades para que el acoplamiento permanezca bajo GRASP Patrón Bajo Es un patrón evaluativo: un bajo acoplamiento permite que el diseño de clases sea más independiente. Reduce el impacto de los cambios y aumenta la reutilización No puede ser considerado aisladamente. Puede no ser importante si la reutilización no es un objetivo El acoplamiento describe la interconexión a través de clases Algún grado de acoplamiento es necesario de otra manera las clases no interactuarían GRASP Patrón Bajo Demasiado acoplamiento significa que los cambios a una clase podrían tener también cambios inesperados en otras En cuanto a visibilidad, cuántos objetos se necesitan ver? GRASP - Patrón Bajo Object1 Object2 Object3 Object4 Object5 Message1() Message2() Message7() Message3() Message6() Message4() Message5() Message8() Low coupling (decentralized) Each object sees two other objects at most 17 18

4 GRASP Patrón Bajo Object1 Object2 Object3 Object4 Object5 Message1() Message8() Message7() Message2() Message3() Message6() Message4() Message5() High coupling (centralized) Object1 must see all other objects GRASP Patrón Bajo Se debe preferir el primer modelo llamado stair Las subclases tienen, por definición altos niveles de acoplamiento Particularmente se debe evitar el alto acoplamiento para objetos que pueden cambiar frecuentemente de interface ó su implementación El bajo acoplamiento puede entrar en conflicto con los patrones Expert y Alta Cohesión GRASP Patrón Alta Cohesión (High Cohesion) Cohesión funcional dentro de una clase es una medida que indica cuan relacionadas están las responsabilidades de una clase Problema: Cómo se puede guardar la complejidad manejable? Solución: Asigne responsabilidades para que la cohesión permanezca alta Es un patrón evaluativo: entre más alta cohesión más fácil de entender, de cambiar, de reutilizar No puede ser considerado aisladamente GRASP Patrón Alta Cohesión (High Cohesion) En otras palabras, no haga que un objeto haga demasiado trabajo Alta cohesión se da cuando los elementos (métodos y atributos) de una clase trabajan juntos para producir algún comportamiento bien definido Un objeto con una única simple función compleja (hace todo) puede resultar en baja cohesión Las clases con alta cohesión tienen algunas responsabilidades en un conjunto de funciones y usan otros objetos para completarlas GRASP Patrón Alta Cohesión (High Cohesion) Diseño modular es similar al concepto de alta cohesión y bajo acoplamiento El alto acoplamiento y la baja cohesión a menudo aparecen juntas 23 GRASP Patrón Controlador (Controller) Problema: Quién es el responsable de manejar los eventos de entrada externos del sistema? Solución: Asignar la responsabilidad de manejar los mensajes, eventos del sistema a una clase que representa una de las siguientes elecciones: El sistema total, La empresa u organización (controlador de fachada) Algo en el mundo real que está activo (p.ej. El rol de una persona) y que puede participar en la tarea (controlador de tareas). Un manejador artificial de los eventos del sistema relacionados con un caso de uso.(session controller) 24

5 GRASP Patrón Controlador (Controller) Un evento de entrada al sistema es algún evento desde algún actor externo (humano ó no) El objeto controlador es responsable de decidir que hacer con el evento El controlador se aplica para el manejo de interfaces externas y al manejo de entradas desde interfaces de usuario Los controladores de interface de usuario generalmente tienen la forma: <nombre caso de uso> Coordinador, Manejador, Session. GRASP Patrón Controlador (Controller) El controlador actúa como una fachada entre la interface y la aplicación Los controladores delegan el trabajo a otros objetos ellos no hacen nada por sí mismos El controlador de fachada oculta un sistema debajo de una clase, como un Register ó un system. La fachada trabaja bien si tiene pocos eventos para manejar, de otra manera es necesario tener varios de acuerdo a controladores por caso de uso. System Object8 facade Object7 Object6 Object9 externalsystem Pueden existir varias fachadas, esto para evitar que una sola clase controladora sea muy grande Los controladores podrían tener atributos Las fachadas permiten mantener la separación del modelo de negocios y la vista (GUI), la vista no debe interactuar directamente con el modelo, esto se conoce como el modelo vista controlador (MVC) Permite mantener bajo acoplamiento entre Subsistemas Algunas ventajas: Los cambios al modelo (dominio) no afectan el GUI (vista) y viceversa. Provee una separación entre la lógica de negocio y la visual

6 GRASP Patrón Controlador (Controller) Se deben usar los patrones de evaluación (cohesión/acoplamiento) para decidir cuantos controladores se deben tener, en particular si hay muchos eventos un solo objeto puede volverse poco cohesivo Se recomienda utilizar un controlador por caso de uso para guardar o asegurar una secuencia de eventos Un controlador no es un objeto de la interface Un controlador despacha operaciones Patrones Beneficios Experto: conserva el encapsulamiento, bajo acoplamiento, alta cohesión Creador: bajo acoplamiento Bajo Acoplamiento: no se afectan por cambios de otros componentes, fáciles de entender por separado, fáciles de reutilizar Alta Cohesión: mejoran la claridad y facilidad con que se entiende el diseño, se simplifica el mantenimiento y mejoras, se genera bajo acoplamiento, reutilización Controlador: mayor potencial de los componentes reutilizables Referencias Larman C., UML y Patrones, Prentice Hall, Segunda Edición, 2003 Bruegge B., Ingenieria de Software Orientada a Objetos, Ed. Prentice Hall, Mexico