8 - Curso Arquitecturas - GRASP

Patrones

Curso de Arquitecturas de Software

„ „ „

Programación Orientada a Objetos Patrones GRASP

„

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 „ „

GRASP

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: 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

GRASP „ „

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.

„

4

Los métodos Analizadores (get) tienen una responsabilidad de conocimiento Los métodos Modificadores (set) tienen una responsabilidad de hacer

Diseño: • Definición de métodos 5

6

1

GRASP –Patrón Experto (Expert) „

„

„

GRASP –Patrón Experto (Expert)

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

GRASP –Patrón Experto (Expert)

8

GRASP –Patrón Experto (Expert) „

Sale -date:String -time:String

Caso de Uso: Calcular Total de Venta „ „

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

1

1..*

ProductEspecification

SalesLineItem -quantity:int

0..*

1

Actores: Cajero Flujo Normal:

-description:String -price:float -itemID:int

9

GRASP –Patrón Experto (Expert) „ „ „

GRASP –Patrón Experto (Expert)

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? aSale Sale

aDetail SalesLineItem

10

Sale -date:String -time:String +calcTotal:float

1

aProduct ProductEspecifica...

aBtn

1..* 1: calcTotal():float

ProductEspecification

SalesLineItem 1.1: calSubTotal():float

-quantity:int

1.1.1: getPrice():float

+calSubTotal:float

0..*

1

-description:String -price:float -itemID:int +getPrice:float

Expert Pattern

11

12

2

GRASP –Patrón Creador (Creator) „ „

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

Por ejemplo Sale agrega (contiene) muchas SaleLineItem, por lo tanto Sale debe ser el creador de instancias de SaleLineItem. Por lo tanto una responsabilidad del sistema es que Sale necesita un método makeLineItem aSale Sale aBtn 1: makeLineItem(ProductEspecification,int):void

1.1: (ProductEspecification,int)

aSaleDetail SalesLineItem

13

GRASP –Patrón Bajo Acoplamiento (Low Coupling) „

„

„

14

GRASP –Patrón Bajo Acoplamiento (Low Coupling)

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

„

„

„ „

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

15

GRASP – Patrón Bajo Acoplamiento (Low Coupling)

16

GRASP - Patrón Bajo Acoplamiento (Low Coupling)

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? „

Object1

Object2

Object3

Object4

Object5

Message1() Message2() Message3() Message4() Message5() Message6() Message7() Message8()

Low coupling (decentralized) Each object sees two other objects at most 17

18

3

GRASP – Patrón Bajo Acoplamiento (Low Coupling)

GRASP – Patrón Bajo Acoplamiento (Low Coupling) „

Object1

Object2

Object3

Object4

Object5

„

Message1() Message8() Message3()

„

Message6() Message4() Message5() Message7() Message2()

„

High coupling (centralized) Object1 must see all other objects

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

19

GRASP – Patrón Alta Cohesión (High Cohesion) „

„ „ „

„

20

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

„ „

„ „

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

21

GRASP – Patrón Alta Cohesión (High Cohesion)

22

GRASP – Patrón Controlador (Controller)

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 „

„

„

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: „ „

„

23

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

4

GRASP – Patrón Controlador (Controller)

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: Coordinador, Manejador, Session.

„

„ „

„

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 „

25

GRASP – Controlador de Fachada

26

GRASP – Controlador de Fachada

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

externalSystem

Object7

Object6 Object9

27

GRASP – Controlador de Fachada „ „ „

„

28

GRASP – Controlador de Fachada

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

29

„

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

30

5

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 31

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 32

Referencias Larman C., “UML y Patrones”, Prentice Hall, Segunda Edición, 2003 „ Bruegge B., “Ingenieria de Software Orientada a Objetos,” Ed. Prentice Hall, Mexico 2002 „

33

6