Validación de Patrones de Diseño de Comportamiento a través de Perfiles UML

Transcripción

1 Validación de Patrones de Diseño de Comportamiento a través de Perfiles UML 1

2 INDICE GENERAL CAPITULO I... 4 Especificación de Patrones de Diseño Patrones de diseño Concepto Clasificación de patrones de diseño Características de los patrones de Comportamiento: Una arquitectura para patrones de diseño basada en perfiles UML Base para las relaciones entre características estructurales y comportamentales Consistencia de los elementos de la arquitectura Metodología Técnica para definir perfiles CAPITULO II Perfil de Patrones Genérico Conceptos Introductorios Elementos del metamodelo UML utilizados de elementos Nivel Estereotipos Restricciones en lenguaje OCL CAPITULO III Perfil de Comportamiento Conceptos Introductorios Elementos del metamodelo UML utilizados de elementos Nivel Estereotipos Restricciones en lenguaje OCL CAPITULO IV Perfil Patrones Particulares Perfil Patrón Observer de elementos Nivel Restricciones definidas en OCL Consecuencias CAPITULO V Chequeo de modelos CASO DE ESTUDIO Observer

3 5.1.1 Validación del modelo

4 CAPITULO I Especificación de Patrones de Diseño El uso de perfiles permite extender la sintaxis y la semántica UML para modelar elementos de dominios particulares. Es posible usar perfiles para definir un vocabulario de patrones en UML. En este capítulo se describe el concepto de patrones de diseño, y se detalla la arquitectura de patrones de diseno utilizada en el presente trabajo. 1.1 Patrones de diseño Concepto Los patrones de diseño tuvieron su origen a mediados de la década del noventa, siendo el trabajo de Gamma et al. presentado en [1], uno de los catálogos de patrones más difundidos. A partir de allí fueron ampliamente aceptados en el área de desarrollo de software tanto en empresas como en el mundo académico. En [1] se da una definición precisa de lo que es un patrón de diseño y cómo debe ser usado. Es una visión aceptada en la comunidad de la ciencia de la computación. Define los patrones de diseño como: descripciones de objetos que se comunican y clases que son personalizadas para resolver un problema de diseño general en un contexto particular. Los patrones de diseño describen soluciones adecuadas a problemas que ocurren repetidamente, haciendo al diseño más flexible, elegante y principalmente reusable. Esta solución puede ser aplicada repetidamente para producir estructuras de diseño que lucen de forma similar al desarrollar aplicaciones diferentes. 4

5 Un patrón de diseño nombra, abstrae e identifica los aspectos claves de una estructura de diseño común que lo hacen útil para crear un diseño orientado a objetos reusable. El patrón de diseño identifica las clases que participan y las instancias, sus roles y colaboraciones, y la distribución de responsabilidades. Cada patrón se enfoca sobre un problema de diseño orientado a un objeto particular Clasificación de patrones de diseño Gamma y otros en [1] presentan 23 patrones de diseño, clasificados según dos criterios: el propósito y el ámbito. La Tabla 3.1 muestra esta clasificación. Propósito De Creación Estructurales De Comportamiento Ámbito Clase Factory Método Adaptar (de clase) Interpret Template Method Objeto Abstract Adaptar (de objetos) Chain of Responsibility Factory Bridge Command Builder Composite Iterate Prototype Decorator Mediator Singleton Facade Memento Flyweight Observer Proxy State Strategy Visitor Tabla 1.1: Clasificaciòn de los patrones de diseño El propósito refleja lo que hace el patrón, y los clasifica en: 5

6 - De Creación: Abstraen el proceso de creación de instancias de objetos. Ayudan a hacer a un sistema independiente de cómo se crean, se componen y se representan sus objetos. - Estructurales: Tratan con la composición de clases u objetos. Se ocupan de cómo las clases y objetos se utilizan para componer estructuras de mayor tamaño. - De Comportamiento: Caracterizan el modo en que las clases y objetos interactúan y se reparten la responsabilidad. El segundo criterio, el ámbito, especifica si el patrón se aplica a clases u objetos: Si se aplica a Clases las relaciones se producen entre clases y subclases, y son establecidas a través de la herencia, estáticas, por lo que se fijan al momento de la compilación. Si se aplica a Objetos las relaciones se producen entre objetos, y pueden ser cambiadas en tiempo de ejecución, son dinámicas Características de los patrones de Comportamiento: Variación de la Encapsulación de objetos: Los aspectos cambiantes se encapsulan, para disminuir las dependencias. Se utiliza una clase abstracta o interface para encapsular el objeto y el patrón toma su nombre de este objeto. Un objeto Strategy encapsula un algoritmo que modela una estrategia. Un objeto State encapsula un comportamiento dependiente de un estado. Un objeto Mediator encapsula el protocolo entre objetos. Un objeto Iterator encapsula la forma en que se accede y navegan los componentes de un objeto. La mayoría de los patrones tienen dos tipos de objetos: los objetos nuevos que encapsulan el aspecto y los objetos existentes que usan los nuevos. Por ejemplo, el código para Strategy está unido al Contexto de la estrategia, y el código para State se implementa en el Contexto del estado. Esta característica se define en los patrones de comportamiento en el aspecto estructural. Los patrones que contienen esta característica utilizan los estereotipos estructurales patternclassifier y patternappliedclass. Para verificar que se cumpla este aspecto en el comportamiento de un modelo es necesario verificar que exista consistencia entre los tipos existentes en el diagrama de clases y los tipos de los 6

