Sunteți pe pagina 1din 6
Curso de Arquitecturas de Software Programación Orientada a Objetos Patrones GRASP
Curso de Arquitecturas de
Software
Programación Orientada a
Objetos
Patrones
GRASP

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.

3

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

5

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

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

 

4

GRASP

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

 

6

GRASP –Patrón Experto (Expert) Problema : Cuál es el principio fundamental en virtud del cual
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
7
GRASP –Patrón Experto
(Expert)
Sale
-date:String
-time:String
1
1
*
ProductEspecification
SalesLineItem
-description:String
-price:float
-quantity:int
0
*
1
-itemID:int
9
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
aDetail
aProduct
Sale
SalesLineItem
ProductEspecifica
aBtn
1: calcTotal():float
1.1: calSubTotal():float
1.1.1: getPrice():float
Expert
Pattern
11

GRASP –Patrón Experto (Expert)

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.

8

GRASP –Patrón Experto (Expert) Caso de Uso: Calcular Total de Venta Actores: Cajero Flujo Normal:
GRASP –Patrón 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
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
10
GRASP –Patrón Experto
(Expert)
Sale
-date:String
-time:String
+calcTotal:float
1
1
*
ProductEspecification
SalesLineItem
-description:String
-price:float
-quantity:int
0
*
1
-itemID:int
+calSubTotal:float
+getPrice:float
12

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

13

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

15

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?

17

GRASP –Patrón Creador (Creator)- Por ejemplo Sale agrega (contiene) muchas SaleLineItem, por lo tanto Sale
GRASP –Patrón 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 método makeLineItem
aSale
Sale
aBtn
1: makeLineItem(ProductEspecification,int):void
aSaleDetail
1.1: <constructor>(ProductEspecification,int)
SalesLineItem
14
SalesLineItem 14 GRASP –Patrón Bajo Acoplamiento (Low Coupling) Es un

GRASP –Patrón Bajo Acoplamiento (Low Coupling)

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

16

es necesario de otra manera las clases no interactuarían 16 GRASP - Patrón Bajo Acoplamiento (Low

GRASP - Patrón Bajo Acoplamiento (Low Coupling)

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

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

18

GRASP – Patrón Bajo Acoplamiento (Low Coupling)

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

High coupling (centralized) Object1 must see all other objects

19

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

21

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 Bajo Acoplamiento (Low Coupling)

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

20

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

 

22

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

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.

25

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

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

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

26

GRASP – Controlador de Fachada System Object8 externalSystem facade Object7 Object6 Object9
GRASP – Controlador de
Fachada
System
Object8
externalSystem
facade
Object7
Object6
Object9

28

GRASP – Controlador de Fachada

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

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

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

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