pLinker: Relaciones con Patrones de Diseo

Leonardo Liebener1,2, Marcos Andrs Rossi1,2 and Claudia Marcos1

ISISTAN Research Institute, Facultad de Ciencias Exactas, UNICEN Paraje Arroyo Seco, B7001BBO Tandil, Argentina Tel/Fax: + 542293440362/3 http://www.exa.unicen.edu.ar/~isistan/ E-mail: [lliebner, mrossi, cmarcos]@exa.unicen.edu.ar
1

TELPIN Cooperativa Telefnica de Pinamar Jason 1026, B7167ACT Pinamar, Argentina Tel: + 54-2254-483000 Fax: + 54-2254-482024 http://www.telpin.com.ar/sistemas E-mail: [lliebener, mrossi]@telpin.com.ar

Resumen. Los patrones de diseo se han convertido en una tcnica importante para el reuso de conocimiento de software. Cada patrn provee informacin sobre su diseo, describiendo las clases, mtodos y relaciones que resuelven un problema de diseo en particular. Sin embargo, su documentacin no brinda informacin sobre la integracin de los mismos en un diseo existente, simplemente describen de manera poco detallada los patrones con los cuales esta relacionado. Este trabajo, presenta una clasificacin de las relaciones entre patrones y cmo la estructura de clases de un diseo existente se ve afectada al incorporar un nuevo patrn. Con el objetivo de asistir al usuario en la construccin de diseos utilizando patrones y sus relaciones, se implement pLinker. Dicha herramienta permite construir diagramas de clase UML e incorporar patrones en ellos.

Palabras claves: Patrones de diseo, Arquitecturas de software, Desarrollo de software OO.

1. Introduccin
Los patrones de diseo se han convertido en una tcnica popular para el reuso de conocimiento de diseo de software. La motivacin principal de los patrones de diseo la constituye el hecho de encontrar frecuentemente, en diferentes diseos, problemas similares. Los patrones de diseo de software son patrones de organizacin de jerarquas de clases, protocolos y distribucin de responsabilidades entre clases que caracterizan construcciones elementales del diseo orientado a objetos. Es decir, un patrn es una estructura de clases que aparece repetidamente en diversos diseos orientados a objetos, la cul es utilizada para resolver un problema determinado de forma flexible y adaptable dinmicamente. El propsito de un patrn de diseo es capturar el conocimiento de un diseo de software y hacerlo reusable. Los patrones han sido agrupados y organizados en catlogos ([BMRS+96], [GHJV95], [Grand98]), cada uno dando diferentes clasificaciones y descripciones. Algunos catlogos describen patrones de anlisis mientras que otros patrones de diseo, incluyendo tambin patrones de un dominio particular, o bien, independientes del dominio. El proceso de construccin de aplicaciones utilizando patrones se reduce a que, cada vez que el diseador encuentra un problema, busca en los catlogos un patrn que lo resuelva. Si no existiera tal patrn, el diseador debe pensar en una solucin. En cambio, si existe un patrn, el diseador puede aplicarlo en su diseo. En general, esto significa que los elementos de diseo de la descripcin correspondiente al patrn deben ser mapeados e integrados con los elementos de diseo preexistente. Es decir, se deben identificar las clases, mtodos y atributos de la aplicacin que juegan el rol de aquellos prescritos por el patrn. Lamentablemente, los aspectos que implican integrar un patrn en un diseo parcial existente no son resueltos por la descripcin de los patrones. Cada patrn provee informacin acerca de su propia implementacin de una manera informal, pero no resuelve uno de los aspectos generales de la arquitectura de software con patrones, como es la integracin de los mismos en diseos preexistentes. Es decir, no existe una gua o descripcin que asista al diseador a la hora de integrar un patrn a un diseo existente.