7 objetos de un diagrama de secuencia. Objetos como argumentos: Algunos patrones como el Visitor implantan un objeto que siempre es usado como un argumento. Un objeto Visitor es el argumento para una operación polimórfica Accept sobre el objeto que lo visita. Visitor nunca es considerado una parte de estos objetos. Otros patrones definen objetos que actúan como tokens mágicos para ser pasados e invocados. Son ejemplo de esta técnica los patrones Comand y Memento. En Command el token representa un pedido; en Memento, representa el estado interno de un objeto en un momento particular. Ejecutar el objeto Command es una operación polimorfica. Un memento solo puede ser pasado como un valor. Para verificar esta característica se debe verificar la consistencia entre las operaciones del diagrama de clases y las invocaciones del diagrama de secuencia. Si la operación en el diagrama de clases tiene como argumento un objeto en las llamadas a una operación, existe un argumento de tipo objeto. Para verificarlo se crearon restricciones. Distribución de la comunicación: Observer distribuye la comunicación introduciendo los objetos Observer y Subject, asi que el patrón de comunicación está determinado en este caso por la forma en la que observadores y sujetos están interconectados. Como no se encapsulan las restricciones de la comunicación, los observadores y sujetos deben colaborar para mantener la restricción. Existe una comunicación de tipo broadcast, es decir, se actualizan el estado del sujeto en todos los observadores de la lista a través de esta comunicación. Para representar esta característica se define un estereotipo denominado broadcast. Desacoplamiento entre emisores y receptores: Los objetos que colaboran se vuelven dependientes entre sí y esto provoca desequilibrio y baja reusabilidad. Para desacoplar se utilizan diferentes tipos de envío y recepción de mensajes. Definiendo la conexión emisor-receptor en un objeto separado permite al emisor trabajar con diferentes receptores. De esta manera el emisor se desacopla de los receptores, haciendo más fácil reusar los emisores. Por ejemplo el Command provee un objeto simple para distribuir el pedido. Se puede reusar el objeto Command para 7

8 parametrizar un receptor con diferentes emisores. El patrón Command es un intermediario entre emisores y receptores. Por ejemplo el patrón Observer es un intermediario que desacopla emisores (subjects) de receptores (observers) definiendo una interface para mostrar los cambios en los sujetos. Observer separa el emisor del receptor porque un subject puede tener múltiples observers, y su número puede variar en tiempo de ejecución. Las interfaces Subject y Observer en el patrón Observer son designadas para comunicar cambios. Consecuentemente el patrón Observer es mejor para desacoplar objetos cuando hay dependencias de datos entre ellos y su número puede variar en tiempo de ejecución. El patrón Mediator desacopla objetos por haberlos referido indirectamente a través de un intemediario, objeto Mediador. Un objeto Mediador rutea pedidos entre objetos Colleague y centraliza su comunicación. Consecuentemente, los colleagues solo pueden hablar entre ellos a través de la interface Mediator. El patrón Mediator puede reducir subclaseo en un sistema, porque centraliza el comportamiento de comunicación en una clase en lugar de distribuirlo entre subclases. Sin embargo, los esquemas de despacho como este, decrementan la seguridad. El patrón Chain of Responsibility desacopla el emisor del receptor pasando el pedido a lo largo de una cadena receptores potenciales. Dado que se fijó la interface entre emisores y receptores, Chain of Responsibility también podría requerir un esquema de despacho. En todos los casos existe una dependencia que se desacopla mediante la generación de un intermediario. El desacoplamiento se puede visualizar en el diagrama de secuencia porque es una característica totalmente dinámica. 1.2 Una arquitectura para patrones de diseño basada en perfiles UML El uso frecuente del lenguaje UML se presenta como una opción importante para la especificación de modelos, y en particular, patrones de diseño. Para lograr una mejor especificación UML ofrece el mecanismo de Perfiles. Este componente posibilita extender la sintaxis y semántica de UML, de manera de poder expresar los conceptos 8

9 específicos de un determinado dominio de aplicación. En este caso se extiende para definir conceptos utilizados en la representación de Patrones de Diseño posibilitando de esta forma una clara definición de los mismos. En los patrones de diseño se observan características generales y otras particulares. Utilizando perfiles UML se puede generar una estructura general; pero no es posible precisar una misma semántica para todos los patrones en un único perfil. Es necesario Fig. 1.1: Arquitectura de patrones de diseño. especificar la semántica para cada patrón particular. De esta manera se establece una jerarquía entre niveles de perfiles que permite el reuso de definiciones. El resultado es la estructura de la arquitectura que se encuentra expresada en la figura 1.1. La arquitectura está compuesta por tres niveles: Nivel 0: provee las estructuras base para todos los patrones de diseño. Contiene los elementos comunes de todos los patrones y puede ser reutilizado por los otros niveles de perfiles. Es decir, en este nivel se describen los estereotipos necesarios para formular restricciones, de manera de verificar que los elementos de un patrón sean válidos. Se basa en los elementos de un diagrama de clases, abstractos y concretos, sus tipos de relaciones posibles para formar una estructura válida en cualquier patrón. 9

10 Nivel 1: Se inspira en el catálogo Gof, y tiene la responsabilidad de proveer un perfil por cada clasificación. En el perfil de patrones de comportamiento provee los patrones de comunicación entre clases y objetos y su flujo de control. Contiene la clasificación por propósito dividida en estructurales (Perfil Estructural), creacionales (Perfil Creacional), y de comportamiento (Perfil de Comportamiento). En el caso especìfico de los patrones de comportamiento su base son las interacciones, por lo que se toman como elemento de validación. Nivel 2: Es el nivel inferior de este modelo, está compuesto por los perfiles de patrones particulares. Para su descripción se importan elementos definidos en los niveles anteriores (niveles 0 y 1). Cuando se incluye un nuevo patrón, se debe definir un nuevo perfil, y cada perfil agregado tendrá su sintaxis y semántica particular. Pero todos absorberán las estructuras genéricas de los niveles 0 y 1. Un perfil de un patrón especifìco importará estos dos perfiles del nivel anterior. La definición de restricciones y estereotipos permite verificar que los modelos se ajusten a un determinado patrón de Diseño. Además al marcar los modelos es posible verificar la consistencia entre modelos estáticos y dinámicos Base para las relaciones entre características estructurales y comportamentales. Para poder evaluar la coherencia del modelo de arquitectura planteado es importante tener claras las relaciones entre la estructura y el comportamiento del mismo. Para interpretar el significado de los aspectos estructurales y su influencia en los aspectos comportamentales se tomó como modelo la arquitectura semántica definida en las especificaciones de la OMG [2]. En la figura 1.2 puede verse su constitución, donde en la base se encuentran las estructuras conocidas semánticamente como Structural Foundations. El comportamiento es un aspecto intangible, originado por estas estructuras que definen acciones. Es decir, todo comportamiento está compuesto por las acciones de elementos estructurales. Para la descripción de los comportamientos también se debe 10

