Curso de Arquitecturas de Software

Patrones
Es una solucin a un problema recurrente Capturan las mejores prcticas establecidas para diseo Describen un problema que ocurre repetidas veces en algn contexto determinado de desarrollo de software y entregan una buena solucin ya probada Est definido por su nombre, un resumen de la solucin y una descripcin del problema que resuelve
2

Programacin Orientada a Objetos Patrones GRASP

Patrones
Los patrones no son siempre la mejor solucin Beneficios:
Diseo correcto en menos tiempo Facilita la documentacin y comunicacin con otros miembros del equipo de desarrollo. No se necesita reinventar soluciones para problemas comunes Mantenibilidad (disminuye errores), extensibilidad (adicionar nuevas caractersticas), reestructuracin (reorganizacin de componentes), portabilidad.

GRASP
GRASP: General Responsabilities Assignment Software Patterns (Patrones de Asignacin de Responsabilidades). Son principios fundamentales de asignacin 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 informacin privada del objeto, conocer acerca de los objetos relacionados, conocer acerca de lo que se puede calcular derivar realizar algo l mismo, ejecutar un clculo, crear un objeto, iniciar acciones en otros objetos, controlar o coordinar actividades en otros objetos

Hacer

GRASP
Los mtodos son implementados para satisfacer las responsabilidades Las responsabilidades se asignan en las fases de anlisis y diseo
Anlisis:
Definicin de atributos de las clases del modelo conceptual del mundo Definicin de diagramas de interaccin, para refinar el modelo conceptual del mundo.

GRASP
Los mtodos Analizadores (get) tienen una responsabilidad de conocimiento Los mtodos Modificadores (set) tienen una responsabilidad de hacer

Diseo:
Definicin de mtodos
5 6

GRASP Patrn Experto (Expert)

Problema: Cul es el principio fundamental en virtud del cual se asignan las responsabilidades en el diseo orientado a objetos? Solucin: Asignar la responsabilidad al experto en la informacin, la clase que tiene la informacin necesaria para satisfacer la responsabilidad. Cada objeto es responsable por mantener su propia informacin, principio de encapsulamiento
Conoce y puede informar el valor de sus atributos Puede modificar el valor de sus atributos

GRASP Patrn Experto (Expert)

Cuando el objeto tiene relaciones de agregacin o composicin con otros objetos, tambin ser responsable de conocer la informacin de ellos, de crearlos (patrn creador) y de delegarles las operaciones.
8

GRASP Patrn Experto (Expert)

Sale -date:String -time:String

GRASP Patrn Experto (Expert)

Caso de Uso: Calcular Total de Venta
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 lnea de producto multiplicando la cantidad por el precio del producto 3. El sistema acumula cada subtotal y retorna el total de la venta

1..* SalesLineItem -quantity:int 0..* 1

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

10

GRASP Patrn Experto (Expert)

Quin es el experto en calcular el total de la venta? Quin es el experto en calcular el subtotal? Quin es el experto en informar el precio del producto?
aSale Sale aBtn aDetail SalesLineItem aProduct ProductEspecifica...

GRASP Patrn Experto (Expert)

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

1..*
1: calcTotal():float

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

SalesLineItem
1.1: calSubTotal():float 1.1.1: getPrice():float

-quantity:int +calSubTotal:float

0..*

Expert Pattern

11

12

GRASP Patrn Creador (Creator)

Problema: Quin es el responsable de crear una nueva instancia de una clase? Solucin: 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 informacin necesaria para inicializar a A

GRASP Patrn Creador (Creator)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 mtodo makeLineItem
aSale Sale aBtn 1: makeLineItem(ProductEspecification,int):void aSaleDetail SalesLineItem

1.1: <constructor>(ProductEspecification,int)

13

14

GRASP Patrn Bajo Acoplamiento (Low Coupling)

Acoplamiento es la medida de cuanto una clase est conectada (tiene conocimiento) a otras clases Problema: Cmo podemos soportar baja dependencia a travs de las clases, bajo impacto de cambios, e incremento en la reutilizacin de clases? Solucin: asignar responsabilidades para que el acoplamiento permanezca bajo
15

GRASP Patrn Bajo Acoplamiento (Low Coupling)