Por otro lado, en la mayora de los catlogos, como parte de la descripcin de cada patrn, se mencionan posibles relaciones de ste con otros patrones de diseo. Estas relaciones muestran que un patrn puede complementar, de alguna manera, la funcionalidad de otro; o bien puede servir como alternativa del mismo. As, se puede notar que si se aplica un determinado patrn quizs se lo pueda utilizar en conjunto con algn otro patrn relacionado para obtener una solucin de diseo ms completa. Desafortunadamente, la descripcin de dichas relaciones no se encuentra documentada de la misma manera en la que se documenta un patrn de diseo. Ms bien se trata de una descripcin informal o poco detallada. Generalmente slo se hace referencia al nombre del patrn que puede ser usado en conjunto con un patrn de diseo dado para mejorar o complementar su funcionalidad, pero no se describe en que manera se ve afectada la estructura de clases del primero para reflejar esta relacin. Entonces, la descripcin no ayuda al diseador a integrar dos patrones relacionados para lograr una solucin de diseo ms completa. Esto hace dificultosa la tarea de construir un diseo de software aprovechando las relaciones entre los patrones. De manera de ayudar y asistir al diseador en la construccin de aplicaciones con patrones de diseo, este trabajo propone una clasificacin de las diferentes relaciones entre patrones. Se han analizado diferentes catlogos de patrones de diseo y definido relaciones entre ellos. Dichas relaciones han sido documentadas siguiendo un esquema de documentacin similar al que es utilizado para describir patrones de diseo, lo cual facilita la comprensin y la forma de aplicacin de las relaciones entre patrones. Con el objetivo de asistir al usuario en la construccin de diseos utilizando patrones y sus relaciones de manera simple, se implement pLinker. Esta herramienta permite construir diagramas de clase UML e incorporar patrones en ellos. Una vez incorporado un patrn, la herramienta mostrar las relaciones existentes del patrn aplicado con el resto de los patrones y proveer acciones a desarrollar, o puede desarrollar actividades automticamente, de manera de incorporar el segundo patrn al diseo. El trabajo esta organizado de la siguiente manera. A continuacin se describen las relaciones entre patrones de diseo definidas y el esquema de documentacin utilizado. Seccin 3 presenta la herramienta pLinker con sus caractersticas y sus dos modos de trabajo mostrando cada uno de ellos por medio de un ejemplo. Por ltimo, en la Seccin 4 se presentan las conclusiones de este trabajo.

2. Relaciones entre patrones

En la mayora de los catlogos, los patrones estn documentados por medio de una plantilla o ficha descriptiva. Como parte de esta ficha, cada patrn debe indicar, entre otras cosas, sus relaciones con otros patrones. Pero, desafortunadamente estas relaciones se encuentran descriptas muy brevemente y adems, los diferentes catlogos de patrones describen distintas relaciones de diferentes maneras. Es decir, cada catlogo o libro de patrones de diseo, describe a las relaciones entre los patrones usando su propia clasificacin idiomtica de esas relaciones. Por ejemplo, las relaciones en [GHJV95] son descriptas de manera informal, usando el lenguaje natural. Generalmente slo se hace referencia al nombre del patrn que puede ser usado en conjunto con un patrn de diseo dado para mejorar o complementar su funcionalidad, pero no se describe en que manera se ve afectada la estructura de clases del primero para reflejar esta relacin. Entonces, la descripcin, no ayuda al diseador a integrar dos patrones relacionados para lograr una solucin de diseo ms completa. Esta inconsistencia, hace que los patrones sean difciles de utilizar. La relacin de un patrn con otro es, desde la perspectiva de este trabajo, una de las partes ms importantes de la descripcin de los patrones; y la inconsistencia de las descripciones hace que sea difcil, para los diseadores, entender estas relaciones y aprovechar as las ventajas de los patrones de diseo. Se han definido y clasificado los tipos de relaciones existentes entre patrones de diseo. Esta categorizacin surgi luego del estudio exhaustivo de algunos de los catlogos de patrones ms importantes ([GHJV95], [BMRS+96], [Grand98], [Larman98]), y tiene el propsito de ayudar al diseador a comprender mejor las relaciones entre los patrones. En el mismo, se propone un esquema de documentacin similar al que es utilizado para describir patrones de diseo, lo cul facilita la comprensin y la forma de aplicacin de las relaciones entre patrones.

1.1. Documentacin de relaciones