11 considerar si surgen a partir de la comunicación con otros objetos o surgen de la propia entidad. La siguiente capa en gris contiene los formalismos que describen el comportamiento de las estructuras de la primer capa y consiste de tres subcapas. Fig. 1.2: Extraído de OMG Superestructura [2]Versión La subcapa de comportamiento inter-objetos (en inglès, inter-object behavior base), que muestra como entidades estructurales se comunican unas con otras, la subcapa de comportamiento intra-objetos que se refiere al comportamiento dentro de las estructuras (en inglès, intra-object behavior base) y la subcapa de acciones (en inglès, Actions) que define la semántica de acciones individuales. Acciones son la unidad fundamental de comportamiento y son comparables a las instrucciones de un lenguaje de programación. La capa superior se compone de los formalismos de UML que permiten describir comportamiento: interacciones, máquinas de estado y actividades Consistencia de los elementos de la arquitectura El concepto de consistencia implica que para poder definir un nivel superior en la arquitectura debe ser coherente con el nivel inferior. Consecuentemente, la consistencia en el Nivel 2 debe incluir la consistencia del Nivel 0 y el Nivel 1 (para definir un perfil deben existir elementos estructurales que cumplan las restricciones del Nivel 0 y 11

12 elementos comportamentales que cumplan las restricciones del Nivel 1). Hay tres niveles de consistencia: Nivel 0: Se verifica la consistencia de diagrama de clase mediante la aplicación de reglas OCL. Cada elemento debe estar bien formado para lo cual se verifica reglas sintácticas y semánticas. Nivel 1: Se verifica la consistencia de las características de comportamiento y de consistencia entre diagramas de comportamiento (secuencia) y diagrama de clases, chequeando reglas semánticas. Nivel 2: Se verifican elementos de un patrón de diseño particular a partir de elementos del nivel 0 y 1 y se chequea la consistencia del modelo con el patrón de diseño. Los tipos de consistencia contemplados son: 1. Consistencia de sintaxis Abstracta: Para un nivel de consistencia dado, esto envuelve : consistencia con las metaclases, sus relaciones estructurales, y cualquier restricción definida como parte del metamodelo UML compuesto para aquel nivel de consistencia. 2. Consistencia de sintaxis Concreta: Consistencia para la notación de elementos del diagrama de un detereminado patrón, en el cual estos elementos pueden aparecer Metodología En el primer Nivel 0 se validan las estructuras elementales construyendo reglas bien formadas para los diagramas de clase. Se validan cada diagrama en particular. De esta manera se comprueba que la base del modelo es consistente para los elementos estructurales de las características estáticas. El Nivel 1 se basa en la clasificación Gof [1], conteniendo un perfil por cada clasificación: Estructural, Creacional y De Comportamiento. A los fines de este trabajo se generó solo el perfil de comportamiento. Este perfil contiene estereotipos que incluyen restricciones para validar la consistencia entre los diagramas de secuencia (vista dinámica) y de clases (vista estructural). Chequeàndose 12

13 además la existencia de ciertas características de comportamiento. En este nivel se obtiene un modelo en el que se corrobora la buena formación de elementos, la consistencia de sus interacciones y comportamiento. En el Nivel 2 existe un perfil por cada patrón particular. Se verifican las características estructurales del patrón: la cantidad y tipo de clases que contiene, sus conexiones, que operaciones contiene y sus parámetros. Y también las características dinámicas: las interacciones de cada objeto Técnica para definir perfiles Para incorporar un nuevo patrón de comportamiento al Nivel 2 de la estructura, se debe crear un perfil, conteniendo su sintaxis (estereotipos) y su semántica (restricciones ocl). Dicho perfil debe importar aspectos de los niveles 0 y 1. Una técnica para definir un perfil de patrón se resume a continuación: 1. Identificar los participantes principales del patrón y sus responsabilidades 2. Importar los niveles 0 y Tomar elementos del Nivel 0 para definir un estereotipo para las características generales del perfil (relaciones, etc.), un estereotipo por cada participante del patrón y un estereotipo por cada operación y atributo de cada participante. 4. Imponer restricciones sobre los estereotipos para definir tanto características generales del patrón (relaciones, etc.) como particulares de cada participante. 5. Validar la sintaxis y consistencia del perfil a través de la opción correspondiente. 6. Liberar la versión del patrón para su uso. 7. Validar el perfil utilizando en un modelo particular. Si bien, la técnica describe la forma de incorporar perfiles en el Nivel 2, en todos los niveles es posible seguir añadiendo nuevos perfiles. En éste caso sólo se han definido los necesarios para ajustarse a los establecido en Gof, pero la arquitectura es compatible para incorporar otros patrones de diseño también, tales como los de arquitectura. 13

14 CAPITULO II Perfil de Patrones Genérico El perfil de patrones genérico presenta los formalismos necesarios para especificar la estructura de los patrones de diseño. Los aspectos estructurales refieren elementos del diseño orientado a objetos: clasificadores, clases, atributos, operaciones. Estos aspectos estructurales se validan a través de estereotipos creados para ese fin. El Nivel 0 de la arquitectura es la raíz de una jerarquía de paquetes. Cada paquete contiene uno o más perfiles conteniendo estereotipos validados por restricciones que validan los formalismos definidos anteriormente. Este capìtulo está dividido en dos partes. En primer lugar se describen los conceptos introductorios que contiene un resumen de las principales expresiones, palabras reservadas y elementos del metamodelo UML utilizados. Y además las expresiones del lenguaje OCL empleadas en la elaboración de las restricciones junto con una reseña de las funciones del RSA aplicadas. En la segunda parte se presentan los estereotipos del Nivel 0 y sus validaciones definidas en forma de restricciones OCL. 2.1 Conceptos Introductorios Elementos del metamodelo UML utilizados Los elementos del metamodelo UML representan la base de los estereotipos creados en la arquitectura. Para construir un perfil se recurre a las metaclases del metamodelo UML: Class, Interface, Operation, etc. [2]. En una expresión OCL se define un contexto. Un contexto se define en forma de conjunto de elementos de tipo: Class, Interface, etc. La verificación de la expresión incluye a todas las instancias del conjunto definido. 14

