Patrones eva Lleonart Martín Asunción García-Menacho Rovira



Descargar 103,79 Kb.
Página2/2
Fecha de conversión06.01.2017
Tamaño103,79 Kb.
1   2

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

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



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:



Del caos a la organización

Niveles

Tuberías y filtros

Pizarra

Sistemas distribuidos

Intermediario o broker

Sistemas interactivos

MVC: Modelo-Vista-Controlador

PAC: Presentación, Abstracción, Control

Sistemas adaptables

Microkernel

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.

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

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

Clase

Método de Fabricación

Adaptador (clases)

Interprete

Plantilla



Objeto

Fábrica

Adaptador (objetos)

Cadena de Responsabilidad

 

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

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:


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

  • 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) Ejemplo de código, 12) Usos conocidos y Patrones relacionados


Laboratorio de Sistemas de Información

Facultad de Informática

Universidad Politécnica de Valencia



1   2


La base de datos está protegida por derechos de autor ©absta.info 2016
enviar mensaje

    Página principal