Valid Ac i on Patrones
39
1 Validación de Patrones de Diseño de Comportamiento a través de Perfiles UML
-
Upload
victor-hugo-panca -
Category
Documents
-
view
236 -
download
0
description
proyectos de programacion
Transcript of Valid Ac i on Patrones
1
Validación de Patrones de Diseño de
Comportamiento a través de Perfiles UML
2
INDICE GENERAL
CAPITULO I ............................................................................................................................................. 4
Especificación de Patrones de Diseño .................................................................................................... 4
1.1 Patrones de diseño ......................................................................................................................... 4 1.1.1 Concepto ............................................................................................................................... 4 1.1.2 Clasificación de patrones de diseño ..................................................................................... 5 1.1.3 Características de los patrones de Comportamiento: .......................................................... 6
1.2 Una arquitectura para patrones de diseño basada en perfiles UML.............................................. 8 1.2.1 Base para las relaciones entre características estructurales y comportamentales. ........... 10 1.2.2 Consistencia de los elementos de la arquitectura .............................................................. 11 1.2.3 Metodología ....................................................................................................................... 12 1.2.4 Técnica para definir perfiles ................................................................................................ 13
CAPITULO II .......................................................................................................................................... 14
Perfil de Patrones Genérico ................................................................................................................. 14
2.1 Conceptos Introductorios ............................................................................................................. 14 2.1.1 Elementos del metamodelo UML utilizados ....................................................................... 14
2.2 Descripción de elementos Nivel 0 ................................................................................................. 16 2.2.1 Estereotipos ........................................................................................................................ 16 2.2.2 Restricciones en lenguaje OCL ............................................................................................ 17
CAPITULO III ......................................................................................................................................... 21
Perfil de Comportamiento ................................................................................................................... 21
3.1 Conceptos Introductorios ................................................................................................................. 21 3.1.1 Elementos del metamodelo UML utilizados ............................................................................ 21
3.2 Descripción de elementos Nivel 1 .................................................................................................... 22 3.2.1 Estereotipos ............................................................................................................................. 22 3.2.2 Restricciones en lenguaje OCL ................................................................................................. 23
CAPITULO IV ........................................................................................................................................ 25
Perfil Patrones Particulares .................................................................................................................. 25
4.1 Perfil Patrón Observer ...................................................................................................................... 26
4.2 Descripción de elementos Nivel 2.................................................................................................... 28 4.2.2 Restricciones definidas en OCL ............................................................................................... 31
4.3 Consecuencias .................................................................................................................................. 35
CAPITULO V ......................................................................................................................................... 36
Chequeo de modelos ........................................................................................................................... 36
5.1 CASO DE ESTUDIO Observer ............................................................................................................. 36
3
5.1.1 Validación del modelo .............................................................................................................. 38
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
1.1.1 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.
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.
1.1.2 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
Factory
Builder
Prototype
Singleton
Adaptar (de objetos)
Bridge
Composite
Decorator
Facade
Flyweight
Proxy
Chain of Responsibility
Command
Iterate
Mediator
Memento
Observer
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:
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.
1.1.3 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
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
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
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.
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.
1.2.1 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
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 2.4.1.
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.
1.2.2 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
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.
1.2.3 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
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.
1.2.4 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 1.
3. 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 .
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
2.1.1 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.
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.
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 Descripción 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.
2.2.1 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
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.
2.2.2 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()
Descripción
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)
18
Descripción
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
self.getAppliedStereotypes().parents()->select (name=' patternClassifier ')->
notEmpty())
implies
self.generalization.specific->notEmpty()
Descripción
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())
Descripción
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
(self.general().getAppliedStereotypes().parents()-
>select(name='patternClassifier') -> notEmpty())
implies
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()
Descripción
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()->
select (name=' patternClassifier ')->notEmpty()
implies
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))
Descripción
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
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) )))
Descripción
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.
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
3.1.1 Elementos del metamodelo UML utilizados
Los elementos del metamodelo UML constituyen el cimiento para los estereotipos de un
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 Descripción de elementos Nivel 1
3.2.1 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
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.
3.2.2 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()
Descripción
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()
Descripción
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))
Descripción
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()
Descripción
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.
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
26
secuencia para un determinado modelo.
4.1 Perfil Patrón Observer
4.1.1 Descripción 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 4.1.
Fig. 4.1: Diagrama de clases Patron Observer.
- Clasificación
Patrón de comportamiento y de objeto.
- Participantes
- Subject:
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.
- Observer:
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.
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 4.3.
28
Fig. 4.3: Diagrama Patron Observer modificado
4.2 Descripción de elementos Nivel 2
4.2.1 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.
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.
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
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).
4.2.2 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()
Descripción
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
32
and m.type.getAppliedStereotypes()->select(name='ConcreteSubject')
->notEmpty()).class.getAppliedStereotypes()->select(name='ConcreteObserver')
->notEmpty()
Descripción
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()
Descripción
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()
Descripción
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
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()
Descripción
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()
Descripción
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 debe contener una
operación estereotipada como update.
Contexto PerfilObserver::Observer
self.getAllOperations().getAppliedStereotypes()->select(name='update' )-> notEmpty()
Descripción
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
34
and m.connector.end.role.type.getAppliedStereotypes()
->select(name='ConcreteObserver' or name='ConcreteSubject')->notEmpty()))
Descripción
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()
Descripción
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()
Descripción
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')
35
-> notEmpty())
Descripción
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.
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.
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.
38
Fig. 5.2: Diagrama de secuencia Observer.
5.1.1 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 4.2.2
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.
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, 1994.
2. OMG: UML Superstructure, version 2.4.1, 2011.
3. Rational Software Architect. Link http://www-306.ibm.com/software/rational, 2008.