15 Fig. 2.1: Fragmento del metamodelob Estructural UML. En la figura 2.1 se muestra un fragmento del metamodelo UML con los formalismos definidos en la especificación UML para representar las construcciones estructurales que son utilizadas por los diagramas de clases. En base a este metamodelo se genera el perfil de este capìtulo, tomando algunos de sus elementos para extenderlos a través de estereotipos. Un ejemplo de un elemento del metamodelo empleado en el perfil se ilustra en la figura 2.2, estos elementos se denominan metaclases. En este caso una metaclase Class que contiene atributos y operaciones esquematizada con el software RSA [3]. Fig 2.2: Metaclase Class. Una metaclase es un elemento de metamodelado que define una clase con atributos y operaciones. Algunas de las metaclases introducidas en el Nivel 0 de la arquitectura son las siguientes. 15

16 Class : Para referirse al elemento clase del metamodelo UML. Classifier : Para referirse a cualquier elemento dentro del metamodelo. Interface : Para referirse a una interface del metamodelo UML. 2.2 de elementos Nivel 0 Este nivel es la base estructural de la arquitectura y se compone de un patrón genérico que contiene estereotipos y sus restricciones asociadas Estereotipos El patrón genérico se compone de cinco estereotipos: patternprofile, patternclassifier, patternclass, patternoperation, patternproperty, que extienden metaclases del metamodelo UML. Figura 2.3: Estereotipos para modelos estáticos En la Figura 2.3 se muestran como los estereotipos patternprofile, patternclassifier, patternclass, patternproperty y patternoperation extienden las metaclases Package, Classifier, Class, Property y Operation. Es decir, los estereotipos contienen las operaciones y propiedades de la metaclase a la que extienden. La metaclase extendida establece el ámbito de aplicación de un estereotipo. Esto implica que, por ejemplo, los estereotipos que extienden la metaclase Class se podrán aplicar a elementos de tipo clase en un diagrama de clases. Seguidamente se describen los estereotipos: patternprofile: Permite definir restricciones que tengan como contexto un paquete. Se validan características propias de un patrón, como por ejemplo las relaciones que deben existir entre los elementos. patternclassifier: Representa un clasificador validado como una clase abstracta o 16

17 interface. patternclass: Describe una clase de tipo concreto que además implementa las operaciones de un tipo patternclassifier. patternproperty: Describe un atributo de una clase y valida la corrección de sus características. patternoperation: Permite chequear si una operación fue implementada. Por ejemplo, cada participante de un patrón es patternclassifier o patternclass; en el primer caso, el participante debe ser una clase abstracta o una interfaz, y en el segundo caso, una clase concreta. El estereotipo patternoperation se relaciona con modelos estáticos y también permite corroborar la coherencia de modelos dinámicos, contrastando las operaciones con los mensajes invocación de operaciones Restricciones en lenguaje OCL Para validar que los estereotipos cumplan su propósito se emplean restricciones en lenguaje OCL. Se comprueba la validez de los atributos chequeando que posean el nombre y la visibilidad adecuados. Se valida que los elementos estereotipados como clasificadores sean de tipo interface o clase abstracta. Si es una clase abstracta debe existir una relación de herencia y si es una interface una de realización. Además las clases y operaciones válidas contendrán las especificaciones de métodos para las operaciones existentes. Restricción 1 - Verifica nombres de atributos Contexto PerfilNivel0::patternProperty self.name->notempty() and (self.visibility-> exists(visibilidad visibilidad=uml::visibilitykind::private or self.visibilidad=uml::visibilitykind::protected)->notempty()) and self.type->notempty() Se valida que los nombres de los atributos de una clase no esten vacíos, que su visibilidad exista y sea private o protected. Además que el tipo esté definido. Restricción 2 - Validez de clasificador Contexto PerfilNivel0::patternClassifier (self.oclistype(class) and self.isabstract) or self.oclistype(interface) 17

18 Se valida que el tipo clasificador sea una clase abstracta o una interface. Restricción 3 - Herencia en clasificadores Contexto PerfilNivel0::patternClassifier (self.oclistypeof(class) and self.isabstract and implies self.getappliedstereotypes().parents()->select (name=' patternclassifier ')-> notempty()) self.generalization.specific->notempty() Este estereotipo se aplica a elementos de otros niveles para validar su tipo. En este caso su aplicación será en el Nivel 2. La restricción evalúa si el elemento es tipo clase abstracta y el estereotipo del Nivel 0 (como el estereotipo se aplica en otro nivel distinto del nivel 0 se aplica la función parent para evaluar el estereotipo de nivel 0, que es el padre), es de tipo patternclassifier. Como implicación existe una relación de generalizaciòn desde el elemento cuyo extremo opuesto es no vacío, es decir existe una clase concreta. Restricción 4 - Realización de interface Contexto PerfilNivel0::patternClassifier InterfaceRealization.allInstances().contract.name->exists(nombre nombre=self.name) implies self.oclistypeof(interface) ->notempty()) Si existe una relación de realización cuyo extremo contiene un elemento con el mismo nombre que el elemento estereotipado como patternclassifier implica que el elemento estereotipado es una interface. Restricción 5 - Aplica clase abstracta Contexto PerfilNivel0::patternClass implies (self.general().getappliedstereotypes().parents()- >select(name='patternclassifier') -> notempty()) 18

19 self.general().getalloperations()-> select(operacion operacion.isabstract->notempty() and self.ownedoperation -> exists(implementa implementa.name=operacion.name and implementa.ownedparameter=operacion.ownedparameter and implementa.ownedparameter.type=operacion.ownedparameter.type and implementa.ownedparameter.direction=operacion.ownedparameter.direction and implementa.method.specification->notempty()))->notempty() La restricción valida que un elemento estereotipado como patternclass tiene una relación de herencia respecto de un elemento estereotipado como patternclassifier. Lo anterior implica que si el elemento estereotipado como patternclassifier contiene operaciones abstractas, el elemento estereotipado patternclass contiene operaciones con el mismo nombre, los mismos párametros: con igual tipo y dirección. Y además la especificación de los métodos correspondientes a cada operación no está vacía. Restricción 6 - Aplica Interface Contexto PerfilNivel0::patternClass self.interfacerealization.contract.getappliedstereotypes().parents()-> implies select (name=' patternclassifier ')->notempty() self.interfacerealization.contract.ownedoperation-> forall(operacionimplementada self.getalloperations()-> exists(operacionimplementadora operacionimplementadora.name = operacionimplementada.name and operacionimplementadora.ownedparameter = operacionimplementada.ownedparameter and operacionimplementadora.ownedparameter.type = operacionimplementada.ownedparameter.type and operacionimplementadora.ownedparameter.direction = operacionimplementada.ownedparameter.direction)) En esta restricción se valida que cuando existe una clase estereotipada como patternclass y existe una relación de realización de interface cuyo extremo opuesto es 19

