PATRONES

Eva Lleonart Martín

Asunción García-Menacho Rovira
Facultad de Informática - Universidad Politécnica de Valencia

1. Introducción

Los casos de usos se han llegado a convertirse en la base de muchas

metodologías de desarrollo orientadas a objetos. Estos generalmente
proporcionan el fundamento y el punto de partida para el resto de los
procesos de análisis y desarrollo. Un caso de uso es una secuencia de
transacciones en un sistema cuya tarea es producir un valor medible
de un actor individual del sistema. Uno de los aspectos más
importantes de los casos de uso específica la funcionalidad completa
de un sistema.

Por otra parte el uso de patrones para el desarrollo de software

establece la diferencia entre un buen y un mal diseño orientado a
objetos. Un patrón es un fragmento nombrado de información
instructiva, que captura la estructura esencial y la visión interna de
una familia de soluciones con probado éxito sobre un problema
recurrente que surge dentro de un cierto contexto y fuerzas de
sistema. En otras palabras, rehusar soluciones que funcionaron bien
una vez.

2. ¿Qué es un patrón?

En programación orientada a objetos se entiende por patrón una

solución probada que se puede aplicar con éxito a un determinado
tipo de problemas que aparecen repetidamente en el desarrollo de
sistemas software.

Los patrones no son una librería. Van más bien en la línea de un

esqueleto básico que cada desarrollador luego adapta a sus
necesidades y a las peculiares características de su aplicación. Se
describen fundamentalmente en forma textual, acompañada de
diagramas y de seudo-código.

Definiciones:

 “Un patrón es un pedazo de información con nombre,

instructivo y significante, que captura la esencia de una
familia exitosa y completa de soluciones a un problema
recurrente en un contexto dado” Brad Appleton
 “Cada patrón es una regla de tres partes, la cual expresa
una relación entre un contexto dado, un conjunto de
1
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
fuerzas que ocurren repetitivamente en ese contexto y
cierta configuración de software que permite a esas
fuerzas resolverse por si mismas” Richard Gabriel

2
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
 “Cada patrón es una regla de tres partes, la cual expresa
una relación entre un cierto contexto, un problema y una
solución. El patrón es, resumiendo, al mismo tiempo una
cosa que tiene su lugar en el mundo, y la regla que nos
dice cómo crear esa cosa y cuándo debemos crearla. Es al
mismo tiempo una cosa y un proceso; al mismo tiempo
una descripción de una cosa que tiene vida y una
descripción del proceso que la generó” Christopher
Alexander, The Timeless Way of Building, 1.979
 Un buen patrón debe:
–Solucionar un problema: Un patrón captura soluciones,
no solo principios abstractos o estrategias
–Es un concepto probado
–La solución no es obvia
–Describe una relación: No solo describen módulos,
describen estructuras y mecanismos
–Tiene un componente humano significante: es estético y
de utilidad
James Coplien
 “Estos patrones en nuestras mentes son, más o menos,
imágenes mentales de los patrones en el mundo: son
representaciones abstractas de las reglas morfológicas
que definen los patrones en el mundo. Sin embargo, son
realmente diferentes. Los patrones en el mundo solo
existen. Pero esos mismos patrones en nuestras mentes
son dinámicos. Tienen fuerza. Son generativos. Nos dicen
qué hacer, cómo se pueden generar y, en ciertas
circunstancias, que los debemos crear. Cada patrón es
una regla que describe que debemos hacer para generar
la entidad que los define” Christopher Alexander , The
Timeless Way of Building, 1.979

3. Desarrollo histórico

El término patrón se utiliza inicialmente en el campo de la

arquitectura, por Christopher Alexander, a finales de los 70s. Este
conocimiento es trasportado al ámbito del desarrollo de software
orientado por objetos y se aplica al diseño. De allí es extrapolado al
desarrollo en general y a las demás etapas. Algunos libros que
marcan el desarrollo del área son:
 Alexander, Christopher. A Pattern Language: Towns, Buildings,
Construction. 1977
 Alexander, Christopher. The Timeless Way of Building. 1979
 Gamma et al. Design Patterns: Elementos of Reusable Object-
Oriented Software. 1994

3
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
  Bushmann et al. Pattern-Oriented Software Architecture: A