Para describir los distintos tipos de relaciones definidas se utiliza un esquema de documentacin en la cul la descripcin de cada tipo de relacin est organizada en diferentes secciones, descriptas a continuacin. La plantilla permite que la estructura de la informacin sea uniforme, haciendo ms simple la comprensin y posible utilizacin de los tipos de relaciones encontradas. Nombre de la relacin: el nombre con el cul se identifica al tipo de relacin. Descripcin: en esta seccin se muestran los detalles del tipo de relacin. Entre estos detalles se puede encontrar, una descripcin del contexto de aplicacin de la relacin, la descripcin de la funcionalidad adicional proporcionada por el segundo patrn de la relacin, la categora de los patrones involucrados, etc. Momento de aplicacin: esta propiedad establece cundo puede ser aplicada una relacin dada entre dos patrones. Bsicamente, una relacin es aplicable antes de utilizar un patrn en el diseo preexistente (pre-aplicable), implcitamente con la aplicacin del patrn (implcito), o bien, despus que un patrn ha sido aplicado en el diseo del usuario (post-aplicable). Consecuencias de la aplicacin: en esta seccin se describen las implicancias, las ventajas y desventajas de la aplicacin de la relacin. Acciones a realizar sobre la estructura del patrn original: describen el objetivo que tienen las acciones a realizar sobre la estructura de clases del patrn original para reflejar su relacin con el segundo patrn. Este apartado no siempre est disponible ya que depende del momento de aplicacin de la relacin (generalmente presente en relaciones post-aplicables). Un ejemplo de una accin podra ser: Agregar un mtodo llamado op1() a la clase MyClass. Actividades a realizar luego de la aplicacin de la relacin: una actividad es una tarea pendiente que debe ser llevada a cabo posteriormente a la aplicacin de la relacin para completar el uso de la misma. Generalmente, estas actividades son expresadas en lenguaje natural. En la descripcin del tipo de relacin generalmente se indica cual es el objetivo, o como surgen las actividades asociadas a la relacin y pueden tener asociada una prioridad que indique su grado de importancia. Vnculos entre clases: los vnculos entre clases establecen la correspondencia de las clases del segundo patrn (X) con las del primero (Y), es decir, se indica cual es el rol de cada clase del patrn Y en la estructura de clases del patrn X. Ejemplos: para finalizar con la descripcin del tipo de relacin es importante mostrar ejemplos con patrones de diseos reales, que ayude a la identificacin y comprensin del tipo de relacin.

1.2. Tipos de Relaciones

Se han definido seis tipos de relaciones entre patrones de diseo, las cuales son descriptas brevemente a continuacin: X es alternativa de Y: este tipo de relacin se establece entre dos patrones que proponen dos soluciones mutuamente excluyentes a un problema de diseo. Es decir, no pueden convivir la estructura de ambos patrones en un diseo para resolver un determinado problema. X especializa a Y: es una relacin unidireccional que se establece entre dos patrones que poseen la misma estructura, se aplican bajo el mismo contexto y tienen una motivacin similar, pero el patrn X incorpora nueva funcionalidad para soportar requerimientos adicionales o se comporta de manera diferente. Es decir, en este tipo de relacin, X trata con una especializacin del problema que trata Y. X crea a Y: generalmente, el primer patrn que conforma la relacin (X) forma parte de la categora de patrones creacionales, mientras que el patrn Y forma parte de la categora de patrones estructurales. Se trata de una relacin unidireccional en la que el patrn X crea una o ms estructuras de clases similares a las que conforman la solucin del patrn Y.