20 un elemento estereotipado como patternclassifier, la clase lo implementa. Si existe la relación de realización de interface mencionada implica que el elemento estereotipado patternclass contiene operaciones con el mismo nombre, los mismos párametros: con igual tipo y dirección, que el elemento estereotipado patternclassifier. Y además la especificación de los métodos correspondientes a cada operación no está vacía. Restricción 7 - Aplica Operación Context PerfilNivel0::patternOperation Operation.allInstances() ->exists (operacion operacion. getappliedstereotypes().parents()->select(name= 'patternoperation')->notempty() implies operacion.method-> exists(metodo metodo.name = self.name and (metodo.specification->notempty() implies metodo.ownedparameter-> includesall( self.ownedparameter) ))) Esta restricción valida que una operación estereotipada cumple que su estereotipo hereda las propiedades del estereotipo patternoperation. Como implicación de lo anterior va a existir un método con el nombre de la operación no sea vacía y además el método contendrá los mismos parámetros que la operación referida. 20

21 CAPITULO III Perfil de Comportamiento El presente capítulo establece las definiciones para describir la dinámica de los patrones de diseño. Los aspectos comportamentales definen al modelo en funcionamiento, es decir, las características en tiempo de ejecución. En este nivel, el nivel 1, se considera como elemento de estudio: las interacciones. El perfil de comportamiento se construye en base a la clasificación de patrones del libro de Gamma [1] y de acuerdo a su descripción se explican las características de comportamiento. Existen algunas peculiaridades en la dinámica de un sistema como las dependencias y acoplamiento entre objetos que producen entre otros problemas: una baja reusabilidad y dificultad para modificar un sistema. Para aumentar la reusabilidad y calidad de los sistemas se generaron instrumentos como la encapsulación de objetos, el desacoplamiento, la inversión de dependencia, distribución. Los patrones de diseño de comportamiento fueron construídos en base a esos instrumentos que se describen en la primera parte del capítulo como características de comportamiento. Seguidamente se describen la simbología utilizada y finalmente se explica el perfil de comportamiento propiamente dicho. 3.1 Conceptos Introductorios Elementos del metamodelo UML utilizados Los elementos del metamodelo UML constituyen el cimiento para los estereotipos de un 21

22 perfil. Para construir el perfil de comportamiento se emplea la metaclase interacción del metamodelo UML [2]. En la figura 3.1 se muestra un fragmento del metamodelo UML con los asbstracciones presentados en la especificación UML que se utilizan en un diagrama de secuencia para desarrollar las características dinámicas. Fig. 3.1 Fragmento del metamodelo de Comportamiento UML. 3.2 de elementos Nivel Estereotipos Figura 3.2: Estereotipo de comportamiento de un modelo Este estereotipo define una interacción como el aspecto más importane para caracterizar el comportamiento de un determinado patrón ver figura 3.2. El estereotipo patterninteraction extiende la metaclase Interaction. Es decir, comprende las operaciones y propiedades de esta metaclase. Dicha metaclase establece 22

23 el ámbito de aplicación del estereotipo. Este estereotipo permite validar que los elementos de una interacción se comunican de acuerdo al estándard de un determinado patrón. Es decir, los mensajes y líneas de vida deben estar correctamente construidos Restricciones en lenguaje OCL Con estas restricciones se comprueba las características del perfil y la consistencia entre los diagramas del modelo, a saber, diagrama de clases y diagrama de secuencia. El contexto de las restricciones es patterninteraction, el estereotipo que representa una interacción específica. Restricción 1 - Mensajes de Creación. Contexto PerfilNivel1::patternInteraction Message.allInstances()-> select(mensaje mensaje.messagesort=uml::messagesort::createmessage)->size() =Class.allInstances().clientDependency.getApplicableStereotypes()-> select(name='instantiate'or name='create')->size() Por cada mensaje de creación debe existir una relación de dependencia estereotipada como Instanciate o create, en el diagrama de clases. Se toman todos los objetos de tipo mensaje y se seleccionan los de tipo creación de mensaje. Y su cantidad debe ser igual a la cantidad de dependencias a las que se le haya aplicado el estereotipo Instantiate or create en el diagrama de clases. Restricción 2 Argumento de mensaje de creación. Contexto PerfilNivel1::patternInteraction Message.allInstances()-> select(messagesort=uml::messagesort::createmessage).argument-> notempty() implies Operation.allInstances().ownedParameter.type.oclIsTypeOf(Class)->notEmpty() 23

24 Si existe un mensaje de petición de creación de un objeto debe existir en el diagrama de clases una operación que contenga como párametro una clase. Si se seleccionan el conjunto de los mensajes de creación y este conjunto no está vacío esto implica que al seleccionar el conjunto de parametros de las operaciones cuyo tipo es una clase este conjunto no debe estar vacío. Restricción 3 - Lineas de vida como tipos en el diagrama de clases. Contexto PerfilNivel1::patternInteraction Lifeline.allInstances().represents.type-> forall(lineadevida Class.allInstances()-> exists(clase clase.name=lineadevida.name)) Cada línea de vida es de un tipo de clase del diagrama de clases. Por cada objeto lifeline se buscan los tipos a los que representa y para toda línea de vida debe existir una clase que pertenece al diagrama de clases. Restricción 4 - Elementos conectados por extremos de mensajes. Contexto PerfilNivel1::patternInteraction Message.allInstances().connector.end.role.type-> intersection(association.allinstances().memberend.type) ->notempty() Los extremos de mensajes conectan los mismos elementos que conectan los extremos de una asociación. Un connector es un link entre las instancias y cada end es el extremo del link. El rol representa el elemento conectado al extremo end del link. Para cada instancia de los mensajes se selecciona los links que realizan la comunicación entre las instancias de los elementos comunicados y para cada uno seleccionamos los roles y sus nombres. Debe existir una intersección entre estos extremos y los extremos de una asociación. 24