System of Patterns. 1996
 Coplien y Schmidth. Pattern Languages of Program Design.
1995

Algunos eventos importantes en la historia del tema de patrones en

Ingeniería de software son:
 1987. Ward Cunningham y Kent Beck escriben sus experiencias
de enseñar Smalltalk por medio de las ideas de Alexander en
Using Pattern Languages for Object-Oriented Programs.
 1990. El GoF empiezan la recopilación de patrones de diseño
 1991. Jim Coplien publica su recopilación de idioms de C++ en
Advanced C++ Programming Styles and Idioms.

1994. El GoF publica el libro Design Patterns: Elementos of Reusable

Object-Oriented Software.

4. Tipos de patrones

Existen varios tipos de patrones, dependiendo del nivel de

abstracción, del contexto particular en el cual aplican o de la etapa en
proceso de desarrollo. Algunos de estos tipos son:

 De arquitectura
 De diseño

 Idioms

 De análisis

 Para ambientes distribuidos

 De negocios

 De procesos y organizacionales

4.1. Patrones de arquitectura

Son esquemas fundamentales de organización de un sistema

software.

Especifican una serie de subsistemas y sus responsabilidades

respectivas e incluyen las reglas y criterios para organizar las
relaciones existentes entre ellos.

Se recogen aquí ocho patrones estructurales, agrupados en cuatro

categorías:
4
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
 Niveles
Del caos a la
organización Tuberías y filtros

Pizarra

Sistemas distribuidos Intermediario o broker

MVC: Modelo-Vista-Controlador
Sistemas interactivos
PAC: Presentación, Abstracción,
Control
Microkernel
Sistemas adaptables
Reflexión

4.2. Patrones de diseño

Son patrones de un nivel de abstracción menor que los patrones de

arquitectura. Están por lo tanto más próximos a lo que sería el código
fuente final. Su uso no se refleja en la estructura global del sistema.

Características de los patrones de diseño

 Son soluciones concretas. Un catálogo de patrones es un

conjunto de recetas de diseño. Aunque existen clasificaciones de
patrones, cada uno es independiente del resto.

 Son soluciones técnicas. Dada una determinada situación, los

patrones indican cómo resolverla mediante OO. Hay patrones
específicos para un determinado lenguaje y otros de carácter más
general.

 Se aplican en situaciones muy comunes. Los patrones de

diseño proceden de la experiencia, y han demostrado su utilidad
resolviendo problemas que aparecen frecuentemente en el DOO.

5
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
 Son soluciones simples. Indican cómo resolver un problema
particular utilizando un pequeño número de clases relacionadas de
forma determinada. No indican cómo diseñar un determinado
sistema sino sólo aspectos puntuales del mismo.

 Facilitan la reutilización de las clases y del propio diseño.

Los patrones favorecen la reutilización de clases ya existentes y la
programación de clases reutilizables. La propia estructura del
patrón es reutilizada cada vez que se aplica.

 El uso de un determinado patrón no se refleja claramente

en el código. A partir de la implementación es difícil determinar
que patrón de diseño se ha usado.

 Referencias a self. Muchos patrones utilizan la delegación de

operaciones y esto provoca el problema del self.

 Es difícil reutilizar la implementación de un patrón. Las

clases del patrón son roles genéricos, pero en la implementación
aparecen clases concretas.

 Los patrones suponen una sobrecarga de trabajo a la hora

de implementar. Se usan más clases, es necesario delegar
mensajes, etc.

Se pueden organizar los patrones según familias de patrones

relacionados . La clasificación facilita la búsqueda del patrón más
adecuado así como su comprensión . Gamma clasifica los patrones
según dos criterios fundamentales: su propósito y su alcance [Gamma
95].

El propósito refleja lo que realiza el patrón . Los patrones pueden

tener propósito de creación, estructural o de conducta. Los patrones
con propósito de creación conllevan el proceso de creación de
objetos. Los patrones estructurales tratan de la composición de clases
u objetos. Los patrones de conducta describen las formas en que las
clases u objetos interactúan o distribuyen responsabilidades.