Es un patrn evaluativo: un bajo acoplamiento permite que el diseo de clases sea ms independiente. Reduce el impacto de los cambios y aumenta la reutilizacin No puede ser considerado aisladamente. Puede no ser importante si la reutilizacin no es un objetivo El acoplamiento describe la interconexin a travs de clases Algn grado de acoplamiento es necesario de otra manera las clases no interactuaran
16

GRASP Patrn Bajo Acoplamiento (Low Coupling)

Demasiado acoplamiento significa que los cambios a una clase podran tener tambin cambios inesperados en otras En cuanto a visibilidad, cuntos objetos se necesitan ver?

GRASP - Patrn Bajo Acoplamiento (Low Coupling)

Object1 Message1() Message2() Message3() Message4() Message5() Message6() Message7() Message8() Object2 Object3 Object4 Object5

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

GRASP Patrn Bajo Acoplamiento (Low Coupling)

Object1 Message1() Message8() Message3() Message6() Message4() Message5() Message7() Message2() Object2 Object3 Object4 Object5

GRASP Patrn Bajo Acoplamiento (Low Coupling)

Se debe preferir el primer modelo llamado stair Las subclases tienen, por definicin altos niveles de acoplamiento Particularmente se debe evitar el alto acoplamiento para objetos que pueden cambiar frecuentemente de interface su implementacin El bajo acoplamiento puede entrar en conflicto con los patrones Expert y Alta Cohesin
19 20

High coupling (centralized) Object1 must see all other objects

GRASP Patrn Alta Cohesin (High Cohesion)

Cohesin funcional dentro de una clase es una medida que indica cuan relacionadas estn las responsabilidades de una clase Problema: Cmo se puede guardar la complejidad manejable? Solucin: Asigne responsabilidades para que la cohesin permanezca alta Es un patrn evaluativo: entre ms alta cohesin ms fcil de entender, de cambiar, de reutilizar No puede ser considerado aisladamente
21

GRASP Patrn Alta Cohesin (High Cohesion)

En otras palabras, no haga que un objeto haga demasiado trabajo Alta cohesin se da cuando los elementos (mtodos y atributos) de una clase trabajan juntos para producir algn comportamiento bien definido Un objeto con una nica simple funcin compleja (hace todo) puede resultar en baja cohesin Las clases con alta cohesin tienen algunas responsabilidades en un conjunto de funciones y usan otros objetos para completarlas
22

GRASP Patrn Alta Cohesin (High Cohesion)

Diseo modular es similar al concepto de alta cohesin y bajo acoplamiento El alto acoplamiento y la baja cohesin a menudo aparecen juntas

GRASP Patrn Controlador (Controller)

Problema: Quin es el responsable de manejar los eventos de entrada externos del sistema? Solucin: 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 organizacin (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)

23

24

GRASP Patrn Controlador (Controller)

Un evento de entrada al sistema es algn evento desde algn 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.
25

GRASP Patrn Controlador (Controller)

El controlador acta como una fachada entre la interface y la aplicacin Los controladores delegan el trabajo a otros objetos ellos no hacen nada por s mismos

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

GRASP Controlador de Fachada

System
Object8 facade Object7 externalSystem

Object6 Object9

28

GRASP Controlador de Fachada

Pueden existir varias fachadas, esto para evitar que una sola clase controladora sea muy grande Los controladores podran tener atributos Las fachadas permiten mantener la separacin 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

GRASP Controlador de Fachada

Algunas ventajas:
Los cambios al modelo (dominio) no afectan el GUI (vista) y viceversa. Provee una separacin entre la lgica de negocio y la visual.

29

30

GRASP Patrn Controlador (Controller)

Se deben usar los patrones de evaluacin (cohesin/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 cohesin Creador: bajo acoplamiento Bajo Acoplamiento: no se afectan por cambios de otros componentes, fciles de entender por separado, fciles de reutilizar Alta Cohesin: mejoran la claridad y facilidad con que se entiende el diseo, se simplifica el mantenimiento y mejoras, se genera bajo acoplamiento, reutilizacin Controlador: mayor potencial de los componentes reutilizables
32

Referencias
Larman C., UML y Patrones, Prentice Hall, Segunda Edicin, 2003 Bruegge B., Ingenieria de Software Orientada a Objetos, Ed. Prentice Hall, Mexico 2002

33