25 CAPITULO IV Perfil Patrones Particulares En el presente capìtulo se representan las definiciones para patrones de comportamiento particulares. Se creó un paquete por cada perfil particular. Para especificar sus características estructurales se importa el perfil del Nivel 0. Para sus características dinámicas se importa el perfil del Nivel 1. Así el patrón queda conformado por una combinación de estereotipos de ambos niveles que sirven como base para su especificación. La presentación de cada patrón incluye una parte teórica en forma de plantilla que contiene sus características estáticas (descripción general, clasificación, participantes). A partir de dichas características se formulan los estereotipos estructurales del patrón. Luego se explica el comportamiento del patrón y se representan sus características dinámicas a través de un diagrama de secuencia. A partir de dichas características se formula el estereotipo de comportamiento. Como corolario se enumeran las consecuencias de cada patrón. Los estereotipos estructurales extienden los estereotipos del Nivel 0, que representan características estáticas a través de: clasificadores, atributos, operaciones y relaciones. Los estereotipos comportamentales extienden los estereotipos de Nivel 1 para describir las interacciones. Los estereotipos se validan a través de restricciones en lenguaje OCL. Se chequea mediante estas restricciones que cada perfil cumpla con sus particularidades, corroborando los estereotipos que contiene un modelo. También se asegura que las clases y clasificadores contengan las operaciones y atributos del perfil particular. Por otro lado se valida la consistencia entre los diagramas de clases y diagrama de 25

26 secuencia para un determinado modelo. 4.1 Perfil Patrón Observer general Se representa una dependencia entre objetos. Subject es el tipo de objeto del cual dependen los objetos tipo Observer, necesitan estar informados de un cambio en el estado del objeto Subject ver figura Clasificación Patrón de comportamiento y de objeto. - Participantes - Subject: - Observer: Fig. 4.1: Diagrama de clases Patron Observer. Tiene una lista de referencia hacia sus observadores. Provee métodos para agregar y de desagregar observadores. Notifica a los observadores cuando un cambio en su estado ocurre. Provee la interfaz para actualizar el estado del sujeto en los observadores, cuando es notificado por Subject. - ConcreteSubject: Implementa la clase Subject. - ConcreteObserver: Contiene una referencia a objetos ConcreteSubject. 26

27 Implementa la clase Observer. A continuación se muestra en la figura 4.2 una variación del diseño anterior del patrón, donde se representan las clases Subject y Observer como interfaces. Las interfaces solo especifican servicios, no son instanciables y no contienen atributos. Dos interfaces no se pueden relacionar por medio de una composición. Si es posible que la clase implementadora de una de las interfaces, tenga una relación de composición con la otra interface, a través de la clase que la implementa. Para poder representar la relación de composición en este caso se toma como elemento fuente la clase ConcreteSubject y como destino la interface Observer. Fig. 4.2: Diagrama Patron Observer con interfaces Otra posible variación implicaría representar Subject como clase abstracta, donde se volvería al diseño mostrado en la figura 4.1. Así también si Subject se representa como interface y Observer como clase abstracta corresponde el diseño de la figura 4.2. En la figura 4.2 se muestra otro aspecto que merece un tratamiento adicional: el estado del Sujeto. En este caso la operación setstate se encuentra en la clase no participante. Está clase notifica el cambio de estado al elemento Subject. La figura 4.1 puede ser modificada para cambiara de lugar el estado del Sujeto lo que nos llevaría a la figura

28 Fig. 4.3: Diagrama Patron Observer modificado 4.2 de elementos Nivel Estereotipos Estructurales Se elaboran a partir de los elementos del patrón representados en las figuras: 4.1, 4.2 y 4.3 como casos generales del patrón. Para elaborar estos estereotipos se utilizan estereotipos importados del perfil del nivel 0: patternprofile, patternclassifier, patternclass, patternoperation. Fig. 4.4: Caracterìsticas estructurales y dinàmicas del patròn Observer. 28

29 Como se puede observar en la figura 4.4, a partir de los estereotipos del Nivel 0 y Nivel 1 se especifican nuevos estereotipos para el perfil Observer, que se describen a continuación. ObserverProfile: Hereda desde patternprofile. Sirve como contexto para verificar aspectos generales del patrón como la existencia de relaciones: asociaciones, agregaciones y composiciones. Observer y Subject: Heredan de patternclassifier. Son los elementos abstractos que figuran con el mismo nombre en el perfil. ConcreteObserver y ConcreteSubject: Heredan de patternclass. Implementan los clasificadores: Observer y Subject. Las operaciones attach, notify, update, detach, setstate y getstate heredan del estereotipo patternoperation. notify: Este estereotipo etiqueta una operación de notificación de un cambio de estado, a los observadores. update: Este estereotipo etiqueta una operación de actualización del estado del Sujeto en los observadores. attach y detach: Son estereotipos que etiquetan operaciones que agregan y quitan un elemento de tipo Observer. setstate y getstate: Son estereotipos que etiquetan operaciones cambiar y obtener el estado del Sujeto. Comportamiento El comportamiento, que muestra las colaboraciones entre objetos, puede verse como una secuencia de pasos, y representarse por medio de un diagrama de secuencia como se observa en la figura 4.5. El diagrama de secuencia representa una secuencia general que se muestra a continuación. 29

30 Fig. 4.5: Diagrama de secuencia Observer. En el momento de ejecutarse el programa existe un objeto tipo Contenedor que contiene el estado y un objeto de tipo ConcreteSubject, el objeto observado. El objeto ConcreteSubject crea uno o varios objetos de tipo ConcreteObserver. Los objetos ConcreteObserver se agregan a la lista de observadores. Se setea el estado observado en los observadores concretos. Al llegar a ConcreteSubject la señal de cambio de estado se invoca la operación notify, de notificación. La notificación desencadena la invocacón de la operación update, que actualiza el atributo State de cada observador concreto. Cuando el comportamiento del observador no depende del estado del Sujeto se puede desagregar a través de la operación detach. Estereotipo Comportamental Figura 4.6: Perfil Observer : estereotipo comportamental 30