X usa a Y en su solucin: al construir la solucin para el problema en el que se enfoca el patrn de diseo X, un subproblema es similar al problema al que apunta el patrn de diseo Y. En consecuencia, el patrn de diseo X usa al patrn de diseo Y en su solucin. Esto implica, que la estructura de clases de Y utiliza una parte de la estructura de clases de X. Se trata de una relacin unidireccional. X se usa en conjunto con Y: este tipo de relacin es la ms simple de detectar. Se puede dar entre patrones de diferentes categoras. Al combinar el patrn X con el patrn Y, se logra una solucin de diseo ms completa. Cuando esta relacin es usada, la estructura de clases del patrn Y debe ser integrada a la estructura de clases del patrn X. X se aplica en cascada: este tipo de relacin es establecida entre dos instancias de un mismo patrn de diseo. Algunos patrones pueden ser aplicados repetidamente para resolver un problema de diseo. Es decir, la estructura de diseo de un patrn es combinada con la misma estructura repetidamente, para resolver problemas de diseo ms complejos. Por ejemplo la relacin X se usa en conjunto con Y es documentada de la siguiente manera: Descripcin: dos patrones se usan en conjunto para brindar una solucin a un problema de diseo que no es resuelto directamente por ningn otro patrn. En casos simples, generalmente se puede encontrar un patrn de gran escala que resuelve un problema completo y otro patrn de menor escala que provee la solucin a un subproblema. Por otro lado, en situaciones ms complejas, dos patrones se combinan para producir una solucin a un problema. El problema mismo y la manera en la cul estos patrones son combinados no se encuentran explcitamente capturado en las descripciones de dichos patrones. Aqu, todo patrn puede ser considerado para usarlo en conjunto con cualquier otro patrn, para brindar una solucin a un problema de gran escala que no se encuentra resuelto por ningn patrn individual. Cuando esta relacin es activada, la estructura de clases del patrn Y debe ser integrada a la estructura de clases del patrn X. Consecuencias de la aplicacin: las consecuencias de utilizar este tipo de relacin en un diseo pueden expresarse como el resultado de aplicar el primer patrn, junto con el resultado de aplicar el segundo patrn involucrado en la relacin. Las consecuencias de aplicar cada uno de los patrones involucrados en la relacin en un diseo, pueden encontrarse documentadas en la ficha descriptiva del catlogo a cual pertenece cada uno de los patrones. Momento de aplicacin: el momento de aplicacin de esta relacin es posterior (post-aplicable) al uso del patrn X. Al seleccionar el patrn X, cualquier otro patrn puede ser considerado para combinarlo con X, con el fin de proveer una estructura de solucin ms completa al problema que se est tratando de resolver. Acciones a realizar sobre la estructura del patrn original: las acciones que surgen con la aplicacin de este tipo de relacin, tendrn como objetivo la integracin de la estructura de clases del patrn X con la estructura de clases del patrn Y. Actividades a realizar luego de la aplicacin de la relacin: aplicar esta relacin significa que, adems de haber utilizado el patrn X en un diseo dado, tambin se utilizar una o ms veces el patrn Y, por lo que las actividades que surgirn sern aquellas correspondientes a la utilizacin de Y. Vnculos entre clases: aqu es importante definir los vnculos entre la o las clases del patrn X y las clases del patrn Y, de tal manera que cualquier modificacin sobre la estructura de clases de Y se vea reflejada en el patrn X. Ejemplo: como ejemplo se pueden considerar los patrones de diseo Composite y al patrn Iterator.

El patrn Composite (Figura 1) permite construir objetos complejos por medio de la composicin recursiva de objetos similares. Tambin permite que estos objetos sean tratados de manera uniforme, si hacer distinciones entre los objetos simples y los complejos.
AbstractComponent operation( )

ConcreteComponent1 operation( )

ConcreteComponent2 operation( )

...

AbstractComposite operation( ) add(AbstractComponent) remove(AbstractComonent) getChild(int)

ConcreteComposite1 operation( ) add(AbstractComponent) remove(AbstractComonent) getChild(int)

ConcreteComposite2 operation( ) add(AbstractComponent) remove(AbstractComonent) getChild(int)

...

Figura 1: Patrn de diseo Composite

El patrn Iterator (Figura 2) define una interfaz que declara mtodos para el acceso secuencial de los objetos de una coleccin. Una clase que acceda a una coleccin a travs de una interfaz, permanecer independiente de la clase que implementa dicha interfaz.
interface CollectionIF iterator( ) : IteratorIF( ) ... Creates interface IteratorIF hasNextItem( ) : boolean getNextItem( ) : InventoryItem

Collection

Fetches-objects-from

Iterator

Figura 2: Patrn de diseo Iterator

Estos dos patrones pueden ser combinados para resolver el problema de recorrer estructuras de objetos complejos sin conocer la estructura interna de los mismos. Es decir, con la aplicacin del patrn Iterator se logra independizar el recorrido del Composite de la organizacin interna de los objetos. En la Figura 3 se muestra la estructura de estos dos patrones combinados. Se puede ver que la clase AbstractComposite del patrn Composite, en la combinacin ha asumido el rol de la clase Collection del patrn Iterator. Por lo tanto, la clase AbstractComposite deber implementar el mtodo iterator() que crea un iterador para recorrer la estructura interna de los objetos compuestos del patrn Composite. En realidad, por tratarse de una clase abstracta, las subclases de AbstractComposite tendrn la responsabilidad de redefinir este mtodo. Complementariamente al estudio realizado para la identificacin de relaciones entre patrones de diseo se ha aplicado el mismo concepto a patrones de diferentes niveles de abstraccin. Existen patrones de mayor nivel de abstraccin, conocidos comnmente como patrones arquitectnicos, y de menor nivel de abstraccin (patrones de diseo). De esta manera es posible especificar relaciones que permitan identificar y describir los patrones de diseo que se utilizan para el diseo detallado de cada uno de los componentes de la arquitectura de software. Por ejemplo, el patrn arquitectnico Model View Controller usa los patrones de diseo Observer, Strategy y Composite: el patrn Observer conecta la vista (View) al modelo (Model), el patrn Strategy permite al controlador (Controller) manejar los eventos que ocurren sobre la vista, y el patrn Composite provee una jerarqua de vistas.