6
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
El alcance indica si el patrón aplica principalmente a clases u objetos.
Los patrones de clases tratan de relaciones entre clases y sus
subclases. Estas relaciones se establecen a través de la relación de
herencia, por consiguiente son estáticas y definidas en tiempo de
compilación. Los patrones de objetos tratan de relaciones entre
objetos que pueden ser cambiadas en tiempo de ejecución y son más
dinámicas. Casi todos los patrones utilizan la herencia de alguna
forma. Pero son los patrones de clases los que se focalizan en las
relaciones de clase.

Los patrones con propósito de creación y alcance de clase difieren

parte de la creación de objetos a subclases mientras que los patrones
con propósito de creación y alcance de objeto difieren ésta a otros
objetos. Los patrones estructurales y alcance de clase utilizan la
herencia para componer clases, mientras que los patrones
estructurales y alcance de objeto describen formas de ensamblado de
objetos. Los patrones de conducta con alcance de clase utilizan
herencia para describir algoritmos y flujos de control mientras que los
patrones de conducta con alcance de objeto describen como un grupo
de objetos cooperan para realizar una actividad que un objeto no
puede realizar por sí solo.

La tabla 1 muestra la clasificación propuesta por Gamma de algunos

de los patrones más utilizados actualmente [Gamma 95]

Creación Estructural De Conducta

Interprete
Método de Adaptador
Clase
Fabricación (clases)
Plantilla
Cadena de
Adaptador
Objeto Fábrica Responsabilid
(objetos)
ad
Constructor Puente Comando
Prototipo Composición Iterador
Singleton Decorador Intermediario
Fachada Observador
Flyweight Estado
Apoderado Estrategia
Visitante
Memoria

Tabla 1. Clasificación de Patrones de Diseño

7
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
4.2.1. Ejemplo de patrón de diseño

Como ejemplo de patrón de diseño se mostrará el patrón

intermediario.

Patrón Intermediario

 Este patrón define un objeto que encapsula como un conjunto

de objetos interaccionan. El intermediario facilita el
acoplamiento mínimo, evitando que los objetos participantes se
tengan que referenciar entre ellos explícitamente , con lo que
se permite variar su interacción independientemente. Los
objetos participantes solo conocen al intermediario.
 El desarrollo orientado a objetos potencia el reparto de
conducta entre objetos. Tal reparto puede resultar en una
arquitectura donde existen múltiples conexiones entre los
objetos. En el peor de los casos cada objeto debería conocer a
todos los demás. Esto dificulta la reutilización. Se puede evitar
esta situación, encapsulando la conducta colectiva en un objeto
llamado intermediario. Un intermediario es responsable de
controlar y coordinar las interacciones de un grupo de objetos.
Esto puede ser útil como se verá en el ejemplo de interacciones
entre elementos gráficos.
 La estructura del patrón siguiendo la notación OMT para el
diagrama de clases es como sigue:

8
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
Figura 1. Patrón Intermediario

 Un ejemplo de utilización de este patrón es la implementación

de cajas de dialogo en una interfaz gráfica . Una caja de dialogo
utiliza una ventana para presentar una colección de elementos
gráficos tales como botones, menús o campos de entrada.
Frecuentemente existen dependencias entre los elementos
gráficos en el dialogo. Por ejemplo un botón esta inhabilitado
cuando cierto campo de entrada esta vacío. Seleccionando una
entrada de una lista de opciones llamada una caja tipo lista
podría cambiar los contenidos de un campo de entrada. Se
puede encapsular esta conducta en un intermediario, llamado
en el ejemplo Director_Dialogo.

Es importante resaltar los siguientes aspectos:

 Cada objeto de las clases participantes es decir los objetos

gráficos de tipo List_Box o Entry _Field solo conoce a su
intermediario concreto .
 Siempre que un objeto gráfico requiera comunicarse con otro ha
de hacerlo a través de su intermediario (Director_Dialogo).

Figura 2. Ejemplo del Patrón Intermediario

5. Patrones y componentes

Cabría aquí preguntarse por la diferencia entre patrones de diseño y

componentes . Encontramos en el mercado una serie de productos
que incorporan un conjunto de elementos, denominados
componentes y que permiten construir de forma rápida partes de la
aplicación, en particular la interfaz de usuario. La disponibilidad
inmediata de botones, ventanas, menús desplegables, etc hacen que
la construcción de una interfaz gráfica sea desde un punto de vista
técnico una tarea relativamente sencilla. Los problemas de
interacción con el usuario y el nivel de usabilidad tienen que ver con
9
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
problemas de diseño más complejos que con la construcción 'física'
de la interfaz.