31 Se definió el estereotipo broadcast que hereda sus características del estereotipo patterninteraction tomado del perfil del Nivel 1, como se observa en la figura 4.6. Para utilizar patterninteraction se importó el perfil del Nivel 1. El estereotipo broadcast caracteriza el comportamiento del patrón Observer, implica que a partir de la notificación (notify) de un cambio de estado en el sujeto, se invoca la actualización del estado del sujeto en los observadores (update) Restricciones definidas en OCL Las restricciones se aplican para verificar el perfil Observer comprobando la existencia de las asociaciones y composiciones entre los elementos estereotipados como Subject y Observer y entre los elementos estereotipados como ConcreteSubject y ConcreteObserver. También se comprueba que los estereotipos Observer y Subject contengan los atributos y operaciones que deben contener por definición. Respecto de su comportamiento se comprueba que exista el tipo de interacción broadcast definida para el patrón Observer. Restricción 1 - El perfil debe contener estereotipos de los participantes del patrón: Subject, Observer, ConcreteObserver y ConcreteSubject. Contexto PerfilObserver::Observer self.allownedelements().getappliedstereotypes()->select(name='subject' or name='observer' or name='concreteobserver' or name='concretesubject') ->notempty() Se comprueba la existencia de los estereotipos definidos a partir de los participantes del patrón. Dado el conjunto de los elementos estereotipados se selecciona aquellos cuyo nombre de estereotipo es Subject, Observer, ConcreteObserver o ConcreteSubjectno está vacío. Restricción 2 - El patrón debe contener una relación de asociación entre los estereotipos ConcreteSubject y ConcreteObserver. Contexto PerfilObserver::Observer Association.allInstances().memberEnd->select(m m.isnavigable()=true 31

32 and m.type.getappliedstereotypes()->select(name='concretesubject') ->notempty()).class.getappliedstereotypes()->select(name='concreteobserver') ->notempty() Dado el conjunto de los extremos de asociación se selecciona aquellos que son navegables, es decir, están dirigidos y el tipo al que apuntan tiene aplicado el estereotipo ConcreteSubject, el extremo opuesto, no dirigido tiene aplicado el estereotipo ConcreteObserver. Restricción 3 - El patrón debe contener una relación de composición entre el estereotipo Observer con alguno de los estereotipos: Subject y Observer. Contexto PerfilObserver::ObserverProfile Association.allInstances().memberEnd -> select(m m.aggregation=uml::aggregationkind::composite and m.type.getappliedstereotypes()->select(name='observer') -> notempty()).class.getappliedstereotypes() -> select(name='concretesubject' or name='subject')->notempty() Dado el conjunto de los extremos de asociación se selecciona aquellos que tienen un extremo de tipo composición, y el tipo al que apunta tiene aplicado el estereotipo Observer. Este conjunto no vacío tiene extremos opuestos tienen como fuente una clase que tiene aplicado el estereotipo Subject o el estereotipo ConcreteSubject. Restricción 4 - El perfil debe contener estereotipos de las operaciones que fijan y configuran el valor del estado del sujeto: setstate, getstate. Contexto PerfilObserver::ObserverProfile self.allownedelements().getappliedstereotypes()->select(name='setstate' or name='getstate')->notempty() Se comprueba la existencia de los estereotipos que restablecen y recuperan el estado del Sujeto. Del conjunto de los elementos estereotipados se selecciona los que están 32

33 estereotipados como setstate o getstate y este conjunto no debe estar vacío. Restricción 5 - El elemento estereotipado como Subject debe contener operaciones estereotipadas como attach, detach y notify. Contexto PerfilObserver::Subject self.getalloperations().getappliedstereotypes().->select(name = 'attach' or name = 'detach' or name = 'notify')->notempty() En el elemento estereotipado como ConcreteSubject existen operaciones a las cuales se les ha aplicado algunos de los estereotipos: attach, notify o detach. Restricción 6 - El elemento estereotipado como Subject contiene una operación que contiene como argumento un objeto estereotipado como Observer. Contexto PerfilObserver::Subject self.getalloperations.ownedparameter.type.getappliedstereotypes() -> select(name='observer') ->notempty() Dentro de la operación estereotipada como attach existen un parámetro a cuyo tipo se les ha aplicado el estereotipo Observer. Restricción 7 - El elemento estereotipado como Observer operación estereotipada como update. Contexto PerfilObserver::Observer debe contener una self.getalloperations().getappliedstereotypes()->select(name='update' )-> notempty() En el elemento estereotipado como Subject existen operaciones a las cuales se les ha aplicado el estereotipo update. Restricción 8 - Existe un mensaje creación para al menos un objeto de tipo ConcreteSubject y uno o varios de tipo ConcreteObserver. Contexto PerfilObserver::broadcast Message.allInstances()-> exists(m m.messagesort=uml::messagesort::createmessage 33

34 and m.connector.end.role.type.getappliedstereotypes() ->select(name='concreteobserver' or name='concretesubject')->notempty())) Existen mensajes cuyo tipo es de creación, y cuyo destino de creación son objetos de un tipo de objeto creado está estereotipado como ConcreteSubject o ConcreteObserver, por Observer. Restricción 9 - Existe un mensaje de llamada a la operación estereotipada como attach. Contexto PerfilObserver::broadcast Message.allInstances().signature.getAppliedStereotypes()-> select(name='attach')->notempty() Existen mensajes cuyo tipo de operación está estereotipada como attach. Restricción 10 - Existe un mensaje de llamada a la operación estereotipadas como notify. Contexto PerfilObserver::broadcast Message.allInstances()->select(m m.signature.getappliedstereotypes()-> select(name='notify')->notempty() and m.connector.end.role.type.getappliedstereotypes()->select(name='concretesubject')-> notempty())->notempty() Existe por lo menos un mensaje cuya signatura deriva de una operación estereotipada como notify que se conecta con una linea de vida cuyo rol es un estereotipo de ConcreteSubject. Restricción 11 - Contiene una interacción que envia un mensaje de invocación de actualización hacia los objetos de tipo Observador. Contexto PerfilNivel1:: broadcast Message.allInstances()->select(m m.signature.getappliedstereotypes()-> select(name='update')->notempty() and m.connector.end.role.type.getappliedstereotypes()->select(name='concreteobserver') 34

35 -> notempty()) El envio de mensajes contiene una estructura broadcast,(envio de un mensaje a un grupo especifico, los observadores). Si la interacción está estereotipada como broadcast debe existir un mensaje de invocación de la operación estereotipada como update. 4.3 Consecuencias El patrón Observer permite variar la cantidad de subjects y observers independientemente. Se puede reusar subjects sin reusar sus observers, y vice versa. Permite agregar observers sin modificar el subject u otros observers. Como consecuencia se produce: 1. Acoplamiento Abstracto entre Subject y Observer. Todos los subject conocen la lista de observers, cuya interface está definida por la clase Observer. El subject no conoce la clase concreta de un observer. El acoplamiento entre subject y observers es mínimo. 2. Soporte para la comunicación broadcast. La notificación que un sujeto envía no necesita especificar su receptor. La notificación es un broadcast automático a todos los objetos interesados que lo suscriben. Esto hace que se puedan agregar o remover observers en cualquier momento. Depende del observer manejar o ignorar una notificación. 3. Actualizaciones inesperadas. Porque los observers no tienen conocimiento de la presencia de los otros. Una operación inofensiva en el sujeto puede causar una cascada de actualizaciones a los observers y sus objetos dependientes. El criterio de dependencia, si no está bien definido o mantenido produce actualizaciones espùreas, de las que puede ser duro volver atrás. 35