AbstractComponent operation()

<<Interface>> CollectionIF iterator()

creates

<<Interface>> IteratorIF hasNextItem() : boolean getNextItem() : InvetoryItem

ConcreteComponent

AbstractComposite operation() add(AbstractComponent) re mo ve(AbstractComponen t) getChild (i nt) fetch e s objec ts f rom Iterator

Figura 3: Resultado de combinar las estructuras de clases de los patrones Composite e Iterator

Adems, es posible determinar en que parte del patrn arquitectnico, o sea, en que componente arquitectnico es usado un determinado patrn de diseo. Siguiendo con el ejemplo, el patrn de diseo Composite es usado en el componente arquitectnico View. Esta informacin resulta til para construir aplicaciones utilizando patrones de software de diferentes niveles de abstraccin.

3. pLinker
Se ha desarrollado una herramienta denominada pLinker la cual pretende que el usuario aproveche las ventajas del uso de patrones de diseo y, principalmente de las relaciones entre los mismos sin tener un conocimiento avanzado sobre el tema. pLinker consiste de un editor grfico de clases UML que facilita la utilizacin y administracin de patrones de diseo, permitiendo mantener y actualizar un catlogo de patrones de diseo y las relaciones entre los mismos. Por otro lado, provee mecanismos que simplifican la incorporacin de patrones a diseos preexistentes, aprovechando adems, las relaciones entre dichos patrones. pLinker posee dos modos de trabajo: El primer modo esta orientado a la construccin de diseos con patrones, permite modelar visualmente clases, interfaces y relaciones entre las mismas (herencia, uso, e implementacin). Pero su principal caracterstica es la posibilidad de incorporacin de forma sencilla de patrones de diseo a un modelo de clases existente. Adems, permite distinguir cuales fueron los patrones utilizados y ofrece opciones que ayudan a mejorar el diseo en desarrollo incorporando nuevos patrones en forma automtica, valindose para ello de las relaciones existentes entre los patrones involucrados. El segundo modo esta destinado a mantener y actualizar el catlogo de patrones de diseo y sus relaciones. La incorporacin de un nuevo patrn puede hacerse tomando como referencia la plantilla de documentacin del mismo, disponible en cualquiera de los catlogos de patrones. Adems, de incorporar la descripcin del nuevo patrn se deben describir las relaciones del mismo con los patrones ya existentes en la herramienta y las acciones a desarrollar en cada uno de los casos. Otra caracterstica que posee pLinker es que permite crear diseos partiendo de arquitecturas de software, organizando de esta manera las clases del modelo del usuario en componentes arquitectnicos. Esto brinda una ayuda adicional a la hora de utilizar un patrn de diseo, ya que por cada componente arquitectnico, pLinker propone los patrones de diseo que se usan ms comnmente en l.

4.1. Configuracin de pLinker

Por cada patrn de diseo, pLinker mantiene tres tipos de informacin: la descripcin general, la estructura de clases que conforma el patrn, y las actividades a realizar para complementar su uso. En la descripcin genera,l se deben especificar el nombre del patrn, la intencin, la motivacin y otros datos relevantes que ayuden al usuario a optar o no por un determinado patrn de diseo. La estructura de clases se refiere a las clases y relaciones entre ellas involucradas para resolver un problema de diseo particular Finalmente, las actividades representan un conjunto de tareas que debe realizar el usuario con el fin de completar la insercin de un patrn en su diseo. Por ejemplo, una actividad que surge generalmente es la de renombrar una clase del patrn para que su nombre represente exactamente lo que modela. Una actividad tiene un nombre (como podra ser:

Renombrar clase C), una descripcin que muestra los detalles y una prioridad que indica la importancia de la misma. Para incorporar la informacin correspondiente a esta relacin, el usuario debe indicar cuales son los patrones involucrados, el tipo de relacin y la descripcin de la relacin. Tambin deben establecerse los vnculos entre las clases que permiten mantener la consistencia entre las estructuras de diseo de los patrones involucrados en la relacin. Al establecer estos vnculos, pLinker crear automticamente las acciones necesarias que permitan incorporar el segundo patrn de la relacin en la estructura de clases del primero. Adicionalmente, pLinker permite almacenar informacin acerca de arquitecturas de software y sus componentes. Un componente arquitectnico puede estar diseado con un conjunto de patrones de diseo. Por cada uno de estos componentes, pLinker permite establecer cuales son los patrones de diseo ms frecuentemente utilizados en su diseo. La Figura 4 muestra cmo establecer una relacin entre dos patrones en pLinker. En la misma se puede observar la configuracin de la relacin entre los patrones Composite y Decorador. A la izquierda de la pantalla de configuracin se muestra las clases del patrn Composite y a la derecha las correspondientes al patrn Decorador. En el panel inferior se puede observar los vnculos establecidos entre las clases de ambos patrones para establecer la relacin entre los mismos.

