Embed Size (px)
Citation preview
UNIVERSIDAD NACIONAL DE SAN LUIS
FACULTAD DE CIENCIAS FÍSICO MATEMÁTICAS Y NATURALES
Tesis
para optar a la titulación de posgrado correspondiente a la
Maestría en Ingeniería de Software
Formalización de Patrones de Comportamiento
desde Perfiles UML y especificaciones OCL
Lic. Alberto Alejandro Cortez
Director: Dr. Daniel Riesco
Co-Director: Mg. Ana Garis
San Luis
2015
Agradecimientos
"No se puede desatar un nudo sin saber cómo está hecho"
Aristóteles (384 AC-322 AC) Filósofo griego.
A todas las personas que me acompañaron en estos últimos años, alentándome
y enriqueciéndome con amor y sabiduría. Estoy infinitamente agradecido de que
Dios las pusiera en este camino.
Quiero dedicar esta tesis con profundo amor a mis hijos, Facundo y Gonzalo.
A todos mis amigos, que día a día compartieron este don de enseñar, a mi gran
amiga Claudia por toda su colaboración y constancia.
Agradezco a mi Director de Tesis, Daniel y su Codirectora Ana, que me
brindaron su dedicación, permanente asistencia y entrega total para poder
finalizar este proyecto.
A todos los profesores de la Maestría que me aportaron un gran conocimiento
para mi formación profesional.
Índice General
CAPITULO I .................................................................................................................. 1
Introducción .................................................................................................................. 1
1.1 Descripción del problema ............................................................................... 3
1.2 Estado del arte ............................................................................................... 5
1.2.1 Trabajos relacionados ............................................................................. 6
1.3 La Propuesta ................................................................................................ 17
1.4 Motivación, hipótesis y objetivos, contribuciones y publicaciones ................. 18
1.4.1 Motivaciones.......................................................................................... 18
1.4.2 Hipótesis y objetivos .............................................................................. 18
1.4.3 Contribuciones ....................................................................................... 20
1.4.4 Publicaciones derivadas ........................................................................ 21
1.5 Estructura de la tesis .................................................................................... 22
CAPITULO II ............................................................................................................... 25
Modelado, Metamodelado en el contexto MDA. UML, Perfiles. OCL .......................... 25
2.1 El concepto de modelo en MDA .................................................................... 25
2.2 Lenguaje de modelado ................................................................................. 26
2.3 Arquitectura .................................................................................................. 27
2.4 Relación entre modelos y metamodelos ....................................................... 28
2.5 UML .............................................................................................................. 31
2.5.1 Introducción ........................................................................................... 31
2.5.2 Características ....................................................................................... 32
2.6 Perfiles ......................................................................................................... 34
2.7 OCL .............................................................................................................. 39
CAPITULO III .............................................................................................................. 43
Especificación de Patrones de Diseño ........................................................................ 43
3.1 Patrones de diseño ....................................................................................... 43
3.1.1 Concepto ............................................................................................... 43
3.1.2 Clasificación de Patrones de Diseño ..................................................... 44
3.2 Catálogo de patrones ................................................................................... 45
3.3 Características de los patrones de Comportamiento: .................................... 47
3.4 Una arquitectura para patrones de diseño basada en Perfiles UML ............. 49
3.4.1 Metodología ........................................................................................... 51
3.4.2 Técnica para definir el perfil de un patrón particular............................... 51
CAPITULO IV ............................................................................................................. 53
Perfil de Patrones Genérico ........................................................................................ 53
4.1 Conceptos Introductorios .............................................................................. 53
4.1.1 Elementos del metamodelo UML utilizados ........................................... 53
4.2 Descripción de elementos nivel 0 ................................................................. 56
4.2.1 Estereotipos .......................................................................................... 56
4.2.2 Restricciones en lenguaje OCL ............................................................. 58
CAPITULO V .............................................................................................................. 65
Perfil de Comportamiento ........................................................................................... 65
5.1 Conceptos Introductorios .............................................................................. 66
5.1.1 Elementos del metamodelo UML utilizados ........................................... 66
5.2 Descripción de elementos nivel 1 ................................................................. 69
5.2.1 Estereotipos .......................................................................................... 69
5.2.2 Restricciones definidas en OCL ............................................................. 70
CAPITULO VI ............................................................................................................. 73
Perfil Patrones Particulares......................................................................................... 73
6.1 Patrón Observer ........................................................................................... 74
6.1.1 Descripción General .............................................................................. 74
6.1.2 Descripción de elementos nivel 2 – Patrón Observer ............................. 77
6.1.3 Restricciones definidas en OCL para Observer ..................................... 79
6.1.4 Aplicación de perfiles a un caso de estudio del Observer ...................... 88
6.1.5 Gestión del Framework .......................................................................... 91
6.2 Patrón Command.......................................................................................... 95
6.2.1 Descripción General .............................................................................. 95
6.2.2 Descripción de elementos nivel 2 – Patrón Command .......................... 97
6.2.3 Restricciones definidas en OCL para Command ................................... 98
6.2.4 Aplicación de perfiles a un caso de estudio del Command .................. 104
6.2.5 Gestión del Framework ........................................................................ 106
6.3 Patrón Memento ......................................................................................... 110
6.3.1 Descripción General ............................................................................ 110
6.3.2 Descripción de elementos nivel 2 - Patrón Memento ........................... 113
6.3.3 Restricciones definidas en OCL para Memento ................................... 114
6.3.4 Aplicación de perfiles a un caso de estudio del Memento .................... 118
6.3.5 Gestión del Framework ........................................................................ 120
CAPITULO VII .......................................................................................................... 123
Conclusiones y Trabajos Futuros .............................................................................. 123
7.1 Conclusiones .............................................................................................. 123
7.2 Trabajos futuros .......................................................................................... 125
Bibliografía ................................................................................................................ 127
Apéndice A ............................................................................................................... 133
Especificaciones OMG .......................................................................................... 133
Apéndice B ............................................................................................................... 147
OCL ...................................................................................................................... 147
Apéndice C ............................................................................................................... 157
Métodos y atributos del metamodelo UML utilizados ............................................ 157
Apéndice D ............................................................................................................... 161
Uso de perfiles en Rational Software de IBM ......................................................... 161
Índice de tablas
Tabla 2-1 : Notación gráfica de vínculos. ............................................................................. 38
Tabla 2-2 : Notación gráfica de estereotipos, metaclases y perfiles. ............................... 38
Tabla 3-1: Clasificación de los patrones de diseño. ........................................................... 44
Tabla 6-1: Orden general Observer. ...................................................................................... 85
Tabla 6-2: Orden general Command. .................................................................................. 103
Tabla 6-3: Orden general Memento. ................................................................................... 116
Tabla A-1: Multiplicidad de una asociación. ....................................................................... 138
Tabla B-1: Tipos OCL Bàsicos y sus valores. .................................................................... 152
Tabla B-2: Ejemplos de operaciones matemáticas en los tipos predefinidos. .............. 152
Tabla B-3: Ejemplos de operaciones de cadena en los tipos predefinidos................... 152
Índice de figuras
Figura 2.1: Capas de arquitectura MDA. .............................................................................. 28
Figura 2.2: Ejemplo aplicando niveles MDA. ....................................................................... 29
Figura 2.3: Perfil: Sintaxis abstracta. ..................................................................................... 35
Figura 2.4: Ejemplo Perfil EJB. .............................................................................................. 39
Figura 3.1: Arquitectura de patrones de diseño. ................................................................. 50
Figura 4.1: Fragmento del metamodelo UML: características estructurales. ................ 54
Figura 4.2: Fragmento del metamodelo UML: Interfaces. ................................................ 55
Figura 4.3: Metaclase Class. .................................................................................................. 56
Figura 4.4: Estereotipos para modelos estáticos. ............................................................... 56
Figura 5.1: Fragmento del metamodelo - Características dinámicas............................... 66
Figura 5.2: Fragmento del metamodelo de UML - Líneas de vida. .................................. 67
Figura 5.3: Fragmento del metamodelo de UML - Mensajes. ........................................... 68
Figura 5.4: Estereotipos de comportamiento de un modelo. ............................................. 69
Figura 6.1: Diagrama de clases Patrón Observer. .............................................................. 74
Figura 6.2: Diagrama de secuencia Patrón Observer. ....................................................... 76
Figura 6.3: Características estructurales y dinámicas del Patrón Observer. .................. 78
Figura 6.4: Diagrama de clases ejemplo Biblioteca. ........................................................... 89
Figura 6.5: Diagrama de secuencia ejemplo Biblioteca. .................................................... 90
Figura 6.6: Diagrama de clases ejemplo Biblioteca mal formado..................................... 92
Figura 6.7: Diagrama de secuencia ejemplo Biblioteca mal formado. ............................. 92
Figura 6.8: Errores producidos por verificación de Observer. ........................................... 93
Figura 6.9: Diagrama de clases Patrón Command. ............................................................ 95
Figura 6.10: Diagrama de secuencia Patrón Command. ................................................... 96
Figura 6.11: Características estructurales y dinámicas del Patrón Command. .............. 97
Figura 6.12: Diagrama de clases ejemplo Servidores . .................................................... 105
Figura 6.13: Diagrama de secuencia ejemplo Servidores . ............................................. 106
Figura 6.14: Diagrama de clases ejemplo Servidores mal formado. ............................. 107
Figura 6.15: Diagrama de secuencia ejemplo Servidores mal formado. ....................... 108
Figura 6.16: Errores producidos por verificación de Command ...................................... 109
Figura 6.17: Diagrama de clases Patrón Memento. ......................................................... 110
Figura 6.18: Diagrama de secuencia Patron Memento. ................................................... 112
Figura 6.19: Características estructurales y dinámicas del Patrón Memento. .............. 113
Figura 6.20: Diagrama de clases ejemplo Memoria. ........................................................ 118
Figura 6.21: Diagrama de secuencia del ejemplo Memoria. ........................................... 119
Figura 6.22: Diagrama de clases ejemplo Memoria mal formado. ................................. 120
Figura 6.23: Diagrama de secuencia ejemplo Memoria mal formado. .......................... 121
Figura 6.24: Mensajes de Error de mala formación Memento. ....................................... 121
Figura A.1: Diagrama de clases del paquete Kernel. ...................................................... 134
Figura A.2: Notación gráfica de una clase. ........................................................................ 136
Figura A.3: Ejemplo de clases. ............................................................................................. 136
Figura A.4: Notación gráfica de paquete. ........................................................................... 136
Figura A.5: Paquete con clases. .......................................................................................... 137
Figura A.6: Citar clase de otro paquete. ............................................................................. 137
Figura A.7: Ejemplo gráfico de herencia. ............................................................................ 137
Figura A.8: Ejemplo de asociación bidireccional. .............................................................. 138
Figura A.9: Ejemplo de asociación unidireccional. ............................................................ 138
Figura A.10: Ejemplos de multiplicidad de una asociación. ............................................. 138
Figura A.11: Ejemplo gráfico de una interfaz. .................................................................... 139
Figura A.12: Ejemplo gráfico implementación de una interfaz. ....................................... 139
Figura A.13: Elementos del diagrama de Interacción/Secuencia. .................................. 140
Figura A.14: Ejemplo de fragmento combinado con operador LOOP. .......................... 141
Figura A.15: Diagrama de estados. ..................................................................................... 142
Figura B.1: Ejemplo Diagrama de Clase ............................................................................ 147
Figura B.2: Uso de operador ocl AsType()….………………………………………………………………….155
Figura D.1: Creación de proyecto de Perfiles….……………………………………………………………..161
Figura D.2: Proyecto de Perfil UML…………….……………………………………….............................162
Figura D.3: Extensión de Perfiles…………………..…………………………………................................162
Figura D.4: Paleta de elementos gráficos………….………………………………………......................162
Figura D.5: Elementos del metamodelo UML…….……………………………………….………............163
Figura D.6: Ejemplo de Perfil…………………………….………………………........................................163
Figura D.7: Liberación de Perfil ……………………….……………………………...................................163
Figura D.8: Aplicación de Perfiles ……………….……………………………………...............................164
Figura D.9: Perfil Importado ……………………….…………………………….........................................165
Figura D.10: Perfil Nivel 0 aplicado al ejemplo ………….…………………………………………..........165
1
CAPITULO I
Introducción
En esta introducción se presenta una reseña del problema y una evaluación del estado
del arte, con un relato de los distintos trabajos realizados a través del tiempo. También
se exponen las razones de su realización, los objetivos, la contribución y las
publicaciones derivadas de la tesis. Por último se explica la estructura del trabajo.
Los patrones de diseño aportan la experiencia de diseñadores expertos, ayudando a
los desarrolladores de software en la documentación y transferencia de conocimientos,
proporcionándoles un vocabulario común. Uno de los catálogos más conocidos acerca
de los patrones de diseño es presentado por el Gamma et. al [1] .
Presentan 23 patrones de diseño siguiendo dos criterios principales: alcance y
finalidad. El primero se refiere a que si el patrón se aplica principalmente a las clases o
a los objetos; y el segundo establece una clasificación que los divide en creacional
(que crean los objetos), estructural (que componen las estructuras) y comportamiento
(que representan la interacción entre los objetos).
La semántica no está definida con precisión. Debido a esta problemática, se han
propuesto diferentes enfoques con el fin de formalizarlos y, por lo tanto, de mejorar su
uso, aplicación y validación.
Un enfoque plantea el uso de complejos formalismos matemáticos o lógicos que no
son fáciles de entender por un diseñador inexperto en esta metodología como lo
presenta Taibi [2].
Otro enfoque más general es el uso de perfiles UML especificado [3]. Un perfil UML es
un mecanismo para extender la sintaxis y la semántica de dicho lenguaje para una
plataforma o dominio particular. UML es uno de los lenguajes de modelado más
2
populares utilizados en el proceso de desarrollo de software para especificar y
documentar como enuncian Booch et. al [4]. Es un lenguaje no formal, por lo tanto los
modelos son anotados con el lenguaje de lógica de primer orden OCL (por sus siglas
en inglés, Object Constraint Language), con el fin de otorgar su formalidad y precisión
denotado en la especificación [5]. Utilizando dicho mecanismo de extensión para
generar perfiles se puede establecer un vocabulario específico para el dominio de
patrones de diseño. El perfil UML incluye los elementos necesarios para hacer posible
la extensión del lenguaje. Ellos son: los estereotipos (en inglés, stereotypes), los
valores etiquetados (en inglés, tags values) y las restricciones (en inglés, constraints).
La presente tesis sigue este último enfoque de investigación. Se construye una
arquitectura de tres niveles, para aplicar los estereotipos en ella. Posteriormente se
establecen especificaciones para proporcionar la verificación de los patrones de
diseño de comportamiento en modelos UML estáticos y dinámicos, logrando de este
modo proveer a los diseñadores de software un marco de verificación formal, para su
posterior uso. La misma se elabora a través de la herramienta de modelado RSA (por
sus siglas en inglés, Rational Software Architect) [6]. La propuesta del presente trabajo
es la Formalización de Patrones de Comportamiento desde Perfiles UML y
especificaciones OCL.
A través del estudio del metamodelo de UML especificado [7], se pueden descubrir las
relaciones existentes entre las características estructurales y dinámicas de los
patrones de diseño de comportamiento. Permitiendo inducir que se pueden establecer
restricciones que eliminen incoherencias entre los modelos estáticos, representados
por clases y los modelos dinámicos representados por diagramas de secuencia.
Este aporte permite la verificación de consistencias entre diagramas y la relación de
los diferentes elementos del patrón relacionados entre sí; para poder verificar y
establecer restricciones formales, es necesario crear estereotipos que definan los
elementos de cada patrón en los diagramas antes mencionados. De este modo se
garantiza que debe existir consistencia entre los diagramas de clases y el diagrama de
secuencia, o sea entre lo estructural y el comportamiento.
3
1.1 Descripción del problema
Los Patrones de Diseño facilitan a los desarrolladores de software a resolver
problemas de diseño orientado a objetos que repetidamente ocurren. Proveen un
medio para comunicarse a través de un alto nivel de abstracción y permiten
incrementar el vocabulario de diseño.
Los patrones de diseño son una técnica para documentar soluciones a problemas de
diseño recurrentes y para compartir experiencia en diseño independientemente del tipo
de aplicación expresadas por Coad [8], Berczuk [9] y Gamma et al. [1].
Ellos son presentados comúnmente en forma Alexandrina, propuesta por C. Alexander
[10], en la cual los principios de diseño son explicados primeros en inglés informal. Y
luego clarificados con diagramas ilustrativos y ejemplo de código específico planteada
por Gamma et al. [1]. Este formato no es suficientemente informativo para que los
diseñadores comprendan los principios de diseño y aprendan cómo aplicar patrones
para resolver sus propios problemas. Sin embargo como han señalado Eden y
Hirshfeld [11] el formato Alexandrina es muy informal por lo tanto trae tanta
ambigüedad que a menudo es materia de disputa si una implementación conforma un
patrón o no. Actualmente es ampliamente reconocido que una pobre presentación de
patrones puede llevar a un sistema hacia una pobre calidad como lo explica Fayad et.
al [12].
También puede impedir su mantenimiento y evolución, de acuerdo a estudios
experimentales según Khomh y Guéhéneuc [13]. Estos autores sugieren que los
patrones deberían ser usados con precaución ya que pueden impactar negativamente.
Por ejemplo el patrón Observer no hace un sistema más modular, pero mejora la
modularidad de otros patrones. Permite, la separación entre el modelo, la vista y
controlador en el patrón MVC.
El uso de este patrón hace un sistema más flexible: mediante la eliminación de las
dependencias entre módulos, el patrón Observer hace que sea posible sustituir estos
módulos sin problemas. También es fácil de extender funcionalidades mediante la
adición de una o más entidades que cooperan con una existente. Este modelo respeta
el principio de Abierto Cerrado. Por lo tanto, se puede esperar que impacte de manera
positiva en la reutilización, la capacidad de expansión, y sencillez, pero que impacte
4
negativamente en la facilidad de aprendizaje y comprensión debido a la complejidad
de la estructura y el acoplamiento implícito, lo que hace que sea difícil para el
mantenimiento e identificar en un primer momento las relaciones entre las clases. El
patrón Observador debilita la encapsulación y disminuye robustez porque el
acoplamiento implícito lleva a una difícil corrección de errores.
El uso extensivo en la industria del software de los mismos, obliga la necesidad de
crear metodologías para especificarlos, visualizarlos y documentarlos como así
también herramientas para integrarlos y manejarlos.
Otra debilidad de la forma Alexandrina es que presenta conocimiento en una forma no
estructurada. Cada patrón es descripto separadamente, con su relación con otros
patrones sintéticamente explicada. Pero comprender patrones individuales en
aislamiento no es suficiente. Según Winn y Calder ellos necesitan ser catalogados [14]
y combinados para solucionar problemas del mundo real. La especificación formal
puede no sólo remover ambigüedad, como se discutió en la sección previa, sino
también establecer una base sólida para el razonamiento a cerca de sus propiedades
y sus relaciones.
Actualmente, la mayoría de los patrones se describen utilizando una combinación de
las descripciones textuales, notaciones gráficas como UML, y fragmentos de código de
ejemplo. La intención es que sean fáciles de leer, usar, y elaborar un vocabulario
común de patrones. Sin embargo, las descripciones no formales dan lugar a la
ambigüedad, y limitan el apoyo de herramientas y su uso correcto.
Las notaciones matemáticas pueden ayudar a eliminar esta ambigüedad, clarificando
las nociones mencionadas. Por lo que no es sorpresivo que en los últimos años se
halla investigado con interés sobre la especificación formal de los patrones de diseño,
pero el potencial completo de la especificación formal de patrones no ha sido
alcanzado aún.
Uno de los aspectos relevantes encontrados en los patrones de diseño, es que la
semántica no está definida con precisión. Debido a esta problemática, se han
propuesto diferentes enfoques con el fin de formalizarlos para mejorar su uso,
aplicación y validación.
5
Existen numerosos enfoques formales y otros menos formales de investigaciones
orientadas a documentar y especificar patrones de diseño. La corriente de
investigadores que utilizan métodos formales establece una precisa y adecuada forma
de especificar y documentar los patrones.
El uso generalizado de los patrones a través del lenguaje UML permite otra forma de
visualizarlos, y es importante destacar que los mismos son normalmente mostrados a
través de lenguajes gráficos.
La ventaja de que UML es un lenguaje gráfico, estandarizado e integrado a todos los
equipos de desarrollo permite describir a los patrones en una forma sencilla y
amigable.
Debido a que es un lenguaje de propósito general, en ocasiones no es útil para
instancias de soluciones particulares ya que no es lo suficientemente expresivo.
Razón por la cual es inexorable utilizar el mecanismo de extensión que aporta UML
para extender su semántica y sintaxis a través de los perfiles para modelar situaciones
de diseño específicas.
El presente trabajo se centra en esta característica para establecer un catálogo de
patrones de diseño, formalizando su estructura a través del uso de OCL.
1.2 Estado del arte
A lo largo del tiempo se han estudiado los patrones con diversos fines como por
ejemplo proporcionar catálogos de elementos reusables en el diseño de sistemas de
software o evitar la reiteración en la búsqueda de soluciones a problemas ya
conocidos y solucionados anteriormente. Otro de los propósitos es implementarlos en
el desarrollo de software.
Los patrones pueden describirse a través de especificaciones formales y otras menos
formales.
La primera de ella es el camino más adecuado para desarrollar el planteo de una
notación precisa, sin embargo es sofisticada y difícil de entender. Necesita un
conocimiento exhaustivo como base matemática y lógica, razón por lo cual son menos
elegibles por los diseñadores de software.
6
La segunda propuesta es menos formal, fácil de entender y usar, ya que generalmente
tiene una notación gráfica/textual, otorgando esta simpleza de uso, imprecisión y
ambigüedad al diseño de modelos.
Algunas investigaciones recientes han adaptado notaciones de modelado existentes y
técnicas de especificación formal, mientras otras han desarrollado nuevos lenguajes
específicos para el propósito.
A continuación se describen algunos de los desarrollos encontrados en el área
utilizando las especificaciones formales, según sus diferentes clasificaciones y los
distintos aspectos que distinguen.
1.2.1 Trabajos relacionados
En esta sección se divide los trabajos existentes en el área según dos categorías, el
enfoque de modelado y metamodelado.
Los primeros especifican patrones de diseño como un modelo de sistemas de
software, por ejemplo, como un conjunto de características dentro de su estructura de
código de programa y/o comportamientos de ejecución.
El segundo enfoque especifica patrones de diseño como metamodelos, por ejemplo
como un conjunto de características de modelos en sí mismos.
Enfoque de Modelado:
Este fue el primero de ser explorado y aún puede ser visto dentro de GOF, donde cada
patrón de diseño es ilustrado con un diagrama de clase [4]. Pero incluso cuando está
acompañado por un diagrama de secuencia, un diagrama de clases no es suficiente
para capturar toda la información trasmitida por un patrón de diseño. Así muchos
investigadores propusieron extensiones al modelado orientado a objetos.
Por ejemplo, existen algunas propuestas que han estudiado el uso de UML para
documentar y definir patrones. Lauder y Kent [15] aplican una notación de modelado
visual, sin recurrir a simbolismos matemáticos. Representan patrones con UML y
“Diagramas de Restricciones” (en inglés, Constraints Diagrams). Segregan la
especificación de patrones dentro de tres modelos. Un modelo abstracto, llamado
“modelo de rol”, determina el espíritu esencial del patrón. El “modelo de tipos” refina el
modelo anterior, incorporando restricciones específicas del dominio. El “modelo de
7
clase” forma un despliegue concreto para refinar el modelo de tipo. Por otro lado
separan la especificación de patrones dentro de tres modelos. Así se obtienen
diferentes representaciones de patrones de acuerdo a su grado de generalidad pero
no utilizaron la capacidad de los perfiles de UML ni la elaboración de restricciones de
OCL.
Un aporte interesante es la representación visual de los patrones de diseño. Porras y
Guéhéneuc [16] evaluaron la eficiencia de la representación para visualizar patrones
de diseño en diagramas UML. Como resultado del trabajo proveyeron un framework
para comparar actuales y futuras notaciones. Expusieron luego de su análisis que era
mejor utilizar estereotipos con diagramas de clases UML para identificar composición y
rol de los elementos de un patrón frente al uso de anotaciones de colaboración de
UML. Y también llegaron a la conclusión de que las herramientas deberían incluir
además de UML otras notaciones para diferentes tareas. En esta publicación se
analiza solo la eficiencia de la representación para visualizar patrones pero no se
construye especificaciones.
Lano et al. [17] también se enfoca a nivel de código y trata los patrones como
transformaciones desde soluciones defectuosas a soluciones mejoradas.
Le Guennec et al. [18], modificaron el metamodelo de UML 1.3 para facilitar el
modelado de patrones de diseño y representar sus ocurrencias en el mismo. La
propuesta es representar la “esencia” de los patrones de diseño en el metanivel con
conjuntos de restricciones. Se usan colaboraciones en cada meta-nivel, y restricciones
OCL en forma conjunta para especificar las restricciones estructurales del patrón. Se
introduce un conjunto de modificaciones al metamodelo. En el presente trabajo se usa
también el lenguaje UML pero la versión 2.5, la cual sigue manteniendo la
incorporación de perfiles y de esta manera no se necesita modificar el metamodelo.
Mak et al. [19] definen la notación de colaboraciones extendiendo UML 1.5 para
acciones semánticas.
Otros trabajos han estudiado el uso de perfiles de UML para definir y documentar
patrones.
Zdun y Avgeriou [20] identificaron primitivas arquitectónicas que ocurren en patrones.
Utilizan perfiles UML para expresar las primitivas arquitectónicas. Las mismas ofrecen
8
abstracciones de modelados reusables que pueden ser usados para modelar
soluciones sistemáticas que son encontradas repetitivamente en diferentes patrones.
La principal contribución radica en modelar variantes de los patrones usando
primitivas, identificar aspectos de patrones que son difíciles de expresar utilizando el
recurso antes mencionado. Determinando un esquema generalizado que usa un
vocabulario de componentes y conectores específicos de patrones, utilizando OCL
para formalizar la extensión.
Dong y Yang [21] aportan una solución al desarrollo de software donde se combinan
múltiples patrones, los elementos participantes pueden intervenir en diferentes
patrones. Esto complica al diseñador en la visualización del modelo de dominio.
Presentan un perfil UML para mejorar la visualización de los patrones en diagramas
UML. De esta forma es posible representar, en el diagrama, el rol de los elementos en
un patrón de diseño. También utilizan un esquema de colores para representar
visualmente los diagramas de clases y de colaboración. En este estudio se investiga
solo la representación gráfica de los patrones a través de un perfil, pero tiene un débil
conjunto de especificaciones de restricciones OCL.
Keen Ngee Loo et al. [22], proponen un método para definir y visualizar los roles de un
patrón y sus variantes de interacción extendiendo el diagrama de secuencia UML a
través de perfiles de UML. En un diagrama normal de secuencia de UML, el fragmento
de interacción no tiene información de contexto del patrón. Así la extensión debe
mantener la información de contexto después de que el patrón está adaptado a una
aplicación diseño. Por otra parte, debe vincular los roles de los fragmentos que existen
en las descripciones de texto del patrón a sus correspondiente a roles en un modelo.
Los autores deben trabajar en la elaboración de restricciones OCL para formalizar el
perfil.
Garis A. et al. [23] establecen las ventajas de utilizar los perfiles para definir,
documentar y visualizar patrones de diseño. Formulan una estructura para la definición
de patrones dada por los perfiles UML. Sin embargo, no es posible definir la semántica
para todos los patrones en un sólo perfil. Se ha definido un perfil para cada patrón y se
ha descripto la semántica de cada uno en forma particular. La imposición de una
jerarquía entre niveles de perfiles permite el reúso de definiciones.
9
Se propone una arquitectura de 4 capas. En el nivel inferior se plantea el “Perfil de
Paquete” del estándar declarado por la OMG, le sigue el “Perfil del Framework de
Patrones de Diseño”, continua en el orden el “Perfil de Clasificación de Patrones” los
patrones están clasificados en creacionales, de objetos y de comportamiento y por
último en la capa superior se establecen los “Perfiles Particulares” de cada patrón. De
este modo la incorporación de un nuevo patrón en el nivel superior deberá adquirir las
mismas características genéricas de los niveles inferiores pero se deberá especificar
las características propias del mismo. La presente tesis adopta el camino formulado
por estos autores, contribuyendo en la definición de especificaciones para los patrones
de diseño de comportamiento.
Las técnicas de especificación de métodos formales han sido aplicadas por Mikkonen
[24], quien formaliza los comportamientos temporales de software en acciones de
lógica temporal.
Taibi describe en [2] el lenguaje BPSL (en inglés, Balanced Pattern Specification
Language) que incorpora la especificación formal de aspectos estructurales y de
comportamiento de los patrones. Los aspectos estructurales son formulados en lógica
de primer orden, y los aspectos dinámicos en lógica temporal. En el marco de este
trabajo fue desarrollada una herramienta para transformar las especificaciones al
lenguaje Java a partir de instancias de patrones. También investigó cómo la
composición de patrones puede ser definida en un framework.
Algunos autores han trabajado en el desarrollo de herramientas para reconocer
patrones mediante el análisis del código fuente. Los ejemplos incluyen:
FUJABA propuesto por Niere et al. [25], HEDGEHOG establecido por Blewitt et al. [26]
y finalmente PINOT por Nija Shi y Olsson [27]. Dong et al. [28] plantean una
comparación exhaustiva de las herramientas que permiten el reconocimiento de
patrones para una revisión y estudio.
Estas herramientas a menudo usan una representación intermedia de características
estructurales y de comportamientos de programa. La más común de estas
representaciones incluye programación lógica (Kramer y Prechelt [29]); y predicados
de lógica de primer orden (Beyer et al. [30]).
10
Todas ellas pueden ser consideradas como especificaciones de patrones a nivel del
modelo. Ellas se consideran como herramienta de diseño con extracción del código
fuente. Pero el nivel de abstracción es demasiado bajo y las especificaciones
necesariamente están abrumadas con detalles relativos a usos específicos de
lenguajes de programación. Esto hace difícil alcanzar alta precisión y reutilización en el
reconocimiento de patrones (Dong et al. [28]). Algunas propiedades de
comportamiento no pueden ser extraídas desde el código fuente porque no se pueden
determinar.
Un problema adicional es que “Los lenguajes de especificación formales, no están
moldeados para expresar detalles de implementación”, como cita Eden et al [31]. Ellos
describen las características externas sin especificar los detalles de implementación
de todo, pero un patrón de diseño es acerca de una solución orientada a la
implementación para un tipo de problema.
Los lenguajes de modelado gráfico como UML no son suficientemente expresivos. En
UML, las descripciones de diseño de GOF han sido trasmitidas simplemente en notas
informales, sólo usando diagramas como ilustración. Esto se debe a que en ausencia
de formalización no se han incluido en el lenguaje.
Finalmente herramientas como PINOT (Nija Shi y Olsson [27]) son deseables. Las
herramientas a nivel de diseño minimizan errores en la etapa de temprana de diseño,
aportando un gran valor. En tal caso los patrones de diseño deben ser especificados
en características estructurales y de comportamiento de modelo de diseño más que en
el código fuente. Esto motivó al segundo enfoque.
Enfoque de Metamodelado
La aproximación de LEPUS, avanzado por Eden [11] y [32]; incluye las facilidades de
ambos enfoques en el mismo lenguaje (modelado y metamodelado). Para soportar
modelado LEPUS ha creado entidades de diseño orientado a objetos tales como
clases, atributos y métodos. Conectados por relaciones tales como herencia,
invocación y creación. Para soportar el metamodelado LEPUS, las entidades y otros
elementos reflejan los bloques comunes de construcción dentro de los patrones de
diseño GOF. Ejemplos de éstos son los llamados clan, tribu, jerarquía y biyección, y
sus semánticas son definidas en lógica de predicados de primer orden.
11
Las relaciones entre los patrones pueden ser descriptas como lógica de relaciones.
(Eden and Hirshfeld [11]).
Un último avance se presentó las notaciones visuales y el lenguaje de lógica de primer
orden, en una definición formal (Eden et al. [33]) y referido como LEPUS3 y CLASS-Z
respectivamente. Una herramienta ha sido implementada para extraer información
desde programas JAVA y representarlos en forma de diagramas LEPUS3. Ello puede
entonces decidir y probar automáticamente si un programa satisface o no las
especificaciones en LEPUS3 (Gasparis et al. [34]). Sin embargo, LEPUS cubre sólo
las características estructurales estáticas de diseño ignorando las características de
comportamiento.
Otro trabajo en esta categoría (Lenguaje visual) es el Design Pattern Modeling
Language (DPML) de Maplesden et al. [35, 36]. En este lenguaje, las soluciones de
patrones de diseño son modeladas como una colección de participantes,
representando características estructurales tales como clases y métodos, adicionando
restricciones asociadas y dimensiones. Las restricciones pueden relacionar un simple
objeto representando un participante, en cuyo caso ellos son escritos como
anotaciones de lenguaje natural dentro de llaves, o dos objetos, en cuyo caso, ellos
son relaciones binarias dibujadas como líneas con flechas entre los dos participantes.
Son relaciones predefinidas y los ejemplos incluyen implements, extends, realizes,
declared in, define in, y refer to. Las dimensiones especifican el conjunto de objetos
que interpretan un rol y las claves de dimensión pueden ser usadas para especificar
que dos o más participantes tienen la misma dimensión, por ejemplo el número de
instancias de errores. Cuando las relaciones binarias son aplicadas a participantes
asociados con dimensiones, ellos pueden ser mapeados a una relación total, regular,
completa o incompleta, entre los conjunto de objetos. Las facilidades para modelados
son mantenidas más separadas que estas para metamodelado que en el caso de
LEPUS.
DPML también define un conjunto de notaciones visuales para especificar los modelos
de instancia de patrones. Una herramienta llamada DPTOOL, reportada en
(Maplesden et al. [36]), soporta ambas especificación de patrón y el chequeo de la
conformidad del patrón respecto al modelo de UML.
12
DPML tiene algunas deficiencias que afectan a su expresividad y precisión. Para
comenzar, las restricciones sobre los participantes son informales y de nuevo, sólo
características estructurales de patrones de diseño pueden ser especificadas.
También, algunos usos importantes no son dirigidos y de este modo mantienen
problemas abiertos. Esto incluye cómo razonar a cerca de patrones, cómo
componerlos, y cómo especificar variantes sin tener que usar un diagrama separado
DPML para cada uno. LEPUS Y DPML ambos mezclan modelado y metamodelado en
el mismo lenguaje.
El Role-Based Meta-modeling Language (RBML) propuesto por France et al. [37],
tomó un enfoque estricto de metamodelado. RBML extiende UML para metamodelado
en una notación como UML. Un patrón es visto como un metamodelo, así que cada
instancia del patrón es un modelo en UML. Los participantes de un patrón y las
relaciones entre ellos son representados en una notación gráfica como roles. Además
las restricciones son representadas en OCL, y las semánticas de métodos y atributos
pueden ser definidas como plantillas OCL, instanciadas para cada patrón. Un
metamodelo RBML puede ser traducido en un metamodelo UML en forma de un
diagrama de clases UML. También podemos determinar si un modelo UML conforma a
un patrón de diseño especificado por un metamodelo RBML. La expresividad de RBML
ha sido demostrada definiendo metamodelos de diagramas de clases, diagramas de
secuencia y diagrama de máquinas de estado, para el patrón de diseño Iterator como
lo hace Kim [38].
Basados en las especificaciones RBML como estas Kim y Lu [39] proponen un
enfoque de programación lógica para identificar patrones en diagrama de clases UML.
El mismo, un modelo UML es un conjunto de hechos Prolog y un patrón es una
consulta Prolog. Ellos ilustraron el enfoque con el patrón Visitor, pero sin los detalles
de cómo traducir un diseño UML en programas Prolog, tampoco como traducir una
especificación de patrones RBML en una consulta Prolog. Más recientemente Kim y
Shen [40] desarrollaron un algoritmo para chequear si un modelo UML conforma a un
patrón especificado en RBML. Ellos implementaron como una herramienta llamada
RBMLCC, como un componente instalable en IBM RATIONAL ROSE [41]. También
reportaron un caso de estudio donde 7 de los patrones GOF son especificados por
Kim y Shen [42]. Sin embargo la herramienta no soporta completamente RBML aún.
En particular, restricciones OCL y las plantillas son omitidas.
13
Otra herramienta en esta categoría, es el Pattern Description Language (PDL)
descripta por Albin-Amiot et al. [43].Los diagramas de PDL no son ni modelos ni
metamodelos. PDL es definido por un metamodelo extendido de UML y nuevamente,
los patrones de diseño son especificados en una notación gráfica. Un diagrama que
conforma a este metamodelo extendido se llama un modelo abstracto y debe ser
instanciado a un modelo concreto como una instancia del patrón. Sin embargo, esta
instanciación no es simplemente la relación de conformidad de modelo a metamodelo
vista en la arquitectura de cuatro capas de la OMG.
Por esta razón, Elaasar et al. [44] propone el Pattern Modeling Framework. Extiende el
MOF (por sus siglas en inglés, Meta Object Facility) y definen un lenguaje de
metamodelado llamado Epattern, con el cual es posible especificar patrones en
cualquier lenguaje de modelado compatible con MOF, en la capa M2 y M3 de la
arquitectura de metamodelado de cuatro capas de la OMG, y tomar las ventajas de las
herramientas de metamodelado existentes.
Cada patrón es un subconjunto de modelos de diseño con ciertas características
estructurales y de comportamiento, razón por lo cual la especificación formal de
patrones es un problema de metamodelado. Zhu y Shan [45] comienzan definiendo el
dominio de todo los modelos en una sintaxis abstracta para modelar lenguajes escritos
en una meta anotación Graphic Extension of BNF (por sus siglas en inglés, GEBNF).
Entonces para cada patrón de diseño definen predicados de primer orden a
restricciones de modelos tal que cada modelo satisface el predicado como una
instancia del patrón. Dicho predicado es escrito en lenguaje de primer orden inducido
desde la definición de la sintaxis abstracta del lenguaje gráfico de modelado. De esta
forma un GEBNF es un plus a los predicados de primer orden. Aprovechando esta
notación para definir modelos de dominio para las clases y diagramas de secuencia de
UML. Como en el caso de la definición BNF de la sintaxis de un lenguaje de
programación, una definición GEBNF de la sintaxis de un lenguaje de modelado es un
conjunto de reglas de sintaxis que definen símbolos no terminales basados en
símbolos terminales.
Las extensiones que GEBNF aporta a BNF son dos. La primera es la denominación de
campo, lo que permite un conjunto de símbolos de función que se deduce de una
definición de sintaxis para formar una firma de un lenguaje de la lógica de predicados
de primer orden. El segundo es la facilidad para ocurrencias referenciales de símbolos
14
no terminales, por lo que las estructuras bidimensionales como gráficos pueden ser
definidos.
Otro camino planteado por Elaasar et al. [46] que describen una aproximación
genérica para especificar dominios específicos de patrones de diseño para DSML
basados en MOF a nivel de metamodelo y automáticamente detectar sus ocurrencias
en modelos. La aproximación está basada en QVT (Query/View/Transformation). Los
patrones son especificados declarativamente con transformaciones de QVT-Relations
[47] desde modelos DSML [48] donde los elementos que juegan roles de patrones son
identificados, para un modelo recientemente definido como DSML, para reportar
ocurrencias identificadas.
Se genera una herramienta en eclipse GMF(por su siglas en inglés de Graphical
Modeling Framework) [49], que permite implementar un lenguaje visual llamado Visual
Modeling Language (VPML). Con esta herramienta se permite especificar un patrón
básico y a partir de él proponer variantes. Se usa Medini QVT [50] para ejecutar
transformaciones que detecten los patrones, basándose en modelos EMF (por su
siglas en inglés de Eclipse Modeling Framework) [51] los resultados de esta
transformación se puede visualizar en la herramienta creada.
Lano et al. [52] describieron 24 especificaciones de transformaciones de modelos,
patrones de diseño y 5 patrones de arquitectura de transformación de modelos. Se
identificaron aquellos patrones de transformación que pueden ser considerados como
meta transformaciones, en el que la aplicación de un patrón a una transformación la
reestructura, para mejorar algunas características de calidad tales como modularidad o
eficiencia.
Una forma natural de implementar la aplicación de patrones de transformación de
modelos, es mediante la formalización de transformaciones de alto orden, donde éstos
son provistos por una herramienta o lenguaje de transformación. Este trabajo se
enfocó en patrones para refinamiento, abstracción, migración y transformaciones de
refactoring. Además el trabajo se necesita en otras áreas para identificar patrones,
tales como comparación de modelos, mezclando y transformando bidireccionalmente.
Más allá del desarrollo del framework de medición también podría ser usado para
proveer identificación automatizada de especificación y fallas de diseño en
transformaciones.
15
El enfoque planteado por los distintos autores desde la clasificación de modelos
presenta estas consideraciones:
De las propuestas mostradas hasta aquí se observa que tanto Lauder y Kent [15], Le
Guennec et al. [18] y Mak et al. [19] definen una sintaxis especial para representar
patrones, sin utilizar perfiles UML. Lauder y Kent representan patrones con UML y
“Diagramas de Restricciones”, aplicando una notación de modelado visual. Le
Guennec y Mak extienden a través de la modificación del metamodelo de UML, sin
utilizar las prestaciones propuestas a partir de la versión UML 2.0.
Sin embargo, si se desea definir una sintaxis especial para un dominio particular, como
es en este caso “patrones de diseño”, resultaría más conveniente utilizar el mecanismo
de extensión propuesto por UML: el perfil. De esta forma, un perfil es usado no solo
para definir un dominio específico, sino que es utilizado para definir un dominio
general, como lo es la definición de patrones.
Si bien Dong y Yang [21] y Keen Ngee Loo et al. [22] definen un único perfil general,
orientado principalmente a la visualización de patrones cuando son aplicados en
modelos UML. Dong y Yang se ocupan de los roles de patrones que ocupan
elementos del UML compartidos, que se desempeñan en la combinación de múltiples
patrones aplicados a un diseño y enriquecen la investigación aportando ampliando el
concepto de las variantes de interacción que se produce en el comportamiento. No
particularizan la definición para un patrón específico. Y deben complementar con
restricciones OCL para garantizar formalidad en el diseño.
Una de las ventajas de usar Perfiles UML para modelar patrones es que si las
herramientas UML reconocen las características de los perfiles (de acuerdo a UML
2.0), no se requiere construir una herramienta específica para patrones.
Finalmente, se observa que es posible establecer una alternativa al enfoque
presentado por Debnath et al. [23], quienes plantean la generación de una arquitectura
de capas para elaborar perfiles según corresponda en cada una, otorgando
características que deben cumplir en las mismas. Así se obtienen diferentes
representaciones de patrones de acuerdo a su grado de generalidad.
La presente tesis continúa la anterior propuesta, ampliando el catálogo de perfiles para
los patrones de diseño de comportamiento, generando restricciones OCL tanto para la
16
estructura como para el comportamiento, asegurando de este modo la consistencia
entre los diagramas de clases y de secuencia.
Por otro lado en el enfoque planteado desde la categoría de los metamodelos
surgen los siguientes comentarios:
Se observa que, los metamodelos son difíciles de entender. Esto es particularmente
resuelto en los trabajos presentados por France et al. [37] a través de RBML,
Maplesden et al. [36] con DPML y Albin-Amiot et al. [43] en la propuesta de PDL,
introduciendo nuevas notaciones gráficas para metamodelos, pero las semánticas
para éstos son complejas y no han sido formalmente definidas.
Los metamodelos gráficos son ambiguos como todo lenguaje basado en UML, ya que
el mismo es informal. Eden et al. [33] con LEPUS tiene su semántica especificada
formalmente, pero su notación no es usada ampliamente por los diseñadores y no
maneja características de comportamiento.
No son suficientemente expresivos los metamodelos gráficos para especificar patrones
en forma precisa. RBML usa OCL para compensar, pero OCL está diseñado para
modelado y tiene problemas de expresividad cuando es usado en metamodelados, por
lo cual se complica seleccionar herramienta que soporten esta características (France
et al. [37]).
Zhu y Shan [45] plantean las ventajas de la formalización de un metamodelo de los
patrones de diseño especificando la estructura como el comportamiento
sistemáticamente en una notación formal legible, habilitando la composición y la
transformación de ellos, y facilitando, a través de una herramienta, la aplicación de los
mismos en la etapa de diseño.
Finalmente, las variantes no pueden ser especificadas de otra manera más que
usando un diagrama diferente para cada variación.
Si bien este aporte es interesante también utiliza métodos formales para precisar los
patrones, siendo una opción poco elegible por los diseñadores de software.
Elaasar et al. [44][46][53] muestran los resultados en los casos de estudio presentando
sólo una efectividad de detección de los patrones en un 3% cuando se aplican
solamente a la estructura, pero la precisión mejora cuando se agregan las
17
interacciones. Si bien generan un DSML a partir de una instancia de MOF, los perfiles
son instancias de UML, por lo que no generan un nuevo lenguaje. Como resultado se
generó una herramienta pero no contempla los perfiles UML, los modelos complejos y
sus posibles variaciones.
El planteo formulado por Lano et al. [52] no consideran la fusión, composición de
patrones, comparación de modelos, transformaciones de alto orden, o transformación
de aspectos tales como la bidireccionalidad y propagación del cambio. Se necesitan
futuros trabajos para identificar y documentar patrones para tales aspectos y
categorías de transformación.
1.3 La Propuesta
El presente trabajo propone la definición de Patrones de Diseño de Comportamiento
con Perfiles UML. En el desarrollo del mismo se crea una biblioteca de perfiles de
patrones. Utilizando los perfiles de UML, como metodología de definición de perfil para
un patrón, se establecen las bondades de utilizar los perfiles para definir, documentar
y visualizar patrones de diseño.
Se selecciona los patrones de diseño del catálogo GOF como objeto de estudio,
particularmente los Patrones de Diseño de Comportamiento definiendo un perfil
adecuado en los casos de estudio. De esta manera se conforma la librería de perfiles
fundacionales del presente trabajo.
A lo largo de la especificación de patrones se observan características generales y
otras particulares. De este modo se establece que no es posible precisar una misma
semántica para todos los patrones en un único perfil, razón por lo cual es
imprescindible especificar la semántica para cada patrón particular como así también
la semántica que especifique el comportamiento.
Esta situación origina el planteo de una arquitectura para patrones usando perfiles
UML, que contenga la especificación no sólo de aspectos estructurales, sino también
de comportamiento. Y también verificar la consistencia entre los diagramas de clase y
secuencia, como así también el orden de la secuencia de la ejecución de los mensajes
entre objetos.
18
1.4 Motivación, hipótesis y objetivos, contribuciones y publicaciones
1.4.1 Motivaciones
Este trabajo es impulsado por el deseo de mejorar el estado del arte en el uso de los
patrones de diseño en la industria del software. Por lo tanto, esta tesis investiga cómo
proporcionar un mejor apoyo para desarrollar sistemas de software de calidad
utilizando un lenguaje de notación gráfica como es UML y su mecanismo de extensión
para generar nueva semántica a través de los Perfiles UML a los patrones de diseño
de comportamiento.
Los diseñadores de software pueden adoptar este criterio de una manera amigable y
segura para sus desarrollos donde apliquen el uso de los patrones de diseño, en
especial los de comportamiento según el catálogo GoF.
No se usa una sintaxis especial para representar patrones; sino un artefacto UML: “el
perfil”. De esta forma, un perfil se utiliza no solo para definir un dominio general sino
también para un dominio específico, como lo es la definición de patrones.
De esta forma no se verían con la limitación de aprender complejos métodos formales
orientados a la matemática y la lógica.
El uso de patrones para el diseño de modelos en la industria del software aumenta su
eficiencia.
1.4.2 Hipótesis y objetivos
Desde el comienzo de este trabajo y teniendo en cuenta lo descrito en la sección
anterior, buscamos responder los siguientes interrogantes:
1- ¿Qué debería formar parte de la esencia de un patrón de diseño?
2- ¿Qué aspectos deberían especificarse en los patrones de diseño de
comportamiento?
19
3- ¿Es posible determinar la consistencia entre las características estructurales y
dinámicas de un modelo, comprobando que los elementos pertenecientes a la
estructura también estén presentes en el comportamiento?
4- ¿Es posible determinar en el comportamiento el orden lógico de la secuencia de
aparición de los mensajes acorde a cada patrón de diseño de comportamiento?
5- ¿Es posible describir el comportamiento a través de un perfil de UML?
6- ¿Es posible reutilizar los perfiles generados a través una arquitectura en capas?
Por tanto, el objetivo principal de este trabajo deriva directamente de la hipótesis
expuesta:
Especificar las características dinámicas de patrones de comportamiento a través de
Perfiles UML. Definir una arquitectura compuesta por tres niveles de representación,
que pueda ser verificada a través de una herramienta UML, formalizando los aspectos
estructurales del primer nivel, mediante restricciones. En el segundo nivel, establecer
un perfil con restricciones para los aspectos dinámicos de los patrones de
comportamiento, y en el tercer nivel individualizar un perfil particular por cada patrón
de comportamiento.
Para lograr el objetivo propuesto se han planteado los siguientes objetivos parciales:
Analizar los conceptos base: Perfiles UML y lenguaje OCL.
Comparar y analizar las herramientas que trabajan en forma estándar con
los conceptos estudiados.
Definir las particularidades más importantes de los patrones de
comportamiento a ser especificados.
Crear los Perfiles necesarios para la especificación: genérico, de
comportamiento y particulares.
Construir una arquitectura en una herramienta de software para organizar
los Perfiles.
Definir la metodología para la validación y verificación de los perfiles.
20
Construir casos de estudio para la validación y verificación de los perfiles.
1.4.3 Contribuciones
La arquitectura MDA (por sus siglas en inglés, Model-Driven Architecture) [54] es un
framework para el desarrollo de software dirigido por modelos, definido por el Object
Management Group (OMG) [3].
La propuesta de MDA es elevar el nivel de abstracción mediante el uso de modelos.
Propone el desarrollo dirigido por modelos, partiendo de modelos con alto nivel de
abstracción hasta llegar a implementaciones concretas. De esta manera, los
conceptos de modelado están mucho menos ligados a la tecnología de
implementación y existen diferentes niveles de abstracción.
Las bondades ofrecidas por los perfiles se pueden aprovechar en la transformación de
modelos a otros modelos o a código (facilitando la tarea a los diseñadores de
software). En los últimos años el concepto de perfil ha servido para cubrir distintos
dominios.
De esta forma se establece un marco de formalización de especificaciones para los
patrones de diseño de comportamiento permitiendo la generación de modelos
verificados para una generación de código precisa.
El desarrollo de la especificación de patrones particulares tiene un valor considerable.
Si esto es llevado a cabo, es posible conformar una librería de patrones con perfiles.
Esta librería puede ser luego introducida en cualquiera de las herramientas UML
habilitadas para la incorporación de perfiles.
Con la implementación de los Perfiles se puede generar modelos marcados. Esta
técnica facilita la transformación de un modelo independiente de la plataforma a un
modelo específico de plataforma a través de una transformación.
En particular, si en los modelos se aplican patrones de diseño y se genera código a
través de una transformación MDA el resultado del desarrollo puede ser más eficiente,
previa verificación y validación del mismo.
21
Por lo dicho anteriormente, se puede concluir que este trabajo tiene las siguientes
contribuciones:
1- La visualización y documentación de los patrones de diseño, con una definición
estándar a nivel práctico, en un marco formal utilizando los perfiles de UML.
2- El presente trabajo utiliza el mismo enfoque planteado [23], pero establece nuevas
definiciones para la especificación de patrones de comportamiento. Se enriquece el
nivel 0 (de características estructurales) cuyas descripciones solo incluían el diagrama
de clases, agregando diagramas de secuencia y sumando nuevas especificaciones a
las descriptas. La ventaja esencial de esta metodología es que al usar perfiles no se
requiere una herramienta específica sino que se puede usar cualquier software de
modelado que reconozca el lenguaje UML, OCL y la definición de perfiles.
3- El beneficio principal de una arquitectura de este tipo es la reutilización de los
distintos perfiles utilizados en la jerarquía. Dicha reutilización produce valor agregado
en el desarrollo del software.
4- Verificar la consistencia entre el modelado de la estructura de un sistema y su
comportamiento a través de verificaciones formales con OCL.
1.4.4 Publicaciones derivadas
La propuesta planteada en el presente trabajo, se ha publicado en diferentes
congresos nacionales y revistas internacionales.
Alberto Cortez, Ana Garis, Daniel Riesco. “Perfiles UML para la Especificación de
Patrones de Comportamiento: Un caso de Estudio", Proceedings of the XVIII
Congreso Argentino de Ciencias de la Computación (CACIC 2012), 2012. ISBN:
978-987-1648-34-4.
Alberto Cortez, Ana Garis. “Aplicación de Perfiles UML en la Especificación de
Patrones de Comportamiento”, Proceedings of the 13th Argentine Symposium on
Software Engineering (ASSE 2012), 41 Jornadas Argentinas de Informática (41
JAIIO), ISSN: 1850-2792, pp. 199-214, 2012.
22
Alberto Cortez, Ana Garis, Daniel Riesco. “Perfiles UML para la Definición de
Patrones de Comportamiento”, Proceedings of the XIV the Workshop de
Investigadores en Ciencias de la Computación, Editorial de la Universidad Nacional
de Misiones, ISBN 978-950-766-082-5, pp. 467-471, 2012.
Alberto Cortez, Ana Garis, Daniel Riesco. “Formalización de Patrones de Diseño de
Comportamiento”, Proceedings of the XIII the Workshop de Investigadores en
Ciencias de la Computación (WICC 2011), Editorial de la Universidad Nacional de
Rosario, ISBN 978-950-673-892-1, pp. 435-438, 2011.
Alberto Cortez, Claudia Naveda, Ana Garis, Daniel Riesco. “Validación de Patrones
de Diseño de Comportamiento a través de Perfiles UML, un caso de estudio”.
REABTIC 2014 – Revista editada por la Facultad Três de Maio (SETREM), de Três
de Maio, RS, Brasil. Revista electrónica Argentina – Brasil de Tecnologías de
Información y de la Comunicación. ISSN 2446-7634.
http://revistas.setrem.com.br/index.php/reabtic/issue/view/2
1.5 Estructura de la tesis
La tesis se encuentra dividida en siete capítulos. El presente capítulo contiene la una
introducción a la problemática de la formalización de los patrones de diseño, se
presentan distintos enfoques utilizados por investigadores para resolver su
ambigüedad. También se elaboran los conceptos preliminares de toda tesis, hipótesis,
objetivos, contribuciones y publicaciones derivadas del presente trabajo.
En el segundo capítulo se explican los conceptos de metamodelado y la tecnología
MDA, mostrando la gran importancia puesta en los modelos, para guiar el proceso de
desarrollo de software. Se continúa con una explicación del lenguaje UML y el
mecanismo que tiene para realizar la extensión a través de los perfiles de UML. Se
establece posteriormente la noción de OCL para formalizar los modelos y
metamodelos.
El tercer capítulo se hace una breve referencia a los patrones de diseño y
especialmente se expresan las características de comportamiento. Seguidamente se
brinda una explicación de la arquitectura jerárquica planteada para aplicar los perfiles
23
de UML en cada nivel, se determinan las funcionalidades y responsabilidades de las
restricciones que cada capa debe asumir. Por último se muestra el mecanismo para
definir perfiles de patrones.
En el capítulo cuatro se describe el primer nivel de la arquitectura planteando el perfil
de patrones genérico. Se analizan los elementos del metamodelo de UML que se
utilizarán para definir los estereotipos. También se destacan los formalismos
necesarios para la especificación de la estructura de los patrones de diseño. Los
aspectos estructurales refieren a elementos del diseño orientado a objetos:
clasificadores, clases, atributos, operaciones. Estos aspectos estructurales se verifican
a través de estereotipos creados para ese fin. Por último se crean las restricciones que
deben cumplir los elementos generados en este nivel.
En el capítulo cinco está dedicado al segundo nivel de la arquitectura, donde se
especifica el perfil de patrones de comportamiento, se realiza una descripción de
aspectos dinámicos y su especificación formal.
En el capítulo seis se presenta el tercer nivel de la arquitectura, donde se plantea la
especificación para cada patrón particular con sus restricciones y la aplicación en
ejemplos de casos de estudio.
Finalmente, en el capítulo siete se formulan las conclusiones derivadas de la
investigación y posibles trabajos futuros.
24
25
CAPITULO II
Modelado, Metamodelado en el contexto MDA. UML, Perfiles. OCL
MDA es un framework para el desarrollo de software definido por la OMG. Su clave es
la gran importancia puesta en los modelos, para guiar el proceso de desarrollo de
software. En la actualidad la propuesta MDA está tomando cada vez más fuerza en el
desarrollo de software como se presenta [55].
MDA postula que la especificación de la funcionalidad del sistema no debe tener en
cuenta su implementación en una plataforma de una tecnología específica. Una forma
de facilitar este proceso es la identificación de elementos que deben transformarse en
un modelo de una manera concreta, y marcarlos como tales. Por ejemplo, los modelos
que contengan en su interior patrones de diseño deben contener ciertos roles. Este es
el tema tratado en este trabajo.
2.1 El concepto de modelo en MDA
Un modelo [4] es una descripción o especificación de un sistema y su ambiente para
algún cierto propósito. Los siguientes modelos son el centro de MDA:
Modelo independiente de la computación (en inglés, Computation Independent Model
o CIM): también llamado modelo del dominio, muestra el sistema en el ambiente en
que operará y lo que se espera que haga. Es útil no sólo para entender el problema,
sino también como fuente de un vocabulario común para usar en los otros modelos.
Modelo independiente de la plataforma (en inglés, Platform Independent Model o PIM):
tiene un alto nivel de abstracción y es independiente de cualquier tecnología de
implementación. Se centra en el funcionamiento de un sistema mientras oculta los
26
detalles necesarios para una plataforma particular. Este modelo muestra aquella parte
de la especificación completa que no cambia de una plataforma a otra, por ejemplo
dotNET o J2EE.
Modelo específico a la plataforma (en inglés, Platform Specific Model o PSM): combina
el punto de vista independiente de la plataforma con un enfoque adicional en el detalle
del uso de una plataforma específica para un sistema. Es adecuado para especificar el
sistema en términos de construcciones de implementación que son disponibles en una
tecnología de implementación específica. Por ejemplo, un PSM EJB típicamente
contendrá términos específicos EJB, como “home interface”, “entity bean”, etc.
Modelo específico a la implementación (en inglés, Implementation Specific Model o
ISM): muestra el sistema a nivel de código, se refiere a componentes y aplicaciones
escritos en lenguajes de programación tales como Java o Eiffel.
2.2 Lenguaje de modelado
Otro elemento de MDA es el lenguaje de modelado. Un modelo es siempre escrito en
un lenguaje. Se puede entender un modelo o esquema conceptual como un mapa de
conceptos (clases) y sus relaciones (asociaciones) que intenta representar un
fragmento de la realidad. Un modelo especifica qué elementos pueden existir en un
sistema.
La definición de un lenguaje de modelado especifica que elementos pueden existir en
un modelo. Por ejemplo, el lenguaje UML especifica que dentro de un modelo se
pueden usar los conceptos Clase, Estado, Paquete, etc. Debido a esta similitud, se
puede describir un lenguaje por medio de un modelo, usualmente llamado metamodelo
[7]. El metamodelo de un lenguaje describe que elementos pueden ser usados en el
lenguaje.
Como un metamodelo es también un modelo, el metamodelo en sí mismo debe estar
escrito en un lenguaje. Este lenguaje se llama metalenguaje.
27
2.3 Arquitectura
La Arquitectura de cuatro capas de Modelado es la propuesta de la OMG orientada a
estandarizar conceptos relacionados al modelado, desde los más abstractos a los más
concretos.
En la figura 2.1 se observa la arquitectura definida por la OMG de cuatro capas para
sus estándares, llamadas M0, M1, M2 y M3:
1. En el nivel M3 reside el meta-metamodelo. Este nivel forma la base de la
arquitectura de metamodelado. MOF es un lenguaje estándar de la OMG y es la capa
más abstracta.
2. En el nivel M2 reside el metamodelo. Éste es una instancia de un meta-metamodelo
(elemento de M3) que a su vez especifica elementos de la capa M1. Lenguajes de
modelado como UML, CWM (por sus siglas en inglés, Common Warehouse Model)
[56] son instancias del MOF. El lenguaje UML está considerado un estándar para
especificar modelos conceptuales.
3. El nivel M1 contiene modelos. Cada modelo es una instancia de un metamodelo
(elemento de M2) y a su vez especifica elementos de la capa M0. En la definición de
modelos en UML se pueden usar entre otros elementos: clases, atributos y
asociaciones, ya que el metamodelo de UML define qué es una clase, qué es un
atributo y qué es una asociación.
4. En el nivel M0 se encuentra un sistema en ejecución en el cual existen instancias
reales, los elementos en este nivel son instancias de los elementos especificados por
modelos a nivel M1.
28
Nivel Descripción
M3 MOF
M2 metamodelos, instancias de los elementos MOF : UML
M1 modelos, instancia de un metamodelo UML
M0 el sistema, objetos y datos, instancias de los elementos de un modelo
Figura 2.1: Capas de arquitectura MDA.
2.4 Relación entre modelos y metamodelos
Un meta-metamodelo es un modelo que define el lenguaje para representar un
metamodelo. La relación entre un meta-metamodelo y un metamodelo es análoga a la
relación entre un metamodelo y modelo [3].
Un metamodelo es un modelo que define el lenguaje formal para representar un
modelo. Un metamodelo se expresa con notación gráfica y con un lenguaje formal,
como OCL, para aumentar su precisión y eliminar ambigüedades. Si bien este
acercamiento carece de la precisión de la especificación de los métodos formales,
ofrece una especificación intuitiva y comprensible.
El metamodelado entonces es un mecanismo que permite definir formalmente
lenguajes de modelado, como por ejemplo, UML y OCL.
Como resultado se puede mostrar la definición de capas del modelo MOF (figura 2.1) a
través del ejemplo usado en la figura 2.2, en dicho ejemplo se ven diferentes niveles.
29
Figura 2.2: Ejemplo aplicando niveles MDA.
Nivel M0: Instancias
En el nivel M0 se encuentran todas las instancias “reales” del sistema, es decir, los
objetos de la aplicación. Aquí no se habla de clases, ni atributos, sino de entidades
físicas que existen en el sistema. Para entender mejor la relación entre los elementos
en las distintas capas, se presenta un ejemplo de cómo se modela un sistema con
UML.
En el caso de la figura 2.2 se trata de un sistema donde se maneja información acerca
de los clientes, y los artículos de los cuales se dispone. Existen dos clientes “c1” y
“c2”, donde “c1” tiene los atributos nombre, dirección y teléfono, cuyos valores son
respectivamente “David Aguilar”, “Ronda Norte” y 968905541. Y “c2” contiene a su vez
los valores “Miguel Martínez”, “Abderraman 2,4” y 968294122.
Todas estas entidades son instancias pertenecientes a la capa M0.
30
Nivel M1: Modelo del sistema
Por encima de la capa M0 se sitúa la capa M1, que representa el modelo de un
sistema de software. Los conceptos del nivel M1 representan categorías de las
instancias de M0. Es decir, cada elemento de M0 es una instancia de un elemento de
M1. Sus elementos son modelos de datos, por ejemplo entidades como “Cliente”,
“Artículo”, atributos como “nombre” y relaciones entre estas entidades.
En el nivel M1 aparece entonces la entidad “Cliente” la cual representa los clientes del
sistema, tales como “David Aguilar”, con los atributos nombre, dirección y teléfono. Lo
mismo ocurre con la entidad “Artículo”.
Nivel M2: Metamodelo
Análogamente a como ocurre con las capas M0 y M1, los elementos del nivel M1 son
a su vez instancias del nivel M2. Esta capa recibe el nombre de metamodelo. En este
nivel aparecen conceptos tales como Clase, Atributo o Asociación.
Siguiendo el ejemplo, la entidad “Cliente” será una instancia de la metaclase Class del
metamodelo UML. Sus atributos, nombre, teléfono y dirección serán instancias de la
metaclase Attribute. El ejemplo más popular de un lenguaje en la capa M2 es el
metamodelo UML, que describe el lenguaje UML.
Nivel M3: Meta-metamodelo
De la misma manera se observa los elementos de M2 como instancias de otra capa, la
capa M3 o capa de meta-metamodelo. Un meta-metamodelo es un modelo que define
el lenguaje para representar un metamodelo. La relación entre un meta-metamodelo y
un metamodelo es análoga a la relación entre un metamodelo y modelo.
Es el nivel más abstracto, que permite definir metamodelos concretos. La OMG define
a MOF como el lenguaje estándar de la capa M3. Esto supone que todos los
metamodelos de la capa M2, son instancias de MOF. Puede ser usado para definir
metamodelos orientados a objetos, como es el caso de UML, y también para otros
metamodelos, como es el caso de las redes de Petri o metamodelos para servicios
web.
31
La figura 2.2 muestra la relación entre los elementos del metamodelo UML (Nivel M2)
con los elementos del metamodelo de MOF (Nivel M3). Puede verse que las entidades
de la capa M2 son instancias de las metaclases MOF de la capa M3.
Por último, como vista general, la figura 2.2 muestra las cuatro capas de la
arquitectura de modelado, indicando las relaciones entre los elementos en las
diferentes capas. Puede observarse que en la capa M3 se encuentra el meta-
metamodelo MOF, a partir del cual se pueden definir distintos metamodelos en el nivel
M2, como UML, OCL, etc.
Las instancias de estos metamodelos serán los elementos del nivel M1, como modelos
UML por ejemplo. A su vez, instancias de los elementos M1 serán los objetos, como
los objetos UML.
Una de las principales ventajas de este enfoque es que cada uno de los objetos puede
ser verificado contra su respectivo metaobjeto, en la capa inmediata superior. Por
ejemplo, la clase Cliente debe corresponder a las características y especificaciones de
Class en el metamodelo.
MOF define una arquitectura de metamodelado estricta, cada elemento de modelo de
cada capa se corresponde estrictamente con un elemento de modelo de la capa
superior.
2.5 UML
2.5.1 Introducción
El diseño y modelado de sistemas ocupan un importante lugar entre los ingenieros de
software [57]. Los modelos brindan la posibilidad de abstraer sistemas y facilitar la
posterior codificación. La elaboración de buenos modelos ayuda a la comunicación
entre ingenieros. Por otro lado, asegura un correcto desarrollo de la arquitectura del
sistema, a medida que este aumenta en complejidad.
Para la descripción de un modelo, es necesario tener un lenguaje con una sintaxis y
semántica precisa. Un lenguaje de modelado, permite elaborar los modelos requeridos
en el diseño de un sistema. Existen numerosos lenguajes de modelado, pero UML es
uno de los más conocidos y utilizados en la actualidad.
32
UML es creado por Grady Booch, James Rumbaugh e Ivar Jacobson [4]. Numerosas
corporaciones ven la utilidad del lenguaje, razón por la cual se conforma un consorcio.
En 1997, el consorcio produce la primera versión y lo presenta a la OMG, quien lo
publica como lenguaje de modelado estándar. A partir de allí, la OMG publica
numerosas versiones, hasta llegar a la versión 2.5, vigente en la actualidad.
La versión UML 2.5 es una revisión menor de la especificación UML 2.4.1, que en ella
presentaba dos documentos que se complementaban entre sí, “Superstructure”
(superestructura) y “Infraestructure” (infraestructura). La primera define los
constructores a nivel de usuario y la segunda los fundamentos de los constructores del
lenguaje.
2.5.2 Características
UML permite fácilmente especificar, construir, visualizar y documentar artefactos de
sistemas de software [7]. La construcción de sistemas se relaciona a la posibilidad de
mapear modelos por ejemplo, a lenguajes de programación o a tablas en una base de
datos.
La posibilidad de visualización de diferentes elementos gráficos en los modelos, es
una de las características más representativas de UML. Es un lenguaje de modelado
visual para construir sistemas orientados a objetos y basados en componentes.
El aspecto referido a la documentación está ligado a la organización de componentes
que surgen del proceso de desarrollo se software (requerimientos, arquitectura,
diseño, código, pruebas, prototipos, revisiones, etc.). Dichos componentes son
fundamentales en el control, validación y comunicación de un sistema.
UML provee los medios para una adecuada organización del proceso de desarrollo de
software. De esta forma las personas involucradas (analistas, desarrolladores,
clientes, etc.) puedan comprenderlo correctamente. UML toma muchas de las buenas
prácticas relacionadas al modelado orientado a objetos, unificando los métodos más
utilizados en el mundo.
Entre alguno de los principales objetivos de UML está, el de proveer mecanismos de
extensibilidad y especialización para extender conceptos. También soportar
especificaciones independientes de lenguajes de programación y procesos de
33
desarrollo. Finalmente tiene como objetivo soportar conceptos de desarrollo de alto
nivel tales como componentes, colaboraciones, frameworks y patrones.
Los bloques de construcción de UML son los elementos, las relaciones y los
diagramas. Los primeros son abstracciones básicas (en UML existen cuatro:
estructurales, de comportamiento, de agrupamiento y anotacionales). Las relaciones
ligan los elementos entre sí (existen cinco: dependencia, asociación, generalización,
realización y agregación). Los diagramas son representaciones gráficas de un
conjunto de elementos. En el anexo A se pueden ampliar los conceptos mencionados
a UML.
UML define diagramas gráficos para mostrar diferentes vistas del modelo y ofrecer
múltiples perspectivas de un sistema. Un diagrama representa un conjunto de
elementos que integran un sistema. Dichos elementos pueden aparecer en todos o en
parte de alguno o varios diagramas.
Los diagramas definidos por UML son: diagrama de casos de uso, de clase, de
comportamiento, de estados, de actividad, de interacción (colaboración y secuencia),
implementación, componentes y despliegue.
El enfoque de metamodelado utilizado para definir UML se basa en técnicas de
especificación formal. Es deseable que dichas especificaciones contengan las
propiedades de correctitud, precisión y consistencia; como así también la
particularidad de no incorporar detalles insignificantes.
La correctitud del metamodelo está relacionada con su validación; por ejemplo, las
reglas bien formadas deberían ayudar a verificar la sintaxis abstracta y a identificar
errores. La precisión de la técnica de especificación se refiere a la no existencia de
ambigüedades entre la sintaxis y la semántica del lenguaje.
Las características de UML lo posicionan como un lenguaje de modelado de propósito
general; capaz de ser aplicado en diferentes dominios de aplicación y en distintas
plataformas de implementación. Son muchos los dominios de aplicación cubiertos por
UML. El lenguaje es estructurado modularmente, esto permite seleccionar la parte del
lenguaje más útil para cada fin.
Por otro lado, un exceso de modularidad trae añadidos inconvenientes. Dos
herramientas UML que soportan diferentes subconjuntos del lenguaje tienen
34
aparejados problemas de intercambio. Por esta razón, se requiere un balance entre
modularidad y facilidades para intercambio. Para lograr dicho objetivo, UML provee el
concepto de “unidades del lenguaje”.
Las unidades de lenguaje agrupan los conceptos de modelado. Proveen al usuario de
los elementos necesarios para representar aspectos del sistema, de acuerdo a un
paradigma particular.
2.6 Perfiles
En repetidas ocasiones, UML no es lo suficientemente expresivo para representar
conceptos específicos de dominios particulares. Por esta razón, UML estándar incluyó
un mecanismo para extender y adaptar UML a diferentes dominios y plataformas: el
"Perfil UML” (en inglés, “UML Profile”).
La propuesta de extensión del perfil, no permite modificar al metamodelo existente,
sino adaptar al metamodelo existente, agregando constructores propios para un
dominio particular. El origen del mecanismo se remonta a la versión UML 2.0. En ese
momento se definieron los conceptos de “estereotipos” y “valores etiquetados” como
elementos básicos de extensión. La intención inicial era proveer un conjunto de
características que permitiese añadir información a los elementos del modelo de una
manera sencilla y flexible.
Las versiones siguientes procuraron otorgar cada vez mayor precisión en su definición.
Pero es el actual UML 2.5 el que muestra mayores avances en este sentido, y provee
una técnica de metamodelado sólida y consistente, donde los estereotipos son
especificados como metaclases, los valores etiquetados como meta atributos y los
perfiles como una clase de paquete.
El mecanismo de extensión del metamodelo impone restricciones en cómo el
metamodelo UML puede ser modificado. No está permitido insertar nuevas
metaclases, o modificar definiciones de la metaclase (agregando meta asociaciones).
Las características presentes en UML 2.5 hacen que sea posible especializar la
semántica de elementos del metamodelo de UML estándar. También brinda una
convención notacional para definiciones de estereotipos gráficos. Las clases del
paquete Profile son mostradas a través de un diagrama de clases (figura 2.3).
35
Descripción de metaclases
Dentro de la especificación de la sintaxis abstracta, se describen las metaclases
principales con sus respectivas restricciones y operaciones adicionales.
Figura 2.3 Perfil: Sintaxis abstracta.
Class: Clase se relaciona con un subtipo de asociación, esto indica como ésta puede
ser extendida a través de uno o más estereotipos. Pero un estereotipo no puede ser
extendido por otros estereotipos.
Extension: La extensión es una clase de asociación. Se utiliza para indicar que las
propiedades de una metaclase son extendidas a través de un estereotipo. Brinda la
capacidad para flexibilizar la agregación y el borrado de estereotipos.
ExtensionEnd: La extensión final es una clase de Property utilizada para asociar una
extensión a un estereotipo, cuando se extiende una metaclase. Solo puede ser
accedida a través de Extension. No es posible agregar propiedades a un clasificador
extendido (no está permitido cambiar un elemento del metamodelo, únicamente
agregar nuevas propiedades).
36
Package: Un paquete puede tener uno o más ProfileApplications para indicar cuáles
son los perfiles que se aplican. Dado que un perfil es un paquete, es posible aplicar un
perfil no solo a paquete sino también a perfiles.
Profile: El perfil es una clase de paquete que establece las extensiones para un
elemento del metamodelo. El propósito es adaptarlo a un dominio particular. El
elemento básico de extensión es el estereotipo. Por esta razón es definido como parte
del perfil. Un perfil es una forma restrictiva de un metamodelo. Las extensiones se
definen como estereotipos que se aplican a metaclases existentes.
ProfileApplication: Se utiliza para mostrar cuáles son los perfiles que se aplican a un
paquete. Uno o más perfiles pueden ser aplicados a un paquete.
Stereotype: Un estereotipo define cómo se extiende una metaclase y habilita al uso
de una terminología específica para un dominio particular. Es un tipo de clase que
extiende clases a través de Extension. Una clase puede ser extendida por uno o más
estereotipos.
Dado que es una clase, puede tener propiedades, a las cuales se refiere como
definiciones de etiquetas (tags). Cuando un estereotipo se aplica a un elemento del
modelo, los valores de las propiedades se refieren como valores etiquetados.
Ventajas
Son numerosas las ventajas que genera el uso de perfiles. Se detallan algunas de las
principales:
Definir un nuevo vocabulario para un dominio o plataforma especifica (para
Tiempo Real, Enterprise Java Beans, etc.).
Dar una sintaxis para constructores que no tienen notación.
Definir una notación particular para elementos ya existentes, de acuerdo al
dominio donde dichos elementos se encuentran.
Agregar semántica a elementos del metamodelo que tienen una semántica
imprecisa.
Agregar nueva semántica al metamodelo.
37
Agregar restricciones que restrinjan la forma en que el metamodelo y sus
constructores puedan ser usados.
La posibilidad de agregar información en los modelos puede ser usada para
transformarlos en código.
Elementos
El perfil UML incluye los elementos necesarios para hacer posible la extensión del
lenguaje. Ellos son: los estereotipos (en inglés, stereotypes), los valores etiquetados
(en inglés, tags values) y las restricciones (en inglés, constrains).
Un estereotipo permite extender el vocabulario UML. Durante su definición, se lleva a
cabo su asociación con elementos del metamodelo (clase, operación, etc.). Dentro de
los modelos es denotado de la siguiente manera “<<stereotype-name>>”.
Los valores etiquetados están cercanamente relacionados a los estereotipos, dado
que son sus atributos asociados. La forma de expresarlos es a través de la dupla
{nombre=valor}.
Las restricciones permiten agregar semántica tanto a los elementos del modelo como
a los del metamodelo. En este último caso, es llevado cabo cuando se le añaden
restricciones a los estereotipos. Si esto sucede, debe cumplirse que los modelos que
utilicen dichos estereotipos, conformen las restricciones impuestas para él.
En muchas ocasiones, el lenguaje natural es usado para definir restricciones. Sin
embargo, OCL es una mejor alternativa, debido a su precisión y consistencia.
Notación Gráfica
Se hace uso de distintos elementos gráficos al momento de llevar a cabo la definición
de un perfil. Utilizando estereotipos para denotar los elementos. A continuación se
exponen las diferentes notaciones gráficas, cada notación con su correspondiente
elemento de perfil asociado. En la tabla 2.1, se muestra la notación para los vínculos y
en la tabla 2.2 para estereotipos, metaclases y perfiles.
38
Elemento de Perfil Notación gráfica
Extension
ProfileApplication
Tabla 2-1: Notación gráfica de vínculos.
Elemento de Perfil Notación gráfica
Stereotype
Metaclass
Profile
Tabla 2-2: Notación gráfica de estereotipos, metaclases y perfiles.
Han sido creados numerosos perfiles para los más variados dominios. Por ejemplo, se
han definido perfiles para “Testing” [58], [59], “Java y especificaciones EJB” [60],
“Tiempo Real” [61], “Agentes inteligentes” [62], [63], “Tolerancia a las fallas” [64]–[66];
entre otros.
La figura 2.4 muestra el Perfil de Enterprise Java Beans (EJB). En el ejemplo se
muestra cómo definir estereotipos, valores etiquetados y restricciones.
39
Figura 2.4: Ejemplo Perfil EJB.
La forma de especificar un estereotipo es asociando su nombre con elementos del
metamodelo. Por ejemplo el estereotipo JAR es asociado con el meta elemento
Artifact; Remote y Home con Interface, y el estereotipo abstracto Bean con Component
(una instancia de clases concretas Entity o Session debe ser asociado a cada
instancia de Component). Un ejemplo de valor etiquetado es state, el cual es asociado
a Session. Finalmente hay dos restricciones, una relacionada a Component y otra a
Bean, ambas en lenguaje natural, OCL no es utilizado.
2.7 OCL
Tal como se mencionó en las secciones anteriores, las restricciones son
frecuentemente descriptas a través del lenguaje natural, pero esto resulta en
ambigüedades. OCL es un lenguaje para la especificación de restricciones no
ambiguas [67].
Una de sus principales características es su fácil comprensión, no es necesario tener
excesivo conocimiento previo en matemáticas para entender sus especificaciones.
Según se manifiesta en las especificaciones de OMG fue diseñado para compensar el
desajuste que se producía en los modelos con una estructura fácil de leer y escribir. La
utilidad de OCL se manifiesta en la diversidad de propósitos para los cuales puede ser
aplicado, tal como también se expresa [68].
- Como lenguaje de consultas.
40
- Para especificar invariantes sobre clases y tipos en los modelos de clases.
- Para especificar invariantes de tipos para estereotipos.
- Para describir pre y post condiciones sobre operaciones y métodos.
- Para describir guardas.
- Para especificar objetivos (o conjuntos) para mensajes y acciones.
- Para especificar restricciones sobre operaciones.
- Para especificar reglas de derivación de atributos para cualquier expresión
sobre un modelo UML.
OCL es un lenguaje tipado, cada expresión tiene un tipo. Por ejemplo, no se puede
comparar un Integer con un String. Los tipos pueden ser cualquier clase de
clasificadores dentro de UML.
Cabe destacar que no es un lenguaje de programación, por lo que no es posible
escribir lógica de programas o flujos de control. Tampoco es válido pensar que la
especificación pueda ser directamente ejecutable.
El mismo OCL es utilizado para definir la semántica de UML, especificando reglas bien
formadas sobre el metamodelo. Las reglas bien formadas son definidas como
invariantes sobre las metaclases en la sintaxis abstracta. También es usado para
definir operaciones adicionales, cuando las reglas bien formadas las precisan. Para un
mayor detalle ver Anexo B.
Funciones de RSA en expresiones OCL
En las expresiones OCL utilizadas en este trabajo, se emplearon dos métodos que
figuran dentro del software RSA. Estos métodos se pueden aplicar a un elemento o a
un paquete dentro de una restricción OCL. Dichos métodos sirven para verificar los
estereotipos aplicados en un modelo.
GetAppliedStereotypes (): Obtiene los estereotipos aplicados en un elemento. Por
ejemplo un clasificador es un elemento que puede representar clases o interfaces, etc.
en un modelo.
41
getAppliedProfiles: Obtiene los perfiles aplicados en un paquete.
42
43
CAPITULO III
Especificación de Patrones de Diseño
Como fue explicado en capítulos anteriores 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 diseño utilizada en el presente trabajo.
3.1 Patrones de diseño
3.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.
44
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.
3.1.2 Clasificación de Patrones de Diseño
Gamma et al. [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.
PROPOSITO
Creacional Estructural Comportamiento
Clase
- Factory Method
- Adapter
- Interpreter
- Template Method
Objeto
- Abstract Factory
- Builder
- Prototype
- Singleton
- Adapter
- Bridge
- Composite
- Decorator
- Façade
- Flyweight
- Proxy
- Chain of Responsibility
- Command
- Iterator
- Mediator
- Memento
- Observer
- State
- Strategy
- Visitor
Tabla 3-1: Clasificación de los patrones de diseño.
A
L
C
A
N
C
E
45
El propósito refleja lo que hace el patrón, y los clasifica en:
- 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.
3.2 Catálogo de patrones:
Abstract Factory: Permite crear objetos de distintas familias.
Adapter: Convierte la interfaz de una clase a otra interfaz que es las que los clientes
esperan.
Bridge: Desacopla una abstracción de su implementación.
Builder: Separa la construcción de un objeto complejo de su representación.
Chain of Responsability: Evita el acoplamiento de objetos que envían un
requerimiento a su receptor. Esto se logra dando a más de un objeto la chance de
manejar el requerimiento.
Command: Encapsula el requerimiento como a un objeto.
Composite: Relaciona objetos compuestos, para permitir su manipulación de una
manera más simple.
46
Decorator: Añade responsabilidades adicionales a un objeto dinámicamente.
Factory Method: Se define una clase encargada de crear objetos de un subtipo dado.
Facade: Define una interfaz simple para facilitar el acceso a una interfaz o grupo de
interfaces de un subsistema.
Flyweight: Disminuye la redundancia cuando muchos objetos poseen idéntica
información.
Interpreter: Define una gramática para un lenguaje, así como las herramientas
necesarias para interpretarlo.
Iterator: Ofrece un medio para acceder a una colección de objetos de manera
secuencial.
Mediator: Define un objeto para coordinar la comunicación entre objetos de distintas
clases, pero que a su vez, funcionan como un conjunto.
Memento: Captura y externaliza el estado interno de un objeto.
Observer: Define una dependencia entre objetos, cuando un objeto cambia de estado
notifica y actualiza automáticamente a los objetos dependientes.
Prototype: Especifica la clase de objetos para crear nuevos objetos clonándolos de
una instancia ya existente.
Proxy: Provee una referencia para acceder a un objeto más sofisticado
Singleton: Establece la existencia de una única instancia para una clase.
State: Permite que un objeto alterne su comportamiento cuando cambia su estado.
Strategy: Define una familia de algoritmos, encapsula a cada uno, y los hace
intercambiable.
Template Method: A través de una operación se define el esqueleto de un algoritmo
en una clase. Las subclases deben realizar algunos de los pasos del algoritmo.
Visitor: Define nuevas operaciones sobre una jerarquía de clases sin cambiar los
objetos sobre los que opera.
47
3.3 Características de los patrones de Comportamiento:
Variación de la Encapsulación de objetos:
Los aspectos cambiantes de un sistema se encapsulan, para disminuir dependencias
entre objetos. 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.
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 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 Command 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 polimórfica.
Un memento solo puede ser pasado como un valor. Para validar 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
48
tiene como argumento un objeto en las llamadas a una operación, existe un argumento
de tipo objeto.
Distribución de la comunicación:
Observer distribuye la comunicación introduciendo los objetos Observer y Subject, así
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 emisor (broadcast), es decir,
se actualizan el estado del sujeto en todos los observadores de la lista a través de esta
comunicación.
Desacoplamiento entre emisores y receptores:
Los objetos que colaboran entre sí explícitamente pueden volverse dependientes y
esto provoca desequilibrio y baja reusabilidad. Los patrones Command y Observer
entre otros tratan este problema a través de la comunicación, desacoplando emisores
de receptores.
Definir 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 un pedido. Se puede
reusar el objeto Command para 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 intermediario, objeto Mediador. Un objeto Mediador rutea pedidos entre objetos
49
Colleague y centraliza su comunicación. Consecuentemente, los colleagues sólo
pueden hablar entre ellos a través de la interface Mediator. El patrón Mediator puede
reducir subclases o 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.
3.4 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
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. Se puede
definir características generales en un nivel, características dinámicas en otro y las
particulares en el próximo. Esto se puede concretar en una jerarquía. El establecer
una jerarquía entre niveles de perfiles permite el reúso de definiciones. El resultado
es la estructura de la arquitectura que se encuentra expresada en la figura 3.1.
50
Figura 3.1: Arquitectura de patrones de diseño.
La arquitectura está compuesta por tres niveles:
1. El Nivel 0 tiene la responsabilidad de proveer las estructuras más usadas para
todos los patrones de diseño. Posee las características comunes de todos los perfiles
de patrones y puede ser reutilizado por los otros niveles. En este nivel se describen los
elementos usados en cada uno de los diagramas presentados para la descripción de
un modelo. Se verifica la buena formación de dichos elementos. Por ejemplo se
verifica que los elementos posean un nombre.
2. El Nivel 1 se inspira en el catálogo GoF [1], y provee un perfil por cada clasificación
por propósito, estructurales (Perfil Estructural), creacionales (Perfil Creacional), y de
comportamiento (Perfil de Comportamiento). El perfil de patrones de comportamiento
verifica la consistencia, entre el comportamiento representado por los diagramas de
secuencia y la estructura representada por los diagramas de clases.
3. El Nivel 2 es el nivel inferior de este modelo, compuesto por los perfiles individuales
para cada patrón. Se describen en este nivel las características particulares. Cada
uno de los patrones en el nivel 2 utiliza los elementos definidos en los niveles
anteriores (niveles 0 y 1). Cuando se incluye un nuevo patrón, se define un nuevo
perfil, y cada perfil agregado tiene su sintaxis y semántica particular. Pero todos
absorberán la estructura genérica del nivel anterior.
51
Los niveles 0 y 1 de la arquitectura están construidos cada uno en su propio perfil que
se aplican a los perfiles del nivel 2.
Con la definición de restricciones y estereotipos se busca verificar que se cumplen los
estándares de diseño. Al marcar los modelos es posible prepararlos para su
implementación o su transformación en otro modelo.
3.4.1 Metodología
En el primer nivel (nivel 0) se verifican las estructuras elementales construyendo reglas
bien formadas para los diagramas de clase. De esta manera se comprueba que la
base del modelo es sólida para los elementos estructurales de las características
estáticas.
El nivel 1 se basa en la clasificación GoF, conteniendo un perfil por cada clasificación:
Estructural, Creacional y de Comportamiento. En esta tesis se generó un perfil de
comportamiento. Este perfil contiene estereotipos asociados a restricciones, que
verifican la consistencia entre los diagramas de secuencia (vista dinámica) y de clase
(vista estructural). La consistencia de aspectos dinámicos respecto de aspectos
estáticos asegura que los objetos sean bien formados al ejecutarse.
En el nivel 2 se creó un perfil por cada patrón particular, de manera de verificar las
características individuales del patrón, por ejemplo: clases participantes junto a su
comportamiento, definiendo sus operaciones obligatorias y su secuencia de
comunicación.
3.4.2 Técnica para definir el perfil de un patrón particular
Para incorporar un nuevo patrón en 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 un patrón particular se resume a continuación:
1. Identificar los participantes principales del patrón, sus relaciones y comportamiento.
2. Importar los niveles 0 y 1.
3. Determinar por cada participante el criterio del estereotipo del cual debe extender.
Se deberá considerar entre otros si el participante es:
52
- Clase abstracta o concreta, atributo o extremo de asociación.
- Operaciones de ejecución.
4. Imponer restricciones sobre los estereotipos, que verifiquen las especificaciones del
patrón.
5. Verificar el perfil construido a partir de su aplicación a modelos formulados para tal
efecto.
6. Liberar la versión del patrón para su uso
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 lo establecido en GoF, pero la arquitectura es
compatible para incorporar otros patrones de diseño, tales como patrones de
arquitecturas [69].
Para definir estereotipos en estos niveles se crea un estereotipo que se extiende con
alguna metaclase del metamodelo UML. Si se quiere utilizar en el nivel 1 un
estereotipo del nivel 0, se puede importar como se hizo en el paso 2 de esta sección.
Ver Anexo C.
53
CAPITULO IV
Perfil de Patrones Genérico
El perfil de patrones genérico presenta los formalismos necesarios para la
especificación de la estructura de los patrones de diseño. Los aspectos estructurales
describen elementos del diseño orientado a objetos: clasificadores, clases, atributos,
operaciones. Estos aspectos estructurales se plasman 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 un perfil integrado por estereotipos que documentan los formalismos. Este
capítulo está dividido en dos partes. En la primera parte se definen los elementos del
metamodelo UML utilizados. En la segunda parte se presentan los estereotipos del
nivel 0 y las restricciones que verifican las reglas de buena formación de los elementos
estereotipados.
4.1 Conceptos Introductorios
4.1.1 Elementos del metamodelo UML utilizados
Los elementos del metamodelo UML representan una base para los estereotipos
creados en la arquitectura. Para construir un perfil se emplean las metaclases del
metamodelo UML: Class, Interface, Operation, etc. [7].
En una expresión OCL lo primero que se define es un contexto. Un contexto es un
conjunto de elementos cuyo tipo puede ser: Class, Interface, etc. La expresión incluye
a todas las instancias del conjunto definido por la metaclase (Class, Interface, etc.).
54
Figura 4.1: Fragmento del metamodelo UML: características estructurales.
En la figura 4.1 se muestra un fragmento del metamodelo UML con los formalismos
definidos en la especificación UML. Se representan allí las construcciones
estructurales aplicadas por los diagramas de clases. En el gráfico se puede observar
cómo están relacionados los elementos, por tres tipos de relaciones: generalización
(elementos más generales son heredados por elementos más específicos, es decir,
son padres de), composición (los elementos de los cuales parte un rombo están
constituidos por los elementos del extremo opuesto) y asociación bidireccional donde
los elementos colaboran entre sí. En este caso se muestra una clase y sus
componentes. Un elemento Class se deriva de un Classifier. Se compone de
operaciones y properties. Existe una relación de composición desde Class hacia
Property y hacia Operation. El elemento Property es una característica estructural. Una
55
Association contiene dos extremos. El elemento Property representa un atributo de un
elemento Class o un extremo de un elemento Association. Class está asociado a
través de ownedattributes con Property, es decir, la cantidad de atributos de Class
está determinada por ownedattributes. Association está asociado a Property a través
de memberEnd.
Figura 4.2: Fragmento del metamodelo UML Interfaces.
Interface (figura 4.2) es un tipo de clasificador que contiene properties de tipo extremo
y operaciones abstractas.
56
Para crear el perfil del nivel 0 se emplean los elementos descriptos en el párrafo
anterior. Se extienden dichas metaclases, a través de estereotipos para generar
elementos más específicos en un metamodelo. Un ejemplo de representación de
metaclases se ilustra en la figura 4.3, a través de la metaclase Class que contiene
atributos y operaciones esquematizadas con el software RSA [6].
Figura 4.3: Metaclase Class.
Una metaclase es un elemento del metamodelo UML que define una clase con
atributos y operaciones.
4.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.
4.2.1 Estereotipos
El patrón genérico se compone de cinco estereotipos: patternPackage,
patternClassifier, patternClass, patternOperation, patternProperty, que extienden
las metaclases del metamodelo UML. Como se explicó en el capítulo II una metaclase
es un elemento de metamodelado que sirve para definir una clase con atributos y
operaciones.
Figura 4.4: Estereotipos para modelos estáticos.
57
En la Figura 4.4 se muestran los estereotipos patternPackage, patternClassifier,
patternClass, patternProperty y patternOperation que extienden las metaclases
Package, Classifier, Class, Operation y Property. Los estereotipos contienen las
operaciones y propiedades de la metaclase extendida.
La metaclase extendida establece el ámbito de aplicación del estereotipo. Esto quiere
decir que, por ejemplo, un estereotipo que extiende la metaclase Class se podrá
aplicar solo a elementos de tipo clase. Se verifica en este dominio que los elementos
del patrón estén bien formados.
A continuación se describen los estereotipos mencionados:
patternPackage: Este estereotipo extiende la metaclase Package. Incluye
restricciones acerca de la buena formación de los elementos del patrón, como que
tengan nombre, visibilidad.
patternClassifier: Extiende la metaclase Classifier que representa una metaclase
abstracta. Los elementos etiquetados con este estereotipo simbolizan una clase
abstracta o una interface.
patternClass: Extiende la metaclase Class. Esta metaclase define una clase concreta,
es decir que implementa operaciones. En el caso de la arquitectura su objetivo es
implementar aspectos abstractos definidos en un elemento etiquetado como
patternClassifier. Puede implementar las operaciones de una clase abstracta o realizar
las operaciones de una interface.
patternProperty: Extiende la metaclase Property. Dicha metaclase hace referencia a
un atributo de una clase o a un extremo de una asociación.
patternOperation: Extiende la metaclase Operation. Esta metaclase especifica el
comportamiento asociado a un clasificador.
58
4.2.2 Restricciones en lenguaje OCL
Las restricciones en lenguaje OCL, formuladas en el nivel 0, permiten comprobar la
buena formación de los elementos de un patrón. Se chequea por ejemplo que los
atributos posean nombre y visibilidad, o que los clasificadores sean de tipo interface o
clase abstracta.
Restricción 1: Buena formación de properties
Context PerfilNivel0::patternPackage
Class.allInstances().attribute->
forAll(atributo|(atributo.visibility=uml::VisibilityKind::
private or atributo.visibility = uml::VisibilityKind::protected)
and atributo.name<>''and atributo.type.oclIsTypeOf(OclVoid)->
forAll(tipo|tipo=false))
Descripción: Se verifica que todas las properties del paquete contengan visibilidad
privada o protegida y su nombre sea distinto de blanco. Además se verifica que las
etiquetas de los tipos para todas las propiedades (properties) sean distintas de blanco.
Utilización: Es una regla de buena formación para los atributos de las clases del
modelo y extremos de asociaciones.
Nota: Para cumplir el principio de encapsulación de la orientación a objetos los
atributos deben ser privados. Pero en caso de herencia los atributos son de tipo
“protected”.
Restricción 2: Buena formación de Operaciones
Context PerfilNivel0::patternPackage
Operation.allInstances()-> forAll(Operacion|Operacion.name<>''
and Operacion.visibility<>null)
Descripción: Se verifica que las operaciones del paquete contengan un nombre y una
visibilidad.
Utilización: Es una regla de buena formación para operaciones del modelo.
Restricción 3: Buena formación de clases abstractas
Context PerfilNivel0::patternPackage
Class.allInstances()->
select(isAbstract=true).attribute.visibility->
59
forAll(visibilidad|visibilidad=uml::VisibilityKind::
protected)
Descripción: Se verifica que las clases abstractas contengan solo atributos de tipo
“protected”.
Utilización: Es una regla de buena formación para los elementos abstractos del
modelo.
Nota: Para cumplir el principio de encapsulación de la orientación a objetos los
atributos en caso de herencia deben ser de tipo “protected”.
Restricción 4: Buena formación de clases concretas
Context PerfilNivel0::patternPackage
let clases: OrderedSet(Class)=Class.allInstances()->
select(isAbstract=false) ->asOrderedSet() in
clases.attribute.visibility->
forAll(visibilidad|visibilidad=uml::VisibilityKind::
private) and
clases.ownedOperation->select(isAbstract<>true)->notEmpty()
Descripción: Se verifica que las clases concretas contengan solo atributos de tipo
“private” y sus operaciones sean concretas.
Utilización: Es una regla de buena formación para las clases concretas.
Restricción 5: Buena formación de operaciones de Interfaces
Context PerfilNivel0::patternPackage
Interface.allInstances()->notEmpty()
implies
Interface.allInstances().ownedOperation->
select(isAbstract<>false)->notEmpty()
Descripción: Se verifica que las interfaces solo contengan operaciones abstractas.
Utilización: Es una regla de buena formación para las interfaces.
60
Restricción 6: Buena formación de relaciones de herencia
Context PerfilNivel0::patternPackage
Classifier.allInstances().generalization->
forAll(c|
if c.general.oclIsTypeOf(Interface)=true then
c.specific.oclIsTypeOf(Interface)
else
c.specific.oclIsTypeOf(Class)
endif)
Descripción: Se verifican las relaciones de generalización. Si el extremo general es de
tipo interface entonces el extremo de la clase específica debe ser una clase o una
interface. Si el extremo general no es una interface entonces el extremo de la clase
específica es de tipo clase.
Utilización: Permite verificar la relación de generalización de un clasificador.
Restricción 7: Buena formación sin herencia múltiple – Precaución de uso
Context PerfilNivel0::patternClass
self.general()->size()<=1
Descripción: Se verifican las relaciones de generalización, que una clase herede sólo
de una superclase.
Utilización: Permite verificar la relación de generalización de un clasificador.
Restricción 8: Buena formación de relaciones de implementación
Context PerfilNivel0::patternPackage
InterfaceRealization.allInstances().source->
forAll(oclIsTypeOf(Class)=true)
Descripción: Se verifica que las relaciones de realización de interface tengan como
fuente una clase.
Utilización: Permite verificar la implementación de una interface.
61
Restricción 9: Definición de operaciones abstractas en una clase abstracta
deben ser implementadas en una clase concreta.
Context PerfilNivel0::patternPackage
let operacionesAbstractasPadre : Set(Operation)=
Class.allInstances()->select(clasesHijas|
clasesHijas.isAbstract=false).general().getAllOperations()
-> select(isAbstract=true)->asSet(),
OperacionesConcretasHijo : Set(Operation) =
Class.allInstances()->select(clasesHijas|
clasesHijas.isAbstract=false and
clasesHijas.general()->notEmpty()).ownedOperation->
select(isAbstract=false)->asSet()
in
(operacionesAbstractasPadre->
select(o1|OperacionesConcretasHijo-> exists(o2|o1.name=o2.name
and o1.ownedParameter.name=o2.ownedParameter.name and
o1.ownedParameter.type.name=o2.ownedParameter.type.name)).
name>intersection(operacionesAbstractasPadre.name))=
operacionesAbstractasPadre.name
Descripción: Esta restricción verifica que una operación abstracta contenga una
operación concreta que la implemente y que la operación concreta contenga los
mismos parámetros y el mismo nombre.
Utilización: Permite verificar la implementación de las operaciones abstractas.
Restricción 10: Definición de operaciones abstractas en una interfaz deben ser
implementadas en una clase concreta.
Context PerfilNivel0::patternPackage
let
operacionesAbstractasPadre : Set(Operation)=
Class.allInstances()-> select(clasesHijas|
clasesHijas.isAbstract=false).interfaceRealization.contract.
ownedOperation->asSet(),
OperacionesConcretasHijo : Set(Operation) =
Class.allInstances()->select(clasesHijas|
clasesHijas.isAbstract=false
and clasesHijas.interfaceRealization.contract->
notEmpty()).ownedOperation->select(isAbstract=false)-> asSet()
in
(operacionesAbstractasPadre->
select(o1|OperacionesConcretasHijo->
62
exists(o2|o1.name=o2.name
and o1.ownedParameter.name = o2.ownedParameter.name and
o1.ownedParameter.type.name = o2.ownedParameter.type.name
and o1.ownedParameter.direction =
o2.ownedParameter.direction)).name->
intersection(operacionesAbstractasPadre.name))=
operacionesAbstractasPadre.name
Descripción: Esta restricción verifica que una operación abstracta sea implementada
correctamente, garantizando la existencia de sus parámetros y su signatura.
Utilización: Permite verificar la implementación de las operaciones abstractas.
Restricción 11: Buena formación del clasificador
Context PerfilNivel0::patternClassifier
(self.oclIsTypeOf(Class)and self.isAbstract) or
self.oclIsTypeOf(Interface)
Descripción: Se verifica que el tipo clasificador sea una clase abstracta o una interface.
Utilización: Verifica los elementos estereotipados como patternClassifier.
Restricción 12: Buena formación de estereotipo patternClass
Context PerfilNivel0::patternClass
self.isAbstract=false
implies
self.ownedOperation->forAll(isAbstract=false)
Descripción: En esta restricción un elemento estereotipado como patternClass, debido
a que es una clase concreta no permite la creación de métodos abstractos.
Utilización: Verifica los elementos estereotipados como patternClass.
63
Restricción 13: Buena formación de estereotipo patternClassifier
Context PerfilNivel0::patternClassifier
self.oclIsTypeOf(Interface)
implies
self.getAllOperations()->forAll(isAbstract=true)
Descripción: En esta restricción una interface estereotipada como patternClassifier y
es una interface no permite la creación de métodos concretos.
Utilización: Verifica que los elementos estereotipado como patternClassifier.
64
65
CAPITULO V
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. Se estudia en
este nivel las interacciones construidas a partir de elementos tales como: invocaciones
de operaciones, ejecución de comportamientos, líneas de vida.
Este perfil de comportamiento se construyó en base a la clasificación de patrones del
catálogo GoF [1] que contiene las características de comportamiento.
Algunos de los problemas que solucionan estos patrones, respecto de la dinámica de
un sistema, son: la baja reusabilidad y las dificultades surgidas en el mantenimiento de
un sistema. Para aumentar la reusabilidad y la calidad de los sistemas se generaron
instrumentos como la encapsulación de objetos, el desacoplamiento, la inversión de
dependencia, la distribución de la comunicación.
El perfil de patrones genérico presenta los formalismos necesarios para la
especificación de la estructura de los patrones de diseño. Los aspectos estructurales
describen elementos del diseño orientado a objetos: clasificadores, clases, atributos,
operaciones. Estos aspectos estructurales se plasman a través de estereotipos
creados para ese fin.
El nivel 1 de la arquitectura contiene un Perfil integrado por estereotipos que verifican
la consistencia de los patrones de comportamiento. Este capítulo está dividido en dos
partes. En la primera parte se definen los elementos del metamodelo UML utilizados.
En la segunda parte se presentan los estereotipos del nivel 1 y las restricciones que
verifican las reglas de buena formación de los elementos estereotipados.
66
5.1 Conceptos Introductorios
5.1.1 Elementos del metamodelo UML utilizados
Los elementos del metamodelo UML son el cimiento para los estereotipos de un perfil.
En este caso se emplea la metaclase interacción para construir el perfil de
comportamiento [7].
Figura 5.1: Fragmento del metamodelo - Características dinámicas.
En la figura 5.1 se muestra un fragmento del metamodelo UML con la especificación
de algunas de las características dinámicas de un modelo en UML. Dentro de los
elementos mostrados podemos mencionar:
Interaction: Una interacción representa la comunicación entre objetos. Se presenta
toda la secuencia de llamadas a operaciones, de donde se obtienen las
responsabilidades claramente.
Behavior: Representa un comportamiento básico, una interacción hereda sus
elementos. Una interacción contiene varios fragmentos de interacción
(InteractionFragment), de los que hereda también propiedades.
InteractionFragment: Representa la unidad más básica de una interacción. Sus tipos
pueden ser una interacción (interaction), una ejecución de especificación
(ExecutionSpecification) o una ocurrencia de especificación (OcurrenceSpecification).
67
ExecutionSpecification: Hereda las propiedades de interactionFragment y representa
un periodo en la vida del participante (en la línea de vida) donde se:
- Ejecuta una acción (unidad de comportamiento)
- Se envía una señal a otro participante
- Se espera un mensaje de respuesta de otro participante
Figura 5.2: Fragmento del metamodelo de UML - Líneas de vida.
OcurrenceSpecification: Indica el comienzo o final de la ejecución de una ejecución
de la especificación (ExecutionSpecification).
Lifeline: Una línea de vida representa un participante de una interacción. Dicho
participante puede ser un objeto o un actor. Una interacción puede contener varias
líneas de vida (lifeline). Una línea de vida es parte de un interactionFragment. Las
líneas de vida representan los objetos presentes en la interacción (figura 5.2).
A continuación se describe el elemento que da vida al diagrama de secuencia: el
mensaje y sus componentes (figura 5.3).
68
Figura 5.3: Fragmento del metamodelo de UML - Mensajes.
Message: una interacción contiene mensajes para representar la comunicación entre
los distintos objetos (lifeline) del diagrama. Están compuestos por dos extremos: el
evento de envío del mensaje (SendEvent) y el de recepción del mensaje
(ReceiveEvent).
MessageEnd: Es el extremo de un mensaje e involucra los eventos: SendEvent y
ReceiveEvent.
Un mensaje puede perderse en el camino o recibirse completo, eso se ve
representado en la enumeración MessageKind. Para definir la forma de transmisión de
un mensaje se emplea la enumeración MessageSort con dos literales síncrona o
asíncrona por ejemplo.
69
5.2 Descripción de elementos nivel 1
En una secuencia como la que se presenta en un diagrama de interacción existen dos
puntos de vista principales: las interacciones por sí misma y el orden de los mensajes
de las llamadas a las operaciones. Este nivel describe estos rasgos de
comportamiento mediante los estereotipos que se describen a continuación.
Figura 5.4: Estereotipos de comportamiento de un modelo.
Se crearon dos estereotipos patternInteraction y patternOcurrence. El estereotipo
patternInteraction simboliza características de las interacciones. El estereotipo
patternOcurrence simboliza las ocurrencias de especificación. Los estereotipos se
muestran en la figura 5.4. Se importó el nivel 0 para poder adquirir las reglas de buena
formación formuladas tanto para el paquete como para las operaciones. A su vez se
recurrió a dos metaclases para agregar aspectos de comportamiento a los
estereotipos. El ámbito de aplicación en este caso es doble para cada estereotipo ya
que el estereotipo toman el ámbito de las metaclases y heredan los ámbitos de los
estereotipos planteados en el nivel 0 como se describe a continuación.
5.2.1 Estereotipos
patternInteraction: Este estereotipo permite verificar la consistencia entre el diagrama
de secuencia y el diagrama de clases, aspecto necesario para el funcionamiento del
patrón. Además se verifica la consistencia del paquete que implica la buena formación
de elementos.
patternOccurrence: Este estereotipo hereda aspectos estructurales del estereotipo
patternOperation del nivel 0. De esta manera se pueden estereotipar las operaciones
del diagrama de clases, bajo su ámbito. A su vez extiende la metaclase
OcurrenceSpecification lo que permite estereotipar tanto el comienzo como el final de
cada ejecución de comportamiento y verificar el orden de ejecución de las operaciones
dentro del comportamiento.
70
5.2.2 Restricciones definidas en OCL
Con estas restricciones se comprueban las características del perfil y la consistencia
entre los diagramas del modelo, a saber, diagrama de clases y diagrama de
secuencia.
Restricción 14: Verifica líneas de vida en Interacciones
Context PerfilNivel1::patternInteraction
Lifeline.allInstances().represents.type->
forAll(lineaDevida| Class.allInstances()->
exists(clase|clase.name=lineaDevida.name))
Descripción: Se verifica que el conjunto de las líneas de vida está simbolizado por un
objeto. Este objeto debe ser de un tipo representado en el diagrama de clases.
Utilización: Regla de consistencia entre el diagrama de clases y el diagrama de
secuencia.
Restricción 15: Verifica existencia de Orden General.
Context PerfilNivel1::patternInteraction
GeneralOrdering.allInstances()->notEmpty()
Descripción: Debe existir por lo menos un orden general.
Utilización: Verifica que exista por lo menos una secuencia de ordenamiento.
Restricción 16: Verifica consistencia de ejecución de operaciones.
Context PerfilNivel1::patternInteraction
(BehaviorExecutionSpecification.allInstances().finish.getApplied
Stereotypes()->size()+ Message.allInstances()->
select(m|m.messageSort=uml::MessageSort::createMessage).signatur
e.getAppliedStereotypes()->asSet()-> size())=
(Class.allInstances()->select(o|o.oclIsTypeOf(Class) and
o.isAbstract=false)).ownedOperation.getAppliedStereotypes()
->size()
Descripción: Las ejecución de comportamiento a las que se les aplicó estereotipos
sumados a los mensajes de creación del diagrama de secuencia deben ser en
cantidad igual a la cantidad de operaciones estereotipadas en el diagrama de clases.
Todas las operaciones estereotipadas deben ejecutarse en el diagrama de secuencia.
71
Utilización: Verifica la consistencia entre el diagrama de clases y el diagrama de
secuencia.
Restricción 17: Verifica consistencia de mensajes.
Context PerfilNivel1::patternInteraction
Message.allInstances().signature->
forAll(operacion|operacion.visibility=
uml::VisibilityKind::public)
Descripción: Las llamadas de mensajes solo pueden realizarse a operaciones cuya
visibilidad sea pública.
Utilización: Verifica la consistencia entre el diagrama de clases y el diagrama de
secuencia.
Restricción 18: Verifica consistencia de mensajes y operaciones.
Context PerfilNivel1::patternInteraction
Message.allInstances()->asSet()->
forAll(iteradorMensaje|Operation.allInstances()->
exists(iteradorOperacion|iteradorMensaje.name=iteradorOperacion.
name))
Descripción: Dentro del conjunto de mensajes existentes en la interacción los mismos
deben corresponderse con las operaciones del diagrama de clases.
Utilización: Verifica la consistencia el diagrama de clases y el diagrama de secuencia.
72
73
CAPITULO VI
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)
y se definen los estereotipos estructurales.
Luego se explica su comportamiento a través de un diagrama de secuencia con su
estereotipo correspondiente. Finalmente se enumeran sus consecuencias.
Los estereotipos estructurales extienden los estereotipos del nivel 0, que representan
características estáticas a través de: clasificadores, atributos, operaciones y
properties. Los estereotipos comportamentales extienden los estereotipos del nivel 1
para describir sus operaciones, interacciones y su secuencia de ejecución. La
verificación de los estereotipos se concreta a través de restricciones en lenguaje OCL.
Se verifica mediante estas restricciones que cada perfil cumpla con sus
particularidades, corroborando los estereotipos que contiene un modelo: clases,
clasificadores, operaciones y atributos. Por otro lado se verifica la consistencia entre
los diagramas de clases y de secuencia para un determinado modelo.
74
6.1 Patrón Observer
6.1.1 Descripción General
Se representa una dependencia entre objetos. Subject es el tipo de objeto del cual
dependen los objetos tipo Observer, por lo cual necesitan estar informados de un
cambio en el estado del objeto tipo Subject, (figura 6.1).
Figura 6.1: Diagrama de clases Patrón 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”.
75
- ConcreteObserver:
Contiene una referencia a objetos “ConcreteSubject”.
Implementa la clase “Observer”.
- Comportamiento
El comportamiento, visto como una secuencia de pasos, se representa en este trabajo
por un diagrama de secuencia. Existe un actor que genera el comienzo de la ejecución
y que está definido dentro del Sistema. Los participantes del patrón están
representados por objetos en forma de líneas de vida. Los objetos “ConcreteObserver”
se agregan a la lista de observadores. Se cambia el estado en el Sujeto lo que
desencadena la señal de cambio de estado que invoca la operación “ notify” (figura
6.2).
76
Figura 6.2: Diagrama de secuencia Patrón Observer.
La notificación desencadena el llamado a la operación update en los observadores,
que actualiza el atributo “State” de cada observador concreto. Los observadores
pueden desagregarse de la lista en el momento en que lo requieran mediante la
operación “detach”.
77
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.
- Consecuencias
1. Acoplamiento abstracto entre Subject y Observer. Todos los subjects 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 espurias,
de las que puede ser duro volver atrás.
6.1.2 Descripción de elementos nivel 2 – Patrón Observer Estereotipos
A partir del diagrama de clases de la figura 6.1 se elaboraron los estereotipos
estructurales del patrón. Se importan los estereotipos del nivel 0 que permiten
especificar sus participantes de los cuales se puede heredar sus atributos,
operaciones y restricciones: patternClassifier, patternClass, patternProperty (figura
6.3).
78
Figura 6.3: Características estructurales y dinàmicas del Patrón Observer.
ObserverConsistency: Hereda las características de patternInteraction, lo que
garantiza su consistencia entre el diagrama de clases y el diagrama de secuencia. Es
un estereotipo que permite verificar que existan los elementos obligatorios del patrón y
que dichos elementos contengan los aspectos incluidos en la definición del mismo.
Observer y Subject: Heredan las características de patternClassifier, lo que los
configura como elementos abstractos. Y representan los actores principales del patrón,
por ende el perfil.
ConcreteObserver y ConcreteSubject: Heredan las características de patternClass.
Y representan las implementaciones de los aspectos abstractos en clases concretas a
través de la implementación de las operaciones ya definidas en las abstracciones
Observer y Subject.
State: Este estereotipo describe el estado del Sujeto que debe figurar del lado del
Sujeto como del lado de los observadores. Se deben etiquetar por tanto el sujeto y los
observadores.
Del nivel 1 se importan los estereotipos: patternInteraction y patternOccurrence. Como
se vio en el nivel 1 patternInteraction hereda características de patterpackage y
extiende la metaclase Interaction. Y patternOcurrence hereda características de
patternOperation y extiende características de la metaclase OcurrenceSpecification.
Los estereotipos patternInteraction y patternOccurrence permiten verificar
características dinámicas del patrón, tanto desde la interacción como desde las
79
ocurrencias de especificación. Las ocurrencias de especificación simbolizan el punto
de comienzo y final para la ejecución de comportamiento de una operación.
Los estereotipos attach, notify, update, detach, setState y getState heredan las
características del estereotipo patternOcurrence. Este estereotipo les permite
estereotipar tanto operaciones como especificaciones de ocurrencia. Se puede
especificar aspectos de operaciones como la secuencia de su ejecución.
attach y detach : Son estereotipos definidos para etiquetar las operaciones que
agregan y eliminan elementos de la lista de observadores.
notify : Es un estereotipo que etiqueta una operación que notifica a los observadores
de un cambio de estado.
update: Es un estereotipo que etiqueta una operación que actualiza en los
observadores el cambio de estado de Subject.
setState: Permite cambiar el estado observado en el Concrete Subject.
getState : Permite obtener el estado del Subject para actualizarlo en el observador.
6.1.3 Restricciones definidas en OCL para Observer
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 su consistencia y secuencia de ejecución.
Restricción 19: El perfil debe contener estereotipos de los participantes del
patrón: Subject, Observer, ConcreteObserver y ConcreteSubject.
Context PerfilObserver::ObserverConsistency
let TotalEstereo : Set(String) =
self.allOwnedElements().getAppliedStereotypes().name->asSet(),
ConjuntoEstereo : Set(String)=
Set{'Observer','ConcreteObserver','Subject','ConcreteSubject'}->
asSet()
in
ConjuntoEstereo->forAll(e1| TotalEstereo->exists(e2|e1=e2))
80
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
comprueba la existencia de aquellos cuyo nombre sea Subject, Observer,
ConcreteObserver o ConcreteSubject.
Utilización: Se verifica que los participantes del patrón estén representados en el
modelo.
Restricción 20: El patrón debe contener una relación de asociación entre los
estereotipos ConcreteSubject y ConcreteObserver.
Context PerfilObserver::ObserverConsistency
Association.allInstances().memberEnd->
select(m|m.isNavigable()=true
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 apunta tiene aplicado el
estereotipo ConcreteSubject, el extremo no dirigido tiene aplicado el estereotipo como
ConcreteObserver.
Utilización: Se verifica que las relaciones de asociación estén representadas en el
modelo.
Restricción 21: El patrón debe contener una relación de asociación entre el
estereotipo ConcreteSubject y Observer o entre el estereotipo Subject y
Observer.
Context PerfilObserver::ObserverConsistency
Association.allInstances().memberEnd ->
select(m|m.aggregation=uml::AggregationKind::none
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
cuyo tipo de agregación es simple, y el tipo al que apunta tiene aplicado el estereotipo
81
Observer, el extremo tiene aplicado el estereotipo Subject o el estereotipo
ConcreteSubject.
Utilización: Se verifica que las relaciones de asociación estén representadas en el
modelo.
Restricción 22: El perfil debe contener estereotipos de las operaciones que fijan
y configuran el valor del estado del sujeto: setState, getState.
Context PerfilObserver::ConcreteSubject
let TotalEstereo : Collection(String) =
self.allOwnedElements().getAppliedStereotypes().name,
ConjuntoEstereo : Collection(String)=
Set{'setState','getState'}
in
TotalEstereo->exists(e1| ConjuntoEstereo->exists(e2|e1=e2))
Descripción: Se comprueba la existencia de los estereotipos que manejan el estado
del Sujeto. Dado el conjunto de los elementos estereotipados se selecciona aquellos
cuyo nombre de estereotipo es setState y getState.
Utilización: Se verifica que las operaciones del patrón estén representadas en el
modelo.
Restricción 23: El elemento estereotipado como Subject debe contener
operaciones estereotipadas como attach, detach y notify.
Context PerfilObserver::Subject
let TotalEstereo : Collection(String) =
self.allOwnedElements().getAppliedStereotypes().name,
ConjuntoEstereo : Collection(String)= Set{'attach','detach',
'notify'} in
TotalEstereo->exists(e1| ConjuntoEstereo->exists(e2|e1=e2))
Descripción: En el elemento estereotipado como Subject existen operaciones a las
cuales se les ha aplicado el estereotipo attach, el estereotipo notify o el estereotipo
detach.
Utilización: Se verifica que las operaciones del patrón estén representadas en el
modelo.
82
Restricción 24: El elemento estereotipado como Observer debe contener una
operación estereotipada como update.
Context PerfilObserver::Observer
self.getAllOperations().getAppliedStereotypes().name->
includes('update')
Descripción: En el elemento estereotipado como Observer existen operaciones a las
cuales se les ha aplicado el estereotipo update.
Utilización: Se verifica que las operaciones del patrón estén representadas en el
modelo.
Restricción 25: El elemento estereotipado como Subject contiene una operación
que contiene como argumento un objeto estereotipado como Observer.
Context PerfilObserver::Subject
self. getAllOperations()->
select(o|o.ownedParameter.type.getAppliedStereotypes()->
select(name='Observer')-> notEmpty()).
getAppliedStereotypes()->
select(name='attach')->size()>=1
Descripción: En el elemento estereotipado como Subject existe una operación con un
parámetro estereotipado como Observer, cuyo estereotipo es attach.
Utilización: Se verifica que las operaciones del patrón estén representadas en el
modelo.
Restricción 26: El elemento estereotipado como Subject contiene una operación
detach que contiene como argumento un objeto estereotipado como Observer.
Context PerfilObserver::Subject
self.getAllOperations->
select(o|o.ownedParameter.type.getAppliedStereotypes()->
select(name='Observer')-> notEmpty()).
getAppliedStereotypes()->
select(name='detach')->size()>=1
83
Descripción: En el elemento estereotipado como Subject existe una operación con un
parámetro estereotipado como Observer, cuyo estereotipo es detach.
Utilización: Se verifica que las operaciones del patrón estén representadas en el
modelo.
Restricción 27: Existe un mensaje de llamada a la operación estereotipada como
attach.
Context PerfilObserver::ObserverConsistency
Message.allInstances().signature.getAppliedStereotypes().
getLabel()->includes('attach')
Descripción: Existen mensajes cuyo tipo de operación está estereotipada como attach.
Utilización: Se verifica que las operaciones del patrón estén representadas en el
modelo dinámico.
Restricción 28: Existe un mensaje de llamada a la operación estereotipada como
notify.
Context PerfilObserver::ObserverConsistency
Message.allInstances()->
select(m|m.signature.getAppliedStereotypes().getLabel()->
includes('notify')and
m.connector.end.role.type.getAppliedStereotypes().getLabel()->
includes('ConcreteSubject'))->notEmpty()
Descripción: Dentro del conjunto de mensajes de la interacció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 ConcreteSubject.
Utilización: Se verifica que las operaciones del patrón estén representadas en el
modelo dinámico y su receptor sea el adecuado.
Restricción 29: Existe un mensaje de llamada a la operación estereotipada como
update hacia los objetos de tipo Observador.
Context PerfilNivel1::ObserverConsistency
Message.allInstances()->
select(m|m.signature.getAppliedStereotypes().getLabel()->
includes('update')and
m.connector.end.role.type.getAppliedStereotypes().getLabel()->
includes('ConcreteObserver'))-> notEmpty()
84
Descripción: Dentro del conjunto de mensajes de la interacción, hay un conjunto no
vacío de mensajes cuya signatura está estereotipada como update. Estos mensajes
tienen como receptor el elementos estereotipado como ConcreteObserver.
Utilización: Se verifica que las operaciones del patrón estén representadas en el
modelo dinámico y su receptor sea el adecuado.
Restricción 30: Contiene ocurrencias estereotipadas como attach, setState,
getState y notify dentro del ConcreteSubject.
Context PerfilNivel1::ObserverConsistency
let Ocurrencias: Set(String)=
OccurrenceSpecification.allInstances().getAppliedStereotypes().name
->asSet(),
OcurrenciaOperacion : Set(String)= Set{'setState', 'getState',
'attach', 'notify'}->asSet()
in
OcurrenciaOperacion->forAll(iteradorOcurrenciaOperacion|Ocurrencias->
exists(iteradorOcurrencia|iteradorOcurrenciaOperacion=iteradorOcurrenc
ia))
Descripción: Dentro del conjunto de ocurrencias de especificación existe al menos una
ocurrencia. Para la línea de vida que proviene de una clase estereotipada como
SujetoConcreto existen las ocurrencias estereotipadas como attach, setState, notify y
getState.
Utilización: Verifica que las ocurrencias del modelo dinámico se encuentren
estereotipadas con el estándar del patrón.
Restricción 31: Para la línea de vida que proviene de una clase estereotipada
como ConcreteSubject debe existir una ejecución de comportamiento
estereotipada como attach.
Context PerfilNivel1::ObserverConsistency
Lifeline.allInstances()->
select(l|l.represents.type.getAppliedStereotypes()->
select(name='ConcreteSubject')->notEmpty()).coveredBy->
select(oclIsTypeOf(BehaviorExecutionSpecification))-> notEmpty()
implies
BehaviorExecutionSpecification.allInstances().finish.
getAppliedStereotypes().name-> asSequence()->
exists(n1|n1='attach')
85
Descripción: Para la línea de vida que proviene de una clase estereotipada como
ConcreteSubject se halla al menos una ocurrencia de especificación. Esto quiere decir,
que se ejecuta al menos una operación. Como consecuencia el comienzo de alguna
de las ejecuciones debe estar estereotipado como attach.
Utilización: Verifica que dentro de las ocurrencias del modelo dinámico exista una
ocurrencia estereotipada como attach.
Restricciones de orden general
Orden General: definición
Un orden general es una relación parcial entre dos ocurrencias de especificación, que
se utiliza para establecer que una ocurrencia de especificación debe ocurrir antes que
otra. De esta manera se puede definir un orden parcial que de otra manera no existiría.
Como UML no cumple órdenes específicos se puede definir un orden a través de
órdenes parciales.
En este caso se puede definir la obligatoriedad de que se cumplan cuatro órdenes
parciales: attach con setState, setState con notify, notify con update y update con
getState (Tabla 6.1).
Orden before after
g1 attach setState
g2 setState notify
g3 notify update
g4 update getState
Tabla 6-1: Orden general Observer.
Restricción 32: Define un orden de ejecución de la secuencia de comandos
attach y setState. Debe existir una ejecución de comportamiento estereotipada
como attach.
Context PerfilNivel1::ObserverConsistency
let oc : Sequence(OccurrenceSpecification)=
OccurrenceSpecification.allInstances()->asSequence()
,go:Sequence(GeneralOrdering)=
GeneralOrdering.allInstances()->asSequence()
in
86
go->exists(g1| oc->exists(o1,o2|g1.before.name=o1.name and
g1.after.name=o2.name implies
(o1.getAppliedStereotypes()->select(name='attach')->
notEmpty())
and (o2.getAppliedStereotypes()-> select(name='setState')->
notEmpty())))
Descripción: Dentro de la interacción existe un conjunto de órdenes generales, y un
conjunto de ocurrencias. En la restricción se asignan a dos variables la secuencia de
estos dos conjuntos. Dentro la secuencia de órdenes se encuentra un orden
denominado g1 en esta restricción. Y dentro de este orden se halla una ocurrencia o1
como primer elemento de la secuencia, ya que es elemento etiquetado como before.
Además se encuentra un segundo elemento etiquetado como after, la ocurrencia o2.
En términos simples, o1 debe ir primero y o2 debe ir después. El elemento o1 está
antes que o2 y el elemento o2 está después de o1. Y además esos elementos están
estereotipados por attach y setState.
Utilización: Verifica que las ocurrencias del modelo dinámico se encuentren
estereotipadas para cumplir el estándar del patrón.
Restricción 33: Define un orden de ejecución de la secuencia de comandos
setState y notify.
Context PerfilNivel1::ObserverConsistency
let oc : Sequence(OccurrenceSpecification)=
OccurrenceSpecification.allInstances()->asSequence(),
go : Sequence(GeneralOrdering)=
GeneralOrdering.allInstances()->
asSequence()in
go->exists(g2| oc->exists(o1,o2|g2.before.name=o1.name and
g2.after.name=o2.name implies
(o1.getAppliedStereotypes()->select(name='setState')->
notEmpty()) and (o2.getAppliedStereotypes()->
select(name='notify')->notEmpty())))
Descripción: Se definió un orden general g2 en los mismos términos que g1, pero
describe la secuencia de los elementos: setState y notify.
87
Utilización: Verifica que las ocurrencias del modelo dinámico se encuentren
estereotipadas para cumplir el estándar del patrón.
Restricción 34: Define un orden de ejecución de la secuencia de comandos
notify y update.
Context PerfilNivel1::ObserverConsistency
let oc : Sequence(OccurrenceSpecification)=
OccurrenceSpecification.allInstances()->asSequence(), go:
Sequence(GeneralOrdering)= GeneralOrdering.allInstances()->
asSequence() in
go->exists(g3| oc->exists(o1,o2|g3.before.name=o1.name and
g3.after.name=o2.name implies
(o1.getAppliedStereotypes()->select(name='notify')->
notEmpty())
and (o2.getAppliedStereotypes()-> select(name='update')->
notEmpty())))
Descripción: De la misma forma que los ordenes g1 y g2 se puede verificar g3.
Utilización: Verifica que las ocurrencias del modelo dinámico se encuentren
estereotipadas para cumplir el estándar del patrón.
Restricción 35: Define un orden de ejecución de la secuencia de comandos
update y getState.
Context PerfilNivel1::ObserverConsistency
let oc : Sequence(OccurrenceSpecification)=
OccurrenceSpecification.allInstances()-> asSequence()
, go: Sequence(GeneralOrdering) =
GeneralOrdering.allInstances()-> asSequence()
in
go->exists(g4| oc->exists(o1,o2|g4.before.name=o1.name and
g4.after.name=o2.name implies
(o1.getAppliedStereotypes()-> select(name=’update’)->
notEmpty()) and (o2.getAppliedStereotypes()->
select(name=’getState’)->notEmpty())))
Descripción: De la misma forma que los ordenes g1, g2 y g3 se puede verificar g4.
Utilización: Verifica que las ocurrencias del modelo dinámico se encuentren
estereotipadas para cumplir el estándar del patrón.
88
Restricción 36: Verifica la ejecución de la operación update.
Context PerfilNivel1::ObserverConsistency
OccurrenceSpecification.allInstances()->
exists(o|o.covered.represents.type.getAppliedStereotypes()->
select(name='ConcreteObserver')->notEmpty() implies
o.getAppliedStereotypes()->select(name='update')-> notEmpty())
Descripción: Dentro del conjunto de ocurrencias de especificación existe una
ocurrencia cuya línea de vida proviene de una clase estereotipada como
ConcreteObserver. Como consecuencia, la ocurrencia está estereotipada como
update.
Utilización: Verifica que las ocurrencias del modelo dinámico se encuentren
estereotipadas para cumplir el estándar del patrón.
6.1.4 Aplicación de perfiles a un caso de estudio del Observer
En esta sección 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.
Una vez definido el modelo se aplicó el perfil, para lo cual se siguió el procedimiento
explicado en el capítulo III, sección 3.4.2. El próximo paso es estereotipar los
elementos del modelo y verificar que se cumplan las restricciones. En ambos
diagramas se aplican los estereotipos estructurales y de comportamientos según
corresponda. Posteriormente se verifica el modelo de acuerdo a las características
correspondientes a cada patrón.
A continuación se presentan los casos ejemplo para los patrones de comportamiento.
Caso Ejemplo Patrón 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. Las áreas interesadas
son notificadas para realizar la actualización del estado del libro. El proceso comienza
cada vez que un lector devuelve un libro. Si el lector devolvió el libro dañado entonces
la aplicación avisa a las clases: Stock, Compras y Administración, que se ven
89
afectadas por este hecho. Cada vez que el libro se devuelve en mal estado se crea un
objeto de tipo AlarmaLibro, que representa el Subject del patrón. Y las clases Stock,
Compras y Administración 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 6.4 se puede ver el diagrama de
clases con la aplicación de los estereotipos del perfil definido anteriormente.
Figura 6.4: Diagrama de clases ejemplo Biblioteca.
Los estereotipos Subject y ConcreteSubject se aplican respectivamente a Alarma y
AlarmaLibro, que los representan dentro del ejemplo. Se estereotipan también sus
operaciones con attach, detach, notify, getState y setState. Los estereotipos asociados
a los observadores se aplican en el diagrama de clases UML en clases y métodos. Por
ejemplo, la clase AlarmaMalEstado está marcada por el estereotipo Observer y
Administración, Stock, Compras por ConcreteObserver; y finalmente el método
actualiza con update.
En la figura 6.5 se muestran las características dinámicas del ejemplo a través de un
diagrama de secuencia. Como puede observarse se deben reflejar los participantes
del patrón estereotipados en el diagrama de clases pero además se estereotipan las
ocurrencias de especificación que no se pueden observar a simple vista en el
diagrama. Pero se verifica al estereotipar la interacción que se cumpla la secuencia de
ejecución y existan los elementos necesarios para la ejecución del patrón.
90
Figura 6.5: Diagrama de secuencia ejemplo Biblioteca.
91
6.1.5 Gestión del Framework
La aplicación de los estereotipos en diferentes modelos UML permite la verificación de
cada diagrama UML con el fin de establecer si los mismos especifican correctamente
las características del patrón, y también permite comprobar la consistencia entre el
diagrama de secuencia y de clases.
La consistencia entre los diagramas se garantiza marcando los modelos. A saber, los
diagramas de secuencia UML se generan después de las definiciones del diagrama de
clases UML.
A fin de usar el framework se construirá un modelo mal formado, violando las
características propias del patrón Observer. Se aplicará posteriormente la verificación
y chequeo del mismo, comprobando las restricciones en los distintos niveles que
conforman la arquitectura.
Para que de esta forma se violen algunas características estructurales y de secuencia
del mismo. Por este motivo las restricciones OCL expresarán la mala formación del
modelo.
Es posible detectar inconsistencias, a través de la evaluación de restricciones OCL, en
el caso particular de la herramienta RSA, esto se lleva a cabo marcando los modelos
con la opción validación. Luego de chequear las restricciones OCL asociadas a los
estereotipos, la herramienta informa si los modelos se encuentran bien especificados,
de acuerdo a las características del patrón.
La figura 6.6 representa un diagrama de clases estereotipado por un ingeniero de
software, aplicando la importación del perfil Observer, donde se omiten algunos
elementos importantes o se generan algunos errores para su para su posterior
verificación.
92
Figura 6.6: Diagrama de clases ejemplo Biblioteca mal formado.
La figura 6.7 representa un diagrama de secuencia estereotipado por un desarrollador
de software, que debe tener una relación directa con el de clases, aplicando la
importación del perfil Observer, donde se omiten algunos elementos importantes o se
generan algunos errores para su para su posterior verificación.
Figura 6.7: Diagrama de secuencia ejemplo Biblioteca mal formado.
93
La figura 6.8 muestra claramente la ejecución de validación que permite el software
RSA, denotando las violaciones establecidas para ambos modelos marcados.
Figura 6.8: Errores producidos por verificación de Observer.
El siguiente resumen simplifica los errores asumidos por un desarrollador de software,
al construir en forma indebida ambos diagramas.
Verificaciones en el nivel 0:
Restricción 5: Se escribe una operación concreta en una interface en la interfaz
Prueba.
Restricción 12: Se escribe un método abstracto llamado operacionAbstracta en una
clase concreta en el modelo, llamada AlarmaLibro.
Restricción 14: Se grafica una línea de vida llamada Propiedad en el diagrama de
secuencia y no tiene su correspondiente clase en el diagrama de clases.
Restricción 15: No se planteó un orden general en el modelo.
Verificaciones en el nivel 1:
Restricción 14: Se grafica una línea de vida llamada Propiedad en el diagrama de
secuencia y no tiene su correspondiente clase en el diagrama de clases.
94
Restricción 15: No se planteó un orden general en el modelo.
Verificaciones en el nivel 2 del patrón Observer:
Restricción 19: Se confeccionó un modelo sin el participante Subject, no se estereotipo
la clase Alarma como tal.
Restricción 21: No se realizó la asociación entre el una clase estereotipada con
ConcreteSubject y ConcreteObserver, ya que no está estereotipada la clase Alarma.
Restricción 22: Se construye una clase ConcreteSubject sin el método getState y
setState.
Restricción 27: Se construye la clase Alarma sin el método attach.
Restricción 29: Se construye la clase AlarmaMalEstado sin estereotipar la operación
actualiza con update.
.Restricción 30: Se construye un diagrama de secuencia donde no existe una
ocurrencia de ejecución estereotipada como notify.
Restricción 31: Se construye un diagrama de secuencia donde no existe ningún
mensaje que provenga de una operación agregarObservador estereotipada como
attach.
Restricción 32: Se construye un diagrama de secuencia donde se hace una llamada al
método setState antes que el attach.
Restricción 33: Se construye un diagrama de secuencia donde se hace una llamada al
método notify antes que el setState.
95
6.2 Patrón Command
6.2.1 Descripción General Encapsula un pedido en un objeto, lo que permite parametrizar clientes con diferentes
pedidos, colas o log request, y soporta operaciones de deshacer (figura 6.9).
Figura 6.9: Diagrama de clases Patrón Command.
- Clasificación
Patrón de comportamiento y de objeto.
- Participantes
- Command:
Declara una interface para ejecutar una operación.
- ConcreteCommand
Define un enlace entre un objeto Receiver object y una operación action.
Implementa la operación Execute invocando las operaciones
correspondientes en el Receiver.
- Client
crea un objeto ConcreteCommand y configura su receptor.
- Invoker
Invoca el comando para cumplir el pedido.
96
- Receiver
Conoce como implementar las operaciones asociadas con el cumplimiento de
un pedido. Cualquier clase puede ser Receiver.
- Comportamiento
Un Cliente solicita un servicio para el que crea un Comando Concreto. Se activan los
receptores. El Comando Concreto es almacenado en el Invoker. El Invoker invoca la
operación execute del ConcreteCommand. Si se quiere volver atrás utilizando el
Comando Concreto lo puede hacer ya que tiene almacenado su estado, antes de la
invocación del execute. El comando concreto solicita la ejecución de las operaciones
del receptor (figura 6.10).
Figura 6.10: Diagrama de secuencia Patrón Command.
- Consecuencias
1. Command desacopla el objeto que invoca la operación del que sabe cómo
realizarla.
2. Los elementos Command pueden ser manipulados y extendidos como cualquier
objeto.
3. Puedes ensamblar commands dentro de un command compuesto. Se puede
combinar con el patrón Composite.
97
4. Es fácil agregar nuevos elementos Command, porque no tienes que cambiar las
clases existentes.
6.2.2 Descripción de elementos nivel 2 – Patrón Command Estereotipos
A partir del diagrama de clases de la figura 6.9 se elaboraron los estereotipos
estructurales del patrón. Se importan los estereotipos del nivel 0 que permiten
especificar sus participantes de los cuales se puede heredar sus atributos,
operaciones y restricciones: patternClassifier, patternClass, patternProperty (figura
6.11).
Figura 6.11: Características estructurales y dinàmicas del Patrón Command.
CommandConsistency: Hereda las características de patternInteraction, lo que
garantiza su consistencia entre el diagrama de clases y el diagrama de secuencia. Es
un estereotipo que permite verificar que existan los elementos obligatorios del patrón y
que dichos elementos contengan los aspectos incluidos en la definición del mismo.
Receiver y Command: Hereda las características del estereotipo patternClassifier
como elemento abstracto. El Command representa el comando encargado de ejecutar
las acciones que contiene el receptor (Receiver).
Invoker y Client: Heredan las características de una clase concreta. El Cliente debe
existir para crear el comando concreto. En el caso de Invoker almacena el comando y
lo invoca para que realice la ejecución de una acción.
98
State: Este estereotipo describe el estado del comando concreto lo que va a permitir
volver atrás con el comando en el caso de necesitarlo.
Los estereotipos execute y action heredan las características del estereotipo
patternOcurrence. Este estereotipo les permite estereotipar tanto operaciones como
especificaciones de ocurrencia. Se puede especificar aspectos de operaciones como
la secuencia de su ejecución.
execute: Fue definido para etiquetar las operación que comanda la ejecución de una
secuencia de acciones en el receptor.
action: Es un estereotipo que etiqueta una operación que refiere una determinada
acción dentro del Receptor.
6.2.3 Restricciones definidas en OCL para Command
Las restricciones se aplican para verificar el perfil Command, comprobando que
existan las asociaciones y composiciones necesarias entre los elementos del patrón.
Se comprueba que los estereotipos: Command, ConcreteCommand, Invoker, Client y
Receiver contengan los atributos y operaciones que deben contener por definición.
Respecto de su comportamiento, como en el caso del Observer, se comprueba su
consistencia y secuencia de ejecución.
Restricción 37: El perfil debe contener estereotipos de los participantes del
patrón: Command, ConcreteCommand, Client, Invoker y Receiver.
Context PerfilCommand::CommandConsistency
let TotalEstereo : Set(String) =
self.allOwnedElements().getAppliedStereotypes().name->asSet(),
ConjuntoEstereo : Set(String)=
Set{'Command','ConcreteCommand','Client','Invoker', 'Receiver'}
->asSet()
in
ConjuntoEstereo->forAll(e1| TotalEstereo->exists(e2|e1=e2))
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 ‘Command’, ‘Invoker’,
‘ConcreteCommand’, 'Client' o 'Receiver’, garantizando su existencia.
99
Utilización: Se verifica que los participantes del patrón estén representados en el
modelo.
Restricción 38: El patrón debe contener una asociación entre los estereotipos ConcreteCommand y Receiver.
Context PerfilCommand::CommandConsistency
Association.allInstances().memberEnd->
select(m|m.isNavigable()=true
and m.type.getAppliedStereotypes()->
select(name='Receiver')->
notEmpty()).class.getAppliedStereotypes()->
select(name='ConcreteCommand')->size()=
(Class.allInstances().getAppliedStereotypes()->
select(name='ConcreteCommand'))->size()
Descripción: La cantidad de objetos ConcreteCommand es igual a la cantidad de
relaciones entre ellos y los objetos receptores.
Utilización: Se verifica las relaciones de asociación entre el Receiver y los elementos
ConcreteCommand y Client.
Restricción 39: El patrón debe contener una relación de agregación entre los estereotipo Invoker y Command.
Context PerfilCommand::CommandConsistency
Association.allInstances().memberEnd ->
select(m|m.aggregation=uml::AggregationKind::shared and
m.type.getAppliedStereotypes().getLabel()->
includes('Command')->
notEmpty()).class.getAppliedStereotypes().name ->
includes('Invoker')
Descripción: Dado el conjunto de los extremos de asociación, se selecciona aquellos
que tienen un extremo de tipo agregación, y el tipo al que apunta tiene aplicado el
estereotipo Command. El extremo tiene aplicado el estereotipo Invoker.
Utilización: Se verifica que las relaciones de asociación estén representadas en el
modelo.
100
Restricción 40: El elemento estereotipado como Command debe contener una operación estereotipada como execute.
Context PerfilCommand::Command
self.getAllOperations().getAppliedStereotypes().getLabel()->
includes('execute')
Descripción: En el elemento estereotipado como Command existe una operación a las
cual se le ha aplicado el estereotipo execute.
Utilización: Se verifica que las operaciones del patrón estén representadas en el
modelo.
Restricción 41: El elemento estereotipado como Receiver debe contener la operación estereotipada como action.
Context PerfilCommand::Receiver
self.getAllOperations().getAppliedStereotypes().getLabel()->
includes('action')
Descripción: En el elemento estereotipado como Receiver existen operaciones a las
cuales se les ha aplicado el estereotipo action.
Utilización: Se verifica que las operaciones del patrón estén representadas en el
modelo.
Restricción 42: El elemento estereotipado como Invoker contiene una operación que debe contener como argumento un objeto estereotipado como Command.
Context PerfilCommand::Invoker
self.ownedOperation.ownedParameter.type.
getAppliedStereotypes().getLabel()->includes('Command')
Descripción: En el elemento estereotipado como Invoker existen operaciones con
parámetros a cuyo tipo se les ha aplicado el estereotipo Command.
Utilización: Se verifica la validez de las operaciones del patrón representadas en el
modelo.
101
Restricción 43: La cantidad de líneas de vida de comandos concretos deben ser iguales a los mensajes de creación solicitados por Cliente.
Context PerfilCommand::CommandConsistency
Message.allInstances()->
select(m|m.messageSort=uml::MessageSort::createMessage and
m.connector.end.role.type.getAppliedStereotypes()->
select(name='Client')->notEmpty())->size()=
Lifeline.allInstances().represents.type.
getAppliedStereotypes()-> select(name='ConcreteCommand')->size()
Descripción: Debe existir la misma cantidad de mensajes de creación enviados por
clientes que las líneas de vida que provienen de clases estereotipadas como
ConcreteCommand.
Utilización: Se verifica la consistencia de los mensajes de creación.
Restricción 44: Existe un evento de llamada desde la operación estereotipada
como execute hacia un objeto de tipo Invoker.
Context PerfilCommand::CommandConsistency
Message.allInstances()->
select(mensaje|mensaje.signature.getAppliedStereotypes()->
select(name='execute') -> size()>=1 and
mensaje.connector.end.role.type.getAppliedStereotypes()->
select(name='Invoker')->size()>=1)->size()>=1
Descripción: Debe existir por lo menos un mensaje de llamada hacia una opreración
estereotipada como execute, y este mensaje debe tener como extremo por lo menos
un objeto de un tipo estereotipado como Invoker. La cantidad de mensajes de este tipo
debe ser mayor o igual a 1.
Utilización: Se verifica la consistencia entre las operaciones y los mensajes del patrón
en el modelo.
102
Restricción 45: Existe una ejecución de comportamiento estereotipada por
execute. Dicha ejecución se encuentra en una línea de vida que proviene de una
clase estereotipada como ConcreteCommand.
Context PerfilCommand::CommandConsistency
let ejecucion: Collection(BehaviorExecutionSpecification)=
BehaviorExecutionSpecification.allInstances()
in ejecucion.covered.represents.type.
getApplicableStereotypes()-> select(name='ConcreteCommand')->
size()>=1 and ejecucion.finish.getAppliedStereotypes().name->
asSequence()->exists(n1,n2|n1='execute')
Descripción: Dado el conjunto de especificaciones de comportamiento , deben existir
algunas dentro de la línea de vida que proviene de una clase estereotipada como
ConcreteCommand y además halla al menos una ocurrencia de especificación. Esto
quiere decir, se ejecuta al menos una operación. Como consecuencia el comienzo de
alguna de las ejecuciones debe estar estereotipado como execute.
Utilización: Verifica que dentro de las ocurrencias del modelo dinámico exista una
ocurrencia estereotipada como execute.
Restricción 46: Existe una ejecución de comportamiento estereotipada por
action. Dicha ejecución se encuentra en una línea de vida que proviene de una
clase estereotipada como Receiver.
Context PerfilCommand::CommandConsistency
let ejecucion: Collection(BehaviorExecutionSpecification)=
BehaviorExecutionSpecification.allInstances()
in
ejecucion.covered.represents.type.
getApplicableStereotypes()->
select(name='Receiver')->size()>=1
and ejecucion.finish.getAppliedStereotypes().name->
asSequence()->exists(n1,n2|n1='action')
Descripción: Para la línea de vida que proviene de una clase estereotipada como
Receiver se halla al menos una ocurrencia de especificación. Esto quiere decir, se
ejecuta al menos una operación. Como consecuencia el comienzo de alguna de las
ejecuciones debe estar estereotipado como “action”.
Utilización: Verifica que dentro de las ocurrencias del modelo dinámico exista una
ocurrencia estereotipada como action.
103
Restricciones de orden general
Orden General
Se plantea el orden general en la tabla 6.2 para las ocurrencias de ejecución del
patrón Command.
Orden before after
g1 storeCommand execute
g2 execute action
Tabla 6-2: Orden general Command.
Restricción 47: Define un orden de ejecución de la secuencia de comandos
almacena y execute.
Context PerfilCommand::CommandConsistency
let oc : Sequence(OccurrenceSpecification)=
OccurrenceSpecification.allInstances()->asSequence(),
go : Sequence(GeneralOrdering)=
GeneralOrdering.allInstances()->
asSequence() in
go-> exists(g1| oc->exists(o1,o2|g1.before.name=o1.name and
g1.after.name=o2.name implies
(o1.getAppliedStereotypes()->select(name='storeCommand')->
notEmpty()) and (o2.getAppliedStereotypes()->
select(name='execute')-> notEmpty())))
Descripción: Se definió un orden general g1 y g2, se verifica la secuencia de los
elementos: almacena y execute.
Utilización: Verifica que las ocurrencias del modelo dinámico se encuentren
estereotipadas para cumplir el estándar del patrón.
Restricción 48: Define un orden de ejecución de la secuencia de comandos
execute y action.
Context PerfilCommand::CommandConsistency
let oc : Sequence(OccurrenceSpecification)=
OccurrenceSpecification.allInstances()-> asSequence()
, go: Sequence(GeneralOrdering) =
GeneralOrdering.allInstances()-> asSequence()
104
in
go->exists(g2| oc->exists(o1,o2|g2.before.name=o1.name and
g2.after.name=o2.name implies
(o1.getAppliedStereotypes()-> select(name='execute')->
notEmpty()) and (o2.getAppliedStereotypes()->
select(name='action')->notEmpty())))
Descripción: De la misma forma que el orden g1 se validó g2.
Utilización: Verifica que las ocurrencias del modelo dinámico se encuentren
estereotipadas para cumplir el estándar del patrón.
6.2.4 Aplicación de perfiles a un caso de estudio del Command
Se sigue el mismo procedimiento explicado en el patrón Observer, estereotipando
todos los participantes del modelo en el diagrama de clases y de secuencia respectivo,
y se verifican las restricciones propias de este perfil.
Caso Ejemplo Patrón Command
En este ejemplo se muestra el caso de servidores distribuidos en distintos lugares, a
los que se requiere aplicar los comandos de arranque y detención. Estos comandos
incluyen varias acciones: encender, conectar, verificar conexión para el caso de
arranque. Y para el caso de detención: guardar log, desconectar y apagar. Cada
server tendrá todas estas acciones implementadas. Para diseñar los comandos se
creó una clase por cada uno de los Comandos: ArrancaServer y DetenerServer. Cada
uno de ellos contiene una operación denominada operaServer que ejecuta el arranque
o la detención de los servidores. En este ejemplo se toman dos servidores: uno que se
encuentra en Argentina y otro que se encuentra en Brasil. También se definió un
invocador que actúa en el momento de llamar a la ejecución del comando. En la figura
6.12 se muestra el modelo estereotipado por los estereotipos del perfil del patrón
Command.
105
Figura 6.12: Diagrama de clases ejemplo Servidores.
Con este diseño el ejemplo desacopla la invocación de la operación respecto de su
implementación. Asimismo la parte comportamental del modelo puede verse en el
diagrama de secuencia de la figura 6.13, donde se presenta el diagrama de secuencia.
El comando de arranque está compuesto por tres acciones: encender, conectar y
verificar conexión. El cliente solicita un comando de Arranque. Se crea el comando
que será invocado por el Invoker para llevar a cabo el comando de arranque para el
receptor.
106
Figura 6.13: Diagrama de secuencia ejemplo Servidores.
Su parte comportamental es muy simple por lo que se puede representar
perfectamente con solo un diagrama de secuencia. Su simplicidad es lo que lo hace
tan útil.
6.2.5 Gestión del Framework
Se adopta la metodología explicada en la sección 6.1.5 para realizar la gestión de la
herramienta verificando el conjunto de restricciones especificadas para el patrón
Command. Otorgando como salida el siguiente resultado.
La figura 6.14 representa un diagrama de clases estereotipado por un ingeniero de
software, aplicando la importación del perfil Command, donde se omiten algunos
107
elementos importantes o se generan algunos errores para su para su posterior
verificación.
Figura 6.14: Diagrama de clases ejemplo Servidores mal formado.
La figura 6.15 representa un diagrama de secuencia estereotipado por un
desarrollador de software, que debe tener una relación directa con el de clases,
aplicando la importación del perfil Command, donde se omiten algunos elementos
importantes o se generan algunos errores para su para su posterior verificación.
108
Figura 6.15 : Diagrama de secuencia ejemplo Servidores mal formado.
La figura 6.16 muestra la verificación utilizando RSA, denotando las violaciones
establecidas para ambos modelos marcados.
109
Figura 6.16: Errores producidos por verificación de Command.
Verificaciones en el nivel 0:
Restricción 10: Se escribe una operación abstracta en la interface y en la clase que la
implementa no se escribe el método correspondiente.
Restricción13: Se escribe una operación concreta en una interface.
Verificaciones en el nivel 1:
Restricción 14: Al crear una línea de vida de un elemento que no existe en el diagrama
de clases. No existe una correspondencia entre las líneas de vida del diagrama de
secuencia y las clases del diagrama de clases.
Restricción 16: Todas las operaciones estereotipadas en el diagrama de clases se
deben ejecutar en el diagrama de secuencia, al crear una línea de vida de un elemento
que no existe en el diagrama de clases, no existe esta correspondencia.
Verificaciones en el nivel 2 del patrón Command:
Restricción 37: Se confeccionó un modelo sin el participante Invoker.
Restricción 39: No existe la agregación entre un elemento estereotipado como Invoker
hacia un elemento estereotipado como Command.
Restricción 44: No existe un mensaje de llamada a la operación estereotipada como
execute desde el Invoker.
Restricción 45: Se construye un diagrama de secuencia donde no exista un mensaje
execute en la línea de vida Command.
110
Restricción 46: No se aplicó en el diagrama de secuencia el estereotipo execute a la
ejecución de comportamiento que corresponda.
Restricción 47: Se construye un diagrama de secuencia donde se hace una llamada al
método execute antes que almacena.
Restricción 48: Se construye un diagrama de secuencia donde se hace una llamada al
método action antes que execute.
6.3 Patrón Memento
6.3.1 Descripción General
Este patrón de diseño permite capturar y exportar el estado interno de un objeto para
que luego se pueda restaurar, sin romper la encapsulación.
Su finalidad es almacenar el estado de un objeto (o del sistema completo) en un
momento dado, de manera que se pueda restaurar posteriormente si fuese necesario.
Para ello se mantiene almacenado el estado del objeto para un instante de tiempo en
una clase independiente de aquella a la que pertenece el objeto (pero sin romper la
encapsulación), de forma que ese recuerdo permita que el objeto sea modificado y
pueda volver a su estado anterior (figura 6.17).
Figura 6.17: Diagrama de clases Patrón Memento.
111
- Clasificación
Patrón de comportamiento y de objeto.
- Participantes
- Memento:
Almacena el estado interno del objeto Originator. El memento puede
almacenar los aspectos necesarios del estado interno del Originator.
Protege del acceso de otros objetos que no sean el Originator. Memento
tiene dos interfaces. Caretaker ve solo una parte del Memento. Originator, ve
una interface amplia, una que permite acceder a todos los datos necesarios
para restaurarse a sí mismo a su estado previo. Idealmente, solo el originator
que creó el memento puede acceder al estado interno del memento.
- Originator
Crea un memento conteniendo una copia de su estado interno actual.
Usa el memento para restablecer su estado interno.
- Caretaker
Es responsable por la seguridad del memento.
No funciona sobre los contenidos del memento o los examina.
- Comportamiento
El cliente crea el elemento a ser recordado (Originator) y el mecanismo de
salvaguarda (Caretaker). Caretaker guarda la copia del estado del elemento en ese
momento, y que será recordado y lo contabiliza como existente. Cuando el objeto
Originator lo requiere el objeto Caretaker le pasa la copia, del elemento Memento
(figura 6.18).
112
Figura 6.18: Diagrama de secuencia Patrón Memento.
- Consecuencias
1. Preserva los límites de la encapsulación. Memento evita exponer información que
solo un originator manejaría pero que debe ser almacenado fuera del originator. El
patrón protege otros objetos de potenciales y complejos del tipo Originator internos,
preservando así los limites de encapsulación.
2. Simplificación de Originator. Teniendo los clientes el manejo de los estados, ellos
requieren simplificar el Originator y que los clientes no tengan que notificar a los
objetos del tipo Originator cuando ellos hayan terminado.
3. Usar mementos podría ser caro. Los Mementos podrían incurrir en una considerable
sobrecarga si el Originator debe copiar grandes cantidades de información para
almacenar en el memento o si los clientes crean y retornan mementos del originator
demasiado a menudo.
4. Definir interfaces estrechas y amplias. Puede ser dificultoso en algunos lenguajes
para asegurar que solo el originator puede acceder al estado del memento.
5. Un caretaker es responsable por borrar los mementos que cuida. Sin embargo, el
caretaker no sabe cuánto un estado está en el memento. Un caretaker podría incurrir
en grandes costos de almacenamiento, cuando almacena mementos.
113
6.3.2 Descripción de elementos nivel 2 - Patrón Memento Estereotipos
A partir del diagrama de clases de la figura 6.19 se elaboraron los estereotipos
estructurales del patrón. Se importan los estereotipos del nivel 0 que permiten
especificar sus participantes de los cuales se puede heredar sus atributos,
operaciones y restricciones: patternClass, patternProperty (figura 6.19).
Figura 6.19: Características estructurales y dinámicas del Patrón Memento.
MementoConsistency: Hereda las características de patternInteraction, lo que
garantiza su consistencia entre el diagrama de clases y el diagrama de secuencia. Es
un estereotipo que permite verificar que existan los elementos obligatorios del patrón y
que dichos elementos contengan los aspectos incluidos en la definición del mismo.
Caretaker, Originator y Memento: Heredan las características de una clase concreta.
Caretaker cuida la seguridad del memento. Originator es la clase que crea el Memento
y Memento guarda el estado de Originator.
State: Este estereotipo describe el estado del Memento lo que va a permitir volver
atrás el estado del Memento en el caso de necesitarlo.
Los estereotipos createMemento, getState, setState y setMemento heredan las
características del estereotipo patternOcurrence. Este estereotipo les permite
estereotipar tanto operaciones como especificaciones de ocurrencia. Se puede
especificar aspectos de operaciones como la secuencia de su ejecución.
114
6.3.3 Restricciones definidas en OCL para Memento
Las restricciones se aplican para verificar el perfil Memento, comprobando que existan
las asociaciones y composiciones necesarias entre los elementos del patrón. Se
comprueba que los estereotipos: Caretaker, Originator y Memento contengan los
atributos y operaciones que deben contener por definición. Respecto de su
comportamiento, se comprueba su consistencia y secuencia de ejecución.
Restricción 49: El perfil debe contener estereotipos de los participantes del
patrón: Caretaker, Originator y Memento
Context PerfilMemento::MementoConsistency
let TotalEstereo : Set(String) =
Class.allInstances().getAppliedStereotypes().name->asSet(),
ConjuntoEstereo : Set(String)= Set{'Originator','Caretaker',
,'Memento'}->asSet()
in
ConjuntoEstereo->forAll(e1| TotalEstereo->exists(e2|e1=e2))
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 y el
conjunto de los estereotipos del patrón. Se verifica que existan los estereotipos dentro
de la colección de estereotipos que corresponden a los elementos estereotipados del
modelo.
Utilización: Se verifica que los participantes del patrón estén representados en el
modelo.
Restricción 50: Dependencia Originator-Memento
Context PerfilMemento::Originator
self.clientDependency.oclAsType(Usage).relatedElement.
getAppliedStereotypes()-> select(name='Memento')->size()>=1
Descripción: El elemento estereotipado como Originator contiene al menos una
dependencia respecto del elemento estereotipado como Memento.
Utilización: Se verifica que las relaciones estén representadas en el modelo.
115
Restricción 51: Agregación Caretaker-Memento
Context PerfilMemento::Caretaker
self.attribute->exists(atributo|
atributo.type.getAppliedStereotypes()->
select(name='Memento')->
size()>=1 and
atributo.aggregation=uml::AggregationKind::shared))
Descripción: El elemento estereotipado como Caretaker contiene al menos una
agregación dirigida hacia el elemento estereotipado como Memento.
Utilización: Se verifica que las relaciones estén representadas en el modelo.
Restricción 52: Operación createMemento del estereotipo Originator
Context PerfilMemento::Originator
self.getAllOperations()->select(o|o.getAppliedStereotypes()->
select(name='setMemento' or name='createMemento')->notEmpty()
and o.ownedParameter.type.getAppliedStereotypes().getLabel()->
includes('Memento'))->notEmpty()
Descripción: Si se selecciona las operaciones que contienen como parámetro un
objeto estereotipado como Memento, existe por lo menos una de estas operaciones
que están estereotipadas como createMemento.
Restricción 53: Los estereotipos setMemento y createMemento deben estar
presentes en las operaciones de Originator
Context PerfilMemento::Originator
let TotalEstereo : Set(String) =
self.getAllOperations().getAppliedStereotypes().name->asSet(),
ConjuntoEstereo : Set(String)= Set{'setMemento',
'createMemento'}-> asSet()in
ConjuntoEstereo->forAll(e1| TotalEstereo->exists(e2|e1=e2))
Descripción: Existe por lo menos una operación estereotipada como setMemento en
el elemento estereotipado como Originator. Y
Utilización: Se verifica que las operaciones del patrón estén representadas en el
modelo.
116
Restricciones de orden general
Orden General
En este caso se puede definir la obligatoriedad de que se cumplan dos órdenes
parciales: createMemento con setState, y setState con setMemento, ver tabla 6.3.
Orden before after
g1 createMemento setState
g2 setState setMemento
Tabla 6-3: Orden general Memento.
Restricción 54: Define un orden de ejecución de la secuencia de comandos
createMemento y setState.
Context PerfilMemento::MementoConsistency
let oc : Sequence(OccurrenceSpecification)=
OccurrenceSpecification.allInstances()->asSequence()
, go:Sequence(GeneralOrdering)=
GeneralOrdering.allInstances()->
asSequence() in
go-> exists(g1| oc->exists(o1,o2|g1.before.name=o1.name and
g1.after.name=o2.name implies
(o1.getAppliedStereotypes()->select(name='createMemento')->
notEmpty()) and (o2.getAppliedStereotypes()->
select(name='setState')-> notEmpty())))
Descripción: Dentro de la interacción existe un conjunto de órdenes generales, y un
conjunto de ocurrencias. En la restricción se asignan a dos variables la secuencia de
estos dos conjuntos. Dentro la secuencia de órdenes se encuentra un orden
denominado g1 en esta restricción. Y dentro de este orden se halla una ocurrencia o1
como primer elemento de la secuencia, ya que es elemento etiquetado como before.
Además se encuentra un segundo elemento etiquetado como after, la ocurrencia o2.
En términos simples, o1 debe ir primero y o2 debe ir después. El elemento o1 está
antes que o2 y el elemento o2 está después de o1. Y además esos elementos están
estereotipados por createMemento y setState.
Utilización: Verifica que las ocurrencias del modelo dinámico se encuentren
estereotipadas para cumplir el estándar del patrón.
117
Restricción 55: Define un orden de ejecución de la secuencia de comandos
setState y setMemento.
Context PerfilMemento::Memento
let oc: Sequence(OccurrenceSpecification)=
OccurrenceSpecification.allInstances()->asSequence(),
go: Sequence(GeneralOrdering)= GeneralOrdering.allInstances()
-> asSequence() in
go-> exists(g2| oc->exists(o1,o2|g2.before.name=o1.name and
g2.after.name=o2.name implies
(o1.getAppliedStereotypes()->select(name='setState')->
notEmpty()) and (o2.getAppliedStereotypes()->
select(name='setMemento')-> notEmpty())))
Descripción: Se definió un orden general G2 en los mismos términos que G1, pero
describe la secuencia de los elementos: setState y setMemento.
Utilización: Verifica que las ocurrencias del modelo dinámico se encuentren
estereotipadas.
118
6.3.4 Aplicación de perfiles a un caso de estudio del Memento
Se sigue el mismo procedimiento explicado en el patrón Observer, estereotipando
todos los participantes del modelo en el diagrama de clases y de secuencia respectivo,
y se verifican las restricciones propias de este perfil.
Caso ejemplo Patrón Memento
Este patrón debe ser utilizado cuando se necesite salvar el estado de un objeto y tener
disponible los distintos estados históricos que se necesiten. El siguiente ejemplo ilustra
el uso de "undo" con el patrón Memento (figura 6.20). Intervienen tres clases: la
clase Originator (Originador) es una clase que cambia de estado; la clase
Caretaker (Portero) se encarga de registrar los cambios del estado de
Originador; Memento (Memoria) almacena el estado interno de un objeto Originator. El
Memento puede almacenar mucho o parte del estado interno de Originator. A su vez
tiene dos interfaces una para el Portero que le permite manipular el Memento
únicamente para pasarlo a otros objetos. Y la otra interfaz sirve para Originador que
puede almacenar/restaurar su estado interno.
Figura 6.20: Diagrama de clases ejemplo Memoria.
Asimismo la parte comportamental del modelo puede verse en el diagrama de
secuencia de la figura 6.21, donde se presenta el diagrama de secuencia que se
describe a continuación. En primer lugar el objeto Main crea los objetos de tipo Portero
(P1) y Originador (O1). Se le da un estado inicial a O1 (Originador). La secuencia del
patrón comienza cuando el objeto Main llama al procedimiento agregarMemento del
objeto P1, lo que origina que el Portero realice una llamada a la operación
crearMemoria del Originator. O1 (Originator) crea el Memento M1, llamando a la
operación newMemoria y establece su estado mediante el método establecerEstado
del objeto M1 creado. De esta manera ya tenemos salvaguardada la memoria del
estado del Objeto O1 (Originator). En un momento determinado O1 cambia su estado.
Se vuelve a generar el ciclo de guardado. Es decir, se envía desde Main el mensaje a
119
P1 para que agregue en este caso un memento M2. Se crea M2 mediante
newMemoria y M2 establece su estado con la operación establecerEstado. En un
momento determinado se hace necesario volver el Originator al estado original M1.
Figura 6.21: Diagrama de secuencia ejemplo Memoria.
120
Es decir, realizar el undo. Es ahí cuando el Main hace una llamada al método
recuperarDelaMemoria del Portero P1, dicho método posibilita el acceso al memento
M1. El próximo paso es recuperar el estado del memento, llamando desde Main al
procedimiento recuperarEstado. En el ejemplo también se recupera el estado de M2
de la misma manera llamando las operaciones recuperarDelaMemoria y
recuperarEstado respectivamente.
6.3.5 Gestión del Framework
Se adopta la metodología explicada en la sección 6.1.5 para realizar la gestión de la
herramienta verificando el conjunto de restricciones especificadas para el patrón
Memento. Otorgando como salida el siguiente resultado.
La figura 6.22 representa un diagrama de clases estereotipado por un ingeniero de
software, aplicando la importación del perfil Memento, donde se omiten algunos
elementos importantes o se generan algunos errores para su para su posterior
verificación.
Figura 6.22: Diagrama de clases ejemplo Memoria mal formado.
La figura 6.23 representa un diagrama de secuencia estereotipado por un ingeniero
de software, que debe tener una relación directa con el de clases, aplicando la
importación del perfil Memento, donde se omiten algunos elementos importantes o se
generan algunos errores para su para su posterior verificación.
121
Figura 6.23: Diagrama de secuencia ejemplo Memoria mal formado.
La figura 6.24 muestra claramente la ejecución de validación que permite el software
RSA, denotando las violaciones establecidas para ambos modelos marcados.
Figura 6.24: Mensajes de Error de mala formación Memento.
122
Verificaciones en el nivel 0:
Restricción 1: Se escribe una propiedad en la clase Portero sin tipo de dato.
Restricción 12: Se escribe una operación abstracta en una clase concreta Portero.
Verificaciones en el nivel 1:
Restricción 16 : Al no estereotipar la operación establecerMemoria como setMemento
no coinciden las operaciones estereotipadas con las ejecuciones estereotipadas.
Restricción 17: Se crea un método Operacion1 en una clase con signatura privada y
se crea un mensaje en el diagrama de secuencia para este método.
Restricción 18: Se crea un mensaje cuyo con nombre no se corresponde con ninguna
operación de la clase.
Verificaciones en el nivel 2 del patrón Memento:
Restricción 50: Se confeccionó un modelo sin el participante Memento
Restricción 51: Al no estar estereotipado el participante Memento no existe su
instanciación.
Restricción 53: Al no estar estereotipado el participante Memento la operación
createMemento que está en Originator no tiene un párametro estereotipado de tipo
Memento.
Restricción 52: Se confeccionó un modelo sin la agregación entre el Caretaker y el
Memento.
Restricción 54: No se estereotipa la operación establecerMemoria con el estereotipo
setMemento.
Restricción 55: Se construye un diagrama de secuencia donde se hace una llamada al
método establecerEstado antes que crearMemoria.
Restricción 56: Se construye un diagrama de secuencia donde se hace una llamada al
método establecerMemoria antes que establecerEstado.
123
CAPITULO VII
Conclusiones y Trabajos Futuros
En este capítulo se presentan las conclusiones y orientaciones que pueden servir para
continuar en un futuro esta línea de investigación. Dada la imprecisión de UML
muchas investigaciones estudian como proveer una mejor verificación de los modelos
generados con este lenguaje. La verificación formal basada en la lógica matemática
supera las debilidades de otras formas de verificación. Aquí se plantea una forma de
verificación de patrones de diseño basada en lógica de primer orden.
7.1 Conclusiones
En esta tesis se ha presentado un conjunto de especificaciones en el marco de una
arquitectura de patrones de diseño. La técnica utilizada implica la creación de perfiles
UML y restricciones OCL. De esta manera puede formularse una especificación
genérica y reusable, fácil de expresar y mantener. La lógica de primer orden resulta
normalmente más fácil de aprender y comprender que otros formalismos matemáticos.
En este trabajo se muestra que es posible la especificación de los patrones diseño de
comportamiento con dicho formalismo, brindando así, consistencia y precisión en la
técnica utilizada.
El artefacto “Perfil UML”, definido por la OMG, se emplea como mecanismo para
documentar y definir patrones de diseño. Esto permite; siguiendo con la noción de
perfil, introducir estereotipos, valores etiquetados y restricciones en modelos
particulares.
También se muestra que la definición de un perfil para cada patrón es una opción para
la especificación de patrones de diseño. No se usa una sintaxis especial para
representar patrones; sino que se usa un artefacto UML: “el perfil”. De esta forma, el
124
mismo se utiliza no solo para definir un dominio especifico sino también para un
dominio general, como lo es la definición de patrones.
Esta metodología permite a los diseñadores de software visualizar claramente los
patrones que están utilizando. Esto favorece la comunicación entre ellos; a la vez, que
posibilita establecer un vocabulario común (características propias del uso de patrones
de diseño).
Utilizando dichas especificaciones en el marcado de modelos se dota de una mayor
precisión al mismo. Al estereotipar los elementos de un modelo se pueden verificar las
condiciones obligatorias para un determinado patrón. De esta manera se puede
verificar los modelos y preparar los mismos para una futura transformación tanto a
nivel PIM como PSM. En este trabajo se han definido restricciones semánticas sobre
estereotipos, siguiendo el estándar definido para los patrones. El uso de un conjunto
de restricciones le da al patrón su substancia ya que lo hace más formal. También la
definición de restricciones para cada nivel de una arquitectura introduce mayor
generalidad en la definición del modelo.
Los patrones de comportamiento, tienen características particulares que se
puntualizaron y que son propias de la programación orientada a objetos.
El presente trabajo permitió representar las interacciones entre las clases y su
comportamiento, con claridad y en forma legible. Asimismo se mostraron ejemplos
simples y prácticos para representar los patrones.
Según lo destacado anteriormente podemos afirmar que se ha logrado con la
investigación de esta tesis aportar los siguientes beneficios a la ingeniería de
software:
• Facilitar la representación de modelos que contengan patrones de
comportamiento definidos.
• Estandarizar y simplificar las especificaciones de patrones de comportamiento.
• Especificar los aspectos dinámicos de los patrones.
• Formalizar una estructura para la definición de futuros patrones
125
Dentro de las contribuciones mencionadas al comienzo del trabajo cabe
destacar como utilidades:
• Aplicación de conceptos MDA al modelado de patrones de diseño como contribución
general.
• Formalización de especificaciones para los patrones de diseño.
• Definición de una arquitectura específica para patrones de comportamiento.
• Visualización y documentación de los patrones de diseño.
• La posibilidad de utilizar las herramientas UML estándar para la especificación de
patrones sin necesidad de crear una herramienta especifica.
7.2 Trabajos futuros
A continuación se detallan futuros trabajos y extensiones aplicables a la presente
propuesta de tesis.
El trabajo realizado proporciona la base para ampliar y mejorar los instrumentos para
la validación y verificación de software a través de investigaciones sobre las siguientes
ideas.
Se pueden incorporar nuevos perfiles dentro de la arquitectura en cualquier nivel
aprovechando el reúso de definiciones, generando nuevos estereotipos y
extensiones. La ventaja de definir en el nivel de arquitectura los patrones
particulares permite anexar cualquier tipo de patrón independiente de los
catalogados como patrones de diseño.
Se puede generar un catálogo que contenga un patrón base y distintas variantes
de especificación de un patrón que permitan verificar los modelos en forma más
flexible. Ya que en la especificación presentada falta plantear la variabilidad de
patrones y su utilización en modelos complejos.
Se puede construir una herramienta para la detección de patrones, tomando como
referencia los modelos y perfiles definidos en el catalogo. La detección de patrones
puede formularse ya que se cumplen los requisitos necesarios. Como ya se dijo
126
existe una especificación genérica y reusable, fácil de expresar y mantener. Y
además la lógica de primer orden es fácil de aprender y comprender
Se pueden definir transformaciones para mutar de una variante de un patrón hacia
otra variante menos compleja.
Otra arista posible es la formulación de las especificaciones en lógica de primer
orden pero en lenguajes que permitan la verificación de UML como es el caso del
lenguaje Prolog.
En la especificación presentada se recurrió a tecnologías existentes y dentro de ellas
su posible integración con herramientas de modelado. De esta manera los usuarios
obtienen el valor añadido de maniobrar herramientas que ya manejan en lugar de
tener que emplear nuevas. La detección puede ser implementada a través del uso de
transformaciones en lenguaje QVT y lograr también generar su correspondiente código
a través de una transformación de modelo a texto.
A partir de la arquitectura desarrollada es posible desarrollar una herramienta
UML/MDA que abarque las ideas presentadas. Un punto a tener en cuenta es la
importancia de la compatibilidad con herramientas existentes. Por ejemplo, la
herramienta presentada necesariamente importará y exportará formatos como XMI u
otros de tipo estándar.
127
Bibliografía
[1] E. Gamma, H. Richard, R. Jhonson, and J. VLislides, Patrones de diseño: elementos de software orientado a objetos reutilizable. Addison-Wesley, 2003.
[2] T. Taibi, Design Patterns Formalization Techniques. IGI Publishing, 2007.
[3] “OMG Formal Specifications”, OMG, 2015. Disponible: http://www.omg.org/spec/. [Último acceso: 28-Jul-2015].
[4] G. Booch, J. Rumbaugh, and I. Jacobson, El Lenguaje Unificado de Modelado. Addison-Wesley, 1999.
[5] “OCL 2.4,” OMG, 2014. Disponible: http://www.omg.org/spec/OCL/2.4/ [Último acceso: 28-Jul-2015].
[6] “IBM developerWorks : Download : IBM Rational Software Architect,” IBM, Disponible: https://www.ibm.com/developerworks/downloads/r/architect/. [Último acceso: 28-Jul-2015].
[7] “UML 2.5,” OMG, 2015. [Online]. Disponible: http://www.omg.org/spec/UML/2.5/ [Último acceso: 28-Jul-2015].
[8] P. Coad, “Object-oriented patterns” Commun. ACM, vol. 35, no. 9, pp. 152–159, 1992.
[9] S. Berczuk, “Finding solutions through pattern languages”, Computer (Long. Beach. Calif)., vol. 27, no. 12, pp. 75–76, 1994.
[10] C. Alexander:, The Timeless Way of Building: 9780195024029: Amazon.com: Books. Oxford University Press, 1979.
[11] A. H. Eden and Y. Hirshfeld, “Principles in formal specification of object oriented design and architecture” CASCON ’01 Proc. 2001 Conf. Cent. Adv. Stud. Collab. Res., p. 3, 2001.
[12] M. E. Fayad, C. Chiang, P. Chacin, S. Ramaswamy, A. Sánchez-Ruíz, and S. Nurcan, “The first international workshop on patterns languages” in Companion to the 22nd ACM SIGPLAN conference on Object oriented programming systems and applications companion - OOPSLA ’07, p. 743, 2007.
[13] F. Khomh and Y. Guéhéneuc, “Do Design Patterns Impact Software Quality Positively?”, Softw. Maint. Reengineering. CSMR 2008. 12th Eur. Conf., pp. 274–278, 2008.
[14] T. Winn and P. Calder, “A pattern language for pattern language structure”, Proceeding CRPIT ’02 Proc. 2002 Conf. Pattern Lang. programs, vol. 13, pp. 45–58, 2003.
128
[15] A. Lauder and S. Kent, “Precise visual specification of design patterns”, ECOOP’98 — Object-Oriented Programming, vol. 1445, pp. 230–236, 1998.
[16] G. Cepeda Porras and Y.-G. Guéhéneuc, “An empirical study on the efficiency of different design pattern representations in UML class diagrams”, Empir. Softw. Eng., vol. 15, no. 5, pp. 493–522, 2010.
[17] K. Lano, J. C. Bicarregui, and S. Goldsack, “Formalising design patterns”, p. 11, 1996.
[18] A. Le Guennec, G. Sunyé, and J.-M. Jézéquel, “Precise modeling of design patterns”, pp. 482–496, 2000.
[19] J. K. H. Mak, C. S. T. Choy, and D. P. K. Lun, “Precise modeling of design patterns in UML”, Proceedings. 26th Int. Conf. Softw. Eng., 2004.
[20] U. Zdun and P. Avgeriou, “Modeling architectural patterns using architectural primitives”, ACM SIGPLAN Not., vol. 40, no. 10, p. 133, 2005.
[21] J. Dong, S. Yang, and K. Zhang, “Visualizing Design Patterns in Their Applications and Compositions”, IEEE Trans. Softw. Eng., vol. 33, no. 7, pp. 433–453, 2007.
[22] K. N. Loo, S. P. Lee, and T. K. Chiew, “UML Extension for Defining the Interaction Variants of Design Patterns”, IEEE Softw., vol. 29, no. 5, pp. 64–72, 2012.
[23] N. C. Debnath, A. Garis, D. Riesco, and G. Montejano, “Defining OCL constraints for the Proxy Design Pattern Profile”, 2007 IEEE/ACS International Conference on Computer Systems and Applications, pp. 880–885, 2007.
[24] T. Mikkonen, “Formalizing design patterns”, Proc. 20th Int. Conf. Softw. Eng., 1998.
[25] J. Niere, W. Schäfer, J. P. Wadsack, L. Wendehals, and J. Welsh, “Towards pattern-based design recovery”, pp. 338–348.
[26] A. Blewitt, A. Bundy, and I. Stark, “Automatic verification of Java design patterns,” Proc. 16th Annu. Int. Conf. Autom. Softw. Eng. (ASE 2001), 2001.
[27] N. S. N. Shi and R. a. Olsson, “Reverse Engineering of Design Patterns from Java Source Code”, 21st IEEE/ACM Int. Conf. Autom. Softw. Eng., 2006.
[28] J. Dong, Y. Zhao, and T. Peng, “Architecture and design pattern discovery techniques-a review”, Proc. Int. Conf. Softw. Eng. Res. Pract. (SERP), USA, p. 11, 2007.
[29] C. Kramer and L. Prechelt, “Design recovery by automated search for structural design patterns in object-oriented software”, Proceedings of WCRE ’96: 4rd Working Conference on Reverse Engineering, pp. 208–215. 1996.
129
[30] D. Beyer, A. Noack, and C. Lewerentz, “Efficient relational calculation for software analysis”, IEEE Trans. Softw. Eng., vol. 31, no. 2, pp. 137–149, 2005.
[31] A. H. Eden, A. Yehudai, and J. Gil, “Precise specification and automatic application of design patterns”, Proceedings 12th IEEE International Conference Automated Software Engineering, pp. 143–152, 1997.
[32] A. H. Eden, “A Theory of Object-Oriented Design”, Inf. Syst. Front., vol. 3, pp. 379–391, 2002.
[33] A. H. Eden, E. Gasparis, and J. Nicholson, “LePUS3 and Class-Z Reference Manual”, Computer (Long. Beach. Calif), pp. 1–19, 2009.
[34] E. Gasparis, J. Nicholson, and A. H. Eden, “LePUS3: An object-oriented design description language”, Lect. Notes Comput. Sci. (including Subser. Lect. Notes Artif. Intell. Lect. Notes Bioinformatics), vol. 5223 LNAI, pp. 364–367, 2008.
[35] D. Maplesden, J. Hosking, and J. Grundy, “A visual language for design pattern modelling and instantiation”, Proc. IEEE Symp. Human-Centric Comput. Lang. Environ. (Cat. No.01TH8587), pp. 2–3, 2001.
[36] D. Maplesden, J. Hosking, and J. Grundy, “Design Pattern Modelling and Instantiation using DPML”, Proc. Fortieth Int. Conf. Tools Pacific Objects internet, Mob. Embed. Appl. - CRPIT ’02, vol. 10, pp. 3–11, 2002.
[37] R. B. France, D. K. Kim, S. Ghosh, and E. Song, “A UML-based pattern specification technique”, IEEE Trans. Softw. Eng., vol. 30, no. 3, pp. 193–206, 2004.
[38] D. K. Kim, “A meta-modeling approach to specifying patterns”, 2004.
[39] D. K. Kim and L. Lu, “Inference of design pattern instances in UML models via logic programming,” 11th IEEE Int. Conf. Eng. Complex Comput. Syst., 2006.
[40] D. K. Kim and W. Shen, “An approach to evaluating structural pattern conformance of UML models”, Proceedings of the 2007 ACM symposium on Applied computing - SAC ’07, p. 1404, 2007.
[41] IBM, “IBM - Rational Rose Enterprise”, Disponible: http://www-03.ibm.com/software/products/es/enterprise. [Último acceso: 31-Jul-2015].
[42] D. K. Kim and W. Shen, “Evaluating pattern conformance of UML models: A divide-and-conquer approach and case studies”, Softw. Qual. J., vol. 16, no. 3, pp. 329–359, 2008.
[43] H. Albin-Amiot, P. Cointe, Y.-G. Gueheneuc, and N. Jussien, “Instantiating and detecting design patterns: putting bits and pieces together”, Proc. 16th Annu. Int. Conf. Autom. Softw. Eng. (ASE 2001), 2001.
130
[44] M. Elaasar, L. C. Briand, and Y. Labiche, “A metamodeling approach to pattern specification”, Model Driven Engineering Languages and Systems, vol. 4199, pp. 484–498, 2006.
[45] H. Zhu and L. Shan, “Well-formedness, consistency and completeness of graphic models”, Proc. UKSIM’06, Oxford, UK, pp. 47–53, 2006.
[46] M. Elaasar, L. C. Briand, and Y. Labiche, “VPML : An Approach to Detect Design Patterns of MOF-Based Modeling Languages”, pp. 1–42, 2013.
[47] “QVT 1.2,” OMG, 2015. Disponible: http://www.omg.org/spec/QVT/1.2/. [Último acceso: 01-Sep-2015].
[48] J. Fernandes, Ralf Lämmel, J. Visser, and J. Saraiva, Generative and Transformational Techniques in Software Engineering III: International Summer School, GTTSE 2009, Braga, Portugal, July 6-11, 2009, Revised Papers. Springer, 2011.
[49] “Graphical Modeling.” Disponible: https://eclipse.org/modeling/graphical.php. [Último acceso: 01-Sep-2015].
[50] “medini QVT.” Disponible: http://projects.ikv.de/qvt. [Último acceso: 01-Sep-2015].
[51] “Eclipse Modeling Project.” Disponible: https://eclipse.org/modeling/emf/. [Último acceso: 01-Sep-2015].
[52] K. Lano and S. Kolahdouz-Rahimi, “Model-Transformation Design Patterns”, IEEE Trans. Softw. Eng., vol. 40, no. 12, pp. 1224–1259, 2014.
[53] M. Elaasar, L. C. Briand, and Y. Labiche, “An Approach to Detecting Design Patterns in MOF- Based Domain-Specific Models with QVT,” pp. 1–41, 2010.
[54] “MDA Specifications,” OMG, 2014. Disponible: http://www.omg.org/mda/specs.htm. [Último acceso: 28-Jul-2015].
[55] P. H. T. Costa and E. Dias Canedo, “Using a MDD approach to develop software systems”, 2015 10th Iberian Conference on Information Systems and Technologies (CISTI), pp. 1–6, 2015.
[56] “CWM,” OMG, 2003. Disponible: http://www.omg.org/spec/CWM/. [Último acceso: 28-Jul-2015].
[57] P. Denning, C. Martell, and V. Cerf., IEEE Xplore Book Home Page - Great Principles of Computing. MIT Press, 2015.
[58] E. Rodrigues, M. Bernardino, L. Costa, A. Zorzo, and F. Oliveira, “PLeTsPerf - A Model-Based Performance Testing Tool”, 2015 IEEE 8th International Conference on Software Testing, Verification and Validation (ICST), pp. 1–8, 2015.
131
[59] S. Herbold, A. De Francesco, J. Grabowski, P. Harms, L. M. Hillah, F. Kordon, A.-P. Maesano, L. Maesano, C. Di Napoli, F. De Rosa, M. A. Schneider, N. Tonellotto, M.-F. Wendland, and P.-H. Wuillemin, “The MIDAS Cloud Platform for Testing SOA Applications”, 2015 IEEE 8th International Conference on Software Testing, Verification and Validation (ICST), pp. 1–8, 2015.
[60] A. Ati, “An Automatic Transformation From COSA Software Architecture To EJB Platform”, 2008 3rd International Conference on Information and Communication Technologies: From Theory to Applications, pp. 1–6, 2008.
[61] F. Jarray, H. Chniter, and M. Khalgui, “New adaptive middleware for real-time embedded operating systems”, 2015 IEEE/ACIS 14th International Conference on Computer and Information Science (ICIS), pp. 610–618, 2015.
[62] A. B. H. Ali, M. Khalgui, and S. Ben Ahmed, “UML MARTE-based design of reconfigurable distributed embedded control systems”, 2013 IEEE International Conference of IEEE Region 10 (TENCON 2013), pp. 1–4, 2013.
[63] A. Di Marco and S. Pace, “Model-driven approach to Agilla Agent generation”, 2013 9th International Wireless Communications and Mobile Computing Conference (IWCMC), pp. 1482–1487, 2013.
[64] S. Tucci-Piergiovanni, C. Mraidha, E. Wozniak, A. Lanusse, and S. Gerard, “A UML Model-Based Approach for Replication Assessment of AUTOSAR Safety-Critical Applications”, 2011IEEE 10th International Conference on Trust, Security and Privacy in Computing and Communications, pp. 1176–1187, 2011.
[65] X. Qiu and L. Zhang, “Providing Support for Specifying Redundancy Tactics Using Aspect-Oriented Modeling”, 2013 13th International Conference on Quality Software, pp. 183–186, 2013.
[66] O. Ongsiriporn and T. Senivongse, “UML profile for fault tolerance patterns for service-based systems”, The 2013 10th International Joint Conference on Computer Science and Software Engineering (JCSSE), pp. 240–245, 2013.
[67] M. Gogolla, M. Kuhlmann, and L. Hamann, “Consistency, independence and consequences in UML and OCL models”, Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), vol. 5668 LNCS, pp. 90–104, 2009.
[68] H. M. Chavez, “Formalization of UML Composition in OCL”, 2012 IEEE/ACIS 11th International Conference on Computer and Information Science, pp. 675–680, 2012.
[69] M. T. T. That, S. Sadou, and F. Oquendo, “Using Architectural Patterns to Define Architectural Decisions”, 2012 Joint Working IEEE/IFIP Conference on Software Architecture and European Conference on Software Architecture, pp. 196–200, 2012.
132
133
Apéndice A
Especificaciones OMG
Construcciones básicas utilizadas por MOF
MOF usa cinco construcciones básicas para definir un lenguaje de modelado de las
cuales vimos dos (clase y atributo):
Clases: usadas para definir tipos de elementos en un lenguaje de modelado. Por
ejemplo, la relación de dependencia de UML es una clase definida en MOF, que
representa el tipo de todas las dependencias que pueden crearse en un modelo UML.
Generalización: define herencia entre clases. Por ejemplo UML Classifier es una
generalización de UML Class. La subclase hereda todas las características de la clase
padre.
Atributos: usados para definir propiedades de elementos del modelo. Los atributos
tienen un tipo y una multiplicidad.
Asociaciones: definen relaciones entre clases. Una relación tiene dos extremos, cada
uno de los cuales puede tener definido un nombre de rol, navegabilidad y multiplicidad
Operaciones: definen operaciones dentro del ámbito de una clase, junto con una lista
de parámetros.
Las construcciones básicas de MOF permiten construir el lenguaje UML. A
continuación se describen los metamodelos correspondientes a los paquetes de UML
especificados en la Superestructura definidos por la OMG. En UML un diagrama es en
realidad más que una colección de elementos de notación. Por ejemplo, un diagrama
de clase puede contener una clase, una asociación y otros elementos. A continuación
se presenta un diagrama de clases con los principales elementos y su descripción
correspondiente.
134
Metamodelo Diagrama de Clases
El diagrama de clases fue extraído de [7] como se muestra en la figura A1 y define los
constructores para el modelado basado en clases.
Figura A.1: Diagrama de clases del paquete Kernel.
Diagramas UML
Un diagrama es la representación gráfica de un conjunto de elementos con sus
relaciones. En concreto, un diagrama ofrece una vista del sistema a modelar. Para
poder representar correctamente un sistema, UML ofrece una amplia variedad de
diagramas para visualizar el sistema desde varias perspectivas. UML incluye los
siguientes diagramas:
Diagrama de colaboración.
Diagrama de casos de uso.
Diagrama de clases.
Diagrama de objetos.
Diagrama de secuencia.
Diagrama de estados.
Diagrama de actividades.
135
Diagrama de componentes.
Diagrama de despliegue.
Para modelar el comportamiento dinámico del sistema están los de interacción,
colaboración, estados y actividades. Los diagramas de componentes y despliegue
están enfocados a la implementación del sistema.
En resumen, UML resuelve de forma bastante satisfactoria un viejo problema del
desarrollo de software como es su modelado gráfico. Además, se ha llegado a una
solución unificada basada en lo mejor que había hasta el momento, lo cual lo hace
todavía más excepcional.
Sintaxis UML para Diagramas de Clase
1. Representación de una clase
· Una clase se representan como un rectángulo dividido en tres partes (tres
compartimentos).
· En el compartimento superior, centrado, va el nombre de la clase.
· El segundo compartimento contiene los atributos, en la forma:
visibilidad nombreAtributo: tipo
· El tercer compartimento contiene los métodos, en la forma:
visibilidad nombreMétodo(parámetros): tipoRetorno.
· Los parámetros van separados por comas y se especifica el nombre y el tipo.
· Los constructores no tienen tipo de retorno.
· La visibilidad, de atributos y métodos, puede ser:
- privado
+ público
# protegido
~ de paquete
136
Ejemplo figura A.2 :
Figura A.2: Notación gráfica de una clase.
Es posible representar una clase usando sólo el compartimento del nombre, o el
compartimento del nombre y uno de los dos siguientes (atributos o métodos). Cuando
se representa una clase de esta forma no es posible deducir nada de los
compartimentos faltantes.
Ejemplo figura A.3 :
Figura A.3: Ejemplo de clases.
2. Paquetes
· Un paquete se representa de la siguiente forma, ver figura A.4:
Figura A.4: Notación gráfica de paquete.
La relación de un paquete con las clases que contiene, se representa como se ilustra
en la figura A.5 :
137
Figura A.5: Paquete con clases.
En un diagrama de clases, cuando se desea incluir una clase en otro paquete se
escribe, en el compartimento correspondiente al nombre de la clase, el nombre del
paquete seguido de dos puntos. Como se muestra en la figura A.6 :
Figura A.6: Citar clase de otro paquete.
3. Herencia
· La herencia se representa con una línea continua que va de la clase hija a la clase
padre, y que termina en un triángulo vacío (Fig. A.7).
Figura A.7: Ejemplo gráfico de herencia.
En el ejemplo anterior la clase Cuadrado es hija de la clase FiguraGeométrica y
hereda todos sus atributos y métodos. En este caso sólo es necesario mostrar los
métodos que se sobrescriben. Es decir, cuadrado sobrescribe el método área, pero no
el método perímetro, aunque tiene ambos métodos.
138
4. Asociación
· Una asociación (relación entre dos clases) se representa como una línea continua
entre dos clases, y puede tener el nombre de la relación sobre esta línea (figura A.8).
Figura A.8: Ejemplo de asociación bidireccional.
En el ejemplo anterior cada Avión tiene una relación con Piloto, pero también cada
Piloto tiene relación con Avión. Esta es una relación en ambos sentidos.
Para mostrar que la relación sólo tiene un sentido se muestra con una flecha que
indica el sentido de la relación (figura A.9).
Figura A.9: Ejemplo de asociación unidireccional.
En este ejemplo un Pasajero conoce el Avión (o aviones) con el cual viaja, pero el
Avión no tiene ninguna relación con los Pasajeros. Para determinar cuántos objetos de
cada clase participan en una relación (multiplicidad), se escribe el rango de la forma:
límiteInferior, límiteSuperior (tabla. A.1).
Tabla A-1: Multiplicidad de una asociación.
· La multiplicidad se muestra en el extremo “destino” de la relación (figura A.10) :
Figura A.10: Ejemplos de multiplicidad de una asociación.
En este caso las relaciones son:
- Un Piloto tiene relación con cero o más aviones.
139
- Un Avión tiene relación con uno, dos o tres pilotos.
- Una Aerolínea tiene relación con cero o muchos aviones.
- Un Avión tiene relación con una Aerolínea.
Aunque estas relaciones se traducirán en atributos en las clases, estos atributos no se
muestran en el diagrama de clases.
5. Interfaces
· Una interfaz se puede representar como una clase. En el primer compartimento del
rectángulo debe ir la palabra “interfaz” encerrada en símbolos de << y >>. En los otros
compartimientos, se trabaja igual que con las clases (figura A.11).
Figura A.11: Ejemplo gráfico de una interfaz.
Para mostrar que una clase implementa una interfaz, se utiliza una línea punteada
desde la clase hacia la interfaz, que termina en un triángulo vacío (figura A.12).
Figura A.12: Ejemplo gráfico implementación de una interfaz.
Diagrama de Interacciones
Las Interacciones modelan aspectos dinámicos de un sistema
Una interacción es un comportamiento que incluye un conjunto de mensajes que
intercambian entre sí un conjunto de objetos dentro de un contexto para lograr un
propósito.
140
Figura A.13: Elementos del diagrama de Interacción/Secuencia.
Los aspectos dinámicos se modelan como flujos de control.
A través del intercambio de mensajes secuenciales sencillos como en la figura A.13, o
Flujos más complejos con bifurcaciones, iteraciones, recursión y concurrencia (figura
A.14). En los flujos más complejos se utilizan operadores de interacción. Los
operadores de interacción se aplican fragmentos del diagrama denominados
Combinedfragment, es decir, fragmentos combinados. Se representan como regiones
rectangulares dentro del diagrama que engloban parte de las interacciones del
diagrama. El tipo de operador se indica en la etiqueta de la esquina superior
izquierda.�El cuerpo del operador (alcance) lo representan las líneas de vida que
abarca.
Message=Mensaje : define una
comunicación particular entre
líneas de vida de una
interacción.
ExecutionSpecification : unidad de
comportamiento dentro de la línea de vida
, cuya duración es representada por Start y
Finish (ExecutionOcurrenceSpecification :
momento de inicio o final de una
ExecutionSpecificacion)
Lifeline = Línea de vida :
representa un objeto como una
línea vertical punteada con un
rectángulo de encabezado y con
rectángulo a través de la línea
principal que denotan la
activación, es decir el período de
tiempo en el cual el objeto se
encuentra desarrollando alguna
operación.
141
Figura A.14: Ejemplo de fragmento combinado con operador LOOP.
Operadores de interacción
Flujo de control
loop – repetir (iterar) un fragmento de interacción
opt – opcional (se ejecuta si se cumple una condición)
alt – selección entre varias alternativas (regiones separadas por líneas discontinuas
horizontales). Existe el “else”.
par – concurrencia (paralelismo entre las regiones definidas)
break – fragmento de ruptura elegido como alternativa al resto de la interacción
Orden
seq – ordenación débil (Secuenciación parcial)
strict – ordenación estricta
critical – fragmento atómico a efectos de validez
Combinedfragment: es
una expresión de
fragmento, definida por
un operador de
interacción y sus
operandos
InteractionOperator:
especifica la operación
definida para el fragmento
combinado.
142
Causalidad
assert – requerido (el fragmento representa una aserción)
neg – “no puede ocurrir” (especificación negativa)
ignore / consider – listas de mensajes a ignorar o a considerar
Diagrama de Estados
El Diagrama de Estados modela el comportamiento de una parte del sistema
El comportamiento es modelado en términos del estado en el cual se encuentra el
objeto, qué acciones se ejecutan en cada estado y cuál es el estado al que transita
después de un determinado evento.
Cada objeto está en un estado en cierto instante y el estado está caracterizado
parcialmente por los valores algunos de los atributos del objeto. El estado en el que se
encuentra un objeto determina su comportamiento. Los diagramas de Estados son
grafos dirigidos y en UML son deterministas. Los estados inicial y final están
diferenciados del resto. La transición entre estados es instantánea y se debe a la
ocurrencia de un evento. Los principales elementos del diagrama de estados son
Estados y Transiciones.
Figura A.15: Diagrama de estados.
Máquina de Estados UML
Una máquina de estados describe el comportamiento de un proceso (clase activa) o
de una operación (a través de un method). La máquina de estados de UML 2 es una
notación gráfica definida para una máquina de estados finitos comunicados. Provee
una vista de la máquina con foco en sus estados. Si su máquina de estados
implementa el comportamiento de una operación, quiere decir que la operación define
la especificación.
A B Evento [condición] / Acción
Estado
State
Transición
Transition
143
La máquina de estados tiene dos elementos principales: State y Transition. Transition
conecta dos State. Siempre hay un State donde está posicionada la máquina de
estados. Este es el State activo. Al comienzo de una ejecución siempre está en el
estado inicial, que en un proceso solo debe ser uno. La máquina de estados ingresa
en otro estado a través de la conexión de una Transition. Desde el State activo se
dispara una Transition originada por un evento.
En este perfil hay cuatro suposiciones respecto de la máquina de estados:
• La máquina de estados es ejecutada secuencialmente.
• Una actividad solo puede ser ejecutada sobre transiciones
• Solo hay un evento externo simple que lee desde la cola de entrada. El próximo
evento externo solo será leído desde la cola de entrada si no hay transición
seleccionable desde el estado activo, el cual es habilitado y disparado (principio de
run-to-completion).
• Las guardas de transición no tienen efectos colaterales.
• Los eventos que no pueden disparar ninguna transición son descartadas
silenciosamente a menos que sean diferidos.
Una máquina de estados parte el procesamiento de eventos en pasos simples. La
semántica del perfil está basada en el hecho de que cada evento es colocado en una
cola de entrada y procesado por turnos. Cada evento es capaz de invocar un trigger
que es procesado por un paso denominado run-to-completion (RTC). Si un paso RTC
está pendiente, es despachado a la máquina de estados después que el paso previo
RTC ha sido completado.
SEMANTICA DE RUN-TO-COMPLETION
La ejecución semántica de una máquina de estados UML contiene una secuencia de
pasos run-to-completion (RTC).En particular, un paso es un cambio desde una
configuración (estado activo, variables, colas) a otro de la máquina de estados. Al
comienzo, la secuencia de pasos comienza en la configuración inicial de la máquina
de estados con variables inicializadas por defecto o valores predefinidos y colas de
signo vacío. Una transición múltiple representa la cadena de transición completa entre
dos estados. En un paso RTC de una configuración, un evento es obtenido desde la
144
cola de entrada de eventos. Estos disparan la selección de un conjunto consistente de
transiciones múltiples habilitadas – salidas desde el estado de la configuración en uso
y sus guardas son satisfechas. Si tal conjunto – paso – existe, todas sus transiciones
múltiples son ejecutadas sucesivamente. En particular, cuando un evento es
despachado ello puede resultar que una o múltiples transiciones son habilitadas
dependiendo de los triggers de las transiciones. Especialmente, solo transiciones que
son disparados por el tipo de evento correspondiente puede ser habilitado. Si no hay
transiciones habilitadas, el evento disparador es silenciosamente descartado sin
ningún efecto por defecto. Para evitar esta pérdida de un evento disparador, un trigger
puede ser especificado como deferred en el estado activo. Por lo cual, el trigger puede
ser procesado más tarde. La máquina de estados selecciona un subconjunto de
transiciones habilitadas y las ejecuta. Esto toma la máquina de estados en una nueva
configuración activa de máquina de estados. Este cambio de configuración de la
máquina de estados se llama un paso.
Nota : Guardas (guard): condición que permite controlar el disparo de una transición.
Región
Una región es una parte ortogonal de una máquina de estados o de un estado
compuesto. Contiene estados y transiciones. Una región habilita la concurrencia
dentro de la especificación de una máquina de estados. Como en este perfil no se
trabaja con concurrencia debe haber solo una «region» dentro de una especificación
de una «stateMachine».
State
Un «state» representa una condición particular en la cual la máquina de estados
espera por un evento. Este evento puede ser un trigger por ejemplo. Una transición
también puede ser interpretada como el resultado de una condición que se evalúa a
true, esta condición específica se llama guarda. Una transición conecta dos estados o
pseudoestados uno con otro, pero con un estado fuente y un estado destino en un
conjunto ordenado. El próximo estado puede ser considerado alcanzable en un
instante, posiblemente sin consumir tiempo del sistema.
145
Transition
Una transición es un link directo entre un estado fuente y uno destino. Una transición
puede ser parte de una transición compuesta. Una transición compuesta representa el
camino completo de todas las transiciones ejecutadas como reacción de la máquina
de estados a la ocurrencia de un evento de un tipo particular.
146
147
Apéndice B
OCL
El ejemplo de la figura B.1 se emplea para explicar los distintos elementos del lenguaje
OCL.
Figura B.1: Ejemplo Diagrama de Clase.
Self
Cada expresión OCL se escribe en el contexto de una instancia de un tipo específico.
En una expresión OCL, la palabra reservada self se usa para referir a la instancia
contextual. Por ejemplo, si el contexto es Company, entonces self se refiere a una
instancia de Company.
Especificando el Contexto UML
El contexto de una expresión OCL dentro de un modelo UML puede ser especificado a
través de una bien llamada declaración de contexto al comienzo de una expresión
OCL. La declaración de contexto de las restricciones se muestra en las siguientes sub
clausulas. La declaración de contexto es opcional.
Invariantes
La expresión OCL puede ser parte de una Invariante la cual es una Constraint
estereotipada como un «invariant». Cuando la invariante está asociada con un
Clasificador, se lo refiere como un “type” en la clausula. Una expresión OCL es un
invariante del tipo y debe ser verdadero para todas las instancias de aquel tipo en
148
cualquier momento. (Todas las expresiones OCL que expresan invariantes son del tipo
Boolean.) Por ejemplo, si el contexto del tipo Company en la Figura B.1, la siguiente
expresión especificaría un invariante en la que el número de empleados siempre debe
exceder 50:
context Company inv:
self.numberOfEmployees > 50
Donde self es una instancia de tipo Company. Esta invariante mantiene para cada
instancia del tipo Company. El tipo de la instancia contextual de una expresión OCL, el
cual es parte de un invariante, está escrito con la palabra clave Context, seguido por el
nombre del tipo. La etiqueta inv: declara la restricción como «invariant».
Context Company inv:
self.numberOfEmployees > 50
En la mayoría de los casos, la palabra reservada self puede ser evitada porque el
contexto es claro. Como alternativa para self, se puede definir un alias en lugar de self.
Por ejemplo:
Context c : Company inv:
c.numberOfEmployees > 50
Esta invariante es equivalente a la anterior. Opcionalmente el nombre de la restricción
puede ser escrito después de la palabra clave inv, que permite a la restricción ser
referenciada por el nombre.
En el siguiente ejemplo el nombre de la restricción es enoughEmployees.
context c : Company inv enoughEmployees:
c.numberOfEmployees > 50
Pre- y Postcondiciones
La expresión OCL puede ser parte de una Precondition o Postcondition,
correspondiente a los estereotipos «precondition» y «postcondition» de una restricción,
asociadas con una Operación u otras características de comportamiento. La instancia
contextual self entonces es una instancia del tipo que posee la operación o método
como una característica. La declaración de contexto en un OCL usa la palabra clave
Context, seguida por el tipo y la declaración de la operación. El estereotipo de la
149
restricción contiene las etiquetas ‘pre:’ y ‘post:’ antes que las Preconditions y
Postconditions reales. Por ejemplo:
Context Typename::operationName(param1 : Type1, ... ): ReturnType
pre : param1 > ... post: result = ...
El nombre self se puede usar en la expresión que refiere al objeto en el cual la
operación fue llamada. La palabra reservada result denota el resultado de la
operación, si existe. Los nombres de los parámetros (param1) se pueden usar en la
expresión OCL. En el diagrama ejemplo, se puede escribir:
Context Person::income(d : Date): Integer
post: result = 5000
Opcionalmente, el nombre de la precondición o postcondición puede ser escrito
después de la palabra clave pre o post, que permite a la restricción ser referenciada
por el nombre. En el siguiente ejemplo el nombre de la precondición es parameterOk
y el nombre de la postcondición es resultOk. En el metamodelo UML, estos nombres
son los valores del atributo name de la metaclase Constraint que es heredada desde el
ModelElement.
Context Typename::operationName(param1 : Type1, ... ): ReturnType
pre parameterOk: param1 > ...
post resultOk : result = ...
Package Context
La declaración de contexto anterior es demasiado precisa cuando el paquete en el
cual el Clasificador incumbe es claro desde el medio ambiente. Para especificar
explícitamente en el cual el paquete es invariante, pre o postcondition. Estas
restricciones pueden ser encerradas entre las sentencias 'package' y 'endpackage'.
Las sentencias package tiene la sintaxis:
Package Package::SubPackage
Context X inv:
... alguna invariante ...
150
Context X::operationName(..)
pre: ... alguna precondición ...
endpackage
Un archivo OCL (o cadena) puede contener cualquier número de sentencias package,
permitiendo así a todas las invariantes, precondiciones, postcondiciones para ser
escritos y almacenados en un archivo. Este archivo puede co-existir con modelo UML
como una entidad separada.
Expresión Operación
Valores Inicial y Derivado
Una expresión OCL puede ser usado para indicar el resultado de una operación de
consulta. Esto puede ser hecho usando la siguiente sintaxis:
Context Typename::operationName(param1 : Type1, ... ): ReturnType
body: -- alguna expresión
La expresión debe ajustarse al tipo de resultado de la operación. Como en las pre y
postcondiciones, los parámetros se pueden usar en la expresión. Las expresiones pre,
postcondiciones, y body se pueden mezclar juntas después de un contexto de
operación. Por ejemplo:
Context Person::getCurrentSpouse() : Person
pre: self.isMarried = true
body: self.mariages->select( m | m.ended = false ).spouse
Una expresión OCL se puede usar para indicar el valor inicial o derivado de un atributo
o un extremo de asociación. Esto puede ser hecho usando la siguiente sintaxis:
Context Typename::attributeName: Type
init: -- una expresión que representa el valor inicial
context Typename::assocRoleName:
Type derive: -- una expresión que representa la regla de derivación
151
La expresión debe ajustarse al tipo del resultado del atributo. En el caso de que el
contexto sea un extremo la expresión debe ajustarse al clasificador en ese extremo
cuando la multiplicidad es a lo sumo uno, o Set, o OrderedSet cuando la multiplicidad
es mayor a uno. Las expresiones Inicial y de derivación pueden ser mezcladas juntas
después de un contexto. Por ejemplo:
Context Person::income : Integer
init: parents.income->sum() * 1% -- dinero de bolsillo
derive: if underAge
then parents.income->sum() * 1% -- dinero de bolsillo
else job.salary – ingresos del trabajo regular
endif
La restricción de derivación debe ser satisfecha en cualquier momento, por lo tanto, la
derivación incluye la inicialización. Los dos se permiten en la misma property pero no
deben ser contradictorios. Por cada property debería haber al menos una restricción
de inicialización y al menos una restricción de derivación.
Otros tipos de Expresiones
Tipos y valores básicos.
Cualquier expresión OCL se puede usar como el valor de un atributo de una Expresión
de metaclase UML o uno de sus subtipos. En OCL, un número de tipos básicos están
predefinidos y disponibles para el modelador en todo momento. Estos tipos de valores
predefinidos son independientes de cualquier modelo de objeto y son parte de la
definición de OCL. El valor más básico en OCL es un valor de uno de los tipos
básicos. Los tipos básicos de OCL, con los ejemplos correspondientes de sus valores,
son mostrados en la tabla B.1. OCL define un número de operaciones sobre los tipos
predefinidos. La tabla da algunos ejemplos de las operaciones en los tipos
predefinidos.
152
Tabla B-1: Tipos OCL básicos y sus valores.
OCL define un número de operaciones sobre los tipos predefinidos. La tabla B.2 da
algunos ejemplos de operaciones en los tipos predefinidos.
Tabla B-2: Ejemplos de operaciones matemáticas en los tipos predefinidos.
Tabla B-3: Ejemplos de operaciones de cadena en los tipos predefinidos.
Collection, Set, Bag, Sequence, y Tuple son tipos básicos también.
Tipos del Modelo UML
Tipo Enumeración
Expresiones Let
Cada expresión OCL está escrito en el contexto de un modelo UML, un número
de clasificadores (tipos/clases,…), sus características y asociaciones, y sus
generalizaciones. Todos los clasificadores del modelo UML son tipos en las
expresiones OCL que están embebidas en el modelo. Las Enumeraciones son
Datatypes en UML y tienen un nombre, como cualquier otro clasificador. Una
enumeración define un número de literales de enumeración que representan
los posibles valores de la enumeración. Dentro de OCL se puede referir al valor
de una enumeración. Cuando se tiene un Datatype denominado Gender en el
153
modelo ejemplo con los valores ‘female’ o ‘male’ que se pueden emplear de
esta manera:
Context Person inv: gender = Gender::male
Algunas veces una sub-expresión es usada más de una vez en una constraint. La
expresión let expression permite definir una variable que puede ser usada en la
restricción.
Context Person inv:
let income : Integer = self.job.salary->sum() in
if isUnemployed then income < 100 else income >= 100 endif
Una expresión puede ser incluida en cualquier clase de expresión OCL. Solo es conocido
dentro de su expresión específica. Una declaración de variables dentro de un let debe tener un
tipo declarado y un valor inicial.
Operaciones adicionales/atributos a través de expresiones «definition»
La expresión Let permite a una variable ser usada en una expresión OCL. Para habilitar el
reúso de variables/operaciones sobre múltiples expresiones OCL se puede usar una restricción
con el estereotipo «definition», en el cual son definidas variables/operaciones auxiliares. Esta
restricción «definition» debe ser atachada a un Clasificador y puede contener solo definiciones
de variables y/o operaciones, nada más. Todas las variables y operaciones definidas en la
restricción «definition» son conocidas en el mismo contexto donde cualquier propiedad del
Clasificador puede ser usada. Tales variables y operaciones son atributos y operaciones con el
estereotipo «OclHelper» del clasificador. Ellos son usados en una expresión OCL exactamente
de la misma manera como se usan atributos y operaciones. La sintaxis de las definiciones del
atributo u operación es similar a la expresión Let, pero cada definición de atributo y operación
son establecidas con la palabra clave ‘def’ como se muestra.
Context Person
def: income : Integer = self.job.salary->sum()
def: nickname : String = ‘Little Red Rooster’
def: hasTitle(t : String) : Boolean = self.job->exists(title = t)
Las operaciones o atributos definidos por "expresiones de definición" pueden ser estáticos
como se muestra en el siguiente ejemplo.
154
Context MyClass
static def : globalId() : Integer = ...
Los nombres de los atributos/operaciones en una expresión let pueden no estar en
conflicto con los nombres de los respectivos atributos/extremos y operaciones del
Clasificador.
Objetos y propiedades
Las expresiones OCL pueden referirse a clasificadores, atributos, fin de asociaciones,
métodos y operaciones (o métodos) de modelos UML. En un diagrama de clases, los
atributos, asociaciones finales, y operaciones (libre de efectos colaterales) son
propiedades dentro de las expresiones OCL.
Cabe mencionar que self hace referencia a un objeto, y “self.propiedad” se relaciona al
valor de una propiedad para self. En el siguiente ejemplo, se muestra cómo el valor de
una propiedad para un objeto se expresa a través de OCL.
Context Person inv:
self.isMarried
La forma de especificar el valor de un atributo en OCL, también es mostrado por medio
de un ejemplo. En este caso, la expresión “self.age” especifica el valor del atributo age
para una instancia de Person. Dicha expresión es expuesta en forma seguida.
Context Person inv:
self.age > 0
A partir de un objeto específico, es posible navegar una asociación de un diagrama de
clases para alcanzar a otros objetos. Esto se logra a partir de las asociaciones finales
de una asociación (el role name), tal como se muestra a continuación,
object.associationEndName
El valor de la expresión previa es el conjunto de objetos que están en el otro extremo
de associationEndName. Si la multiplicidad en el final de la asociación es “0..1” o 1, el
155
resultado de la expresión es un objeto. Pero si la multiplicidad es “*”, el resultado es un
conjunto.
Context Company
inv: self.manager.isUnemployed = false
inv: self.employee->notEmpty()
En el ejemplo que se muestra, “self.manager” devuelve una instancia (un objeto) de la
clase persona ya que la multiplicidad del fin de asociación es uno. En cambio,
“self.employee” devuelve un conjunto, dado que la multiplicidad del fin de asociación
es superior a uno. Por defecto, la navegación a través de una asociación resulta en un
conjunto. Pero si la asociación está adornada con “{ordered}”, entonces resulta en un
conjunto ordenado (OrderedSet). El tipo Collect incluye a los tipos Set, OrderedSet,
Bag y Sequence. Como tipos predefinidos de OCL, tienen asociadas operaciones
predefinidas. Una propiedad de Collect se accede por medio del símbolo “->”, seguido
del nombre de la propiedad; por ejemplo,
Context Person inv:
self.employer->size() < 3
Figura B.2: Uso de operador oclAsType().
Cuando las propiedades se redefinen para un tipo, la propiedad de los supertipos
pueden ser accedida usando la operación oclAsType(). La utilidad de dicha operación
se evidencia en el ejemplo asociado a la figura B.2. La clase ModelElement tiene dos
subclases Note y Dependency. Si se desea acceder al atributo source, desde el
contexto Dependecy (el cual hereda de ModelElement), pueden surgir ambigüedades
que solo son resueltas a través del uso del operador oclAsType(). Esto queda explícito
en la siguiente restricción.
156
Context Dependency
inv: self.oclAsType(Dependency).source->isEmpty()
inv: self.oclAsType(ModelElement).source->isEmpty()
Existen otras operaciones predefinidas que resultan de utilidad. Dos de las más
importantes son oclIsType y oclIsKindOf, cuya sintaxis se muestra a continuación,
oclIsTypeOf(t : OclType):Boolean
oclIsKindOf(t : OclType):Boolean
La operación oclIsTypeOf devuelve true si el tipo del self y “t” es el mismo; y
oclIsKindOf devuelve true si el self y “t” es el mismo o si es igual a su supertipo. En
forma seguida, se ejemplifica la utilización de la primera de dichas operaciones.
Context Person
inv: self.oclIsTypeOf( Person ) -- es verdadero
inv: self.oclIsTypeOf( Company) -- es falso
157
Apéndice C
Métodos y atributos del metamodelo UML utilizados
allInstances (): Para referirse a todas las instancias de un elemento se aplica la
expresión allInstances. Por ejemplo Class.allInstances representa el conjunto de todas
las instancias de una clase, allInstances puede usarse en un elemento a la hora de
evaluar una expresión.
OwnedOperation: Para referirse a operaciones de un elemento ( interface, clase). Las
operaciones se definen por una signatura, es decir, contienen el nombre de la
operación y su parámetro.
Method: Implementa una operación, lo que implica describir su contenido.
Specification: Define las características de comportamiento que el comportamiento
implementa. Una especificación puede tomar distintas formas: actividad, máquina de
estados.
ownedParameter :Describe los parámetros de una operación.
direction: Define la dirección de un parámetro: de retorno, entrada, salida,
entrada/salida.
uml: ParameterDirectionKind: Enumeración que contiene la clase de parámetro al
que se está haciendo referencia: entrada/salida (in/out) o retorno (return). Por ejemplo
para preguntar si la dirección del parámetro de la operación de un objeto llamado
Objeto1 se puede formular:
Objeto1.ownedParameter.direction=uml::ParameterDirectionKind::return
Si el resultado es true la clase de dirección de un parámetro es de retorno
type : Define el tipo de un elemento (Class, Object). Por ejemplo el tipo de una
operación1 con una operación2:
operacion1.ownedParameter.type= operacion2.ownedParameter.type
158
general : Refiere al elemento general (clasificador o clase abstracta) en una relación
de generalization (herencia). Por ejemplo si existe una relación de herencia entre la
clase1 y la clase2 :
clase2.general hace referencia a clase1
isAbstract : Es un atributo de clases y operaciones de tipo booleano que define a un
elemento de tipo abstracto. Por ejemplo si se definió la clase1 como clase abstracta:
clase1.isAbstract devuelve true como resultado
property: Es una característica estructural de un clasificador. Hace referencia a un
atributo de una clase o al extremo de una asociación.
attribute: Referencia a las properties , atributos directos de un clasificador.
Aggregation: Especifica el tipo de agregación del extremo de una asociación: puede
simbolizar una asociación, una agregación o una composición, es decir de tipo none,
aggregate o composite.
uml::AggregationKind: Enumeración que contiene los tipos de agregación existentes
y se usa en el momento de realizar una comparación. Por ejemplo para preguntar si el
tipo de agregación de un extremo de asociación es de tipo composite se puede
formular:
Atributo1.aggregation= uml::AggregationKind::composite si el resultado es true el
tipo de agregación es una composición.
relatedElement: En el caso de conocerse una relación pero no conocer los
elementos relacionados , con este atributo se consulta los elementos relacionados.
ownedStereotype: Referencia los estereotipos de un elemento (por ejemplo los
estereotipos de un paquete).
specification: Define las características de comportamiento que el comportamiento
implementa. Una especificación puede tomar distintas formas: actividad, máquina de
estados.
attribute: Referencia a las properties , atributos directos de un clasificador.
Message.allInstances(): Selecciona las instancias de tipo mensaje.
159
Lifeline.allInstances(): Selecciona todos los objetos tipo lifeline.
MessageSort :Se refiere a la clase de comunicación reflejada por el mensaje.
Tipos de MessageSort: synchCall (sincrónica), asynchCall (asincrónica), asynchSignal
(Señal asincrónica), createMessage (mensaje de creación), deleteMessage (mensaje
de borrado), reply (respuesta).
covered: Referencia una lifeline (línea de vida) a partir de un fragmento de interacción
o de una ocurrencia dentro de una interacción.
represents: Referencia el tipo de una línea de vida , ya que cada línea de vida es de
un tipo de clasificador especifico.
coveredBy: Referencia el fragmento de la interacción dentro del cual se encuentra
una lifeline.
Expresiones del lenguaje ocl utilizadas
Para construir las restricciones sobre los elementos de la arquitectura se emplean
expresiones OCL. A seguir un resumen de dichas expresiones y su significado.
Context: Palabra reservada para indicar el contexto de una instancia particular. En el
caso de las restricciones definidas a continuación los elementos contextuales son
estereotipos que extienden una clase, clasificador, operación o paquete.
self: En una expresión OCL el nombre self indica una instancia del contexto.
oclIsTypeOf (): Devuelvo true si el tipo del objeto evaluado es igual al del argumento.
substring (inferior, superior): Selecciona un conjunto de caracteres de un string. Por
ejemplo el nombre de un elemento desde el carácter inferior hasta el carácter superior.
implies: Establece que si la primera parte de la expresión es verdadera entonces la
segunda parte debe ser verdadera, si la primera parte es falsa, no se conoce el valor
de la segunda parte.
->: Dado un conjunto de instancias, se hace referencia al conjunto a través de este
símbolo.
A partir del símbolo flecha se pueden aplicar las siguientes expresiones al conjunto
160
exists (): Especifica que hay al menos un elemento de que cumple una condición
definida entre paréntesis.
select (): Se obtiene un subconjunto de una colección para los que una expresión es
verdadera.
notEmpty (): El conjunto de elementos no está vacío.
forAll: Especifica una condición que debe ocurrir para todos los elementos de una
colección
161
Apéndice D
Uso de perfiles en Rational Software de IBM
A continuación se describe sintéticamente los pasos para crear un perfil en RSA. El primer paso
es crear un proyecto de tipo perfil UML. Para lo cual se hace click sobre el menú Archivo, y se
selecciona luego Nuevo. Aparece un menú del que se selecciona Otros. A continuación aparece
la pantalla de la figura D.1, se selecciona la carpeta Capacidad de extensión UML y de esa
carpeta Proyecto de perfil UML.
Figura D.1: Creación de proyecto de perfiles.
Se puede escribir el nombre del proyecto como se muestra en la figura D.2 que en nuestro
caso es EjemploPerfil.
162
Figura D.2: Proyecto de perfil UML.
Una vez creado el proyecto se muestra una carpeta sobre el margen izquierdo del
menú y se selecciona la carpeta Perfil dentro de Diagramas. Haciendo click derecho
se selecciona Añadir Diagrama y Diagramade clase.
Figura D.3: Extensión de perfiles.
En el lateral derecho de la pantalla se puede observar la paleta de herramientas.
Figura D.4: Paleta de elementos gráficos.
Haciendo click sobre aparece el conjunto de metaelementos del
metamodelo UML. Se selecciona el metaelemento Class (figura D.4).
163
Figura D.5 : Elementos del metamodelo UML.
Posteriormente se selecciona el elemento al que se le coloca un
nombre, en este caso patternappliedClass. Se selecciona luego el elemento
para dotar al estereotipo de las propiedades de la metaclase. El
resultado puede verse en la figura D.6.
Figura D.6: Ejemplo de perfil.
Una vez elaborado el diagrama , y corregido cualquier error dentro del diagrama se liberar el
perfil. Haciendo click derecho sobre la carpeta que se encuentra en el lateral
izquierdo ( ver figura D.3), aparece un menú donde se selecciona la opción
Figura D.7: Liberación de perfil.
Liberar y en un cuadro de dialogo colocar un nombre de etiqueta del perfil (figura D.7).
164
Figura D.8 : Aplicación de perfiles.
En la definición de la arquitectura se han aplicado perfiles de los niveles 0 y 1, para
realizar esta acción a nuestro perfil ejemplo se clickea dos veces sobre y
aparece una pantalla, donde se selecciona la estiqueta Detalles. Dentro de esa
pantalla hay varios cuadros. Se realiza un click sobre del cuadro Perfiles
Importados y se muestra el cuadro de dialogo de la figura XX. Para escoger un perfil
del espacio de trabajo se selecciona la opción Perfil en espacio de trabajo y luego
.
Al aparecer el cuadro de dialogo de la figura D.9 se selecciona el perfil a importar. En
este caso se elige el PerfilNivel0 y se presiona , con lo que en el cuadro
Perfiles importados ahora aparace dicho perfil.
165
Figura D.9 : Perfil importado.
Si se observa la parte izquierda de la pantalla el ejemplo tiene, después de la importación,
agregados los estereotipos del perfil Nivel 0 (figura D.10).
Figura D.10 : Perfil Nivel 0 aplicado al ejemplo.