36 CAPITULO V Chequeo de modelos En este capítulo se muestra la aplicación de los perfiles particulares, definidos para patrones de diseño, a casos de estudio. Se construyeron diagramas de clase para todos los ejemplos presentados, en el caso del comportamiento se utilizaron diagramas de secuencia para representar las interacciones entre objetos existentes en el modelo ejemplo en el momento de su ejecución. Una vez definido el modelo se llevó a cabo la aplicación del perfil al modelo, para lo cual haciendo click en las propiedades del paquete del modelo se selecciona la pestaña Profile. Dentro de esta ventana se hace click sobre el botón Add Profile para agregar el perfil al modelo desde el Workspace donde se encuentr. El próximo paso fue estereotipar los elementos del modelo y validar que se cumplan las restricciones. El diagrama de clases fue estereotipado con estereotipos estructurales del patrón. El diagrama de secuencia fue estereotipado con estereotipos de comportamiento. Una vez estereotipados los diagramas se validó la construcción del modelo de acuerdo a las características del patrón correspondiente y se hicieron las correcciones necesarias. A continuación se presentan los casos ejemplo para los patrones de comportamiento. 5.1 CASO DE ESTUDIO Observer En este caso particular se toma como ejemplo la dinámica de devolución de libros en una Biblioteca. El propósito de este caso de estudio, es desencadenar los procesos necesarios, en caso que el libro sea devuelto en mal estado. Se instrumenta un método para notificar a las áreas interesadas: Stock, Compras, Administración, cada vez que un libro se devuelve en mal estado. El proceso comienza cada vez que un lector devuelve un libro con la ejecución del método devuelvelibro que pertenece a la clase Biblioteca. 36

37 Si el lector devolvió el libro dañado entonces la aplicación avisa a las clases: Stock, Compras y Administración, que se ven afectadas por este hecho. Cada vez que el libro se devuelve en mal estado se crea un objeto de tipo AlarmaLibro, esta clase es el sujeto de interés para Stock, Compras y Administración. Dichas clases se convierten en observadoras de la clase AlarmaLibro, que tiene la responsabilidad de notificarles el mal estado del libro. Para poder recibir esta notificación las clases deben suscribirse como observadoras, suscripción de la cual pueden desagregarse posteriormente. En la figura 5.1 se puede ver la aplicación de los estereotipos del perfil al diagrama de clases. Fig. 5.1: Diagrama de clases Observer A continuación se muestra una ejecución del sistema en el diagrama de secuencia ver figura 5.2, donde puede verse la estructura de la interacción de tipo broadcast.dicha interacción contiene un emisor representado por una línea de vida que es de tipo ConcreteSubject y receptores, líneas de vida cuyo tipo está estereotipado como ConcreteObserver. A su vez los mensajes desde el emisor hacia los receptores derivan de la operación estereotipada como update. El desencadenante del envio de estos mensajes es el mal estado del libro que al ser registrado por la biblioteca produce un mensaje de llamada derivado de la operación estereotipada como notify. 37

38 Fig. 5.2: Diagrama de secuencia Observer Validación del modelo Utilizando la herramienta Rational Software Architect, se detectan inconsist, encias al evaluar las restricciones OCL asociadas a los estereotipos. Después de marcar los modelos, se accede a la opción de validación, y se pueden comprobar las restricciones OCL asociadas a los estereotipos. En este caso aparecen errores de validación para las restricciones 5, 6, 7, 9,10 y 11. (Figura 5.3, 5.4 y 5.5), que fueron descriptas en la especificación del patrón observador del capítulo IV, sección Fig. 5.3: Error de validación modelo Observer. En la figura 5.3 se valida que exista el correspondiente párametro de la operación attach. Fig. 5.4: Error de validación modelo Observer. 38

39 En las restricciones de la figura 5.4 se valida que existan las operaciones dentro del elemento estereotipado como Subject: attach, detach, notify (Restricción 5) y update (Restricción 7). Fig. 5.5: Error de validación modelo Observer. En las restricciones de la figura 5.5 se valida que existan los mensajes de invocación correspondientes tanto para la creación de los observadores (Restricción 9), como para la notificación del cambio de estado (Restricción 10) y su actualización en los observadores (Restricción 11). Referencias 1. Gamma, E., Helm, R., Johnson, R., Vlissides J.: Design Patterns: Elements of Reusable software, Addison-Wesley, OMG: UML Superstructure, version 2.4.1, Rational Software Architect. Link