Ingeniería de Software II

Conferencia 5

Patrones de Diseño
Objetivos:

•
Definir los patrones.
•
Conocer la influencia de los patrones en el
desarrollo de software.
•
Aprender a aplicar los patrones GRASP.
 ¿Qué conoce un programador experto
que desconoce uno inexperto?

Reutilizar soluciones que funcionaron

en el pasado.
EXPERIENCIA

REUTILIZACIÓN
¿Qué es un Patrón de Diseño?

“Un patrón describe un problema que

ocurre una y otra vez en nuestro
ambiente y que describe el núcleo de la
solución a este problema de una forma
que puede ser reusada millones de
veces, sin hacerlo de la misma forma
cada vez”
(Christopher Alexander 1995)
 Orígenes de los Patrones

Christopher Alexander: patrones en edificios

∙ Publica los libros “A Pattern Language” (1977) y
“The Timeless Way of Building” (1979)
∙ Acuña el término “patrón” sobre 1977-1979

Pioneros
∙ Kent Beck y Ward Cunningham, Textronix (OOPSLA'87)
Usan las ideas de “patrones” de Alexander para el diseño de
GUIs en Smalltalk

∙ Erich Gamma, en su tesis doctoral (1988-1991)

∙ James Coplien, en su libro “Advanced C++ Idioms” (1989-

1991)
 Patrones en el desarrollo de Software

» El Gang-of-Four (GoF): Erich Gamma, Richard Helm, Ralph

Johnson y John Vlissides.
∙ Publican “Design Patterns” (1995), dando nombre y modelo
de los 20 patrones más usados
∙ El libro solidifica el uso de patrones y se convierte en la
referencia clásica

» Conferencias sobre patrones

∙ PLoP (Pattern Languages of Programming): 1994-actualidad
› Cada año se presentan nuevos patrones y catálogos de
Patrones

» Libro POSA “Pattern-Oriented Software Architecture: A

System of Patterns”
∙ Autores: Buschmann, Meunier, Rohnert, Sommerland, Stal
Arquitectura Software y Patrones
“Una arquitectura orientada a objetos bien
estructurada está llena de patrones. La
calidad de un sistema orientado a objetos se
mide por la atención que los diseñadores
han prestado a las colaboraciones entre sus
objetos.”

“Los patrones conducen a arquitecturas más

pequeñas, más simples y más
comprensibles”
G. Booch
Patrones: ¿Qué ganamos?

Utilizar de forma racional el

conocimiento acumulado.

Comunicación operativa.

Mayor probabilidad de triunfo.

Soluciones más reutilizables.

 Patrones

Patrones para Casos de Uso

Patrones de Análisis
Objetivo de Patrones de Arquitectura
hoy Patrones de Diseño
Patrones de implementación
Patrones de Prueba
Patrones de diseño en RUP

Flujo Análisis & Diseño

Patrones de diseño en RUP
Análisis & Diseño / Diseñar Componentes

Actividad:
Diseño de Clases
 Patrones GRASP
Craig Larman. UML y Patrones. Introducción
al Análisis y Diseño orientado a objetos.
Patrones Generales de Software para Asignar
Responsabilidades GRASP (General Responsibility
Assignment Software Patterns)

Patrones GRASP
1. Experto 6. Polimorfismo
2. Creador 7. Fabricación Pura
3. Controlador 8. Indirección
4. Bajo Acoplamiento 9. No hables con extraños
5. Alta Cohesión
 Patrones GRASP

Patrones Formato de un Patrón

1. Experto Nombre
2. Creador. Solución
3. Controlador Problema
4. Bajo Acoplamiento Explicación
5. Alta Cohesión Ejemplo de utilización
 Patrones de Diseño de Larman
Experto

Problema: ¿Cuál es un principio general para

asignar responsabilidades a los objetos?

Solución: Asignar una responsabilidad a la

clase que tiene la información necesaria
para cumplimentarla.
Caso de Estudio TPDV
¿Quién es el responsable de conocer el monto total de la venta?

¿Qué información se necesita para calcular el monto total de la venta?

¿Qué información hace falta para calcular el subtotal de la
Línea de venta?
En conclusión, para cumplir con la responsabilidad de
conocer y dar el total de la venta, se asignaron tres
responsabilidades a las tres clases de objeto así:

CLASE RESPONSABILIDAD

EspecificacionDelProducto Conocer el precio

del producto

LineaDeVenta Conocer el subtotal

de la línea de venta

Venta Conocer el total de

la venta
 Patrones de Diseño de Larman
Creador
Problema: ¿Quién debería ser el responsable de la creación
de una nueva instancia de alguna clase?

Solución: Asignar a la Clase B la responsabilidad de crear a

A si:

1. B agrega los objetos A.

2. B contiene los objetos A.
3. B registra las instancias de la clase A.
4. B utiliza específicamente los objetos A.
5. B tiene los datos de inicialización que serán
transmitidos a A cuando este objeto sea creado.
Patrón Creador
 Patrones de Diseño de Larman
Bajo Acoplamiento

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 de demasiados
otros elementos; "demasiados“ depende del contexto. Estos elementos
pueden ser clases, subsistemas, sistemas, etcétera.

Problema: ¿Cómo dar soporte a una dependencia escasa y a

un aumento de la reutilización?

Solución: Asignar una responsabilidad para mantener bajo

acoplamiento
 Formas comunes de
Acoplamiento

El TipoX tiene un atributo (miembro de datos, o variable de instancia)
que hace referencia a una instancia de TipoY, o al propio TipoY.


Un objeto de TipoX invoca los servicios de un objeto de TipoY.


El TipoX tiene un método que referencia a una instancia de TipoY, o
al propio TipoY, de algún modo. Esto, generalmente, comprende un
parámetro o variable local de TipoY, o que el objeto de retorno de un
mensaje sea una instancia de TipoY.


El TipoX es una subclase, directa o indirecta, del TipoY.


El Tipo Y es una interfaz y el TipoX implementa esa interfaz.
Bajo Acoplamiento
 Patrones de Diseño de Larman

Alta Cohesión
Problema: ¿Cómo mantener la complejidad dentro de límites
manejables?

Solución: Asignar una responsabilidad de modo que la

cohesión siga siendo alta.
Alta Cohesión
 Patrones de Diseño de Larman
Controlador
Problema:¿Quién debería encargarse de atender un evento
del sistema?
Solución: Asignar la responsabilidad del manejo de un mensaje
de los eventos de un sistema a una clase que represente una
de las siguientes opciones:

1. El "sistema" global (controlador de fachada).

2. La empresa u organización global (controlador de fachada).
3. Algo en el mundo real que es activo (por ejemplo, el papel de una
persona) y que pueda participar en la tarea (controlador de tareas).
4. Un manejador artificial de todos los eventos del sistema de un caso
de uso, generalmente denominados
"Manejador<NombreCasodeUso>" (controlador
de casos de uso).
 Patrón Controlador
Acoplamiento menos conveniente entre la capa de interfaz y la del dominio
Acoplamiento deseable entre la capa de interfaz y la del dominio
 Patrón Indirección

Problema que resuelve: Acoplamientos

directos a veces provocan un alto acoplamiento
y limitan la posibilidad de reutilización.

Solución: Una clase que sirva de interfaz,

creando una indirección.
Caso de Uso: Asignar especialista de Arte
Obtener los especialistas de arte especializados
en un conjunto de técnicas.
 Ejemplo de Patrón Indirección
Galería de arte
Caso de Uso: Asignar especialista de Arte
Obtener los especialistas de arte especializados
en un conjunto de técnicas.
 Patrón Polimorfismo

Problema que resuelve: Hay varias

implementaciones de un mismo algoritmo
dentro del sistema.

Solución: Una clase abstracta con la interfaz

genérica que deben tener todas las
implementaciones y tantas clases concretas
como implementaciones existan.
Ejemplo de Patrón Polimorfismo
Criptografía
Criptografía

Criptografía Cifrar()
Descifrar()

CifrarCliente()
DescifrarCliente()
CifrarServidor()
DescifrarServidor() Criptografía cliente Criptografía servidor

Cifrar() Cifrar()
Descifrar() Descifrar()
 Bibliografía
UML y Patrones. 2da Edición. Craig Larman,
Capítulo 16. páginas 160-186

Design Patterns. Elements of Rehusable Object-

Oriented Software.Erich Gamma, Richard Helm, Ralph Johnson,
John Vlissides (GoF).