4.1 Construccin de aplicaciones

A continuacin se muestran las caractersticas principales de pLinker cuando es utilizado para la construccin de aplicaciones. Para ello se utilizar como ejemplo la construccin de un diseo que soporte la creacin de diferentes juegos de tablero. Entre los juegos que se tienen en cuenta para el diseo se pueden mencionar el ajedrez, las damas, cuatro en lnea, ta-te-ti, etc., por lo que se lo podra utilizar para crear juegos en los que participen muchos jugadores, o bien que existan distintos tipos de piezas, adems de muchas otras caractersticas que incluyen los juegos mencionados. En cuanto a los jugadores que participan en el juego, el diseo no hace distincin entre lo que puede ser un jugador humano y otro que est controlado por un algoritmo. La idea bsica es que los jugadores involucrados, generen comandos y los apliquen al juego. El juego se encargar de verificar que dichas acciones sean vlidas, actualizar su estado de acuerdo a ellos, y quedar a la espera de nuevas acciones. Una accin ser, por ejemplo para un juego de ajedrez, mover el alfil de tal lugar a tal otro, o bien si se piensa en un juego como el reversi, poner una ficha roja en tal celda.

Figura 4: Configuracin de pLinker: Relaciones entre patrones

4.1.1. Creacin de un proyecto pLinker

Lo primero que se debe hacer antes de comenzar a incorporar clases y relaciones al diseo, es crear un proyecto. El proyecto ser la unidad de trabajo de pLinker, y es el encargado de contener tanto el diseo de clases del usuario como las instancias de los patrones utilizados. As mismo, organiza el diseo en componentes arquitectnicos. pLinker permite trabajar con mltiples proyectos a la vez. El primer paso para crear un proyecto es indicar la arquitectura de software a utilizar, para el caso de la aplicacin ejemplo, se utilizar arquitectura de software Model-View-Controller (MVC), por lo que el diseo se ver estructurado en tres componentes arquitectnicos. En caso de que no se utilice una arquitectura de software, el diseo ser organizado en un nico componente. Continuando con la construccin de la aplicacin se procede a la creacin y organizacin de las clases iniciales de cada uno de los componentes de la arquitectura MVC. Por ejemplo, el componente Model inicialmente tendr las siguientes clases (Figura 5): Player: Contiene informacin referente al jugador (por ejemplo su nombre). Adems, tiene conocimiento de las fichas que tiene para jugar y que no se encuentran sobre el tablero. Esto se puede ver en el juego del scrabbel, en el cual los jugadores disponen de letras (fichas) con las que deben formar palabras sobre el tablero. Piece: Existen muchos juegos de tablero en los que se utilizan diferentes piezas o fichas. Esta clase representa a tales piezas. Una pieza tiene el conocimiento de cuales son las celdas con las que se puede operar, a partir de una celda origen, con una determinada pieza. Esto se ve en el juego de ajedrez, en donde se sabe que la pieza alfil solo se puede mover a celdas diagonales contiguas. Board: Representa al tablero de juego y provee mtodos para acceder a las distintas celdas, adems completa el chequeo de si el movimiento de una pieza es vlido. Siguiendo con el ejemplo de ajedrez, se puede verificar a nivel pieza que un alfil se mueva solo en diagonal, pero a este nivel se desconoce si en la celda destino se encuentra alguna otra pieza del mismo color, por ejemplo. Esta responsabilidad es del tablero. Cell: El tablero esta compuesto por celdas. La celda brinda mecanismos para poner y sacar piezas de ella. Game: Contiene la lgica y reglas del juego y tiene conocimiento del estado del mismo, los jugadores, maneja los turnos, fichas sobre el tablero, etc.

Figura 5: Clases que disean (inicialmente) el componente arquitectnico Model

4.1.2. Creacin de instancias de patrones de diseo

Es posible que el usuario desee utilizar en su diseo varias veces un determinado patrn dado (por ejemplo, el patrn Singleton). Es por ello que surge el concepto de instancia de patrn de diseo. Una instancia puede verse como una copia de un patrn de diseo dado. Incluye adems, informacin para mantener vnculos entre las clases del usuario y las clases que conforman la estructura del patrn. Estos vnculos representan los roles. Un rol indica que clase del modelo del usuario juega el rol de una clase que se encuentra dentro de la estructura de la instancia de

un patrn. Entonces, cualquier modificacin que ocurra sobre una clase de la instancia de un patrn, afectar directamente a una clase del usuario. Para incorporar un patrn de diseo (de los que se encuentran en el catlogo de pLinker) a la estructura de clases preexistente, primero se debe establecer el nombre de la instancia. Luego se debe determinar cual ser el patrn a instanciar. Los patrones disponibles dependern del componente arquitectnico seleccionado ya que solo se mostrarn aquellos que son factibles de utilizar. Sin embargo, el usuario puede no tener en cuenta el componente arquitectnico y utilizar cualquier patrn de diseo includo en el catlogo. Una vez seleccionado el patrn de diseo a instanciar, la herramienta propone alternativas del mismo. Tales alternativas estarn dadas por las relaciones existentes entre patrones. Solo aparecern como alternativas aquellas relaciones entre patrones cuyo tipo implique que deben usadas antes de la instanciacin de un patrn. Continuando con el componente arquitectnico View, la Figura 6.a muestra las clases que disean inicialmente dicho componente. Cada una de estas clases es encargada de representar grficamente los diferentes elementos de un juego de tablero. Se puede ver como la clase GameView tiene la responsabilidad de manejar la vista correspondiente al tablero (BoardView) y las vistas de los jugadores (PlayerView). Para reducir esta complejidad, y manejar esta jerarqua de vistas de manera homognea, es posible utilizar el patrn de diseo Composite [GHJV95]. Al intentar instanciar un patrn para el diseo del componente View, pLinker ofrecer el Composite puesto que dicho patrn es frecuentemente usado en este componente arquitectnico. Entre las actividades que surgirn cuando se cree una instancia de este patrn estarn las de renombrar las clases y los mtodos (por ejemplo, AbstractComponent por AbstractView y operation por paint). En cuanto a los roles, la clases PieceView y PlayerView jugarn el rol de ConcreteComponents, ya que pueden verse como hojas del rbol de vistas. De manera similar, las clases BoardView, GameView y CellView jugarn el rol de AbstractComposite. En la Figura 6.b se la instanciacin de el patrn Composite.

4.1.3. Activacin de las relaciones entre patrones

Una vez instanciado un patrn, pLinker propone al usuario, los patrones de diseo que pueden ser utilizados en conjunto con el primero. Solo aparecern aquellas relaciones entre patrones cuyo tipo implique que deben usadas despus de la instanciacin de un patrn dado.

6.a

6.b
Figura 6.a: Clases que disean el componente View 6.b: Uso del patrn Composite en el diseo del componente View

Para el diseo del juego, se activar la relacin entre los patrones de diseo Composite y Decorator (Figura 7). Esto permitir que las diferentes vistas (que ahora forman parte del Composite) se dibujen de diferente manera, dependiendo posiblemente, del estado del objeto que representan. Por ejemplo, es posible que cuando el usuario seleccione una celda del tablero, la misma se dibuje con un recuadro.

Figura 7: Activacin de la relacin entre los patrones Composite y Decorator

Entonces, pLinker se encarga de actualizar el modelo de clases del usuario para reflejar la activacin de dicha relacin. La activacin de una relacin implica que se ha utilizado un nuevo patrn (o instancia del mismo) en el diseo del usuario. Entonces, la herramienta crea automticamente una instancia de dicho patrn. De esta manera, a medida que se van aplicando patrones en el diseo, la herramienta va asistiendo al diseador para la incorporacin de nuevos patrones de manera de completar el diseo de la aplicacin. Una vez que las posibles relaciones entre patrones han sido mostradas por la herramienta y utilizada esa informacin por el diseador, este ltimo deber analizar el diseo resultante en caso de tener que incorporar nuevas clases o patrones no surgidos de las relaciones.

4. Conclusiones
En este trabajo se realiz un estudio y clasificacin de los tipos de relaciones existentes entre patrones de diseo. Se identificaron puntos en comn que permitieron clasificar y documentar ms formalmente tales tipos de relaciones. Como resultado de este estudio surgi un esquema de documentacin similar al que es utilizado para describir patrones de diseo, lo que facilita la comprensin y la forma de aplicacin de las relaciones entre patrones. Al descubrirse una relacin entre dos patrones de diseo dados, no solo es posible clasificarla, sino que tambin se la puede documentar de manera que permita utilizarla posteriormente en una herramienta de desarrollo que contemple el uso patrones de diseo y relaciones entre los mismos. Con el objetivo de asistir al usuario en la construccin de diseos utilizando patrones y sus relaciones de manera simple, se implement pLinker, una herramienta grfica que permite modelar diagramas de clase UML e incorporar patrones en ellos y aprovechar las relaciones existentes entre los mismos. pLinker provee mecanismos que facilitan la incorporacin de patrones a un diseo preexistente de manera simple, permitiendo establecer vnculos entre las clases del patrn y las clases del usuario para mantener la consistencia entre las instancias de patrones de diseo. Al insertar un patrn de diseo en un diagrama de clases dado, pLinker ofrece opciones que implcitamente llevan a activar relaciones entre el patrn original y aquellos con los cuales est relacionado. Al activar una relacin entre patrones, pLinker se encarga de mantener consistente el modelo del usuario, tomando para ello la informacin propia de la relacin.

Por otro lado, pLinker permite trabajar con arquitecturas de software y sus respectivos componentes arquitectnicos, dando la posibilidad de indicar cuales son los patrones de diseo frecuentemente usados en un determinado componente arquitectnico, mejorando as la posible eleccin y uso de un determinado patrn, dentro de un diseo dado. La configuracin de pLinker est fuertemente relacionada con la documentacin de relaciones entre patrones propuesta. Es por ello que es posible tomar dicha informacin e incorporarla sin mayores problemas a la herramienta.

5. Bibliografa
[AISJ+77] [BASS97] [BMRS+96] [Garlan94] C. Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-King, and S. Angel. A Pattern Language - Towns-Buildings-Construction. Oxford University Press, 1977. Len Bass, Paul Clements and Rick Kazman, Software Architecture in Practice. AddisonWesley, 1997. Frank Buschmann, Regine Meunier, Hans Rohmrt, Peter Sommerlad, and Michael Stal, Pattern-Oriented Software Architecture - A System of Patterns. Wiley and Sons Ltd, 1996. David Garland and Mary Shaw, An introduction to Software Architecture. CMU-CS-94166, School of Computer Science, Carnegie Mellon University, Pittsburgh, PA 15213-3890, 1994. Erich Gamma, Richard Helm, Raph Johnson, and John Vlissides, Design Patterns Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading, MA, 1995. Mark Grand, Patterns in Java: a catalog of reusable design patterns illustrated with UML. Wiley and Sons, Inc, 1998. Erich Gamma and Thomas Eggenschwiler, A Java GUI framework for technical and structured Graphics. http://www.jhotdraw.org. Claig Larman, Applying UML and patterns. Upper Saddle River, N.J. Prentice Hall PTR, 1998. D.H. Lorenz, Tiling Design Patterns a case studio. ECCOP Proceeding, 1997. Marco Meijers, Tool Support for Object-Oriented Design Patterns, Master Thesis. Utrecht s University, CS Dept, INF-SCR-96-28, August 1996. James Noble, Classifying Relationships Between Object-Oriented Design Patterns. Microsoft Research Institute, Macquarie University, Sydney, Australia, 1998. James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, William Lorensen, Modelado y Diseo Orientados a Objetos. Metodologa OMT. Prentice Hall, 1996. S.A. Yeates, Design a garbage collector using design patterns. TOOLS Pacific 25, 1997. Walter Zimmer, Relationships between design patterns in Pattern Languages of Program Design, Addison-Wesley, 1994.

[GHJV95] [Grand98] [JHotDraw] [Larman98] [Lorenz97] [Meijers96] [Noble98] [Rumbaugh96] [Yeates97] [Zimm94]