La diferencia fundamental con un patrón es que el componente es

una combinación fija de objetos, que se puede instanciar mediante el
arrastre desde un icono que lo representa y que se incorpora
inmediatamente a la aplicación que se está construyendo. Esto
significa que se trata de clases que combinan un conjunto de otras
formando macroobjetos pero que están integradas en la librería de
clases suministrada con el producto. De esta manera, se pueden ir
implementando nuevos componentes a los cuales se asociarán íconos
que los identifiquen y que permitan utilizarlos de la misma manera
que los suministrados originalmente con el producto.

Los patrones, por su lado, no forman parte de ninguna librería de

clases . Sólo son modelos de combinación que pueden utilizarse en el
momento que se presenta un problema similar al que pretende dar
solución el patrón correspondiente. A lo sumo, y en una instalación
muy bien organizada, podrían almacenarse en una base de datos a la
cual accedemos cuando nos enfrentamos a las diversas decisiones de
diseño durante las fases de análisis y de diseño.

6. Descripción de patrón y plantillas de patrones

Dependiendo del autor, del nivel de abstracción y de la publicación

misma se han presentado varios formatos para encapsular la
información de un patrón. Los puntos más significativos que debe
contener un patrón son:
 Nombre: Significativo y corto, fácil de recordar y asociar a la
información que sigue
 Problema: Un enunciado que describe las metas y objetivos
buscados y el contexto
 Contexto: Define las precondiciones en las cuales ocurren el
problema y su solución
 Fuerzas: Descripción de las fuerzas y restricciones relevantes en
el problema y como interactúan o entran en conflicto
 Solución: Las relaciones estáticas y reglas dinámicas que
describen cómo solucionar el problema
 Ejemplos: Uno o más ejemplos que ilustren el contexto, el
problema y su solución
 Contexto Resultante: El estado en el cual queda el sistema
después de aplicar el patrón y las consecuencias de hacerlo
 Racionalidad: Una explicación justificada de los pasos o reglas
en el patrón
 Relaciones: relaciones estáticas y dinámicas del patrón con
otros

10
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
  Usos conocidos: Describe ocurrencias del patrón conocidas y su
aplicación dentro de los sistemas existentes

La propuesta de Gamma (1995), por ejemplo, propone que los

elementos esenciales de un patrón son los siguientes:

1. Un nombre del patrón. Es una forma abreviada que pueda darnos

una idea del problema al que se aplica, sus soluciones y
consecuencias. Al asignar un nombre, estamos facilitando la tarea de
diseño puesto que nos comunicamos a un mayor nivel de abstracción.
Es bastante difícil encontrar nombres adecuados que sirvan a este
propósito.

2. El problema describe cuando aplicar el patrón. Aquí se explica el

problema y su contexto. Un añadido útil es el de las condiciones de
aplicabilidad del patrón.

3. La solución describe los elementos que constituyen el diseño, sus

relaciones, responsabilidades y colaboraciones. Se insiste mucho en
que esta solución es como una plantilla que provee una descripción
abstracta de un problema de diseño y cómo una disposición general
de elementos (en este caso clases y objetos) puede resolverlo.

4. Las consecuencias son los resultados y compromisos de aplicar el

patrón.

Estos son los elementos esenciales, pero cuando se trata de realizar

una descripción concreta de un patrón, la plantilla propuesta estará
compuesta por una serie de secciones que permiten una estructura
más detallada que la ofrecida por la enumeración de los elementos
esenciales.

Siguiendo a Gamma, encontramos la siguiente lista y descripción de

secciones dentro de la plantilla que describe cada patrón. Este
formato estructurado es útil puesto que permite la separación
semántica de lo que podría haber sido un texto completo y permite
además su almacenamiento en una base de datos para su posterior
acceso si deseamos aumentar su reutilización.

1) Nombre del Patrón y Clasificación, 2) Intención

3) También conocido como (Sinónimo), 4) Motivación, 5) Aplicabilidad

6) Estructura, 7) Participantes, 8) Colaboraciones

9) Consecuencias, 10) Implementación

11
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
11) Ejemplo de código, 12) Usos conocidos y Patrones relacionados

12
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia