VDMU MorenoDelgado PDF

UNIVERSIDAD DE M
ALAGA
ESCUELA T
ECNICA SUPERIOR DE INGENIER
IA INFORM
ATICA
INGENIER
IA INFORM
ATICA
VERIFICACI
ON DIN
AMICA DE MODELOS UML

Realizado por
ANTONIO MANUEL MORENO DELGADO
Dirigido por
FRANCISCO JAVIER DUR
AN MU
NOZ
Departamento
LENGUAJES Y CIENCIAS DE LA COMPUTACI
ON
M
ALAGA, Septiembre de 2013

UNIVERSIDAD DE M
ALAGA
ESCUELA T
ECNICA SUPERIOR DE INGENIER
IA INFORM
ATICA
INGENIER
IA INFORM
ATICA
Reunido el tribunal examinador en el da de la fecha, constituido por:
Presidente/a D./D
a
.
Secretario/a D./D
a
.
Vocal D./D
a
.
para juzgar el proyecto Fin de Carrera titulado:
Vericacion din amica de modelos UML
del alumno D. Antonio Manuel Moreno Delgado
dirigido por D. Francisco Javier Dur an Mu noz
ACORD
O POR OTORGAR LA CALIFICACI
ON
DE
Y PARA QUE CONSTE, SE EXTIENDE FIRMADA POR LOS COMPARECIENTES
DEL TRIBUNAL, LA PRESENTE DILIGENCIA.
M alaga, a de de 2010
El/La Presidente/a
Fdo.
El/La Secretario/a
Fdo.
El/La Vocal
Fdo.
A mis abuelos. Este trabajo es vuestro. Tanto t u, abuela Angelita, como t u abuelo
Manolo, sembrasteis la semilla de la familia tan bonita que tenemos hoy. Da a da me
inspir ais con vuestra vida ejemplar. Abuelo, ojala alg un da pudiera ser la mitad de buen
docente que eres t u.
A mi madre, que tanto me ense nas con la pasion con la que trabajas. Siempre tengo
presente tu frase si quieres que te ayude en esto, lo hacemos bien, y si no hazlo t u. No
existen abrazos mas verdaderos que los tuyos. Estos estudios son la mejor herencia que
ya me has dejado.
A ella, apareciste en uno de los momentos m as difciles y has sido el GPS capaz de
guiarme por el camino adecuado. Cu antas veces me has obligado a estudiar! Muchas
gracias. Seguiremos llenando nuestros das con momentos felices (y gastando zapatillas de
correr ;-)).
A mis hermanos, Pablo y Javi. Pablo, aunque no aguante m as de un da a tu lado,
cada da que estoy sin ti te echo de menos. Javi, parece que te ha tocado ser mi clon.
Recuerda que a veces los dem as tambien pueden tener raz on, aunque a m tambien se
suele olvidar. No seas tan cabez on como yo ;-).
A mi gua en mi carrera academica (y tambien director) Paco Dur an. Ense nas lo mas
importante: las ganas de aprender. Gracias por haberme dado toda la conanza desde
el primer momento y todos los medios posibles. Ya solo me falta acabar los TO-DOs que
nos hemos dejado por el camino. A Antonio Vallecillo, por haber despertado mi interes
por la investigaci on. A Jose Mara, Ernesto, Manolo Rold an y todos los que colabor ais en
mi formacion.
A mis tos y mis primos. No hay nada como un s abado de comida familiar.
A mi trainer y al deporte en general. Manolo, gracias por los momentos que me has
hecho vivir en el deporte, han sido muchos. Cuando m as vivo me siento es cuando voy
corriendo o en la bici. Los que me conoceis sabeis mi adicci on a las endornas, es mi estilo
de vida. A todos los que me he cruzado y me sigo cruzando gracias al duatlon, no hace
falta que os mencione uno a uno, sabeis quienes sois.
A mi padre, pusiste el germen ingenieril en m. Cuando salta mi peque no espritu
emprendedor, se que es gracias a ti.
A mis compa neros de clase. Habeis ido cambiando pero de todos tengo buen recuerdo.
Quedan muchas cervezas por echar aunque no queden clases a ultima hora de la tarde.
A mis compa neros de piso. De todos vosotros me llevo una experiencia positiva.
A los compa neros del laboratorio y a los atenea, Javi y Loli. Gracias por acogerme
desde el primer momento y de estar dispuestos a ayudarme cada vez que lo necesito.
Indice general
1. Introducci on 1
2. Desarrollo software dirigido por modelos 5
2.1. Principios del DSDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1. Historia del DSDM . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. Fundamentos del modelado . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Niveles del modelado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Metamodelado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4. Transformaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5. Lenguajes de dominio especco . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6. Plataforma Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3. Herramientas y metodos 13
3.1. El lenguaje de restricciones OCL . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1. Por que OCL? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.2. Caractersticas de OCL . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.3. Usos del lenguaje OCL . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.4. Invariantes en OCL . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.5. Especicaci on de operaciones en OCL . . . . . . . . . . . . . . . . 16
3.2. Maude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.1. Tipos, operaciones y variables . . . . . . . . . . . . . . . . . . . . . 18
3.2.2. Modulos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.3. Modulos de sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.4. Core Maude y Full Maude . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.5. Programacion orientados a objetos en Core Maude . . . . . . . . . 27
vii
3.2.6. Programacion orientada a objetos en Full Maude . . . . . . . . . . 30
3.2.7. Metamodelo Maude . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3. El evaluador mOdCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3.1. Tipos b asicos y colecciones . . . . . . . . . . . . . . . . . . . . . . . 34
3.3.2. Estructura del evaluador mOdCL . . . . . . . . . . . . . . . . . . . 36
3.3.3. Invariantes, pre- y poscondiciones en mOdCL . . . . . . . . . . . . 37
3.3.4. Representaci on de la estructura de los sistemas en mOdCL . . . . . 38
3.3.5. Representaci on del comportamiento . . . . . . . . . . . . . . . . . . 40
3.3.6. La pila de ejecucion . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.4. ATL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.4.1. Caso de estudio: FamilyToPerson . . . . . . . . . . . . . . . . . . . 43
3.4.2. Principales estructuras y caractersticas . . . . . . . . . . . . . . . . 44
3.4.3. Otras caractersticas de ATL . . . . . . . . . . . . . . . . . . . . . 48
4. Transformacion 51
4.1. Estructura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.1.1. De diagrama de clases UML a codigo Maude . . . . . . . . . . . . 52
4.2. Comportamiento del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2.1. Necesidad de expresiones OCL . . . . . . . . . . . . . . . . . . . . 56
4.2.2. Esqueleto de transformaci on sin bloques anidados . . . . . . . . . . 56
4.2.3. Casos no generales . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2.4. Bloques anidados: condicionales y bucles . . . . . . . . . . . . . . . 66
4.2.5. Argumentos de las operaciones y variables . . . . . . . . . . . . . . 72
4.3. Conguraciones de objetos: Ejecuci on de ejemplos. . . . . . . . . . . . . . 78
4.4. Detalles tecnicos de la transformacion . . . . . . . . . . . . . . . . . . . . 83
4.4.1. Iniciacion de la transformaci on . . . . . . . . . . . . . . . . . . . . 85
4.4.2. Cuerpo de la transformacion . . . . . . . . . . . . . . . . . . . . . . 89
4.4.3. Finalizacion de la transformaci on . . . . . . . . . . . . . . . . . . . 93
4.5. Transformaci on modelo a texto . . . . . . . . . . . . . . . . . . . . . . . . 97
5. Caso de estudio: RoyalLoyal 99
5.1. Descripci on del caso de estudio . . . . . . . . . . . . . . . . . . . . . . . . 99
5.2. Operaci on enroll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.3. Creaci on de objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.4. Una traza del caso de estudio . . . . . . . . . . . . . . . . . . . . . . . . . 105
6. Caso de estudio: Cinema 109
6.1. Descripci on del caso de estudio . . . . . . . . . . . . . . . . . . . . . . . . 109
6.2. Operaci on goCinema y auxiliares . . . . . . . . . . . . . . . . . . . . . . . 111
6.3. El bloque opt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
6.4. Una traza del caso de estudio . . . . . . . . . . . . . . . . . . . . . . . . . 117
7. Conclusi on 121
7.1. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
7.2. Trabajo relacionado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Bibliografa 125
CAP
ITULO 1
Introducci on
La vericaci on del software ha sido una materia que historicamente ha despertado
el interes de toda la comunidad cientca de la ingeniera software. La gran parte de las
investigacion que se ha hecho y que a da de hoy se hace, es en la comprobacion de los
errores presentes en los programas. Por otro lado, los errores software han producido un
gran n umero de catastrofes econ omicas y personales:
La Mars Climate Orbiter fue una sonda mandada a Marte por la NASA en
los ultimos a nos de los noventa. Tras 9 meses y medio de viaje, un fallo en las
unidades de medida destruyo la nave, al aproximarse demasiado al planeta y entrar
en contacto con la atm osfera de este. El equipo de tierra mandaba las distancias en
unidades anglosajonas mientras que la nave las procesaba y calculaba en el sistema
metrico. Este fallo en la captura de los requisitos y en la especicaci on del sistema
causo una cat astrofe investigadora y econ omica de a nos de trabajo y de 655 millones
de dolares.
El Therac-25 es una m aquina de radioterapia presentada como evoluci on de sus
anteriores Therac-6 y Therac-20 en la decada de los ochenta. Diversos fallos en el
software provocaban una sobredosis de 100 veces la dosis que se deba administrar.
Debido a este fallo 6 personas resultaron heridas y de las cuales 3 murieron como
causa directa la sobredosis del Therac-25. Entre otros, el Therac-25 no haba veri-
cado su c odigo fuente, no consider o la gesti on de errores y no se realizo ninguna
prueba durante su dise no, construccion o puesta en producci on.
En 2010, un error en el sistema software de los frenos de la compa na Toyota,
1
provocaba un retraso en el sistema anti-bloqueo de frenos. Se estima que entre
sustituciones y demandas el error costo 3 billones de dolares.
Se dice que un programa no es correcto cuando su ejecuci on se desva de su espe-
cicaci on pero, y si la especicacion no es correcta? En este sentido la vericacion debe
realizarse en la etapa m as temprana posible del desarrollo software, para prevenir posibles
fallos en la especicaci on y para reducir los costes de los cambios necesarios.
El objetivo del presente proyecto n de carrera es proporcionar mecanismos para
vericar el comportamiento de la especicaci on de un sistema. En particular, se centrar a en
especicaciones UML con restricciones OCL.
Dado un sistema especicado mediante los diferentes diagramas que proporciona UML,
es posible completar dicha especicacion con restricciones formalmente expresadas en
OCL. Una vez que un sistema esta especicado, y se han expresado restricciones sobre
el, es posible realizar la validacion de estas de forma est atica o din amica. As como la
validacion estatica consiste en vericar que un modelo UML verica las propiedades des-
critas por sus invariantes, la validaci on din amica consiste en comprobar que la ejecucion
del mismo no se desva de la especicacion. Se ha hecho mucho esfuerzo en el estudio
de metodos que permitan validar las restricciones de una implementacion en tiempo de
ejecuci on: comprobar las restricciones como una funcionalidad transversal (aspecto) en
programaci on orientada a aspectos, traducir las restricciones a un lenguaje para el que
exista un vericador de estas, etc.
Una vez denidos los modelos que representan el comportamiento del sistema, por
que no vericarlos? Sera interesante tener un enfoque con el cual poder vericar los
errores que pudieran ocasionar la mala especicaci on del comportamiento de un sistema.
Al poder realizar una vericaci on a partir de los modelos que denen el sistema software,
podemos razonar acerca de la especicaci on y de las restricciones impuestas en UML sin
riesgo de que un cambio en la especicaci on suponga un gran coste en el producto nal.
El objetivo principal es poder vericar din amicamente las operaciones denidas a
traves de los diagramas de secuencia UML, habiendo sido denida la parte estatica del
sistema con diagramas de clases y completado con invariantes, pre- y pos-condiciones
descritas en OCL.
Para llevar a cabo este proyecto se ha hecho uso del interprete del lenguaje OCL
(secci on 3.1) mOdCL, desarrollado en el lenguaje Maude (secci on 3.2). Los modelos UML,
en particular diagramas de clases y diagramas de secuencia, se van a desarrollar sobre el
complemento Papyrus de la plataforma Eclipse (secci on 2.6).
2
Captulo 1. Introduccion
Antes de iniciar este proyecto, se tena la posibilidad de denir un sistema en UML y
de vericar din amicamente invariantes, pre- y poscondiciones OCL de un sistema descrito
en Maude con el interprete mOdCL. El trabajo realizado durante este proyecto es
una transformacion que permite de forma automatica traducir un diagrama de secuencia
descrito en UML de forma visual a c odigo Maude ejecutable por este (con ayuda de su
herramienta mOdCL).
Este trabajo ha sido desarrollado siguiendo un enfoque de desarrollo software dirigido
por modelos (captulo 2). En este sentido los diagramas UML han sido tratados como
modelos y la transformaci on realizada crea un modelo Maude, conforme a su meta-modelo,
a partir de los modelos UML, conforme al meta-modelo o superestructura de UML.
Para poder describir la transformaci on se han desarrollado tres ejemplos o casos de
estudio: PersonCar, Fibonacci y RoyalAndLoyal. Adem as se ha modicado y utilizado el
caso de estudio Cinema descrito en [RD11].
Se pueden encontrar los c odigos y todas las im agenes de los casos de estudio en la web
http://maude.lcc.uma.es/mOdCL/.
El captulo 2 introduce la metodologa de desarrollo software dirigido por modelos,
utilizada en este proyecto n de carrera. El captulo 3 enumera las herramientas ya creadas
y utilizadas en este trabajo. El captulo 4 resume las estructuras mas importantes de la
transformaci on realizada como metodo para lograr el objetivo de este proyecto, as como
tambien se describen los casos de estudio PersonCar y Fibonacci. En los captulos 5 y 6
se describen y ejecutan los casos de estudio RoyalAndLoyal y Cinema, respectivamente.
3
4
CAP
ITULO 2
Desarrollo software dirigido por modelos
En este captulo se van a presentar los fundamentos del dise no software dirigido por
modelos (DSDM). El DSDM es una metodologa que propone el uso de modelos como el
principal artefacto en el ciclo de vida de un programa software. Maximizar la compatibili-
dad entre sistemas, simplicar el proceso de dise no y promover la comunicacion entre los
componentes de un equipo de desarrollo son los principales objetivos de esta metodologa.
Este proyecto se ha realizado seg un un enfoque DSDM. Las tecnicas que el DSDM ofrece
han ayudado a la elaboracion de los artefactos necesarios para llevar a cabo el objetivo
planteado.
Este captulo est a dividido en 6 secciones. En la secci on 2.1 se justica la aparicion del
DSDM. En la secci on 2.2 se enumeran los diferentes niveles de modelado, que denen la
abstracci on de las especicaciones del sistema. En la secci on 2.3 se explica el fundamento
del metamodelado y se argumentan los 4 niveles de modelado. En la seccion 2.4 se hace un
recorrido por los principales artefactos del DSDM: las transformaciones. En la secci on 2.5
se hace una breve introduccion a los lenguajes especcos de dominio. Por ultimo se habla
de Eclipse, la plataforma m as popular, que alberga numerosos proyectos que dan soporte
al DSDM, en la seccion 2.6.
5
2.1. Principios del DSDM
2.1. Principios del DSDM
2.1.1. Historia del DSDM
La corriente del DSDM no es nueva. En los a nos 80, se desarrollan las herramientas
CASE (Computer-aided software engineering). El objetivo de estas herramientas era la
disminuci on del tiempo y los costes de la producci on de software, lo cual se pensaba que
sera posible automatizando los procesos. Gracias a la automatizaci on de los procesos, la
calidad y el mantenimiento de los productos incrementara.
El Object Management Group (OMG), fundado en el a no 1989, es un consorcio de
compa nas y organizaciones que se dedica a establecer y promover estandares en las tec-
nologas orientadas a objetos. El OMG se autodene como organismo creado para reducir
la complejidad, bajar los costes y acelerar la introduccion de nuevas aplicaciones softwa-
re [OMG03a].
En noviembre del a no 2000, la OMG hizo p ublica su iniciativa registrando la marca
Model-Driven Architecture (MDA). Esta nueva corriente unicara una larga lista de dife-
rentes enfoques que se haban desarrollado desde la aparici on de las primeras herramientas
CASE.
El MDA no es m as que la vision particular que el OMG tiene del desarrollo dirigido por
modelos (DDM). Por otro lado, el DSDM es un superconjunto de este, ya que mientras el
DDM obliga a realizar software utilizando unicamente tecnicas DDM, el DSDM promulga
el desarrollo software ayudado por los modelos.
2.1.2. Fundamentos del modelado
Los modelos han sido, y son, artefactos de gran importancia en todas las areas de la
ingeniera. Para un ingeniero que dise na un puente, es imposible construirlo sin ning un
modelo previo. Tendr a que realizar, a diferentes niveles, modelos que vayan especicando
propiedades del puente. Para un fsico, el modelo at omico de Bohr es probablemente una
simplicaci on inaceptable, pero para un alumno de secundaria es suciente para entender
las bases del mismo.
Aunque no hay un consenso sobre como deben ser los modelos, una de las descripciones
que podran considerarse como m as acertadas es la de Bran Selic en la que formula que
un modelo debera tener las siguientes funciones [Sel11]:
6
Captulo 2. Desarrollo software dirigido por modelos
Entender el sistema. La estructura, el comportamiento y cualquier caracterstica
relevante. Adem as, debera estar descrito en el nivel apropiado de abstracci on.
Servir como un mecanismo de comunicaci on. Entre organizaciones y entre
stakeholders.
Validar el sistema y su dise no. Detectar errores, razonar sobre el sistema, etc.
Guiar la implementaci on. Servir como un mapa a la hora de desarrollar el
software.
Independientemente de la denici on que se quiera tomar, un modelo no debe ser solo
considerado como mera documentacion, sino como artefactos claves a partir de los cuales
el sistema ser a derivado e implementado.
Por ultimo, destacar algunos mensajes que han aparecido durante la ultima decada
acerca de esta metodologa en auge. Como el de Jean Bezivin [Bez05] todo es un modelo,
que adapta la maxima de la orientacion a objetos todo es un objeto, que buscaba la
simplicidad, genericidad y capacidad de integracion. Por otro lado, debido al nivel de
abstracci on podramos modernizar la frase Escribe una vez, ejecuta donde quieras
con Modela una vez, genera donde quieras, para as rearmar la independencia del
dise no respecto a la plataforma donde se implantara.
2.2. Niveles del modelado
Los niveles de abstraccion de los modelos pueden variar dependiendo de los objetivos
con los que se hayan especicado. En MDA, la OMG especica tres niveles de abstracci on
denidos:
Computation-Independent Model (CIM). El nivel m as abstracto que representa el
contexto, los requisitos y el proposito de la soluci on sin asumir nada acerca de las
implicaciones software que tendra. Es el modelo de negocio, descrito en un lenguaje
del dominio del problema.
Platform-Independent Model (PIM). Este nivel describe el comportamiento y la
estructura de la aplicaci on, independientemente de la plataforma
1
donde se vaya a
implementar. Debe realizarse con un nivel de independencia suciente que permita
desplegarlo en una o mas plataformas concretas.
1
Plataforma: Conjunto de subsistemas y tecnologas que proporcionan una serie de funcionalidades
para lograr un determinado objetivo [OMG03b].
7
2.3. Metamodelado
Platform-Specic Model (PSM). Este modelo debe contener toda la informaci on
sobre el comportamiento y la estructura necesaria para que un desarrollador pueda
implementar la aplicacion en una plataforma especca.
La especializaci on de los modelos en cada paso, desde el m as abstracto (CIM) hasta el
m as concreto (PSM) se realiza mediante transformaciones de modelos como se ver a en la
secci on 2.4.
2.3. Metamodelado
Para describir lenguajes de modelado se ha denido una tecnica llamada metamode-
lado. En el metamodelado, los lenguajes de modelado se consideran como otra categora
cualquiera de sistemas y emplean otros lenguajes de modelado para describirlos: los len-
guajes de metamodelado.
Un metamodelo es un modelo que especica a un nivel superior de abstraccion, los
conceptos de un lenguaje de modelado y las relaciones entre ellos. Un concepto es todo
aquello concreto o abstracto que resulte de interes y tenga un prop osito especco en el
sistema que se est a modelando.
En el sentido practico, los metamodelos b asicamente proporcionan una forma de des-
cribir un conjunto de modelos que pueden ser representados por el lenguaje de metamo-
delado [BCW12]. De esta forma, mientras que un modelo dene la realidad (el sistema),
los metamodelos describen los modelos, y as se podra seguir el proceso recursivamente
(el siguiente paso sera meta-metamodelos, etc.). Aunque de forma te orica se podran re-
presentar innitos niveles de metamodelado, en la pr actica no tiene sentido ir mas alla del
nivel de abstraccion que proporcionan los meta-metamodelos.
En la gura 2.1(a)
2
se muestran los diferentes niveles propuestos por el OMG. En
primer lugar, el nivel b asico M0 muestra los objetos del sistema real. En el nivel M1, el
modelo, se representan los conceptos de los objetos del nivel inmediatamente inferior. En
el ejemplo de la gura 2.1(b)
3
, si en el nivel M0 se tiene una pelcula, en el nivel M1 se
representa el concepto Video, con el atributo title. En el nivel M2, el metamodelo describe
los conceptos del lenguaje utilizado en el nivel M1. Para nuestro ejemplo, existiran los
conceptos Class y Attribute. Por ultimo, el nivel M3 dene las caractersticas del meta-
metamodelo. En nuestro ejemplo solo se dene el concepto Class y muestra por que no
2
Imagen obtenida de [Bez05].
3
Imagen obtenida de [BCW12].
8
(a) Modelos, metamodelos y
meta-metamodelos.
(b) Ejemplo de modelado.
Figura 2.1: Niveles de abstracci on.
tiene sentido denir mas niveles mas alla del M3, ya que cualquier nivel superior tendra
unicamente el concepto Class.
9
2.4. Transformaciones
2.4. Transformaciones
Como se ha mencionado en la seccion 2.1.2, los modelos son el artefacto fundamental
en el DSDM. Por lo tanto, el desarrollo de tecnicas que permiten manipular los modelos
han adquirido gran importancia en el DSDM. Una de estas tecnicas son las transfor-
maciones de modelos, o MT (model transformations). Una transformaci on permite la
correspondencia (en ingles mapping) entre dos modelos diferentes, el fuente y el destino. El
DSDM proporciona lenguajes (declarativos, imperativos o hbridos) que permiten denir
estas MTs. La estructura fundamental en las MTs es la regla de transformacion.
Las transformaciones se denen al nivel de los metamodelos, pero se aplica sobre los
modelos que son conforme a estos metamodelos. En la gura 2.2, Czarnecki y Helen [CH06]
ilustran la arquitectura en las MTs. Observese como, en la gura 2.2, de forma gr aca se
representa el concepto de denici on de las transformaciones a nivel de metamodelos y su
posterior ejecucion a nivel de modelos.
Figura 2.2: Arquitectura de la transformacion de modelos.
Una vez introducidas las transformaciones y repasando la famosa ecuaci on de Niklaus
Wirth:
Algoritmos + Estructuras de datos = Programas
La cual puede ser adaptada al contexto del DSDM de la siguiente forma:
Modelos + Transformaciones = Software
Por ultimo, existen diferentes tipos de transformaciones:
Seg un el metamodelo fuente y destino:
In-place El metamodelo fuente es el mismo que el de destino.
Out-place El metamodelo fuente es distinto que el de destino.
10
Seg un el modelo fuente y destino:
Endogena El modelo fuente es modicado (reescrito) obteniendo el modelo
de destino. Tambien se puede denominar transformaci on de grafos.
Exogena El modelo fuente es ledo, mientras que el destino es creado a partir
de este.
Seg un la direccionalidad:
Unidireccional Las reglas se ejecutan en un sentido denido. Es decir, hay
un modelo de entrada y uno de salida.
Bidireccional Las reglas pueden ser ejecutadas en ambos sentidos. Ambos
modelos son de entrada y de salida.
Algunos ejemplos de lenguajes de transformacion de modelos son QVT, ATL, RubyTL,
ETL, e-Motions, etc.
2.5. Lenguajes de dominio especco
Dentro del DSDM, se ha hecho hincapie en la importancia de especicar los sistemas
a un nivel de abstraccion adecuado. La especicacion precisa de un sistema, en el nivel
de abstraccion adecuado, puede ser lograda con un lenguaje de dominio especco.
Los lenguajes de dominio especco, Domain-Specic Languages (DSLs), son lenguajes
dise nados y/o desarrollados para solventar las necesidades de un dominio concreto de
aplicaci on. Un DSL proporciona los conceptos, notaciones y mecanismos propios para
facilitar la especicaci on de un sistema a los expertos del dominio. Un ejemplo tpico de
DSL es SQL, un lenguaje que permite realizar operaciones en una base de datos relacional.
Un DSL debe ser lo sucientemente simple para que un experto en el dominio concreto
que se desea abarcar pueda manejarlo, y a la vez lo sucientemente preciso para que
pueda ser ejecutable. Los modelos de sistemas generados por DSLs son posteriormente
transformados a artefactos software que puedan ser ejecutados en las plataformas destino.
Como un subconjunto de los DSLs, aparecen dos terminos nuevos: lenguajes de mo-
delado de dominio especco, Domain-Specic Modeling Languages (DSMLs) y lenguajes
visuales de dominio especco, Domain-Specic Visual Languages (DSVLs).
11
2.6. Plataforma Eclipse
2.6. Plataforma Eclipse
Eclipse es una plataforma de software libre que alberga numerosos proyectos. Entre
ellos esta el proyecto Eclipse Modeling Framework (EMF) [Fou], que es la base del DSDM
en Eclipse. EMF es un buen representante de la metodologa de DSDM por varias razones.
EMF permite la denicion de sus propios metamodelos utilizando el lenguaje Ecore, y a
partir de esta denicion es posible traducci on desde Ecore a Java, por ejemplo. Adem as,
EMF proporciona diversas funciones para manipular modelos, tales como serializaci on/-
deserializaci on, editores en arbol, etc. Este proyecto esta desarrollado por completo sobre
la plataforma Eclipse.
En el captulo 3 se presentar an los complementos necesarios a lo largo del desarrollo
de este proyecto. En concreto, realizamos transformaciones de modelo a modelo con el
lenguaje ATL, transformaciones de modelo a texto con el lenguaje Acceleo y ejecuciones en
el interprete Maude. Estas tres principales herramientas tienen soporte directo en Eclipse.
Adem as, para la representacion de los diagramas de clases y de secuencia en Eclipse, se
hace uso de la herramienta Papyrus. Papyrus es un complemento que se ejecuta sobre la
plataforma Eclipse.
En la secci on 4.5 se describe la herramienta Acceleo. Acceleo es un complemento que
permite ejecutar el DSL Acceleo sobre Eclipse. El DSL Acceleo es usado para realizar la
transformaci on de modelo a texto de modelos conforme al metamodelo Maude.
12
CAP
ITULO 3
Herramientas y metodos
En este captulo se van a explicar las herramientas utilizadas en la realizaci on del
presente proyecto n de carrera. Cada una de las cuatro secciones que contiene este
captulo describen las principales cuatro herramientas usadas durante este proyecto n
de carrera. En primer lugar, en la secci on 3.1 se detalla el lenguaje de restricciones de
objetos OCl, en el cual se basa el trabajo que en esta memoria se expone. En la secci on 3.2
se describen los principales conceptos del lenguaje de reescritura l ogica Maude, en el que
est a implementado el evaluador de expresiones mOdCL, cuyo funcionamiento y estructura
se desarrolla en la seccion 3.3. Por ultimo, en la secci on 3.4 se describe el lenguaje de
transformaci on de modelos ATL.
3.1. El lenguaje de restricciones OCL
OCL (Object Constraint Language) es un lenguaje textual, con base formal, que per-
mite denir expresiones sobre modelos (denidos en UML o Ecore).
3.1.1. Por que OCL?
Para que un modelo sea preciso, no puede permitir ning un tipo de ambig uedad en la
especicaci on del mismo. Ademas, todos los usuarios nales del modelo, deben hacer la
misma interpretaci on del mismo (incluido programas).
Hasta la aparicion de OCL, un modelo UML (o Ecore) no contena todos los aspectos
relevantes que se necesitaba. Para poder completarlos, era necesario denir restricciones,
13
que se hacan en un lenguaje natural. Por otro lado, uno de los objetivos del modelado en
el DSDM, es tener modelos totalmente precisos ya que, por ejemplo, todos los usuarios
nales de estos deben interpretarlos de la misma forma. Para evitar la ambig uedad que
se produce al denir restricciones en lenguaje natural, se han denido lenguajes formales
como OCL.
3.1.2. Caractersticas de OCL
OCL esta denido como un lenguaje de especicacion puro, por lo tanto, se ga-
rantiza que una expresi on OCL no tiene efectos laterales. Esto es, una expresion OCL
solo devuelve un valor. Cuando una expresi on se eval ua no se produce ning un cambio en
el modelo, incluso si la expresi on es utilizada para especicar un cambio en el (en una
poscondici on). Como lenguaje de especicacion, no se permite describir la logica de un
programa o el control de ujo en OCL. Es un lenguaje de modelado y las expresiones
escritas en el no son por denicion ejecutables directamente (como en un lenguaje de
programaci on).
OCL es un lenguaje fuertemente tipado. Es decir, toda expresion OCL tiene un
tipo. El conjunto de tipos de OCL se corresponde con el de UML. Los tipos basicos son:
Integer, Boolean, Real y String. Y los tipos enumerados: Set(T), OrderedSet(T), Sequence(T)
y Bag(T). En la gura 3.1 se representa la jerarqua de tipos de OCL.
Figura 3.1: Jerarqua de tipos de OCL [BCP12].
Por ultimo, otra caracterstica de OCL est a relacionada con la evaluaci on de expresio-
nes. La evaluaci on de una expresi on OCL se supone instantanea, es decir, los estados de
un modelo no pueden cambiar mientras se eval ua una expresion.
3.1.3. Usos del lenguaje OCL
Los principales usos para los que se denio el lenguaje OCL incluyen:
14
Captulo 3. Herramientas y metodos
Como lenguaje de consulta sobre modelos.
Para especicar invariantes y restricciones sobre tipos y clases denidos en un mo-
delo.
Para especicar pre- y poscondiciones en operaciones y metodos.
Para describir guardas.
Para especicar destinatarios (o conjunto de destinatarios) en mensajes y acciones.
Para especicar restricciones en operaciones.
3.1.4. Invariantes en OCL
Ejemplo En la gura 3.2 se muestra el metamodelo del ejemplo (ejemplo tomado
de [Fou]) que se va a seguir durante esta secci on para mostrar las principales estruc-
turas de OCL. El ejemplo consiste en el modelado de una biblioteca. En el metamodelo
de la gura 3.2 se muestran 4 clases que modelan la biblioteca (Library), los libros (Book),
los prestamos (Loan) y los miembros (Member).
Figura 3.2: Metamodelo de una biblioteca.
Una restricci on de integridad, o tambien denominado invariante, expresa las condicio-
nes que debe cumplir un modelo que representa un sistema valido. Un invariante se dene
de la siguiente forma:
context Library inv: self.books->size() >= 0
15
El context de la expresi on indica a la clase que hace uso de dicha expresi on, es decir, todos
los objetos del tipo Library hacen uso de ella. Para referirse a la instancia concreta que
est a haciendo uso de la expresi on, se utiliza self. La palabra reservada inv introduce una
expresi on booleana que debe cumplir el modelo para ser considerado v alido.
La expresi on anterior no es necesaria, ya que la expresividad que ofrece el diagrama de
clases Ecore de la gura 3.2 ofrece esa restricci on: un objeto de la clase Library puede tener
0..* libros, es decir, un n umero positivo de libros. Sin embargo, podra darse el caso de
que un diagrama de clases no expresara invariantes que seran deseables para los modelos
creados. Por ejemplo, no sera valido un libro que contenga un n umero de copias negativo:
context Book inv PositiveCopies: self.copies >= 0
C odigo 3.1: Invariante PositiveCopies.
Es posible a nadir un nombre a los invariantes a nadiendolo tras la palabra reservada inv.
Otros invariantes m as interesantes se muestran a continuacion:
context Member inv MaxTwoLoans: self.loans->size() <= 2
context Book inv SufficientCopies: self.loans->size() <= copies
El primero limita el n umero de prestamos a dos por usuario y el ultimo impide realizar
m as prestamos que copias existan del libro. Esto ultimo es imposible en un escenario real.
3.1.5. Especicacion de operaciones en OCL
Una de las formas mas usuales para especicar operaciones asociadas a una clase de un
metamodelo es mediante pre- y poscondiciones OCL. El prop osito de una precondici on es
establecer los requisitos que se tienen que satisfacer para poder ejecutar correctamente una
operaci on. Una poscondicion especica las condiciones que deben satisfacerse despues de
la ejecucion de la operaci on. El uso de invariantes, pre- y poscondiciones es muy habitual
en informatica, bajo el nombre de Dise no por contrato.
Tanto una pre- como una poscondici on determina que hace una operacion, pero no
c omo lo hace. Detallar la implementaci on de la operaci on no es deseable en un modelo a
este nivel de abstracci on (vease secci on 2.2).
Una precondici on se indica con la palabra reservada pre y una poscondicion con post.
La palabra result representa la variable donde se almacena el resultado de una operacion
que devuelve un valor.
16
Por otro lado, es posible denir el comportamiento de una operaci on solo especicando
el cuerpo de esta, introducido por la palabra body. Un ejemplo de operacion es el siguiente:
context Book::isAvailable() : Boolean
body: self.loans->size() < copies
Un ejemplo de especicaci on de una operaci on es la que se realiza a continuaci on en
el codigo 3.2:
context Member::loanBook(b : Book) : Boolean
pre: self.loans->size() < 2 and b.isAvailable()
post: result = self.loans->any(l | l.book = b)
and self.loans@pre->size() = self.loans->size() - 1
C odigo 3.2: Operaci on loanBook(Book) con pre- y poscondiciones.
Para la clase Member se especica la operaci on loanBook(Book): por medio de pre- y pos-
condiciones se describe el proceso de hacer un prestamo. Con la palabra reservada pre
se introduce la precondici on. Para este ejemplo, un prestamo puede ser llevado a cabo si
el usuario tiene menos de 2 prestamos en curso y adem as el libro sobre el que se quiere
realizar el prestamo esta disponible. Como resultado (introducido con la palabra result)
se tiene un valor booleano que ser a verdadero cuando la operacion haya tenido exito. Por
otro lado se realiza la comprobaci on de que el prestamo Loan haya sido a nadido a la lista
de prestamos del Member. La palabra reservada @pre, precedida de una variable, hace re-
ferencia al valor de esta variable en el momento de evaluar la precondici on.
Para m as informaci on vease [WK03].
3.2. Maude
En nuestro proyecto, Maude se usa como entorno de programacion de la herramienta
mOdCL, explicada en la secci on 3.3. Maude ha demostrado ser un lenguaje apropiado
para la especicaci on algebraica de sistemas. Por esta razon, Maude es elegido como un
buen lenguaje donde, con ayuda de la herramienta mOdCL, vericar las restricciones
(invariantes, pre- y poscondiciones) sobre la especicaci on din amica de un sistema.
Maude es un lenguaje reexivo
1
de alto nivel. Por un lado, se combina el paradigma
1
Capacidad de un lenguaje de observar y modicar su estructura y comportamiento en tiempo de
ejecucion.
17
3.2. Maude
funcional con un estilo ecuacional, y por otro lado, la logica de reescritura. Adem as, Maude
soporta la especicaci on y programaci on de un gran abanico de aplicaciones [CDE
+
07].
En la secci on 3.2.1 se presentar an los tipos, operaciones y variables. En la seccion 3.2.2
se presentaran los m odulos funcionales en Maude, as como las ecuaciones y axiomas de
pertenencia. En la seccion 3.2.3 se presentaran los m odulos de sistema y las reglas de
reescritura. Por ultimo en la seccion 3.2.4 se resume las diferencias entre Core Maude y
Full Maude.
3.2.1. Tipos, operaciones y variables
Tipos, subtipos y kinds
Lo primero que se necesita en una especicaci on es declarar los tipos. Un tipo (sort)
es declarado en Maude con la palabra reservada sort (o sorts en caso de denir m as de un
tipo en la misma declaracion) seguido del nombre del tipo.
Adem as de los tipos, es posible denir una relaci on de subtipado subsort. La relacion
de subtipado hace un paralelismo entre los conjuntos y subconjuntos y los sorts y los
subsorts. En el c odigo 3.3 se declaran el tipo zero (tipo cero), Nat (naturales) y NzNat
(naturales positivos). La sem antica del codigo representa la inclusion del conjunto de los
naturales positivos NzNat en el conjunto de los naturales: N {0} N.
1 sort Zero .
2 sorts Nat NzNat .
3 subsort NzNat < Nat .
4 subsort Zero < Nat .
5 subsorts Zero NzNat < Nat .
C odigo 3.3: Ejemplo sorts, subsorts y kinds.
La lnea 5 del c odigo 3.3 representa una forma m as compacta lo expresado en las lneas
3 y 4.
Como la logica ecuacional que soporta Maude es la logica ecuacional de pertenencia,
los tipos son agrupados en clases de equivalencia denominadas en Maude kinds. Con
este proposito, dos tipos est an en el mismo kind si y solo si corresponden a la misma
componente conexa. Los tipos son denidos por el usuario, mientras que los kinds son
implcitamente asociados con componentes conexas de los tipos (en la secci on 3.2.2 se
muestra un ejemplo). Los kinds en Maude aparecen entre corchetes [].
18
Operaciones
Para mostrar la sintaxis y sem antica de las operaciones con m as facilidad, se va a
utilizar el c odigo 3.4, donde se especican los naturales con los axiomas de Peano. Peano
dene los n umeros naturales como sigue:
El 0 es un n umero natural
2
.
Si n es un n umero natural, se dene la funci on sucesor s. El sucesor de n es tambien
un natural.
Con los axiomas anteriores, para denir el n umero 3 se expresara como s(s(s(0))).
En Maude, para denir una operaci on se utiliza la sintaxis:
op NombreOperacion : Sort-1 Sort-k > Sort .
Cuando la lista de tipos del argumento esta vaca, se denomina constante. Por consiguiente,
en la lnea 2 del codigo 3.4, 0 es una constante. Para denir la funcion sucesor, en la lnea 3
se declara el operador s con un argumento. De esta forma queda especicado el tipo Nat.
Para especicar la operacion suma se declara el operador + con dos argumentos de
tipo Nat. El subrayado ( ) en el nombre de los operadores tiene un signicado especial. Si
el nombre del operador no contiene ning un subrayado se utiliza la notaci on preja para
esa operaci on. En cambio, cuando aparecen subrayados se usa la notacion inja para esa
operaci on (o mixx en terminologa Maude) y el subrayado n-esimo indica el lugar donde
debe aparecer el argumento de tipo n-esimo en la lista de argumentos de la operaci on.
Adem as, en caso de que la operaci on sea mixx, deben existir tantos subrayados como
n umero de tipos declarados como argumentos de la operaci on.
Variables
La declaracion de variables se realiza con la palabra reservada var (o vars para denir
variables del mismo tipo). La sintaxis es la siguiente:
var NombreVariable : SortVariable .
En el c odigo 3.4 se denen las variables N y M en la lnea 4.
2
El debate sobre considerar el 0 un n umero natural o no esta fuera del alcance de este ejemplo.
19
3.2. Maude
1 sort Nat .
2 op 0 : -> Nat .
3 op s : Nat -> Nat .
4 vars N M : Nat .
C odigo 3.4: Especicaci on de los naturales.
3.2.2. Modulos funcionales
Un m odulo funcional dene los tipos de datos y sus operaciones mediante teoras
ecuacionales. Un modulo ecuacional Maude tiene tipos, kinds, operadores, ecuaciones y
axiomas de pertenencia. Se asume que un modulo funcional Maude tiene las siguientes
tres propiedades:
El modulo es Church-Rosser, o tambien conuente
3
. Un m odulo cumple la propie-
dad de conuencia si: Sea a, b y c S, si a
b y a
c, entonces existe d S
tal que b
d y c
d.
El m odulo es terminante. Tras un n umero n de pasos, se deben obtener las formas
can onicas de los terminos.
El modulo es ecuacionalmente simplicante de izquierda a derecha. Es decir,
dado una regla de la forma l = r (o tambien l = r if cond) la parte izquierda r no
puede contener variables libres que no aparezca en l (o l y cond). Esta propiedad se
comprueba en sintacticamente en Maude.
La l ogica ecuacional en la que los m odulos funcionales de Maude est an basados es
la logica ecuacional con pertenencia. Por consiguiente, los m odulos funcionales soportan
diferentes tipos, relaciones con subtipos, sobrecarga de operadores y axiomas de perte-
nencia.
3
En realidad, ser Church-Rosser signica ser conuente y sort decreasing.
20
1 fmod NAT-PEANO is
2 sort Nat .
3 op 0 : -> Nat .
5 op _+_ : Nat Nat -> Nat .
6 vars N M : Nat .
7 eq 0 + N = N .
8 eq s(N) + M = s(N + M) .
9 endfm
C odigo 3.5: M odulo funcional con los naturales de Peano.
En el c odigo 3.5 se muestra un modulo funcional, rodeado por las palabras reserva-
das fmod y endfm. Dicho modulo especica los naturales con la operaci on suma.
Las ecuaciones se introducen con la palabra reservada eq. Su sintaxis es la siguiente:
eq TerminoIzquierdo = TerminoDerecho .
Toda ecuaci on tiene una parte izquierda y una parte derecha, separada por el smbolo =.
Ambos terminos tienen que ser del mismo kind. En la parte derecha no pueden aparecer
variables que no hayan aparecido en la parte izquierda. Dada una ecuacion y un termino t,
se intenta unicar con la parte izquierda de la ecuaci on y se sustituye por la parte derecha,
generando el termino t. Ademas, tambien se pueden denir las ecuaciones condicionales,
que tienen la sintaxis:
eq TerminoIzquierdo = TerminoDerecho if Condicion .
En las ecuaciones condicionales, las variables de la parte derecha tienen que aparecer en
la parte izquierda (como en las ecuaciones normales) o en la condici on. En el ejemplo 3.6
se hara uso de las ecuaciones condicionales.
Ejemplo En el m odulo descrito en el codigo 3.5 reducimos el termino s(s(s(0))) + s(s(0)),
que representa a la operacion 3 + 2. Para ello, en la consola Maude, una vez cargado el
m odulo NAT-PEANO se introduce:
reduce in NAT-PEANO : s(s(s(0))) + s(s(0)) .
Y se obtiene como resultado:
rewrites: 4 in 1555827116ms cpu (0ms real) (0 rewrites/second)
result Nat: s(s(s(s(s(0)))))
Si adem as se visualiza la traza (con el comando show trace on), se puede observar la
21
3.2. Maude
forma de reescribir el termino que se ha introducido:
*********** equation
eq s(M) + N = s(M + N) .
M --> s(s(0))
N --> s(s(0))
s(s(s(0))) + s(s(0))
--->
s(s(s(0)) + s(s(0)))
Se puede observar como, dado el termino introducido, y dada la ecuacion de la lnea 8
del c odigo 3.5 se sustituye la variable M con s(s(0)) (la primera s no se sustituye, ya que
pertenece al patron) y N con s(s(0)), obteniendose s(s(s(0)) + s(s(0)))
4
. Si consideramos
que el termino es de la forma sum1+sum2, el sumando sum1 se va reduciendo hasta que
en el ultimo paso se llega a la siguiente reescritura
*********** equation
eq 0 + N = N .
N --> s(s(0))
0 + s(s(0))
--->
s(s(0))
Una de las ventajas de la especicacion mediante ecuaciones y su similitud con la
notaci on matematica es la facilidad de realizar, por ejemplo, demostraciones por induc-
ci on sobre la especicaci on. En este caso se puede hacer en pocos pasos, por ejemplo, la
demostraci on de que la suma seg un especicaci on del c odigo 3.5 es conmutativa.
Axiomas de pertenencia
Al principio de la seccion se ha mencionado que la logica que soporta Maude es la
logica ecuacional con pertenencia. En los modulos funcionales se permiten axiomas de
pertenencia, memberships. Un axioma de pertenencia especica que ciertos terminos
pertenecen a un tipo dado. La sint axis es la siguiente:
mb Termino : Tipo .
Al igual que para las ecuaciones, existen los axiomas de pertenencia condicionales, a nadien-
do if expresion detr as del tipo. Para mostrar su funcionamiento, podemos ampliar el
ejemplo introducido en el c odigo 3.5 como sigue:
4
Observese que en esta operacion el primer parentesis engloba a todo.
22
1 fmod NAT-PEANO is
2 pr BOOL .
3 sorts NzNat Nat .
4 subsort NzNat < Nat .
5 op 0 : -> Nat .
7 op _+_ : Nat Nat -> Nat .
8 op sd : Nat Nat -> Nat .
9 op _/_ : Nat NzNat -> Nat .
10 op _>=_ : Nat Nat -> Bool .
11
12 vars N M : Nat .
13 var NZ : NzNat .
14
15 mb s(N) : NzNat .
16 eq 0 + N = N .
17
18 eq s(N) + M = s(N + M) .
19 eq sd(0, N) = 0 .
20 eq sd(N, 0) = N .
21 eq sd(s(N), s(M)) = sd(N, M) .
22 eq N >= 0 = true .
23 eq 0 >= s(N) = false .
24 eq s(N) >= s(M) = N >= M .
25
26 ceq N / NZ = 0
27 if not N >= NZ .
28 ceq N / NZ = s(0) + (sd(N, NZ) / NZ)
29 if N >= NZ .
30 endfm
C odigo 3.6: Axiomas de pertenencia.
En el c odigo 3.6 se muestra el codigo del modulo NAT-PEANO ya presentado pero con
tres operaciones adicionales: la diferencia simetrica sd, la operaci on de orden mayor-igual
>= y la divisi on / . La divisi on con denominador 0 no est a denida, por lo que se
ha denido un nuevo tipo NzNat que contendr a los naturales distintos de cero N {0}.
Observese el segundo argumento, de tipo NzNat, en la denici on de la operacion divisi on
en la lnea 9. En la lnea 15, se especica el axioma de pertenencia, donde se expresa que
cualquier termino de la forma s(N), siendo N un natural, es de tipo NzNat.
En la especicaci on de la operaci on divisi on se utilizan las ecuaciones condicionales
que han sido introducidas en esta secci on.
Los axiomas de pertenencia permiten denir y especicar operaciones de una forma
sencilla y expresiva, sin tener que a nadir condiciones para los valores no soportados por
la especicaci on. En el ejemplo no se ha necesitado a nadir ninguna condicion del tipo
denominador mayor que cero.
23
3.2. Maude
Cuando un termino es erroneo, simplemente es elevado al kind. Los kinds son muy
utiles para denir operaciones parciales. Es decir, una operacion en el que un parametro
es de un par ametro subtipado (como, por ejemplo, en el c odigo 3.6 el tipo NzNat).
Ejemplo En el modulo NAT-PEANO introducimos dos terminos, uno correcto y otro, no
v alido, que quedar a en el kind.
Maude> red in NAT-PEANO : s(s(s(s(0)))) / s(s(s(0))) .
reduce in NAT-PEANO : s(s(s(s(0)))) / s(s(s(0))) .
result NzNat: s(0)
Se observa como el valor devuelto pertenece al tipo NzNat, al ser mayor que 0.
Maude> red in NAT-PEANO : s(s(s(0))) / 0 .
reduce in NAT-PEANO : s(s(s(0))) / 0 .
result [Nat]: s(s(s(0))) / 0
En este caso, al estar especicada la operaci on divisi on para un numerador de tipo NzNat,
el termino es elevado al kind. Este es el motivo de que las clases o kinds son denominadas
supertipos de error. La potencia de los kinds permite elevar terminos incorrectos sin
tener que hacer un control de errores explcito.
3.2.3. Modulos de sistema
En esta secci on se van a presentar los modulos de sistema de Maude. Un modulo de
sistema Maude especica una teora de reescritura. Una teora de reescritura tiene tipos,
kinds, operadores, ecuaciones, axiomas de pertenencia y reglas. Por lo tanto, adem as de
lo presentado en la secci on 3.2.2 ahora se permiten las reglas (y reglas condicionadas).
En un modulo de sistema no se asumen las propiedades enunciadas para los modulos
funcionales (conuencia, terminacion, simplicaci on ecuacional y sort-decreasingness).
Un m odulo de sistema es declarado en Maude con las palabras reservadas mod y endm.
Un modulo de sistema admite la importaci on de m odulos, declaracion de tipos, de opera-
dores, de variables, ecuaciones, axiomas de pertenencia y reglas.
24
Reglas
Una regla especica una transicion local y concurrente. Una regla incondicional tiene
la forma l : t t
, donde t, t
son terminos del mismo kind y l es la etiqueta. La transici on

tiene lugar en un sistema si existe un matching con la parte izquierda del termino t con
sustituci on . En este caso, la transicion se ejecuta y el subtermino que hace matching con
la parte izquierda es transformado por la instanciaci on correspondiente del lado derecho
(t
). La sintaxis para denir una regla incondicional en Maude es:

rl [Etiqueta] TerminoIzquierdo => TerminoDerecho .
Ejemplo Para mostrar la ejecuci on y sem antica de las reglas, se va a presentar un
ejemplo [CDE
+
07, p ag. 154] de generaci on de planes, en particular el famoso mundo de
los bloques. En este ejemplo existe una mesa sobre la que se tienen bloques, que pueden
ser movidos solo por medio del brazo rob otico. El brazo rob otico solo puede coger un
bloque que no tenga ning un bloque encima.
Figura 3.3: Ejemplo del mundo de los bloques.
El problema queda especicado en el codigo 3.7. Si se consideran los estados de la
gura 3.3 se tendra el estado inicial:
empty & clear(c) & on(c, a) & table(a) & clear(b) & table(b)
y el estado nal:
empty & clear(a) & on(a, b) & on(b, c) & table(c)
En los estados anteriores, el operador & (especicado en el codigo 3.7) combina es-
tados de nuestro sistema. Dentro de estos estados, empty indica que el brazo est a libre,
el operador clear(S) indica que el bloque S no tiene ning un bloque sobe el, el operador
on(S, R) indica que el bloque S est a colocado sobre el bloque R y por ultimo el operador
table(S) indica que el bloque S est a sobre la mesa.
25
3.2. Maude
1 mod BLOCKS-WORLD is
2 protecting QID .
3 sorts BlockId Prop State .
4 subsort Qid < BlockId .
5 subsort Prop < State .
6
7 op table : BlockId -> Prop . *** block is on the table
8 op on : BlockId BlockId -> Prop . *** block A is on block B
9 op clear : BlockId -> Prop . *** block is clear
10 op hold : BlockId -> Prop . *** robot arm holds the block
11 op empty : -> Prop . *** robot arm is empty
12 op 1 : -> State .
13 op _&_ : State State -> State [assoc comm id: 1] .
14
15 vars X Y : BlockId .
16
17 rl [pickup] : empty & clear(X) & table(X) => hold(X) .
18 rl [putdown] : hold(X) => empty & clear(X) & table(X) .
19 rl [unstack] : empty & clear(X) & on(X,Y) => hold(X) & clear(Y) .
20 rl [stack] : hold(X) & clear(Y) => empty & clear(X) & on(X,Y) .
21 endm
C odigo 3.7: Ejemplo del mundo de los bloques.
Las reglas pickup y putdown (lneas 17 y 18) describen el proceso de coger o soltar
un bloque libre (no tiene ning un bloque encima) de la mesa. Las reglas unstack y stack
(lneas 19 y 20) describen el proceso de mover un bloque cuando est a en la cima de una
columna de bloques o bien soltar un bloque en una columna.
Para poder aplicar las reglas de reescritura existen varios comandos, entre los cuales
caben destacar:
El comando rewrite (abreviado rew) con la sintaxis rewrite [N umeroMaximoReescrituras]
in Modulo : Estado .. Permite realizar reescrituras sobre un estado Estado. Se realizan
como maximo N umeroMaximoReescrituras sobre el estado proporcionado.
El comando search con la sintaxis search in Modulo : EstadoOrigen Flecha EstadoDestino .
(permite m as variedades descritas en [CDE
+
07, p ag. 144]). Permite, dado el estado
inicial, buscar los caminos posibles hasta el estado nal. La echa indica el n umero
de pasos a dar o bien si el estado nal debe ser canonico (no puede reescribirse m as).
En el caso del comando rewrite la cota establece el n umero de reescrituras m aximo,
ya que a un m odulo de sistema Maude no se le exige ser terminante. En el ejemplo
aqu mostrado, la especicaci on es no terminante y se realizan tantas escrituras como
establece la cota.
26
Si nos preguntamos: Dado el estado inicial, es posible llegar al estado nal en 0 o
mas pasos utilizando el modulo BLOCKS-WORLD?. Podemos obtener una respuesta con
el siguiente codigo:
search in BLOCKS-WORLD : empty & clear(c) & clear(b) & table(a) & table(b)
& on(c, a) =>* empty & table(c) & clear(a) & on(a, b) & on(b, c)
.
Solution 1 (state 21)
states: 22 rewrites: 37 in 7948856598ms cpu (11ms real) (0 rewrites/second)
empty substitution
No more solutions.
states: 22 rewrites: 42 in 7948856598ms cpu (14ms real) (0 rewrites/second)
Se puede pedir que se muestre la traza de la soluci on, con el comando show path 21 o
bien show path labels 21, para obtener el camino, con todos los detalles o tan solo con las
etiquetas de las reglas utilizadas, hasta el estado 21, el estado encontrado que satisface las
condiciones de la b usqueda. Las etiquetas del camino solucion en el orden que han sido
ejecutadas son: unstack, putdown, pickup, stack, pickup y stack.
3.2.4. Core Maude y Full Maude
En el sistema Maude se pueden distinguir dos entornos: Core Maude y Full Maude.
Se llama Core Maude a toda la funcionalidad basica (la explicada hasta ahora). Es decir,
al interprete Maude realizado en C++ y utilizado hasta ahora.
Full Maude es una extensi on de Maude, escrito en el propio lenguaje. Es utilizado
como base para a nadir futuras herramientas al lenguaje, como por ejemplo, el vericador
de la propiedad Church-Rosser, la herramienta de tiempo real o la sintaxis y sem antica
de los m odulos de objetos.
3.2.5. Programaci on orientados a objetos en Core Maude
En Core Maude (secci on 3.2.4) se permite el modelado de sistemas orientados a objetos.
Core Maude proporciona un m odulo predenido CONFIGURATION que declara los tipos
que representan los conceptos esenciales: objetos, mensajes y conguraciones. Este modulo
establece un lenguaje com un para especicar sistemas basados en objetos. Por otro lado,
el usuario es tambien libre de denir su propia notaci on para conguraciones y objetos.
Existe una estrategia para reescritura de sistemas orientados a objetos [CDE
+
07, Sec-
27
3.2. Maude
ci on 11.2]. El modelo de paso de mensajes predenido en Maude es asncrono, pero tambien
pueden denirse patrones m as complejos de interacciones sncronas.
Conguraciones
En el c odigo 3.8 se muestra el m odulo predenido CONFIGURATION. Los tipos basicos
describen un sistema orientado a objetos son: Object, Msg (mensajes) y Conguration.
1 fmod CONFIGURATION is
2 sorts Oid Cid Attribute AttributeSet
3 Object Msg Configuration .
4 subsorts Object Msg < Configuration .
5 subsort Attribute < AttributeSet .
6
7 op none : -> AttributeSet .
8 op _,_ : AttributeSet AttributeSet -> AttributeSet
9 [assoc comm id: none] .
10
11 op <_:_| > : Oid Cid -> Object .
12 op <_:_|_> : Oid Cid AttributeSet -> Object .
13
14 op none : -> Configuration .
15 op __ : Configuration Configuration -> Configuration
16 [assoc comm id: none] .
17 endfm
C odigo 3.8: M odulo predenido CONFIGURATION.
Una conguraci on es un multiconjunto de objetos y mensajes que representa un posible
estado del sistema. Una conguracion es representada por la sintaxis vaca que es
conmutativa, asociativa y con elemento identidad none (la conguracion vaca).
Una conguracion de objetos tiene la forma:
Ob-1 Ob-2 Ob-k Mens-1 Mens-2 Mens-n
donde el orden no importa. Una regla tiene la forma:
rl Ob-1 Ob-k Mens-1 Mens-n
=> Ob-1 Ob-j Mens-1 Mens-p
Los elementos de la parte derecha de la regla son versiones actualizadas o nuevas instancias
de los objetos/mensajes que aparecen en la parte izquierda. Si en la parte izquierda de la
regla aparece un objeto, y como m aximo un mensaje, se dice que la regla es asncrona. En
otro caso, se denomina regla sncrona. Ambos tipos de reglas representan comunicacion
asncrona o sncrona respectivamente.
28
De acuerdo al constructor del codigo 3.8, un objeto tiene la siguiente sintaxis:
< O : C | Atributo1, . . . , Atributok>
donde O es un identicador de objeto y C es un identicador de la clase a la que pertenece.
Ejemplo A continuaci on se va a presentar un ejemplo para ilustrar el uso de la progra-
maci on basada en objetos de Maude. Se va a especicar el funcionamiento simplicado
de una cuenta bancaria, a la que se le puede a nadir/quitar credito o traspasarlo entre
cuentas.
1 mod BANK-ACCOUNT is
2 including CONFIGURATION .
3 protecting INT . protecting QID .
4 subsort Qid < Oid .
5
6 op Account : -> Cid [ctor] .
7 op bal :_ : Int -> Attribute [ctor gather (&)] .
8 ops credit debit : Oid Nat -> Msg [ctor] .
9 op from_to_transfer_ : Oid Oid Nat -> Msg [ctor] .
10
11 vars A B : Oid .
12 vars M N N : Nat .
13
14 rl [credit] : < A : Account | bal : N > credit(A, M)
15 => < A : Account | bal : N + M > .
16
17 crl [debit] : < A : Account | bal : N > debit(A, M)
18 => < A : Account | bal : N - M >
19 if N >= M .
20
21 crl [transfer] : (from A to B transfer M)
22 < A : Account | bal : N >
23 < B : Account | bal : N >
24 => < A : Account | bal : N - M >
25 < B : Account | bal : N + M >
26 if N >= M .
27 endm
C odigo 3.9: Ejemplo cuenta bancaria.
En el codigo 3.9 se importa en primer lugar el modulo CONFIGURATION para poder
usar la sintaxis que se ha explicado anteriormente en esta secci on. A continuacion se
declara una nueva clase Account con un atributo entero bal que representa el estado de la
cuenta. Se denen los mensajes credit, debit y from to transfer que denen las operaciones
de a nadir dinero, quitar dinero y transferir dinero entre dos cuentas. Por ultimo se denen
las reglas. Tanto la regla credit como la regla debit especican operaciones asncronas (la
parte izquierda de la regla solo esta compuesta por un objeto y un mensaje). La regla
debit y la regla from to transfer son condicionales, para evitar que una cuenta se quede en
29
3.2. Maude
n umeros rojos.
Para probar la especicacion de la cuenta bancaria se crea un estado que describe una
situaci on hipotetica del sistema:
1 mod BANK-ACCOUNT-TEST is
2 ex BANK-ACCOUNT .
3
4 op initialBank : -> Configuration .
5 eq initialBank =
6 < A01 : Account | bal : 300 >
7 < A02 : Account | bal : 250 >
8 < A03 : Account | bal : 1250 >
9 debit( A01, 200)
10 debit( A01, 150)
11 debit( A02, 400)
12 (from A03 to A02 transfer 300) .
13 endm
C odigo 3.10: Estado concreto del ejemplo cuenta bancaria 3.9.
Para reescribir la conguracion descrita en el codigo 3.10, se ejecuta el c odigo:
rew in BANK-ACCOUNT-TEST : initialBank .
se obtiene como resultado:
result Configuration: debit(A01, 200)
< A01 : Account | bal : 150 >
< A02 : Account | bal : 150 >
< A03 : Account | bal : 950 >
El mensaje debit(A01, 200) no puede ser reescrito debido a que no hay suciente saldo en
la cuenta A01.
3.2.6. Programaci on orientada a objetos en Full Maude
Aunque en Core Maude es posible denir sistemas orientados a objetos en m odulos de
sistema, esta seccion presenta en la denicion de modulos orientados a objetos sobre Full
Maude.
En Full Maude (descrito en la secci on 3.2.4) es posible declarar modulos orientados
a objetos introduciendo la sintaxis omod fmod. Full Maude proporciona una sintaxis lo
sucientemente limpia y expresiva para permitir al usuario pensar y expresar sus proble-
30
mas en terminos de orientaci on a objetos de una manera m as facil e intuitiva que con los
m odulos de sistema denidos en Core Maude.
Los m odulos orientados a objetos son solo az ucar sint actico. Internamente son trans-
formados a m odulos de sistema, incluyendo en primer lugar el m odulo CONFIGURATION
y utilizando su sintaxis.
El codigo con la sintaxis ofrecida por los modulos de objetos para el ejemplo de la
cuenta bancaria (codigo 3.9) es el siguiente:
1 omod ACCOUNT is
2 protecting MACHINE-INT . protecting QID .
3
4 class Account | bal : MachineInt .
5 subsort Qid < Oid .
6 msgs credit debit : Oid MachineInt -> Msg .
7 msg transfer_from_to_ : MachineInt Oid Oid -> Msg .
8 vars A B : Oid .
9 vars M N N : MachineInt .
10
11 rl [credit] : credit(A,M) < A : Account | bal : N >
12 => < A : Account | bal : N + M > .
13
14 crl [debit] : debit(A,M) < A : Account | bal : N >
15 => < A : Account | bal : N - M >
16 if N >= M .
17
18 crl [transfer] : (transfer M from A to B)
19 < A : Account | bal : N >
20 < B : Account | bal : N >
21 => < A : Account | bal : N - M > < B : Account | bal : N + M >
22 if N >= M .
23 endom
C odigo 3.11: Ejemplo cuenta bancaria en Full Maude.
Notar la denici on de las clases con la palabra reservada class y los mensajes msg.
Adem as para las relaciones de herencia se a nade la palabra reservada subclass.
3.2.7. Metamodelo Maude
Para realizar este proyecto con un enfoque DSDM es fundamental tener un metamodelo
de Maude. En el metamodelo de Maude se describen los conceptos del lenguaje (vease
secci on 2.3 para mas informaci on acerca del metamodelado).
Existe un metamodelo de Maude en el lenguaje Ecore y Kermeta. En [RDV] se en-
cuentra el informe tecnico as como el metamodelo.
31
3.2. Maude
El metamodelo de Maude es un artefacto fundamental para poder realizar la transfor-
maci on desde UML a Maude.
32
33
3.3. El evaluador mOdCL
El evaluador mOdCL es un interprete OCL escrito en Maude que permite la evaluaci on
de cualquier expresi on OCL en una conguracion dada [RD11]. La exibilidad sint actica
que proporciona Maude permite implementar el evaluador mOdCL de una manera sen-
cilla. En lugar de utilizar complejas representaciones de los elementos involucrados en
las expresiones OCL, es posible establecer un mapeo de forma sencilla entre la sintaxis
original de OCL y la sintaxis de mOdCL. Del mismo modo, es posible denir los modelos
UML a los que las expresiones OCL hacen referencia de forma intuitiva y legible como se
mostrar a en esta seccion.
B asicamente, para la integracion de OCL en Maude es suciente hacer una correspon-
dencia entre cada elemento OCL y cada elemento Maude que lo representa.
El evaluador mOdCL proporciona una sintaxis de acuerdo a la de OCL en Maude y
dene un operador eval para evaluar expresiones. Ademas, mOdCL soporta la mayora
de los operadores y las caractersticas de alto nivel proporcionadas por OCL [DR]. La
operaci on b asica eval toma una expresion OCL y un estado de tipo Conguration (vease
secci on 3.2.5) y devuelve un valor OCL.
e-Motions mOdCL es una herramienta utilizada diversos entornos, como por ejemplo
e-Motions [Riv10]. e-Motions es por un lado, un lenguaje de modelado de dominio es-
pecco (Domain Specic Modeling Language (DSML) y por otro una herramienta donde
especicar sistemas de tiempo real de forma graca. En e-Motions es posible denir re-
glas de reescritura de forma graca. Un sistema especicado gracamente en e-Motions, es
traducido a Maude con el mismo enfoque que se hace en este proyecto. Posteriormente, el
sistema es ejecutado en el interprete Maude. En e-Motions, es fundamental el uso de OCL
para modicar los atributos de los objetos en las reglas, a nadir condiciones a las reglas,
e incluso agrupar funcionalidad en bloques llamados helper. Como el sistema descrito en
e-Motions, es ejecutado en el interprete Maude (previa transformaci on), las expresiones
OCL han de ser ejecutadas tambien en Maude. Gracias a mOdCL, es posible evaluar las
expresiones OCL escritas en e-Motions, en Maude.
3.3.1. Tipos basicos y colecciones
Los tipos basicos predenidos en OCL (seccion 3.1) son directamente especicados en
Maude. Los tipos OCL Boolean, Integer, Real y String son introducidos en Maude respecti-
vamente como los tipos (sorts) Bool, Int, Float y String.
34
Los tipos denidos por el usuario son representados en Maude como clases, y sus re-
ferencias como elementos del tipo predenido en Maude Oid. Por otro lado se incluye el
tipo con plantilla OCL Tuple(T1, T2). Las colecciones son descritas en OCL como Collec-
tion(T), Set(T), Bag(T), OrderedSet(T) y Sequence(T), con T un tipo plantilla. En mOdCL
est an representados los hom onimos a estos tipos. En la gura 3.4 se representan toda la
estructura de tipos, relacionados con la relaci on subsort.
OclInvalid
OclType
BasicType Oid Enum Tuple Collection
Int Float String Bool Set Bag OrderedSet Sequence
OclVoid
Figura 3.4: Estructura de tipos mOdCL.
La denicion de tipo principal en mOdCL es OclType, que representa cualquier tipo
OCL predenido. Cualquier expresi on v alida OCL es representada por el tipo OclExp.
mOdCL asume que el estado de un sistema es representado como una conguracion de
objetos, de tipo Conguration (vease secci on 3.2.5). En mOdCL tanto los tipos simples como
los tipos compuestos de tipo colecci on son subtipos de OclType. Los tipos OCL OclVoid
y OclInvalid (usados para especicar no denicion de valores y errores, respectivamente)
son representados en mOdCL con la misma sintaxis. Las constantes null e invalid son los
unicos literales de los tipos OclVoid y OclInvalid.
op null : -> OclVoid .
op invalid : -> OclInvalid .
Las expresiones OCL son representadas como terminos del tipo OclExp, con la misma
sintaxis de los operadores OCL. As, en el c odigo 3.12 se puede ver el ejemplo mostrado
en la secci on 3.1.4.
op SuffCopies : -> OclExp .
eq SuffCopies = context Library inv : self . books -> size() >= 0
C odigo 3.12: Ejemplo de invariante en mOdCL.
35
Aunque la sintaxis de mOdCL es muy cercana a OCL, debido a las limitaciones de
Maude en el nivel lexico, los operadores deben estar rodeados por espacios para que el
parseador de Maude pueda romper las expresiones en tokens. En general, para cualquier
operador OCL, en el m odulo SYNTAX se proporcionan las ecuaciones necesarias para dar
una interpretaci on para la funci on eval. Ademas, la especicaci on de un operador podra
usar funcionalidades complementarias denidas en el modulo COLLECTION.
3.3.2. Estructura del evaluador mOdCL
Los tres modulos principales de mOdCL son: COLLECTION, SYNTAX y EVAL. Estos tres
m odulos componen la estructura fundamental de mOdCL, detallada a continuacion:
Modulo COLLECTION Contiene un mapeo de la estructura de tipos (gura 3.1) de
OCL. Todo el evaluador de mOdCL pivota entorno al tipo OclType. La estructura de tipos
del modulo COLLECTION es la siguiente:
1 subsort Int Float String Bool Oid < BasicType .
2 subsort Set Bag OrderedSet Sequence < Collection .
3 subsort BasicType Collection < OclType .
Modulo SYNTAX Este modulo proporciona las deniciones necesarias para expresar
cualquier expresion OCL valida. Una expresion OCL es en mOdCL un termino de ti-
po OclExp. Por ejemplo, el operador includes
5
est a denido en el m odulo SYNTAX como
sigue:
op _-> includes(_) : OclExp -> Bool .
Al igual que includes, todos los elementos que pueden formar una expresi on v alida OCL
est an recogidos en este m odulo.
Modulo EVAL El m odulo EVAL contiene todas las ecuaciones necesarias para evaluar
cualquier expresion OCL. Estas expresiones, denidas previamente en el m odulo SYNTAX,
son reducidas a un valor nal OclType. Dentro de este m odulo est a denido el operador eval
que ya ha sido mencionado en esta secci on. El operador eval est a especicado como se
5
El operador includes, con la sintaxis A->includes(B) con A de tipo Collection y B de tipo OclType,
devuelve true si el elemento B esta contenido en la coleccion A. Devuelve false en otro caso.
36
indica a continuaci on:
op eval : OclExp Configuration -> OclType .
op eval : OclExp Configuration Configuration -> OclType .
C odigo 3.13: Operaci on eval.
La segunda denicion del operador eval (lnea 2 del c odigo list:eval) es necesaria para evaluar
expresiones en el contexto de pre- y poscondiciones. Cuando se eval ua la especicaci on
OCL de una operaci on, se requieren dos estados del sistema: el estado que representa el
sistema antes de ejecutar la operaci on, y el estado que representa el sistema despues de
ejecutar la operaci on.
Continuando con el ejemplo, la ecuaci on correspondiente para la evaluaci on del ope-
rador includes especicado en el m odulo SYNTAX es la siguiente:
1 vars E1 E2 : OclExp .
2 var C : Configuration .
3 eq eval(E1 -> includes(E2), C) = eval(E1, C) in eval(E2, C) .
C odigo 3.14: Evaluacion del operador includes.
En el c odigo 3.14 se hace uso del operador injo in en la lnea 3. El operador in devuelve
true cuando un elemento dado est a contenido en una colecci on.
De forma an aloga, toda la sintaxis y semantica de OCL contemplada en mOdCL
queda denida en Maude. La evaluacion de cualquier expresion OCL es resuelta con una
invocaci on recursiva del operador eval de las sucesivas subexpresiones y de las operaciones
auxiliares denidas en mOdCL.
3.3.3. Invariantes, pre- y poscondiciones en mOdCL
En esta seccion se mostrar a como representar invariantes OCL en mOdCL. Para ello,
esta seccion se basa en el ejemplo expuesto en la secci on 3.1.
Como se ha mencionado en esta secci on, todo invariante OCL en mOdCL es de ti-
po OclType. Un invariante OCL, como el que se muestra en el codigo 3.1 de la seccion 3.1.4,
es especicado en mOdCL como sigue:
1 op PositiveCopies : -> OclExp .
2 eq PositiveCopies
3 = context Book inv : self . copies >= 0 .
37
Un invariante es denido mediante ecuaciones, que han sido declaradas como cons-
tantes, para poder hacer referencia a ellas posteriormente. Los invariantes, las pre- y
poscondiciones son denidas en mOdCL como:
op inv : -> OclExp .
ops pre post : OpName -> OclExp .
Un invariante en mOdCL no tiene nombre (en OCL s lo poda tener). En su lugar, la
constante que especica la ecuaci on eq Maude, puede ser utilizado como nombre. Para las
pre- y poscondiciones, es necesario un par ametro de tipo OpName. Este parametro indica
el nombre del metodo para el que es denida la pre- o poscondicion.
1 op MaxTwoLoans : -> OclExp .
2 eq MaxTwoLoans =
3 context Member inv : self . loans -> size() <= 2 .
4
5 eq inv = PositiveCopies and MaxTwoLoans .
C odigo 3.15: Ejemplo de invariantes en mOdCL.
La constante inv puede ser denida como se muestra en la lnea 5 del c odigo 3.15.
Para mostrar un ejemplo de pre- y poscondiciones se va a mostrar en mOdCL la
operaci on loanBook(Book) de la secci on 3.1.5 en el codigo 3.16.
1 eq pre(loanBook) =
2 (self . loans -> size() < 2) and (b . isAvailable()) .
3 eq post(loanBook) =
4 (result = self . loans -> any(l | l . book = b)) and
5 self . loans pre -> size() = self . loans -> size() - 1 .
C odigo 3.16: Operaci on loanBook en mOdCL.
3.3.4. Representaci on de la estructura de los sistemas en mOdCL
Los modelos a vericar estan representados con notaci on UML. Para poder utilizar
estos modelos en mOdCL es necesario traducirlos a notaci on Maude. En este apartado se
va a explicar la representaci on de los diagramas de clases de UML en notaci on Maude y
mOdCL.
38
Para las especicaciones, se utilizar a la representaci on de objetos que proporciona el
m odulo CONFIGURATION, explicado en la secci on 3.2.5. Cada objeto es identicado con
un elemento del tipo Oid y perteneciente a una clase, de tipo Cid. Cada clase tendra un
n umero arbitrario de atributos, denidos con los tipos mOdCL como elementos del ti-
po Attribute. El siguiente c odigo representa el c odigo correspondiente a la especicacion
de los atributos en mOdCL:
op _:_ : AttributeName OclType -> Attribute .
donde AttributeName representa el nombre del atributo y OclType el valor que lo representa.
En la representaci on original Maude presentada en la secci on 3.2.5 se dene para cada
atributo un operador, como por ejemplo:
op a :_ : OclType -> Attribute .
Para cada clase, se denira un nuevo tipo, subtipo del tipo Cid. Y por cada atributo o
asociaci on, una constante de tipo AttributeName que identica el atributo en la clase. Por
ejemplo para el ejemplo expuesto en la secci on 3.1:
1 sort Car .
2 subsort Car < Cid .
3 op Car : -> Car [ctor] .
4 op started : -> AttributeName [ctor] .
Si existe una relacion de herencia entre la clase A y la clase B es necesario utilizar el
predicado isSubClass : Cid Cid -> Bool de la siguiente forma:
eq isSubClass(Car, Vehicle) = true .
Por otro lado, los metodos en mOdCL son especicados como constantes del tipo Op-
Name. Ademas, cada par ametro del metodo se expresa como una constante de tipo Arg.
Por ejemplo:
39
op getOn : -> OpName [ctor] .
op person : -> Arg [ctor] .
Finalmente, es posible representar clases asociaci on como una clase con dos atributos
a ambos extremos. El lector interesado puede encontrar m as informacion en [?].
3.3.5. Representaci on del comportamiento
En la seccion 3.3.4 se ha mostrado como representar la estructura de un sistema. Esta
estructura se dene de forma visual en UML con un diagrama de clases. El objetivo del
presente proyecto es realizar vericaci on din amica de sistemas. Estos sistemas tendran un
comportamiento denido en un diagrama de secuencia de UML. En esta seccion se va a
mostrar como especicar el comportamiento de un sistema, es decir, c omo modelar un
diagrama de secuencia UML en Maude.
El comportamiento de un sistema vendr a dado por el comportamiento de las operacio-
nes especicadas en su diagrama de clases. Cada una de estas operaciones puede invocar
otras o producir cambios en el estado del sistema.
El comportamiento de una operaci on, denido por un diagrama de secuencia UML,
ser a especicado en Maude como una secuencia de reglas. Una regla Maude que repre-
senta una acci on dentro de la denici on de una operaci on, podra necesitar informaci on
relacionada con el objeto que ha invocado dicha operacion o el valor de los par ametros
de la operaci on. Se va a asumir que todos estos datos son almacenados en un objeto de
tipo Context, que representa el contexto de la ejecuci on. Este contexto contiene la infor-
maci on sobre la operacion que se est a representando y tiene la forma:
< ctx : Context | opN : m, obj : id, args : vars >
donde m es el nombre de la operaci on activa, id el identicador del objeto actual (el
que contiene la operacion llamada) y vars es un conjunto de pares con el nombre de un
par ametro o una variable local y su valor actual.
Una operaci on puede llamar a otra y as sucesivamente pueden encadenarse, incluso
recursivamente. Por lo tanto es necesario almacenar las operaciones pendientes en una
pila de ejecuci on, que es especicada en el modulo STACK (vease secci on 3.3.6). La pila de
ejecuci on es totalmente transparente al usuario. Para hacer transparente el uso de la pila
40
de ejecuci on al usuario, la invocaci on y terminacion de operaciones debe ser identicado.
Con este n se asume que las reglas que especican el comportamiento de una operacion
siguen un esquema b asico con tres mensajes concretos: call, return y resume.
Aunque la exibilidad sint actica de Maude permite denir una operacion con cualquier
sintaxis, se va a asumir que un mensaje es enviado con el operador call:
op call : OpName Oid ArgsList -> Msg [ctor] .
Cuando un usuario quiere enviar un mensaje m(args-list) a un objeto Obj, un mensaje
call(m, Obj, args-list) se situa en la conguraci on de objetos y mensajes que representa el
estado del sistema. Este mensaje call es procesado por el m odulo STACK y crea un objeto
de la clase Context con el nombre de la operaci on invocada, el objeto que llama al metodo
y los valores de los par ametros. En la gura 3.5 se muestra c omo un mensaje call se
call message Context object
resume message return message
wait send
send create
Figura 3.5: Esquema de especicacion del comportamiento de una operaci on.
convierte en un objeto Context. El ujo de control del objeto que enva el mensaje call se
queda bloqueado hasta que la operaci on es completada. Para este n, la regla bloqueada
espera a un mensaje resume especicado como:
op resume : OpName OclType -> Msg [ctor] .
donde el primer par ametro indica el nombre de la operaci on y el segundo par ametro recoge
el valor de devuelve (o null).
Por ultimo, se asume que existe una ultima regla Maude deniendo el comportamiento
de una operaci on con un mensaje return que tiene la siguiente sintaxis:
op return : OclType -> Msg [ctor] .
con el resultado de la operacion. Este mensaje sera procesado por el m odulo STACK y
41
3.4. ATL
reemplazado por un mensaje resume.
3.3.6. La pila de ejecucion
En este apartado se va a describir con detalle el manejo de la pila que se especica en
el modulo STACK.
El m odulo STACK dene las clases Stack y Context. Una pila es representada por un
objeto de la clase Stack con solo un atributo state que almacena una lista de objetos que
representan la secuencia de los contextos de ejecuci on de aquellas operaciones que est an
esperando que se complete una llamada previa.
Como se ha mencionado en la seccion anterior, el m odulo STACK dene los mensajes
call, return y resume y tambien las reglas. El manejo de la pila es transparente al usuario, que
simplemente debe utilizar los mensajes call, return y resume. Con este n, el estado inicial
se asume que sera un termino de tipo Conguration envuelto en corchetes. La ecuacion INIT
denida en este m odulo incluye en esta conguraci on una pila vaca.
La ecuaci on CALL es responsable de procesar los mensajes call, guardando el contexto
de la ejecucion actual en la pila y creando un nuevo contexto para la operaci on invoca-
da. La ecuaci on RETURN es responsable de procesar los mensajes return, reemplazando la
ejecuci on actual por el contexto almacenado en la cima de la pila e incluyendo un men-
saje resume en la conguraci on del sistema. Esto permite desbloquear la regla esperando
a que se complete la llamada al metodo anterior.
3.4. ATL
Atlas Transformation Language (ATL) es un lenguaje de transformaci on de mode-
los (secci on 2.4). Est a dise nado para desarrollar transformaciones exogenas (aunque en
versiones posteriores se ha desarrollado el modo rening que permite transformaciones
end ogenas) y unidireccionales [JABK08].
El enfoque que se ha tenido en cuenta en ATL se muestra en la imagen 3.6. En este
enfoque, un modelo Ma es transformado en un modelo Mb de acuerdo a la denici on de
la transformaci on example.atl. La transformaci on es conforme al metamodelo ATL. Todos
los metamodelos involucrados son conformes a MOF.
ATL es un lenguaje hbrido: contiene constructores declarativos e imperativos. Una
transformaci on se dene en terminos de reglas que especican las relaciones entre un
42
Figura 3.6: Enfoque de transformacion de modelos con ATL.
elemento del modelo de entrada y un elemento del modelo de salida. Por este motivo es
ventajoso programar transformaciones de modelos en un lenguaje declarativo, ya que la
implementaci on tiende a ser mas cercana a como las transformaciones son percibidas por
los desarrolladores. El estilo declarativo permite jarse en los detalles de la transformaci on
y oculta detalles como la seleccion de los elementos de entrada, el orden de ejecuci on de
las reglas, etc.
El lenguaje ATL est a basado en el lenguaje OCL (seccion 3.1), aunque existen algunas
diferencias entre la denici on de algunos operadores OCL y la implementaci on ATL.
3.4.1. Caso de estudio: FamilyToPerson
En este apartado se va a presentar un ejemplo para mostrar las principales estructuras
y caractersticas del lenguaje ATL. El ejemplo FamilyToPerson muestra la transformaci on
entre una lista de familias a una lista de personas. En la gura 3.7(a) se muestra el meta-
modelo de una familia, que se corresponde con el metamodelo fuente (elemento MMa en la
gura 3.6). En la gura 3.7(b) se muestra el metamodelo de una persona, correspondiente
al metamodelo destino (elemento MMb en la gura 3.6).
El metamodelo familia est a compuesto por una clase principal Family a la que se le
asocia un apellido lastName. En una familia existen un n umero indeterminado de hijo-
s/as, un padre y una madre. Todos ellos pertenecen a la clase Member, con un campo
nombre fullName.
43
3.4. ATL
(a) Metamodelo fuente: familia.
(b) Metamodelo destino: personas.
Figura 3.7: Metamodelos fuente y destino.
El metamodelo persona est a compuesto por una unica clase abstracta Person con un
atributo fullName y especializada en funci on del sexo en Male o Female.
El objetivo de la transformacion ser a: dado un modelo conforme al metamodelo
familia, dar una lista de personas en un modelo conforme al metamodelo persona.
3.4.2. Principales estructuras y caractersticas
El elemento mas global de ATL puede ser: un m odulo o una consulta. Un m odulo es
la base de una transformaci on, mientras que una consulta es una operacion puntual sobre
un modelo. En esta seccion se va a hacer especial hincapie en los m odulos ATL.
44
Modulos ATL
Un modulo ATL es un tipo de datos especco de ATL. Un m odulo contiene una sec-
ci on obligatoria llamada encabezado o header, una seccion donde se realizan los imports
de otros m odulos, helpers y reglas de transformaci on.
Por otro lado, existe una referencia thisModule que permite acceder a los diferentes
elementos que contiene un m odulo, as como la operacion resolveTemp que permite acceder
a los elementos del modelo de trazas (vease documentaci on [ea]).
El encabezado o header se compone por el nombre del m odulo y la declaracion del
metamodelo (o metamodelos) de entrada y del metamodelo (o metamodelos) de salida.
Para el ejemplo FamilyToPerson el encabezado sera el siguiente:
module Family2Person;
create OUT : Person from IN : Families;
Dentro de ATL, todas las variables tienen tipo. Una variable puede tener un tipo
b asico ATL (en su mayora coincide con los tipos de OCL), un tipo coleccion o bien una
clase que se encuentre en el metamodelo fuente o destino.
Metodos auxiliares: helpers
ATL permite a los desarrolladores denir metodos con diferentes tipos en una unidad
ATL (m odulo o consulta), denominados helpers. Existen dos tipos de helpers:
Funcionales. Un helper es utilizado para encapsular cierta funcionalidad a la que
es accedida desde cualquier parte del codigo ATL. Puede aceptar par ametros. Un
helper tiene un nombre, una lista (posiblemente vaca) de par ametros, un contexto
(elemento con el que puede ser invocado el helper, en caso de ser vaco, el contexto
es el m odulo) y un cuerpo. El cuerpo de un helper es una expresi on declarativa.
Atributos. Un helper puede ser utilizado para almacenar el valor de un atributo
(del mismo tipo del helper). Puede establecerse un valor para este atributo en un
bloque imperativo y puede obtenerse en cualquier parte del c odigo.
Para el ejemplo presentado en la secci on 3.4.1, se van a denir dos helpers. En primer
lugar, el helper isFemale determina si el objeto de tipo Member con el que es invocado es
femenino o no.
45
3.4. ATL
1 helper context Families!Member def: isFemale(): Boolean =
2 if not self.familyMother.oclIsUndefined() then
3 true
4 else
5 if not self.familyDaughter.oclIsUndefined() then
6 true
7 else
8 false
9 endif
10 endif;
C odigo 3.17: Denici on del helper isFemale().
En el c odigo 3.17 se especica un helper con un nombre isFemale(), un contexto
Families!Member, una lista vaca de argumentos, un tipo del helper y un cuerpo. El cuerpo
est a denido con una expresi on OCL, en particular la expresion if-then-else-endif anidada.
Reglas de transformacion
La generaci on del metamodelo destino se logra con la especicaci on de reglas de
transformacion. En ATL se denen tres tipos de reglas de transformaci on:
Matched rules Una matched rule permite establecer una correspondencia entre
uno o m as elementos del metamodelo fuente y, a partir de estos elementos, crear
uno o m as elementos en el metamodelo destino. Para este n, una matched rule
est a compuesta por un nombre unico en el m odulo, un apartado from donde se
especicar an los elementos del metamodelo fuente que corresponden a esta regla y
opcionalmente una restriccion, un apartado to donde se especican los elementos
creados en el metamodelo destino y sus inicializaciones y opcionalmente un bloque
imperativo do.
Lazy rules Una lazy rule tiene la misma sintaxis que una matched rule pero distinta
sem antica. Una lazy rule no es automaticamente ejecutada sino que tiene que ser
invocada desde el apartado to de una matched rule, en la inicializaci on de los objetos.
Con ayuda de las lazy rules es posible crear un n umero indeterminado de objetos
en el modelo destino a partir de un elemento del modelo fuente.
Called rules Una called rule tiene que ser invocada desde un bloque imperativo de
otra regla. Una called rule no tiene apartado from ya que unicamente crea elementos
en el metamodelo destino a partir de los par ametros que opcionalmente pueda tener.
46
Una regla de transformaci on mas com un matched rule tiene la siguiente sintaxis:
1 rule NombreRegla {
2 from
3 Patr onElementosFuente
4 [ (Condici on) ]?
5 [using {
6 Declaraci onV ariablesLocales
7 }]?
8 to
9 ElementosCreadosY SusInicializaciones
10 [do {
11 BloqueC odigoImperativo
12 }]?
13 }
C odigo 3.18: Sintaxis matched rule.
Tanto los bloques iniciados por using como do son bloques de codigo imperativo. En
el primero es posible declarar variables locales a la regla que seran inicializadas con una
expresi on (puede ser una llamada a un helper). En el bloque do se puede utilizar estruc-
turas imperativas (vease documentacion en [ea]), actualizaciones de helpers con atributos
o impresion por pantalla.
En las ultimas versiones de ATL es posible hacer uso de una estructura de herencia
de reglas. El lector interesado puede obtener m as informacion en [ea].
Continuando con el ejemplo, hay que recordar el objetivo principal de esta transforma-
ci on: transformar un Member en una instancia de la clase Male o Female. En el c odigo que
se muestra a continuaci on se especica una de las reglas, que transforma un objeto Member
del modelo fuente a un objeto Male:
1 rule Member2Male {
2 from
3 s: Families!Member (not s.isFemale())
4 to
5 t: Persons!Male (
6 fullName <- s.firstName + + s.familyName
7 )
8 }
C odigo 3.19: Regla de transformacion matched rule Member2Male.
En la condicion de los elementos que coinciden con el patr on de entrada, se ha utilizado
el helper denido en el codigo 3.17. En la asignacion del atributo fullName se hace uso de
otro helper, familyName.s
47
3.4. ATL
3.4.3. Otras caractersticas de ATL
Para poder comprender la transformaci on realizada en ATL, es necesario profundizar
en algunos aspectos avanzados del lenguaje.
Semantica de ejecucion en ATL
En primer lugar, el modo de ejecuci on de ATL sigue tres fases:
1. Inicializaci on del modulo Durante esta fase, los atributos declarados en el contex-
to del m odulo son inicializados. Cabe destacar que estos atributos tienen la sintaxis
de un helper sin par ametros, y por cuestiones de estilo, sin parentesis precedidos del
nombre. Si en el m odulo se ha denido una called rule con la cabecera precedida
del palabra reservada entrypoint, esta ser a ejecutada (y los elementos de su apartado
target creados) despues de la inicializacion de los atributos.
2. Correspondencia de elementos En esta fase, denominada en ingles matching,
se establece la correspondencia de los elementos incluidos en el modelo de entrada
con la parte from de cada regla. Adem as, la condicion de los elementos de entrada
de la regla (en caso de que exista) es evaluada sobre los posibles elementos a hacer
correspondencia. Un elemento del modelo fuente solo puede hacer matching o co-
rrespondencia con una regla del modulo ATL. Por ultimo, durante esta fase ATL
asigna el conjunto de elementos destino declarado en la parte to de la regla.
3. Inicializaci on de los elementos destino Durante esta fase se inicializan los ob-
jetos destino que han sido asignados con anterioridad, ejecutando el codigo de los
binding de cada elemento. Tambien se resuelven las llamadas a la funcion resolve-
Temp(). Por ultimo se ejecuta el c odigo imperativo, de la parte do de cada regla.
Este codigo imperativo puede ejecutar alguna called rule.
Evaluaci on de condiciones
ATL est a basado sobre el lenguaje de restricci on de objetos OCL, cuyas caractersticas
se detallan en la seccion 3.1. En particular, las condiciones que se imponen en las reglas
matched rules, o las operaciones denidas con helpers, son expresadas con OCL.
En general, los lenguajes de programacion m as utilizados utilizan evaluaci on de con-
diciones en cortocircuito. Esta semantica en la evaluaci on de condiciones permite que
el comportamiento sea:
48
En conjunciones o and las sub-expresiones se eval uan de izquierda a derecha. En
el caso de que una de ellas no sea cierta, se para la evaluaci on y se devuelve falso.
Por ejemplo en el codigo 3.20, se expresa la condici on habitual en un algoritmo de
b usqueda simple. En caso de que el contador sea mayor que el n umero de elementos
en la colecci on que se esta examinando, la expresi on de la izquierda de la conjunci on
devolvera falso y en un lenguaje de programaci on como Java o C
6
no se evaluara la
parte derecha, que en el caso de ser el contador mayor que el n umero de elementos,
elevara una excepci on.
En una disyuncion o or la evaluaci on de la expresi on se detiene cuando alguna
de las sub-expresiones que componen la disyuncion se eval ua a cierto. Es el caso
opuesto al anterior.
if cont <= class1.attr1->size() and class1.attr1->at(cont) = class2
then [. . .]
C odigo 3.20: Ejemplo evaluaci on en cortocircuito.
Sin embargo, en OCL se eval ua toda la expresion, independientemente de si es una
conjunci on o disyunci on y alguno de los elementos se haya evaluado ya a falso o cierto,
respectivamente. Debido a esto, es habitual encontrar en los codigos de transformaciones
complejas anidamientos de expresiones con el operador if como se muestra a continuaci on:
1 if (if cont <= class1.attr1->size()
2 then class1.attr1->at(cont) = class2
3 else false endif)
4 then [. . .]
Navegar en las instancias de entrada
Una operaci on muy utilizada para recorrer elementos del modelo de entrada es allIn-
tances(). S olo es posible recorrer elementos de entrada porque, como ya se ha mencionado
durante esta seccion, con ATL se implementa transformaci on out-place, con lo que el mo-
delo de entrada/modelo fuente s olo puede ser ledo y el modelo de salida/modelo destino
s olo puede ser creado.
6
Lenguajes mas utilizados seg un el ndice TIOBE (a Junio de 2013).
49
3.4. ATL
Para recorrer elementos de un tipo se puede hacer de la siguiente forma:
UML!Property.allInstances()->select(p | p.name = Attr1)
50
CAP
ITULO 4
Transformacion
En este captulo se describe como se realiza la transformaci on de diagramas de clase y
secuencia en UML a c odigo Maude ejecutable por el evaluador mOdCL. La transformaci on
ser a implementada en dos partes diferenciadas o transformaciones:
Transformacion modelo a modelo. Se ha realizado una transformaci on de mo-
delo a modelo en el lenguaje ATL (vease seccion 3.4) unidireccional, ex ogena y out-
place (vease captulo 2), con metamodelo fuente UML y metamodelo destino Maude
(vease secci on 3.2.7). Esta transformaci on contempla tanto la transformaci on de la
estructura del sistema como la del comportamiento, es decir, del diagrama de clases
y de secuencia. El artefacto resultante es un modelo conforme a el metamodelo
Maude, pero no es codigo ejecutable.
Transformacion modelo a texto. Se ha realizado una transformacion de modelo
a texto en el lenguaje Acceleo, partiendo del metamodelo Maude y generando c odigo
ejecutable Maude. Esta transformacion tiene como entrada el modelo generado por
la transformacion modelo a modelo y como salida un chero Maude ejecutable.
El objetivo de este proyecto n de carrera es vericar el comportamiento de un sis-
tema denido con diagramas de secuencia. Se pretende conseguir un c odigo completo
y ejecutable a partir de una especicacion UML completa. Esta transformaci on podra
hacer transparente la vericacion en Maude al usuario, que no tendra que tener cono-
cimiento sobre el lenguaje utilizado para ello (como ocurre en e-Motions [RDV09]). La
automatizaci on completa de este proceso se propone como trabajo futuro en 7.
51
4.1. Estructura del sistema
Este captulo se centra en dicha transformacion como unidad, es decir, partiendo de
diagramas UML y obteniendo c odigo Maude, ya que el modelo obtenido tras la transforma-
ci on de modelo a modelo carece de interes (mas que para generar c odigo). La descripci on
de la transformacion se hace a un nivel de abstracci on lo sucientemente alto para que el
lector no tenga que tener necesariamente conocimientos de ATL (secci on 3.4).
La estructura del captulo es la siguiente. En la seccion 4.1 se describe la transfor-
maci on de un diagrama de clases UML a un m odulo Maude. En la secci on 4.2 se des-
cribe la transformaci on del diagrama de secuencia a un m odulo Maude, que especica
el comportamiento denido. En la secci on 4.4 se detallan los aspectos mas tecnicos de
la transformacion. Por ultimo, en la secci on 4.5 se describe la transformaci on modelo a
texto.
Prototipar un sistema en Maude o transformar un diagrama de clases UML a Maude
ha sido abordado por muchos trabajos anteriormente, como en MOMENT-2 [BM08],
Maudeling [RRDV07] y e-Motions [RDV09].
En este proyecto n de carrera, y en concreto durante esta secci on, se propone la
transformaci on necesaria para describir un sistema en Maude y poder ser evaluado por
mOdCL. En la secci on 4.1.1 se explica la correspondencia entre cada elemento de un
diagrama de clases y el codigo Maude generado, y en la secci on 4.3 se describe como
denir estados en el sistema prototipado.
4.1.1. De diagrama de clases UML a c odigo Maude
Como se describe en la seccion 3.3.4, los diagramas de clases son representados en
Maude como modulos orientados a objetos y los estados como conguraciones de objetos
(de tipo Conguration) descritos en la seccion 3.2.5. Sin embargo, en el evaluador mOdCL
hay diferencias respecto a la representaci on de atributos, asociaciones y operaciones. Estas
diferencias son debidas a la utilizaci on del evaluador mOdCL, que usa los tipos denidos
en OCL.
Ejemplo En el ejemplo cuyo diagrama de clases se presenta en la gura 4.1, se descri-
be un sistema muy sencillo con dos clases: Person y Car. Una persona tiene la operaci on
conducir drive(). El coche tiene dos atributos: started : Boolean y passengers : Person[*] que
52
Captulo 4. Transformaci on
Figura 4.1: Diagrama de clases PersonCar
especican cu ando un coche esta arrancado y la lista de pasajeros del coche, respecti-
vamente. Por otro lado, es posible subirse a un coche con la operaci on getOn(person) y
arrancarlo start().
Las clases son descritas siguiendo el mismo esquema descrito en la secci on 3.2.5:
1 --- Class Person
2 sort Person .
3 subsort Person < Cid .
4 op Person : -> Person [ctor] .
5 --- Class Car
6 sort Car .
7 subsort Car < Cid .
8 op Car : -> Car [ctor] .
C odigo 4.1: Fragmento del c odigo generado por la transformacion.
El codigo 4.1 es un fragmento del codigo generado por el diagrama de clases del ejem-
plo PersonCar. La transformacion genera los constructores de las clases desordenados.
Es decir, aunque es legible el c odigo, el orden de las lneas no se corresponde al que un
programador hara. Esto es debido a que en Maude el orden es irrelevante y por lo tanto
no esta denido en el metamodelo de Maude. Al no denirse el orden de las sentencias en
el metamodelo, un modelo no tiene informacion acerca del orden y es imposible generar
un c odigo realmente ordenado, es decir, que tras la denicion de una clase aparezcan sus
atributos, por ejemplo.
Para los atributos y asociaciones se utiliza la representacion particular de mOdCL,
usando los tipos OCL. Para cada atributo o asociaci on se genera un constructor:
op NombreAtributo : -> AttributeName [ctor] .
donde NombreAtributo es el nombre de dicho atributo o asociacion en el diagrama de
clases. Para el ejemplo PersonCar se tienen los siguientes atributos y asociaciones:
53
1 op started : -> AttributeName [ctor ] .
2 op car : -> AttributeName [ctor ] .
3 op passengers : -> AttributeName [ctor ] .
Por ultimo, las operaciones y sus parametros se especican de forma similar. Para
el nombre de una operaci on se crea una constante de tipo OpName y cada argumento se
especica como una constante de tipo Arg:
1 op NombreOperaci on : -> OpName [ctor] .
2 op Arg
1
: -> Arg [ctor] .
3 [. . .]
4 op Arg
n
: -> Arg [ctor] .
Para el ejemplo PersonCar y las operaciones denidas en el se genera de forma au-
tom atica las siguientes operaciones:
1 op start : -> OpName [ctor ] .
2 op getOn : -> OpName [ctor ] .
3 op person : -> Arg [ctor ] .
4 op drive : -> OpName [ctor ] .
Una clase asociacion denida en UML se modela en Maude como sigue. En la -
gura 4.2 se muestra el ejemplo tpico de una clase asociacion, llamada AssocClass con
extremos las clases ClassA y ClassB.
Figura 4.2: Ejemplo ilustrativo clase asociacion
Para una clase asociaci on como la mostrada, se crear an los constructores necesarios
de una clase como ya se ha explicado en esta seccion. Ademas, cada extremo de la clase
asociaci on sera tratado como un atributo o asociacion. Tanto la clase ClassA como la ClassB
deber an contener un atributo con multiplicidad variable y con nombre AssocClass, para
tener acceso a la asociacion. Por ejemplo el esquema anterior de la gura 4.2 se traducira
a:
54
1 sort ClassA .
2 subsort ClassA < Cid .
3 op ClassA : -> ClassA [ctor] .
4
5 sort ClassB .
6 subsort ClassB < Cid .
7 op ClassB : -> ClassB [ctor] .
8
9 sort AssocClass .
10 subsort AssocClass < Cid .
11 op AssocClass : -> AssocClass [ctor] .
12
13 op classa : -> AttributeName [ctor] .
14 op classb : -> AttributeName [ctor] .
15
16 op AssocClass : -> AttributeName [ctor] .
C odigo 4.2: C odigo generado para el diagrama 4.2.
En la lnea 16 del c odigo 4.2 se a nade un atributo que representa la asociacion y que
estar a tanto en la clase ClassA como en la clase ClassB.
4.2. Comportamiento del sistema
El comportamiento del sistema que ha sido denido en UML con diagramas de se-
cuencia debe ser transformado en c odigo ejecutable por mOdCL.
Como un diagrama de secuencia modela la interacci on entre objetos, es decir, la lla-
mada a sus metodos, resulta complicado establecer cambios en los valores de los atributos
de dichos objetos. Para solventar este inconveniente, adem as de asignar y utilizar como
par ametros valores literales, se pueden utilizar expresiones OCL en estos campos. La uni-
ca objecion acerca de estas expresiones OCL es que deben ser expresadas con espacios, ya
que ser an evaluadas por mOdCL y Maude necesita los espacios para dividir las expresiones
en tokens.
En la seccion 4.2.1 se justica la necesidad de expresiones OCL en los diagramas
de secuencia. En la secci on 4.2.2 se describe el esqueleto general de las reglas Maude
generadas. En la secci on 4.2.3 se muestran operadores que solo aparecen en ciertas reglas
generadas. En la secci on 4.2.4 se describen los bloques alternativos de los diagramas de
secuencia. Por ultimo en la secci on 4.2.5 se describe como utilizar expresiones OCL y
variables locales.
55
4.2.1. Necesidad de expresiones OCL
Como ya se ha mencionado en diversas ocasiones, la necesidad de que la vericacion
en mOdCL sea transparente al usuario obliga a que el c odigo generado por los diagramas
UML sea completo. El alcance de los diagramas de secuencia es en ciertas deniciones
ambiguo [uml05] y no permite identicar algunos detalles que durante esta transformacion
se van a tomar. En este sentido, es necesario que se produzcan efectos laterales en el codigo
generado por el diagrama de secuencia, ya que sin ellos, no se podran modicar el valor
de los atributos.
Como mOdCL es un interprete de OCL y dada la integraci on de UML y OCL, se van
a permitir cualquier tipo de expresiones OCL en los siguientes casos:
En los valores de los argumentos cuando se hacen llamadas a los metodos.
En los mensajes Found se pueden realizar modicaciones a los atributos de las
clases, en forma de asignaci on, utilizando en la parte derecha de la asignaci on una
expresi on OCL. De esta forma se puede denir el comportamiento de un mensaje
de tipo setValue, por ejemplo.
4.2.2. Esqueleto de transformaci on sin bloques anidados
Para un diagrama de secuencia simple, donde no existen bloques (ni condicionales ni
de iteracion), se generan tantas reglas como mensajes hayan sido creados. A continuaci on
se describe la parte general de cada regla. Es decir, las estructuras que se incluyen en
todas las reglas que se generan a partir de un diagrama de secuencia.
Para cada mensaje de llamada a un metodo, se crea una regla Maude con la si-
guiente estructura:
1 rl [NombreMensaje] :
2 {
3 LHS
4 }
5 =>
6 {
7 RHS
8 } .
NombreMensaje es el nombre del mensaje y tiene la siguiente estructura: CLASE::NombreMensaje.
Por ejemplo, podra ser: 1:CREATE()::LoyaltyProgram. El motivo de a nadir los corchetes { }
56
ser a entendido posteriormente en la secci on 4.2.3 cuando se explique la evaluaci on de
expresiones OCL con ayuda del operador eval. Todas las reglas tienen un termino com un
en la parte izquierda LHS (y ligeramente modicado respecto a este en la parte derecha
RHS) compuesto por:
1 < ctx : Context | opN : NombreM etodo, obj : Self:Oid,
2 args : ListaDeArgumentos, seq : Secuencia>
3 < Self:Oid : NombreClase | ListaAtributos >
4 Cf:Configuration
C odigo 4.3: Esqueleto correspondiente a la parte ja izquierda LHS.
y cada termino que aparece en el esquema del LHS contiene las variables:
ListaDeArgumentos. Es una lista de pares con el operador prejo arg y dos par ame-
tros. El primer par ametro corresponde al nombre del par ametro en la signatura
del metodo. El segundo corresponde con la variable Maude que hace referencia a
ese par ametro de la signatura. Ademas, se almacenaran todas las variables locales
utilizadas en el diagrama de secuencia: lneas de vida o variables auxiliares para
almacenar valores. Por convenci on, el segundo argumento empezar a por may uscu-
las. Para evitar la repetici on de variables, se le a nadira un identicador unico al
nal del nombre de la variable. Este ndice sera creciente y nunca se repetira. La
ListaDeArgumentos tendr a tantos elementos como par ametros tenga la signatura
del metodo mas el n umero de variables locales que se utilicen.
Secuencia. Lista de pares que guan la secuencia de ejecucion de reglas. Se describe
con mas detalle en esta secci on.
NombreClase. Nombre de la clase propietaria del metodo.
ListaAtributos. Contiene todas las variables que hagan referencia a atributos de esta
clase o bien asociaciones de la clase.
Todos los elementos que aparecen en la parte izquierda del c odigo 4.3 deben aparecer
en la parte derecha RHS. En otro caso, seran eliminados de la conguracion y por lo
tanto del estado actual, produciendose un estado incompleto. El atributo seq, su selector,
aparecer a debidamente actualizado.
Todas las variables en la transformaci on, ser an variables on the y, es decir, variables
declaradas en el entorno de la regla. Para declarar variables on the y, el tipo de la
variable debe estar a continuaci on del identicador de la variable, con el smbolo : como
separaci on. En el codigo 4.3 se puede observar dos variables: Self:Oid y Cf:Conguration.
57
Atributo seq
Dado un estado s del sistema y el c odigo (un modulo Maude M) generado por un
diagrama de secuencia, es posible que s haga matching en varias reglas de M simult anea-
mente. Esto ocasionara una discrepancia entre el orden de los mensajes que el usuario ha
especicado en el diagrama de secuencia y el orden en el que realmente se han ejecutado
las reglas Maude.
Con el n de que la ejecucion de las reglas Maude se realice en el estricto orden en
el que se especican los mensajes en el diagrama de secuencia (y por lo tanto el usuario)
especica, el objeto de tipo Context tendr a un atributo seq con una lista de pares rodeada
por corchetes []. Cada par tendra la sintaxis del c odigo 4.4. El primer par ametro de tipo Int
op (_|_) : Int Int -> SPair [ctor] .
C odigo 4.4: Sintaxis de los pares utilizados en el selector.
representa la rama en la cual esta el mensaje que dicha regla Maude est a describiendo.
Esto tendr a sentido a partir de la secci on 4.2.4, donde se describen los bloques anidados.
En lo que resta de este apartado y siempre que se tenga un diagrama de secuencia sin
bloques anidados CombinedFragment el primer par ametro sera 1. El segundo par ametro es
el orden de la regla actual respecto al diagrama de secuencia. Si la regla Maude esta re-
presentando el primer mensaje, el selector completo de la parte izquierda LHS ser a:
seq : [ ( 1 | 1 ) ]
En la parte derecha RHS el segundo par ametro del selector se incrementar a en una unidad.
Siguiendo este patron, la regla que se corresponde con el mensaje k-esimo del diagrama de
secuencia, tendra un selector en la parte izquierda LHS y en la parte derecha RHS como
se muestra en el siguiente c odigo (la primera lnea para la parte izquierda y la segunda
lnea para la parte derecha):
1 [. . .] seq : [ ( 1 | k ) ] [. . .]
2 =>
3 [. . .] seq : [ ( 1 | k + 1 ) ] [. . .]
58
4.2.3. Casos no generales
A continuacion se van a describir los casos no generales. Es decir, las estructuras
incluidas en algunas reglas del sistema, pero no necesariamente en todas.
Operador resume
En caso de que la regla l este representando una llamada a un metodo m (por ejemplo,
llamada sncrona) en el diagrama de secuencia, y este metodo m vaya precedido de una
llamada a una operacion (es decir, no es una llamada a una creacion de objeto, ni un
mensaje respuesta), deber a a nadirse el operador resume en la parte izquierda LHS de la
regla:
resume(M etodoAnterior, Rst:OclType)
C odigo 4.5: Operador prejo resume.
donde MetodoAnterior es el nombre de la operaci on que se ha llamado en el mensaje
anterior. Es necesario el operador resume para sincronizar las llamadas como se explica en
la seccion 3.3.6.
Operador call
En el caso de que la regla l describa una llamada a un metodo (un mensaje del
tipo #synchCall) de otra clase representada por una lnea de vida (LifeLine), es necesario
a nadir en la parte derecha RHS de la regla l los operadores:
call(NombreM etodoLlamado, V ariableClaseLlamada, (ListaArgumentosM etodo))
C odigo 4.6: Operadores que representan la llamada a un metodo.
donde las variables son:
NombreMetodoLlamado. Es el nombre del metodo que se invoca con el mensaje
que se describe con esta regla Maude.
VariableClaseLlamada. Es la variable, que debe encontrarse en ListaDeArgumen-
tos, de tipo NombreClaseLLamada y destino de la invocaci on del metodo.
ListaArgumentosMetodo. Lista de argumentos (puede ser vaca) correspondien-
te con los parametros que tiene la denici on del metodo. Cada argumento tiene
59
tres elementos: el operador arg, el nombre del par ametro y por ultimo el valor que
instancia ese par ametro (por ejemplo una variable, una expresion, etc.).
La operacion call es tratada por la pila Stack (vease seccion 3.3.6). B asicamente, se
almacena el objeto Context actual en el objeto Stack y se crea un objeto Context para la
operaci on que se ha llamado. Este objeto Context tiene, entre otros atributos, un selector
inicial [ ( 1 | 1 ) ].
Operador return En caso de que la regla l represente alguno de los siguientes escenarios:
La regla es la ultima que describe el diagrama de secuencia que se est a transforman-
do. Se asume que toda operacion devuelve un valor. En caso de ser una operaci on
void tambien devuelve un valor, representado por el mensaje return(null). Este men-
saje return(null) es necesario para la gestion de la pila (secci on 3.3.6).
La regla est a representando un mensaje perdido, el cual modela el return del metodo
que el diagrama de secuencia esta especicando.
En cualqiuera de los dos casos, debe a nadirse el operador return en la parte derecha de la
regla l.
return(V alorRetorno)
C odigo 4.7: Operador prejo return.
En el operador anterior, ValorRetorno representa el valor que devuelve, que deber a co-
rresponderse con el tipo del metodo.
Operador eval
Para poder evaluar expresiones OCL, en mOdCL se introduce el operador prejo eval.
El operador eval tiene la siguiente especicaci on:
op eval : OclExp Configuration -> OclType .
El operador eval eval ua la expresi on OCL del primer par ametro, en la conguraci on dada
como segundo par ametro. Como la expresion OCL deber a ser evaluada en el estado com-
pleto que este presente en el sistema, es necesario recoger toda la conguracion. Para ello
existe un operador:
60
op {_} : Configuration -> Configuration .
C odigo 4.8: Operador {} para una conguracion.
Con el operador anterior, si la parte izquierda de la regla est a rodeada con corchetes
{} y se a nade una variable Cf:Conguration, es posible capturar toda la conguraci on de
objetos del sistema. Esto es debido gracias al matching existente en Maude. De otra for-
ma, sin a nadir los corchetes denidos en el operador { } (c odigo 4.8), cualquier parte de
la conguraci on podra ser unicada con Cf:Conguration y por lo tanto no capturarse el
estado completo. En el codigo generado se utiliza el operador evl porque internamente,
en Maude, se hace un ltrado de la conguracion que eval tiene como segundo par ametro
por motivos de eciencia.
Si el lector accede al c odigo generado por la transformaci on, podra observar que no se
invoca en ning un caso la funci on eval. En su lugar se invoca la funcion evl. Esta funci on
tiene la siguiente especicaci on:
1 op evl : OclExp Configuration -> OclType .
2 eq evl(E:OclExp,
3 < ctx : Context | opN : Op:OpName, obj : Self, args : L:ArgsList >
4 Cf:Configuration)
5 = eval(E:OclExp,
6 < ctx : Context | opN : Op:OpName, obj : Self, args : L:ArgsList >
7 Cf:Configuration
8 env(self <- Self) OpEnv(L:ArgsList)) .
C odigo 4.9: Especicaci on de la funcion evl.
El motivo de realizar una operaci on evl previa a la llamada a eval es doble. Por un lado,
se instancia la variable self al valor del objeto Self (objeto principal del contexto, sobre
el que se est a realizando la operaci on actual). La variable self es una palabra reservada
de OCL y referencia al objeto actual. De esta forma, en las expresiones OCL, al hacer
referencia a self se hara referencia al objeto que referencia el atributo obj del Context. De
la misma forma, se a naden los argumentos de la operaci on y las variables locales (est an
almacenadas como pares en el atributo args del Context) al contexto de mOdCL. As podran
ser utilizados los argumentos o variables locales en las expresiones OCL.
Por otro lado, al a nadir una operacion intermedia podra utilizarse en el futuro para
hacer un ltrado sobre los objetos que se le pasan como conguraci on Cf:Conguration a la
operaci on eval, consiguiendo as una evaluaci on m as eciente.
61
Por ultimo notar que tanto en la parte izquierda LHS como en la derecha RHS el
objeto Context no tiene el atributo seq. Se debe a que carece de sentido el selector en la
evaluacion de una expresi on OCL. Por motivos de rendimiento, desde la transformaci on,
el Context correspondiente a la conguraci on de la operaci on evl/eval no tiene selector.
Ejemplo de transformacion: PersonCar
Para representar el comportamiento, se va utilizar el mismo ejemplo presentado en la
secci on 4.1.1. En particular se va a especicar la operaci on Person::drive().
(a) Diagrama de clases.
(b) Diagrama de secuencia de la operacion: Per-
son::drive()
Figura 4.3: Diagramas del ejemplo: Persona-Coche.
En el diagrama de secuencia representado en la gura 4.3(b) se representa la asocia-
ci on person owns car y se establecen dos lneas de vida: PPers y CCar. Ambas correspon-
dientes a Person y Car respectivamente.
62
El primer mensaje de la secuencia, con la signatura que se muestra en la gura 4.3(b)
(la signatura con la que se ha denido la operacion en el diagrama de clases) y con nombre
1:getOn tiene un argumento correspondiente al parametro person. El argumento tiene
como nombre el par ametro y como cuerpo la variable instanciada, self.
Para la operaci on Person::drive() se debe generar el codigo Maude 4.10.
Con objeto de representar la correspondencia entre cada elemento del diagrama de
secuencia de la gura 4.3(b) con el c odigo 4.10, en la gura 4.4 se muestran las asociaciones
principales.
En la gura 4.4 se muestra como cada mensaje genera una regla Maude. Ambas reglas
siguen el esqueleto presentado en esta secci on:
1. La primera regla 1:GETON::CAR se corresponde con el primer mensaje a CCar del
diagrama de secuencia. Como en el parametro se ha utilizado una expresi on (con la
palabra reservada en OCL self, aparece en verde la correspondencia con la expre-
si on eval.
2. La segunda regla 2:START::CAR se corresponde con el segundo mensaje del diagrama.
Como no tiene par ametros, la lista de pares de argumentos del operador call es la
constante empty, que representa la lista vaca.
3. La tercera y ultima regla 3:RETURN especica el return de la operaci on drive. Es
necesario a nadir esta regla aunque no devuelva la operaci on ning un valor. Por un
lado se necesita para incluir el mensaje resume que desbloquea la pila de la llamada a
start y por otro, para hacer un correcto funcionamiento de la pila (vease seccion 3.3.6)
a nadir el mensaje return.
El diagrama debe ser completo para que el c odigo sea ejecutable. Por lo tanto, cada
operaci on llamada con una llamada sncrona, debe ser especicada en su correspondiente
diagrama. Por ejemplo, la operacion getOn es especicada en la gura 4.5(a) y la operaci on
start en la gura 4.5(b).
63
1 rl [1:GETON::CAR] :
2 { < ctx : Context | opN : drive, obj : Self:Oid, args : (AL-1:ArgsList),
3 seq : [ ( 1 | 1 ) ] >
4 < Self:Oid : P:Person | car : VAR4:OclType, AS-1:AttributeSet >
5 Cf:Configuration
6 } =>
8 seq : [ ( 1 | 2 ) ] >
10 call(getOn, VAR4:OclType, (arg(person, evl(self, < ctx : Context | opN : drive
, obj : Self:Oid, args : (AL-1:ArgsList) > < Self:Oid : P:Person | car :
VAR4:OclType, AS-1:AttributeSet > Cf:Configuration))))
11 Cf:Configuration
12 } .
13
14 rl [2:START::CAR] :
16 seq : [ ( 1 | 2 ) ] >
18 resume(getOn, Rst:OclType)
19 Cf:Configuration
20 } =>
22 seq : [ ( 1 | 3 ) ] >
24 call(start, VAR4:OclType, empty)
25 Cf:Configuration
26 } .
27
28 rl [3:RETURN] :
30 seq : [ ( 1 | 3 ) ] >
32 resume(start, Rst:OclType)
33 Cf:Configuration
34 } =>
36 seq : [ ( 1 | 4 ) ] >
38 return(null)
39 Cf:Configuration
40 } .
C odigo 4.10: C odigo Maude correspondiente a la operaci on Person::drive().
64
Figura 4.4: Correspondencias del modelo de entrada y la salida obtenida.
(a) Diagrama de secuencia de la operacion Car::getOn(Person). (b) Diagrama de secuencia de la
operacion: Car::start()
Figura 4.5: Diagramas del ejemplo: PersonCar.
65
4.2.4. Bloques anidados: condicionales y bucles
En esta secci on se va a describir la transformaci on necesaria para generar c odigo
Maude que especique un diagrama de secuencia con bloques anidados. Para mejorar la
comprensi on del lector sobre dicha transformacion, se van a presentar algunos conceptos
del metamodelo UML y de c omo UML representa un diagrama de secuencia.
Como representa UML un bloque anidado?
Un diagrama de secuencia UML es una instancia de la clase Interaction. Por ejemplo,
el diagrama presentado en la gura 4.5(a) es un objeto de tipo Interaction. La clase Interac-
tion tiene muchos atributos, entre ellos, el atributo specication que indica la operacion que
se est a especicando en dicha interaccion (o diagrama). Por otro lado, toda interacci on
de tipo Interaction tambien tiene tres atributos, de cardinalidad m ultiple y denominados:
fragment, lifeline y message. Tanto lifeline y message son conjuntos ordenados que contienen
todas las lneas de vida y mensajes de la interacci on respectivamente. Por otro lado, el
atributo fragment es el conjunto ordenado de todos los InteractionFragment. La acci on de
enviar un mensaje
1
o los bloques anidados, son ejemplos de los elementos subtipos de
InteractionFragment que pueden ser almacenados en el atributo fragment. En la gura 4.6 se
muestra el diagrama de clases del concepto Interaction. Se observa la asociacion entre In-
teraction e InteractionFragment.
Figura 4.6: Diagrama de clases de Interaction.
1
Un mensaje que representa una llamada sncrona tiene un evento de envo y uno de recepcion, ambos
de tipo MessageOcurrenceSpecication.
66
Figura 4.7: Diagrama de clases de CombinedFragment.
67
Un bloque anidado es un objeto de tipo CombinedFragment. En el diagrama de clases
de la gura 4.7 se muestran las relaciones de CombinedFragment con otros objetos. La
clase CombinedFragment especializa la clase InteractionFragment. Por lo tanto, un objeto de
tipo CombinedFragment puede ser un elemento del atributo fragment de un objeto Interaction.
Un bloque anidado, es decir, un objeto de tipo CombinedFragment puede ser de diversos
tipos. En particular, esta descripcion se va a centrar en el tipo alt. Se ha elegido el tipo alt
porque es el bloque mas utilizado, ya que se corresponde con la estructura if then else de
un lenguaje de programacion como Java. Un objeto del tipo CombinedFragment tiene un
n umero positivo de objetos de tipo InteractionOperand, en su atributo operand.
Cada objeto de tipo InteractionOperand est a representando un bloque con guarda den-
tro de la interacci on. Ademas, cada objeto InteractionOperand tiene un conjunto ordenado
de InteractionFragments en su atributo fragment, al igual que un objeto de tipo Interaction.
Esto permite tener tantos anidamientos como se quieran. En esta transformacion s olo se
tiene en cuenta el anidamiento de un bloque.
Selector con varias ramas
El selector (atributo seq del Context) se ha explicado en la secci on 4.2.2. Hasta ahora,
se ha tenido en cuenta una rama de ejecucion principal por lo que el selector ha sido de la
forma ( 1 | k ), donde k representa el mensaje k-esimo. Sin embargo, el primer argumento
del selector con operador ( | ) indica que rama es la que est a representando la regla Maude
que contiene este selector. Por ejemplo, en el siguiente pseudo-c odigo:
1 op1
2 op2
3 if cond1 then
4 op3
5 else if cond2 then
6 op4
7 else
8 op5
9 fi
10 op6
C odigo 4.11: C odigo con un esquema de ejemplo.
se consideran tres ramas, una para cada bloque de sentencias englobados por una condi-
ci on. En este caso, el primera argumento n del selector est a indicando que la regla Maude
est a representando un mensaje de la rama n-esima.
El atributo selector tiene una lista de pares. Esto es as porque en realidad hace la
funci on de una pila, ya que al acabar el bloque anidado, la ejecucion debe continuar por
68
el bloque del nivel inmediatamente superior. Por ejemplo, para la sentencia op4 del codi-
go 4.11, el selector de la parte izquierda LHS sera:
< ctx : Context | [. . .] seq : [ ( 1 | 3 ) ( 2 | 1 ) ] >
De esta forma, una vez que se acabe la operacion op4, el segundo par del selector ser a eli-
minado y la ejecuci on seguir a por la tercera operacion del bloque principal, es decir, por
la operacion op6.
Transformando un bloque alt
En los dos apartados anteriores se han mostrado como UML representa un bloque
anidado (es decir, un objeto CombinedFragment) y como se usa el selector para varias
ramas. En este apartado se va a describir c omo se transforma un bloque anidado de
tipo alt a reglas Maude. Un bloque anidado CombinedFragment de tipo alt es el objeto
UML se corresponde con la estructura if then else .
Un objeto de tipo CombinedFragment tiene un n umero positivo de ramas, denominadas
en UML InteractionOperand. En la transformacion, se va a crear una regla con condicion
por cada InteractionOperand de un CombinedFragment. Un InteractionOperand tiene una
guarda, que en el caso los modelos a transformar, ser a una guarda de tipo OpaqueExpression
escrita en mOdCL. Esta guarda sera evaluada con la funci on evaly se espera que devuelva
un valor de tipo Bool. El resultado de esta evaluacion condicionar a la regla creada para
este InteractionOperand.
Para mostrar este proceso de forma m as intuitivo, se va a presentar un nuevo ejemplo,
el calculo recursivo del elemento n-esimo de la serie Fibonacci.
En la gura 4.8(a) se muestra el diagrama de clases utilizado para este ejemplo. Es
necesario tener una clase vaca CallingClass (s olo con una asociacion a AnInteger para
realizar la llamada al metodo b.
En la gura 4.8(b) se especica la operaci on AnInteger::b(Integer). Aparecen muchos
elementos nuevos no detallados hasta ahora: Como especicar el valor que devuelve una
operaci on? Como especicar variables auxiliares?. Estas cuestiones seran descritas en la
secci on 4.2.5.
En el ejemplo de Fibonacci se muestra un bloque anidado, objeto CombinedFragment, en
su diagrama de secuencia. Este CombinedFragment est a compuesto por dos InteractionOpe-
rand (separados en el dibujo por una linea discontinua). Como ya se ha mencionado, para
hacer la seleccion de la rama, es necesario transformar este bloque a un c odigo Maude don-
69
(a) Diagrama de clases.
(b) Diagrama de secuencia de la operacion: AnInteger::b(Integer)
Figura 4.8: Diagramas del ejemplo: Fibonacci.
70
de haya tantas reglas condicionales como InteractionOperand haya en el CombinedFragment.
La condicion de cada regla ser a el cuerpo de la guarda de dicho InteractionOperand: n < 2
y n >= 2. El c odigo 4.12 muestra el codigo generado para ambos InteractionOperand.
1 crl [IF-1] :
2 { < ctx : Context | opN : fib , obj : Self:Oid , args :
3 ( arg(in, In1:Integer) , AL-1:ArgsList ) , seq : [ ( 1 | 1 ) ] >
4 < Self:Oid : A:AnInteger | AS-1:AttributeSet > Cf:Configuration
5 } =>
7 ( arg(in, In1:Integer) , AL-1:ArgsList ) ,
8 seq : [ ( 1 | 2 ) ( 1 | 1 ) ] >
10 } if evl(in < 2, < ctx : Context | opN : fib , obj : Self:Oid , args : ( arg(in,
In1:Integer) , AL-1:ArgsList ) > < Self:Oid : A:AnInteger | AS-1
:AttributeSet > Cf:Configuration) .
11
12 crl [IF-2] :
14 ( arg(in, In1:Integer) , AL-1:ArgsList ) , seq : [ ( 1 | 1 ) ] >
16 } =>
18 ( arg(in, In1:Integer) , AL-1:ArgsList ) ,
19 seq : [ ( 1 | 2 ) ( 2 | 1 ) ] >
21 } if evl(in >= 2, < ctx : Context | opN : fib , obj : Self:Oid , args : ( arg(in
, In1:Integer) , AL-1:ArgsList ) > < Self:Oid : A:AnInteger | AS-1
:AttributeSet > Cf:Configuration) .
C odigo 4.12: Codigo generado a partir de los dos InteractionOperand del ejemplo Fibonacci.
En la gura 4.9 se muestra en azul la correspondencia entre InteractionOperand y cada
regla Maude que selecciona el bloque que se ejecutar a (observese en rojo el selector creado
para cada bloque). En verde se muestra la correspondencia entre la guarda del bloque y
la condicion de la regla Maude.
71
Figura 4.9: Correspondencia entre InteractionOperand y reglas Maude.
4.2.5. Argumentos de las operaciones y variables
En la seccion 4.2.1 se justica por que a nadir expresiones OCL en los argumentos
de los mensajes del diagrama de secuencia. En esta secci on se va a detallar el esquema
necesario para transformar las expresiones OCL/mOdCL
2
de los argumentos, las variables
locales al diagrama de secuencia y modelar los mensajes de retorno.
Un mensaje en un diagrama de secuencia es un objeto UML de tipo Message. Un Mes-
sage tiene una signatura en su atributo signature que ser a una operaci on Operation cuando
el mensaje este modelando la llamada a un metodo. Esta operacion Operation tendr a una
lista (mas precisamente es un OrderedSet) con k par ametros, es decir, k objetos de tipo Pa-
rameter. Para que el mensaje Message sea correcto, debe tener exactamente k argumentos,
es decir, objetos de tipo ValueSpecication que se eval uen a al tipo del par ametro al que
corresponda. En otras palabras, el argumento i con 0 i k debe de tener un tipo
de acuerdo al parametro i de la operaci on que sea signatura del mensaje que contiene el
argumento.
2
La unica diferencia entre OCL y mOdCL es que este ultimo necesita tener los operadores separados
por espacios, para que Maude pueda tokenizar los operadores.
72
Expresiones mOdCL como argumentos
Dentro de la estructura de clases que se despliega a partir de ValueSpecication se van
a emplear objetos del tipo OpaqueExpression. La clase OpaqueExpression, que especica Va-
lueSpecication, a nade dos atributos con cardinalidad 0..: body y language, ambos de tipo
String. Para cada lenguaje denido en la posici on i del atributo language, en la posici on i
del atributo body debe haber una expresion computable en el lenguaje mencionado.
Cada objeto OpaqueExpression tiene un tipo, que ser a el tipo esperado al evaluar la lista
de bodys. En particular, siempre vamos a tener en cuenta que solo existe un valor en
body con lenguaje correspondiente mOdCL.
Para el ejemplo de Fibonacci, es necesario utilizar una expresion mOdCL para decre-
mentar el par ametro de la interacci on actual in en una o dos unidades en ambos mensajes
al metodo b, como se muestra en la gura 4.8(b). Por ejemplo, la primera de ellas se
creara como se muestra en la gura 4.10.
Figura 4.10: Expresion mOdCL como argumento del mensaje b.
Observese en la gura 4.10 el nombre del argumento, que coincide con el nombre
del parametro de la operaci on. Se puede denir el lenguaje como mOdCL, y su cuerpo
correspondiente en el atributo body. Por ultimo cada OpaqueExpression tiene un tipo, que
es el tipo que se espera una vez la expresi on haya sido evaluada. En este caso el tipo es
Integer.
De esta forma, se podra escribir cualquier expresion. Volviendo al ejemplo PersonCar,
73
en la operacion Car::getOn(Person) descrita con un diagrama de secuencia en la gura 4.5(a),
se usa el objeto OpaqueExpression descrito en la gura 4.11.
Figura 4.11: Expresion mOdCL como argumento del mensaje b.
Uso de variables locales
Como se ha mencionado en la secci on 4.2.2, la lista de pares del atributo arg del obje-
to Context de cada regla Maude contiene: par ametros de la operaci on que se esta deniendo
(o parametros del diagrama de secuencia) y las variables locales que se esten utilizando.
Como variable local puede considerarse un valor Integer de un calculo intermedio, o un
objeto que se haya creado con un mensaje de tipo Create (como se realiza en el captulo 6
y 5).
En el caso del ejemplo Fibonacci es necesario almacenar las dos llamadas que se realizan
en el caso general de la recurrencia. Estas llamadas se realizan con mensajes sncronos
con signatura AnInteger::b(Integer):Integer. Llamemosle auxInt1 y auxInt2 a los valores de
retorno de las dos llamadas, respectivamente.
Al inicio de esta seccion (secci on 4.2.5) se ha mencionado la estructura en UML de los
mensajes y sus argumentos. El tipo de una operaci on, es decir, el tipo que va a devolver,
es un parametro Parameter m as de esta, por lo que necesita tener un argumento en el
mensaje que la invoca. Este argumento ser a el ultimo (el que corresponde en posici on
con el par ametro con direccion return) y tendr a como nombre la variable donde se va a
74
almacenar. Esta variable debera tener un identicador unico
3
.
En la gura 4.12 se muestra la lista completa de argumentos del mensaje que realiza
la primera llamada a AnInteger::b(Integer):Integer. Con ese mensaje se esta realizando la
siguiente llamada:
auxInt1 = fib(in - 1)
Con esta llamada, se espera que se bloquee la ejecucion actual hasta que un valor de
retorno se haya obtenido de la ejecuci on de b(in - 1). Es decir, se espera que se cree
un nuevo contexto de ejecuci on para la operaci on llamada. Este contexto de ejecuci on
devolvera nalmente un valor y el contexto actual podr a continuar su ejecucion.
En terminos de mOdCL, se deben crear dos reglas Maude: la primera con el ope-
rador call en su parte derecha RHS y la segunda con el operador resume en su parte
izquierda LHS. El operador resume tiene dos par ametros: el nombre de la operacion y el
valor de retorno (vease seccion 4.2.3). En la segunda regla, se a nadir a un par m as a la lista
de pares del contexto Context, con nombre la variable auxiliar denida en el argumento
que corresponde con el par ametro return y con valor el devuelto en el segundo parametro
del operador resume. En el c odigo 4.13 se muestra el c odigo generado para estas dos reglas.
Figura 4.12: Lista de argumentos del mensaje que invoca a la operacion b.
3
Se podran generar identicadores unicos de forma estatica en la transformacion, pero a nadira com-
plejidad innecesaria y se ha dejado para trabajo futuro.
75
1 rl [2:FIB_MESSAGE::ANINTEGER] :
2 { < ctx : Context | opN : fib, obj : Self:Oid, args : ( arg(in,In1:Integer),
3 AL-1:ArgsList), seq : [ ( 1 | 2 ) ( 2 | 1 ) ] >
4 < Self:Oid : A:AnInteger | AS-1:AttributeSet >
5 Cf:Configuration
6 } =>
8 AL-1:ArgsList), seq : [ ( 1 | 2 ) ( 2 | 2 ) ] >
10 call(fib, Self:Oid, (arg(in, evl(in - 1, < ctx : Context | opN : fib , obj :
Self:Oid , args : (arg(in, In1:Integer), AL-1:ArgsList) > < Self:Oid :
A:AnInteger | AS-1:AttributeSet > Cf:Configuration))))
11 Cf:Configuration
12 } .
13
14 rl [2:FIB_MESSAGE::ANINTEGER-RESUME] :
16 AL-1:ArgsList), seq : [ ( 1 | 2 ) ( 2 | 2 ) ] >
18 resume(fib, Rst:OclType)
19 Cf:Configuration
20 } =>
22 arg(auxInt1, Rst:OclType), AL-1:ArgsList), seq : [ ( 1 | 2 ) ( 2 | 3 ) ] >
24 Cf:Configuration
25 } .
C odigo 4.13: C odigo generado a partir del mensaje auxInt1 = b(in - 1).
Expresiones en los valores de retorno
Un diagrama de secuencia que especique el comportamiento din amico de una opera-
ci on con un tipo de retorno (un par ametro con direcci on return), deber a tener uno o mas
mensajes perdidos que denan los valores de retorno.
En un diagrama de secuencia, un valor de retorno se dene con un mensaje perdido
(en Papyrus Message Lost). Un mensaje perdido es un objeto de tipo Message de tipo
asynchSignal, con la particularidad de que mientras un mensaje que dene una llamada
sncrona a un metodo tiene dos eventos sendEvent y recvEvent para almacenar los datos
de donde parte la llamada y donde se recibe, un mensaje perdido s olo tendr a denido su
sendEvent.
Un mensaje perdido tendra solo un argumento de tipo OpaqueExpression, que en mOdCL
especicar a el valor de retorno. Este mensaje perdido ser a transformado a una regla Maude
con el operador return en su parte derecha y como par ametro, tendr a la evaluaci on del
cuerpo del argumento. En la gura 4.13 se ilustra ambos mensajes perdidos del ejemplo
76
de Fibonacci.
(a) Mensaje de retorno del caso base
de Fibonacci.
(b) Mensaje de retorno del caso general de Fibo-
nacci.
Figura 4.13: Diagramas del ejemplo: Fibonacci.
En el c odigo 4.14 y 4.15 se muestra las dos reglas Maude generadas a partir de los
mensajes perdidos del diagrama de secuencia. Comp arese con el ejemplo de PersonCar
(secci on 4.2.3). En el ejemplo de PersonCar, ninguna operaci on tiene tipo de retorno, por
lo tanto los diagramas de secuencia no tienen mensajes perdidos. A pesar de ello, en sus
transformaciones se genera una regla con el operador return y valor null para cada inter-
acci on o diagrama de secuencia. Esto es debido a que es necesario en toda especicaci on
el operador return para el correcto funcionamiento de la pila.
1 rl [1:MESSAGE_RETURN::] :
2 { < ctx : Context | opN : fib, obj : Self:Oid, args : (arg(in, In1:Integer), AL
-1:ArgsList ), seq : [ ( 1 | 2 ) ( 1 | 1 ) ] >
4 Cf:Configuration
5 } =>
-1:ArgsList), seq : [ ( 1 | 2 ) ( 1 | 2 ) ] >
8 return(evl(1, < ctx : Context | opN : fib, obj : Self:Oid, args : (arg(in,
In1:Integer), AL-1:ArgsList ) > < Self:Oid : A:AnInteger | AS-1
:AttributeSet > Cf:Configuration))
9 Cf:Configuration
10 } .
C odigo 4.14: C odigo generado a partir del primer mensaje perdido.
77
4.3. Conguraciones de objetos: Ejecuci on de ejemplos.
1 rl [4:MESSAGE_RETURN::] :
-1:ArgsList ), seq : [ ( 1 | 2 ) ( 2 | 5 ) ] >
4 Cf:Configuration
5 } =>
-1:ArgsList ), seq : [ ( 1 | 2 ) ( 2 | 6 ) ] >
8 return(evl(auxInt1 + auxInt2, < ctx : Context | opN : fib, obj : Self:Oid, args
: (arg(in, In1:Integer), AL-1:ArgsList ) > < Self:Oid : A:AnInteger | AS-1
:AttributeSet > Cf:Configuration))
9 Cf:Configuration
10 } .
C odigo 4.15: C odigo generado a partir del segundo mensaje perdido.
Modicando atributos con expresiones OCL
En la secci on 4.2.1 se justica el uso de las expresiones OCL para realizar modicacio-
nes en los valores de los atributos de un objeto. Aqu se va a describir como realizar estas
modicaciones y c omo expresar estas expresiones OCL en un diagrama de secuencia.
Volviendo al ejemplo PersonCar, tanto la sem antica de la operaci on Car::getOn(Person)
como la de la operacion Car::start() requieren la modicaci on del estado del objeto. Para
cualquiera de estas dos operaciones, en su diagrama de secuencia se debe crear un Message
Found deniendo la llamada que se crea. En este Message Found deben aparecer un
argumento por cada atributo modicado. Cada argumento ser a un objeto OpaqueExpression
con nombre el atributo a modicar y con cuerpo la expresi on mOdCL deseada.
Estos argumentos seran transformados a expresiones eval, cuyo resultado ser a almace-
nado en el atributo correspondiente del objeto Self presente en cada regla.
Observese como ejemplos la gura 4.5, donde se ilustran ambos diagramas para las
operaciones Car::getOn(Person) y Car::start().
4.3. Conguraciones de objetos: Ejecucion de ejem-
plos.
En las secciones anteriores se ha explicado c omo se transforma un sistema especicado
con un diagrama de clases UML y uno o varios diagramas de secuencia a codigo Maude.
78
O dicho con otras palabras, como se corresponde cada elemento de un diagrama de cla-
ses con constructores Maude y c omo cada construcci on de un diagrama de secuencia se
corresponde con parte de las reglas Maude generadas.
Esta transformaci on no es suciente para poder ejecutar el sistema en Maude, ya que
el estado inicial debe ser especicado directamente en Maude. En esta seccion se van a
describir estados iniciales y restricciones a evaluar sobre los ejemplos ilustrados en esta
secci on: PersonCar y Fibonacci.
En la evaluacion del sistema se va a suponer que todos los objetos que se creen son
conforme al diagrama de clases UML que representa el sistema.
Ejecucion del ejemplo PersonCar
Para el ejemplo PersonCar un estado inicial podra ser como el siguiente:
1 ops antonio pablo javier : -> Oid .
2 op ferrari : -> Oid .
3
4 op init-state : -> Configuration .
5 eq init-state =
6 < antonio : Person | car : ferrari >
7 < ferrari : Car | started : false, passengers : Set{mt-ord} >
8 < pablo : Person | none >
9 < javi : Person | none > .
C odigo 4.16: Estado inicial PersonCar.
Sobre un diagrama de clases UML se pueden denir cuantos invariantes se deseen. De
esta forma se podra denir el siguiente invariante comprueba que si un coche est a arran-
cado, debe tener alg un pasajero en su interior:
op CarEmptyStopped : -> OclExp .
eq CarEmptyStopped =
context Car inv started implies passengers -> size() > 0 .
El invariante anterior puede ser comprobado sobre el estado inicial del codigo 4.16 con
la siguiente llamada:
79
reduce in PERSONCAR-VALIDATION-TEST : eval(CarEmptyStopped, init-state) .
result Bool: true
De esta forma, es posible completar la especicaci on restringiendo ciertos estados que
no se desean que sean accesibles. Si todos estos invariantes se a naden a la ecuacion inv, el
evaluador comprobar a estos invariantes en todos los estados del sistema.
Con la operaci on eval (descrita en la seccion 3.3) se puede evaluar cualquier expresion
OCL sobre la conguraci on inicial.
Para ejecutar el estado inicial del c odigo 4.16 sobre la especicacion Maude de la ope-
raci on Person::drive() es necesario a nadir el mensaje call. A continuaci on, en el codigo 4.17
se ilustra el c odigo inicial que inicia la ejecuci on de la operacion Person::drive()
4
:
1 op init-state-ready-drive : -> Configuration .
2 eq init-state-ready-drive =
3 init-state
4 call(drive, antonio, empty) .
C odigo 4.17: Estado inicial que inicia la ejecucion de Person::drive().
El resultado proporcionado por la consola Maude de reescribir la conguraci on ante-
rior es el estado siguiente:
rewrite in PERSONCAR-VALIDATION-TEST : [init-state-ready-drive] .
result Configuration+: { resume(drive, null)
< stack : Stack | state : nil > < javier : Person | none >
< antonio : Person | car : ferrari > < pablo : Person | none >
< ferrari : Car | started : true,passengers : Set{antonio} >}
Observese en el termino de tipo Conguration anterior que el coche ferrari tiene el atri-
buto started a true y como pasajero a antonio.
4
Tengase en cuenta que se utiliza el estado especicado en el codigo 4.16.
80
Ejecucion del ejemplo Fibonacci
La conguraci on de objetos inicial para el ejemplo Fibonacci es muy sencilla. De
acuerdo al diagrama de clases ilustrado en la gura 4.8(a), solo es necesario mantener un
objeto AnInteger y realizar sobre este llamadas a la operacion AnInteger::b(Integer):Integer.
Con objeto de realizar varias trazas se van a crear estados iniciales para cuatro casos,
descritos en el c odigo 4.18.
1 op imAnInteger : -> Oid .
2
3 op init-state-1 : -> Configuration .
4 eq init-state-1 =
5 < imAnInteger : AnInteger | none >
6 call(fib, imAnInteger, (arg(in, 1))) .
7
9 eq init-state-10 =
12
17
C odigo 4.18: Estados iniciales para la ejecuci on del ejemplo de Fibonacci.
Para este ejemplo, no se ha creado ning un invariante, por lo que se debe a nadir la
lnea:
eq inv = true .
Por otro lado, en este ejemplo se la utilidad de especicar pre- y poscondiciones a la
operaci on AnInteger::b(Integer):Integer.
La operacion Fibonacci podra expresarse con la siguiente pre- y poscondicion:
81
Operacion:
fib(in:Integer):Integer
Precondicion:
in 1
Poscondicion:
1
1 +
5
2
in
5
2
in
La poscondici on es la ecuaci on explcita de la recurrencia de Fibonacci. Cualquier
operaci on que cumpla la pre- y poscondicion anteriores es una operaci on que calcula
correctamente el elemento in-esimo de la sucesi on de Fibonacci. Esta pre- y poscondici on
queda especicada en Maude el c odigo 4.19.
1 eq pre(fib) = in >= 0 .
2
3 eq post(fib) =
4 (((1 / 5 . sqrt()) * (((1 + 5 . sqrt()) / 2)) . pow(in) -
5 (1 / 5 . sqrt()) * (((1 - 5 . sqrt()) / 2)) . pow(in)) - result)
6 . abs() < 0.00001 .
C odigo 4.19: Pre- y poscondici on de la operacion b.
Se asume un error de 10
5
en la poscondicion por el error derivado de realizar las
operaciones en punto otante. Por otro lado, la constante result tendr a el valor resultante
de la operaci on b.
La especicaci on dada con el diagrama de secuencia y transformada a codigo Maude
de la operaci on Fibonacci cumple las pre- y poscondiciones para los casos mencionados
en el c odigo 4.18. La ejecuci on de dichos estados iniciales devuelve las siguientes salidas:
82
rewrite in TEST-AN-INTEGER-FIB : [init-state-1] .
result Configuration+: {resume(fib, 1) < stack : Stack | state : nil >
< imAnInteger : AnInteger | none >}
Una ejecucion incorrecta podra ser una llamada con el par ametro in instanciado a un
valor negativo (ya que no se cumple la precondici on). Por ejemplo si se reescribe el estado
inicial siguiente:
op init-state-error : -> Configuration .
eq init-state-error =
< imAnInteger : AnInteger | none >
call(fib, imAnInteger, (arg(in, -5))) .
se obtiene como salida:
rewrite in TEST-AN-INTEGER-FIB : [init-state-error] .
result Configuration+: {error("Invariant or precondition violation", fib,
< imAnInteger : AnInteger | none >)}
4.4. Detalles tecnicos de la transformacion
El objetivo de esta seccion no es documentar la transformaci on modelo a modelo
realizada en ATL (secci on 3.4), sino profundizar en los esquemas de transformaci on pre-
83
sentados en la secci on 4.1 y 4.2. Se va a profundizar lo adecuado para que el lector pueda
visualizar la transformacion sin conocer los detalles del lenguaje ATL.
Al iniciar el presente proyecto n de carrera, se puso como objetivo generar un esque-
leto Maude que sera completado por el usuario. Con esta restricci on de ser completado
por un usuario, la transformaci on debera generar un c odigo sucientemente legible y or-
denado. Debido a este motivo, la complejidad de la transformaci on aument o, puesto que
ATL es un lenguaje declarativo y el orden de ejecuci on de las reglas no puede ser estable-
cido. Si las reglas ATL no son ejecutadas en el orden deseado (el orden en el que aparecen
los mensajes en el diagrama de secuencia) las reglas Maude generadas no apareceran en
orden y por lo tanto, el c odigo generado no sera legible. Aunque posteriormente y gracias
a a nadir expresiones mOdCL como argumentos de los mensajes el codigo es completamen-
te ejecutable y no necesita ser completado, la transformaci on sigue produciendo c odigo
absolutamente legible.
En esta secci on se van a suponer como conocidos todos los detalles introducidos en 3.4
sobre el lenguaje ATL.
Aunque al explicar las diferente estructuras de la transformacion durante este captulo
se ha dividido en la transformaci on de la estructura del sistema (diagrama de clases UML)
y la del comportamiento (diagrama de secuencia UML), en la pr actica, toda la transfor-
maci on es agrupada en un m odulo ATL SD2Maude. Este m odulo tiene como cabecera:
module SD2Maude;
create OUT: MAUDE from IN: UML;
Es decir, se crea un modelo OUT conforme al metamodelo de Maude (vease secci on 3.2.7)
a partir de un modelo IN conforme al metamodelo UML (denido en [uml05]).
Como se ha explicado en la sem antica de ejecucion de ATL en la secci on 3.4, en ATL
existen dos modicadores especiales para las reglas Called Rules:
entrypoint La regla Called Rule con este modicador es ejecutada al principio de la
transformaci on, durante el proceso de inicializacion.
endpoint La regla Called Rule con este modicador es ejecutada al nal de la trans-
formaci on, despues de la fase de inicializacion de los elementos destino.
A pesar de que el codigo imperativo no esta recomendado en ATL, es indispensable
su uso en las reglas entrypoint/endpoint (son imperativas por naturaleza) para preparar
ciertas estructuras que se describir an en esta seccion y para reordenar las reglas Maude
generadas, respectivamente.
84
La unica forma de obtener identicadores unicos en ATL es tener un atributo de m odu-
lo que sea un valor entero, y sea incrementado desde un codigo imperativo cada vez que
sea utilizado. El siguiente fragmento de c odigo muestra la denici on del atributo con su
iniciaci on y el codigo necesario invocar desde un bloque imperativo ATL:
1 helper def: varCounter: Integer =
2 1;
3
4 -- Incrementar la variable desde un bloque imperativo
5 thisModule.varCounter <- thisModule.varCounter + 1;
4.4.1. Iniciaci on de la transformacion
La regla entrypoint de este transformaci on es de especial menci on, pues en ella se crean
los modulos Maude y se preparan diversas estructuras que se usaran a lo largo de toda
la transformacion. En esta secci on se van a enumerar las acciones llevadas a cabo en la
regla entrypoint.
entrypoint rule Initialize() [. . .]
Modulos Maude. Para cada sistema, se crean dos modulos Maude: el modulo que
contiene la denici on de la estructura y el que contiene las reglas que especican el com-
portamiento. El primero tendr a como nombre CLASSES-NameMainInteraction y el segundo
NameMainInteraction, donde NameMainInteraction es el nombre de la interacci on princi-
pal. Adem as, como las reglas estan denidas usando las estructuras del sistema, se crea
la importaci on (de tipo protecting) del modulo CLASSES y se agrega al modulo del com-
portamiento. Tambien se utilizan mas importaciones como el modulo mOdCL y modulos
auxiliares. Por ultimo, tanto el m odulo que especica la estructura del sistema y como el
que especica el comportamiento, son almacenados en dos atributos de m odulo de ATL.
Estos deben ser accesibles para poder a nadir elementos al modulo.
85
[. . .]
thisModule.sMod <- m; -- Behavior module
thisModule.classesMod <- classesM; -- Classes module
[. . .]
C odigo 4.20: Asignaci on de los modulos creados a atributos de modulo.
En ATL existe un tipo de datos colecci on denominado Map y que se corresponde con
el tipo abstracto de datos mapa. Un mapa asigna para cada clave key un valor value.
Los mapas pueden ser instanciados con cualquier tipo de datos de ATL, por ejemplo, es
posible crear un Map que para cada valor Int asigne una coleccion Sequence(Int).
Mapa Elemento-Atributo. La palabra Atributo es usado en este contexto como
el primer par ametro del par introducido por el operador arg. Es decir, en el par arg(in,
In1:Int) el atributo es in. Como se ha mencionado en la secci on 4.2, en cada regla existira un
objeto de tipo Context con un conjunto de pares, donde se incluiran: los argumentos de la
operaci on que se este deniendo y las variables auxiliares. Este mapa es declarado como
sigue
5
:
helper def: mapNamedElementAttribute: Map(UML!NamedElement, String) =
Map{};
A cada objeto que va a ser a nadido al conjunto de argumentos del objeto Context, se le
asigna un valor String. Es fundamental esta estructura para tener una coherencia durante
todo el c odigo en el nombre de los atributos (tener en cuenta que al inicio, puede asignarse
una cadena arbitraria). El proceso de a nadir parametros al mapa se puede dividir en las
siguientes fases independientes:
1. A nadir todos los par ametros que no sean de retorno de aquellas operaciones descritas
por un diagrama de secuencia (un objeto Interaction). El nombre de estos atributos
coinciden con el nombre del par ametro. Aunque esto conlleva que no pueden existir
dos par ametros con el mismo nombre, esta decision se ha tomado por hacer el codigo
m as legible, ya que simplemente se podra haber utilizado un identicador unico.
2. A nadir todas los objetos creados durante las interacciones con mensajes Create.
Estos atributo tendr an como nombre de argumento newVARX, donde X es el valor
del identicador unico.
5
NamedElement es uno de los objetos mas generales del metamodelo UML. Un objeto NamedElement
contiene un atributo de tipo String name.
86
3. Todas las variables locales usadas en el c odigo. Con este n se recorren todos los
argumentos de los mensajes existentes en el modelo de entrada, y se seleccionan
aquellos argumentos cuyo nombre (atributo name) no coincida con ning un par ametro
de ninguna operacion, ni con ning un atributo de todas las clases. Como objeto clave
en el mapa, se introduce el argumento que crea la variable auxiliar. Como valor
String se asocia el nombre de la variable auxiliar.
Mapa Elemento-Variable. De forma an aloga al mapa Elemento-Atributo, este ma-
pa almacenara nombres de variables. El objetivo es mantener una coherencia a nivel de
regla y a nivel de c odigo completo generado por la transformaci on en los nombres de las
variables. De otra forma habra que generar identicadores unicos por cada regla, y tener
cuidado de que tanto la parte derecha como la izquierda de cada regla sigue el mismo
identicador para cada variable. Este mapa es especicado como el anterior:
helper def: mapNamedElementVariable: Map(UML!NamedElement, String) =
Map{};
Este mapa contendr a mas elementos, ya que cada atributo de clase denido en la es-
tructura del sistema, tendra su propio identicador de variable para cuando tenga que
ser utilizado al denir el objeto Self. El proceso de crear identicadores para todas las
variables sigue el siguiente proceso:
1. Por cada par ametro de una operaci on descrita, se a nade su correspondiente variable,
ya que el par con operador arg tiene dos par ametros, siendo el segundo un valor (de
tipo m as general OclType). Como nombre se utilizar a el nombre del parametro con la
primera letra en may usculas y concatenado con el valor unico thisModule.varCounter.
2. A nadir los atributos de cada clase. Un atributo de clase es representado en UML
con un objeto de tipo Property, es asociado con un String de la forma VAR y el
identicador unico o SET y el identicador unico si tiene cardinalidad variable.
De esta forma se puede crear los objetos Self de una forma sistematica, a nadiendo
todos los atributos con sus variables correspondientes, tanto en la parte izquierda
LHS como en la parte derecha RHS, y siendo coherente el nombre de la variable en
la parte izquierda y en la parte derecha.
3. A nadir las clases asociaci on. Las clases asociacion son a nadidas como una variable
m as. En la seccion 4.1.1 se describe c omo se modela en Maude una clase asociacion.
4. A nadir todos los objetos creados con un mensaje Create. Para todos los objetos
87
creados durante las interacciones, al igual que se han asociado con un atributo
anteriormente, se asocian a un nuevo identicador de variable.
5. A nadir todas las variables locales. Al igual que en el mapa Element-Atributo, aqu se
buscan todas las variables auxiliares utilizadas en las interacciones y se asocia el
argumento a un identicador de variable.
Para el ejemplo PersonCar, ambos mapas hasta ahora descritos quedaran despues del
proceso de iniciaci on como sigue:
MapNamedElementAttribute: Map {(IN!person, person)}
MapNamedElementVariable: Map {(IN!started, VAR2), (IN!person, VAR3),
(IN!passengers, SET1), (IN!car, VAR5),
(IN!car, VAR4), (IN!person, Person1)}
Mapa CurrentVariables. Una vez mas cabe recordar que el objeto Context de cada
regla Maude es como sigue:
< ctx : Context | opN : NombreM etodo, obj : Self:Oid,
args : ListaDeArgumentos, seq : Secuencia>
donde ListaDeArgumentos son los parametros de la operaci on que se esta especicando,
los objetos creados durante la interacci on y las variables auxiliares. Si bien los parame-
tros de la operaci on aparecer an desde la primera regla hasta la ultima, tanto los objetos
creados como las variables auxiliares ser an a nadidas al contexto Context a partir del mo-
mento en el que hayan sido creadas. Es decir, la regla Maude que modela la creaci on
de un objeto con un mensaje Create, tendr a n argumentos en su parte izquierda LHS y
n + 1 argumentos en su parte derecha RHS, siendo el nuevo argumento correspondiente
al objeto creado. Y de forma an aloga para las variables locales. Para poder saber en ca-
da momento que argumentos tiene el contexto Context, se crea e inicia un mapa con la
siguiente denici on:
helper def: currentVariables: Map(UML!Message, OrderedSet(UML!NamedElement)) =
Map{};
En el proceso de iniciaci on se asigna a cada mensaje (objeto UML de tipo Message) un
conjunto de objetos, que pueden ser par ametros, lneas de vida o argumentos (en caso
88
de variables auxiliares) que corresponden con las claves de los mapas Element-Atributo y
Elemento-Variable. Para cada mensaje m, existe una regla Maude que especica su com-
portamiento, y el conjunto de objetos que se corresponde con la clave m en el mapa, es
el conjunto de argumentos que debe tener el contexto en la parte izquierda LHS de dicha
regla.
Es m as sencillo y eciente hacerlo en c odigo imperativo en la iniciacion de la trans-
formaci on porque de no ser as, en cada regla Maude que fuese a ser creada habra que
analizarse que argumentos debe tener el contexto Context.
Por otro lado, se podra realizar una b usqueda de que argumentos son realmente
utilizados en la regla actual y solo a nadir estos, dejando el resto en una variable AL:ArgsList.
Esta mejora en la transformacion no ha sido a un realizada, ya que en la generaci on inicial
de esqueletos que iban a ser completados, no poda asumirse que argumentos no iban a
ser utilizados.
4.4.2. Cuerpo de la transformacion
En esta secci on se describir an las estructuras comunes a todas las reglas ATL Matched
Rules. Las reglas MatchedRules corresponden al cuerpo de la transformaci on. Cada regla
ATL sera asociada por un mensaje y generar a una regla Maude (con alguna excepci on que
ser a detallada m as adelante). Todo el c odigo ATL ha sido modularizado en reglas Lazy
Rules que son invocadas desde las reglas Matched Rules. De esta forma queda un c odigo
ATL muy legible, donde una regla ATL Matched Rule invoca a una regla Lazy Rule por
cada elemento destacable de la estructura de reglas Maude.
Un punto debil de las transformaciones de modelos ATL es un conjunto de variables
muy grande (entiendase por grande a partir de 4 variables) en la parte from de las Matched
Rule. La m aquina de ATL asigna en la primera fase de ejecuci on todas las posibles
combinaciones de objetos a cada regla y posteriormente eval ua las condiciones. Con
modelos de entrada que empiezan a ser grandes (a partir de 200 objetos) la transformaci on
se hace considerablemente lenta (en torno a 30 segundos). Para evitar esta situaci on, se ha
hecho un esfuerzo en tener en la parte from de las reglas ATL Matched Rules estrictamente
las variables indispensables, y obtener el resto de variables en el bloque imperativo using
de cada regla ATL.
Reglas para la estructura del sistema. Unas 5 reglas ATL transforman las clases,
las clases asociaci on, los atributos de clase, las operaciones y los parametros de estas
en sorts Maude o en constantes Maude (de AttributeName, OpName o Arg). Estos objetos
89
Maude se a naden al modulo Maude que contiene la estructura del sistema. Un ejemplo
de codigo podra ser:
1 rule UMLClass2MaudeSort {
2 from
3 class: UML!Class
4 to
5 sort: MAUDE!Sort (
6 name <- class.name,
7 "module" <- thisModule.classesMod
8 ),
9 [. . .] Tambien se crea la relaci on de subsort de Cid
Reglas para transformar el comportamiento del sistema. En lo que respecta a
transformar cada mensaje de una interaccion UML a reglas Maude, se van a enumerar
las principales caractersticas de las reglas ATL usadas con este n. Por ejemplo, la regla
que transforma un mensaje de tipo Synchronous Call (sin almacenar un posible valor de
retorno en una variable auxiliar) de una interacci on en un diagrama de secuencia a una
regla Maude tendra el siguiente bloque from:
1 from
2 inter: UML!Interaction,
3 msg: UML!Message
4 (inter.message->includes(msg) and
5 if (not msg.signature.oclIsUndefined()) and msg.messageSort=#synchCall then
6 msg.signature.ownedParameter
7 ->select(par | par.direction = #return)->size() = 0 or
8 (msg.signature.ownedParameter
9 ->select(par | par.direction = #return)->size() > 0 and
10 msg.argument->size() < msg.signature.ownedParameter->size())
11 else
12 false
13 endif)
B asicamente se busca una mensaje, contenido por una interacci on. Es fundamental tener
la interacci on del mensaje puesto que la interacci on especica una operaci on (atributo
opN del Context) y dicha operaci on pertenece a una clase, al que pertenece el objeto Self.
En la condicion se exige que la interacci on inter contenga al mensaje msg y que no tenga
variable auxiliar para valores de retorno. La ultima condicion se ha dividido en dos, que
no tenga la operacion un par ametro return o bien que tenga un par ametro return pero no
se haya especicado una variable. Esto se debe a que en caso de tener variable auxiliar, se
ejecutara la regla ATL SynchCallWithAuxVar2MaudeRule que crea dos reglas Maude. Una
con la llamada a la operaci on especicada en el mensaje, y una con el operador resume,
90
capturando el valor devuelto y a nadiendolo al contexto Context de la parte derecha de
la segunda regla (la que contiene el operador resume). Finalmente, se navega hasta la
signatura del mensaje con una sentence if then else porque en ATL y OCL no existe la
evaluacion de condiciones en cortocircuito. Esta peculiaridad es descrita con m as detalle
en la secci on 3.4.3.
Para la regla ATL SynchCall2MaudeRule anteriormente mencionada, se va a mostrar el
fragmento de codigo utilizado para crear la parte izquierda LHS y la derecha RHS de la
regla que se genera:
1 [. . .] -- Fragmento de la regla "SynchCall2MaudeRule"
2 externalConfigurationLhs: MAUDE!RecTerm (
3 args <- Sequence{thisModule.CreateContext(inter.debug(), msg.debug()),
4 thisModule.CreateSelfObjectConfigurationLHS(oper),
5 if not precedingMsg.oclIsUndefined()
6 then thisModule.CreateResume(precedingMsg)
7 else OclUndefined endif,
8 thisModule.CreateConfigurationVariable(thisModule.model())}
9 ),
10 externalConfigurationRhs: MAUDE!RecTerm (
11 op <- ____,
12 args <- Sequence{thisModule.CreateContext(inter, msg),
13 thisModule.CreateSelfObjectConfigurationRHS(inter, msg),
14 thisModule.SynchCall2CallMessage(inter, msg),
15 thisModule.CreateConfigurationVariable(thisModule.model())}
16 )
C odigo 4.21: Parte izquierda LHS y derecha RHS de la regla SynchCall2MaudeRule.
La regla LazyRule CreateContext crea el termino que representa el objeto Context. Para
crear el objeto Self es necesario dividirlo en dos Lazy rules distintas porque en la parte
derecha se podran incluir expresiones mOdCL de los argumentos. Por esta raz on, los
par ametros de la primera son unicamente el objeto UML de tipo Operation y en la segunda
tiene el mensaje como par ametro, para poder navegar por los argumentos.
En el bloque using se tiene una variable auxiliar precedingMsg que tendra el valor OclUn-
dened si no hay una llamada anterior (el mensaje msg es el primero, el mensaje anterior
a msg tiene variable auxiliar o bien no es un Synchronous Call ) o el objeto Message co-
rrespondiente al mensaje anterior. En caso de haber mensaje anterior, se crea el operador
resume.
Todos los terminos Maude son construidos siguiendo la sintaxis original con la que
fueron especicados (ya sea inja o preja). Por ejemplo, la sintaxis de los objetos se
especica como un atributo del m odulo ATL. De esta forma se consigue centralizar las
constantes que rigen la sintaxis al inicio del m odulo ATL y mantener la coherencia.
91
helper def: objectOperator: String =
<_:_|_>;
C odigo 4.22: Sintaxis del operador de objetos.
En este sentido, en el codigo 4.21 puede observarse que el objeto Maude RecTerm deno-
minado externalCongurationLhs no tiene operador (atributo op). Esto es debido a que este
termino podra tener 3 o 4 argumentos. Para calcular el operador, en el bloque imperativo
se llama al siguiente helper:
externalConfigurationLhs.op <-
externalConfigurationLhs.getEmptySyntaxOperation();
La operaci on getEmptySyntaxOperation() est a denida en el contexto de MAUDE!RecTerm y
devuelve un String con tantos como argumentos tenga el objeto RecTerm que llama al
helper.
La regla Lazy Rule CreateCongurationVariable crea la variable en Maude Cf:Conguration.
Esta regla es llamada con el objeto raz del modelo UML de entrada, pues no necesita
obtener ning un dato de alg un objeto.
1 lazy rule CreateConfigurationVariable {
2 from
3 model: UML!Model
4 to
5 varCf: MAUDE!Variable (
6 type <- thisModule.CreateConfigurationSort(model),
7 name <- thisModule.varCf
8 )
9 }
Todas las reglas Lazy Rule que devuelven un Sort tienen una peculiaridad: tienen el
modicador unique. Con el modicador unique, una regla Lazy Rule devuelve un objeto
distinto para cada objeto de entrada distinto, es decir, si la regla es llamada dos veces
con el mismo objeto, devuelve el mismo objeto. Esto es util porque no es deseable crear
m as de un objeto MAUDE!Sort, sino crear un unico objeto y referenciarlo cada vez que sea
necesario. Como solo existe un objeto UML!Model para cualquier modelo de entrada, solo
se creara un sort Conguration en el modelo de salida.
92
1 unique lazy rule CreateConfigurationSort {
2 from
3 model: UML!Model
4 to
5 sortConfiguraiton: MAUDE!Sort (
6 name <- thisModule.sortConfiguration
7 )
8
9 }
Existen reglas unique para los tipos Conguration, Cid, OclType, AttributeName, OpName, etc.
4.4.3. Finalizaci on de la transformacion
Como nalizaci on de la transformaci on se entiende la regla con el modicador endpoint.
Esta regla ser a ejecutada despues de completar la 3
a
fase de ejecuci on de ATL (vease
secci on 3.4). Esta regla contiene unicamente codigo imperativo (solo est a compuesta por
el bloque using y do). En esta seccion se describiran las principales estructuras de la regla
endpoint.
1 endpoint rule Finalize(){
2 using {
3 -- Variables locales de la regla
4 [. . .]
5 }
6 do {
7 [. . .]
8 }
9 }
C odigo 4.23: Cabecera de la regla Finalize.
Creaci on de constantes. Cada atributo que se ha a nadido al mapa Elemento-Atributo
y que es utilizado como atributo en el conjunto de pares en el objeto Context, debe ser
una constante de tipo Arg. Si el atributo es un parametro de una operacion, este ya ha
sido declarado en el modulo de la estructura del sistema. Por el contrario si el argumento
es debido a la creaci on de un nuevo objeto o por el uso de una variable auxiliar, no se ha
declarado la constante en ning un m odulo Maude. Desde la regla Finalize() se recorren estos
casos (los objetos creados y los mensajes con variables auxiliares) y se crean los operadores
Maude que especican dichas constantes. La regla ATL que crea estos operadores es una
Called Rule denida como sigue:
93
1 rule CreateOp(n: String, modulo: MAUDE!Module){
2 to
3 o: MAUDE!Operation (
4 "module" <- modulo,
5 name <- n,
6 atts <- Sequence{ctor},
7 coarity <- thisModule.argSort
8 )
9 }
C odigo 4.24: Regla ATL CreateOp.
Mapa Elemento-Reglas Al inicio de esta secci on se ha justicado la importancia de
que el codigo resultante sea legible. En ATL, la ejecuci on de las reglas Matched Rule no
puede ser prejado y por lo tanto las reglas se crearan desordenadas en el modulo. Uno
de los factores que determinan la legibilidad del c odigo es que el orden de las reglas se
corresponda al paso de mensajes de los diagramas de interaccion. Como cada interaccion
es un objeto UML de tipo Interaction, este tiene un OrderedSet con elementos Interaction-
Fragment en su atributo fragment. Un objeto de tipo InteractionFragment puede representar,
por ejemplo, un evento de envo de un mensaje. Estos eventos
6
est an ordenados de
acuerdo a la representaci on graca. Para poder recuperar el orden de los mensajes, se
hace corresponder el evento InteractionFragment que origina el mensaje del diagrama de
secuencia que sera transformado en una regla Maude, con una lista de reglas. Es necesario
una lista de reglas como valor del mapa porque hay excepciones donde un mensaje crea
dos reglas (por ejemplo cuando el mensaje es una Synchronous Call con variable auxiliar).
El mapa es denido como sigue:
helper def: mapNERule: Map(UML!NamedElement, Sequence(MAUDE!Rule)) =
Map{};
Y en cada regla ATL que crea reglas Maude, se a nade a dicho mapa en el bloque impe-
rativo:
1 do {
2 thisModule.mapNERule <-
3 thisModule.mapNERule -> including(msg.sendEvent, Sequence{rl});
4 -- "rl" es el objeto Maude!Rule creado.
5 }
6
En concreto, son objetos UML de tipo MessageOccurrenceSpecication.
94
En el caso de los bloques anidados, se a nade cada regla condicional que selecciona la
ejecuci on al correspondiente InteractionOperand al mapa.
Desde la regla Finalize() se itera sobre cada InteractionFragment frag del mapa y en caso
de que frag pertenezca a las claves del mapa Elemento-Reglas, se a nade las reglas del
conjunto que corresponde al valor de frag al m odulo Maude. El c odigo 4.25 muestra un
fragmento de c odigo de la regla Finalize() donde se itera sobre los InteractionFragments. En
caso de los bloques anidados, se itera por cada InteractionOperand del bloque anidado.
1 for(f in mainInter){
2 if (f.oclIsTypeOf(UML!CombinedFragment)){
3 for(o in f.operand){
4 if(thisModule.mapNERule -> get(o) <> OclUndefined){
5 for(e in thisModule.mapNERule -> get(o)){
6 smodule.els <- smodule.els -> append(e);
7 }
8 }
9 for(fo in o.fragment){
10 if(thisModule.mapNERule -> get(fo) <> OclUndefined){
11 for(e in thisModule.mapNERule -> get(fo)){
13 }
14 }
15 }
16 }
17 } else { -- MessageSend
18 if(thisModule.mapNERule -> get(f) <> OclUndefined){
19 for(e in thisModule.mapNERule -> get(f)){
21 }
22 }
23 }
24 }
C odigo 4.25: Fragmento de c odigo que a nade las reglas ordenadas al m odulo Maude.
El bucle for con cabecera en la lnea 1 del codigo 4.25 itera sobre los InteractionFrag-
ments de la interacci on principal. Esto se debe a que las reglas de la interacci on principal
son situadas en primero orden, y posteriormente se van a nadiendo, tambien ordenadas,
las reglas correspondientes a interacciones que especican operaciones auxiliares o com-
plementarias.
Creaci on de los selectores. Como se ha explicado en la seccion 4.2, cada objeto
Context tiene un atributo seq correspondiente al selector. Como las reglas ATL que crean
las reglas Maude se ejecutan en un orden no denido, crear los pares de la lista del selector
requiere un esfuerzo adicional. Para ello, durante la creacion de todos los objetos Context
95
de todas las reglas Maude, el atributo seq es creado pero sin argumentos (y por supuesto
sin op ya que no se sabe el n umero de argumentos que este tendra. Es en la regla Finalize()
cuando se hace un recorrido de todas las reglas Maude y se crean los pares que conforman
el selector. Las reglas Maude son tomadas del mapa Elemento-Reglas. Con las dos variables
auxiliares auxIntMainBranch y auxIntActualBranch se tiene el n umero del selector (del objeto
Context de la parte izquierda LHS) de la siguiente regla Maude y en caso de que sea un
bloque anidado, el n umero del selector de la siguiente regla dentro del dicho bloque.
La navegaci on hasta el atributo seq del objeto Context no es trivial.
1 for (inter in allInter) {
2 thisModule.auxIntMainBranch <- 1;
3 for (f in inter.fragment) {
4 if (f.oclIsTypeOf(UML!CombinedFragment)) {
5 -- Se obvia por motivos de espacio
6 } else {
7 if(thisModule.mapNERule -> get(f) <> OclUndefined){
8 for(rl in thisModule.mapNERule -> get(f)){
9 --- LHS
10 thisModule.SeqPair(1, thisModule.auxIntMainBranch,
11 rl.lhs.args->first().args->first().args->last().args->last().
args->last());
12 --- RHS
13 thisModule.SeqPair(1, thisModule.auxIntMainBranch + 1,
14 rl.rhs.args->first().args->first().args->last().args->last().
args->last());
15 --- Increment counter
16 thisModule.auxIntMainBranch <- thisModule.auxIntMainBranch + 1;
17 }
18 }
19 }
20 }
C odigo 4.26: Fragmento de c odigo de creaci on del selector.
En el c odigo 4.26 se muestra un trozo del codigo que itera sobre las reglas Maude
creando los selectores. Se ha eliminado el trozo de c odigo que itera sobre los bloques
anidados por motivos de espacio. El lector interesado puede acceder al codigo completo
en el la p agina http://maude.lcc.uma.es/mOdCL.
La regla ATL Called Rule denominada SeqPair encargada de crear un par selector y
a nadirlo a la lista de argumentos del objeto MAUDE!RecTerm que se le pasa como parametro
se ilustra en el codigo 4.27.
96
1 rule SeqPair(branch: Integer, seqNumber: Integer, list: MAUDE!RecTerm) {
2 to
3 seqPair: MAUDE!RecTerm (
4 op <- thisModule.pairSeqOperator,
5 args <- Sequence{branchConstant,
6 seqConstant}
7 ),
8 branchConstant: MAUDE!Constant (
9 op <- branch.toString()
10 ),
11 seqConstant: MAUDE!Constant (
12 op <- seqNumber.toString()
13 )
14 do {
15 list.args <- list.args -> including(seqPair);
16 list.op <- [ + list.getEmptySyntaxOperation() + ];
17 }
18 }
C odigo 4.27: Regla SeqPair.
Mapa Interaccion-
Ultima regla. Para el correcto funcionamiento de la pila de mOdCL

(vease secci on 3.3.6) el conjunto de reglas Maude que denen una interaccion debe acabar
con la inclusi on del operador return en la sopa de terminos de Maude. En el caso de que
una interacci on i corresponda a la especicaci on de una operacion sin valor de retorno,
la interacci on i no tendr a ning un Message Lost modelando un valor de retorno. En estos
casos, la regla ATL Matched Rule denominada LastRule crea una regla Maude con una
ultima regla que contiene el operador return en su parte derecha RHS. Para recuperar esta
regla Maude en la regla ATL Finalize() tanto para incluirla en el m odulo Maude como para
crear la lista de pares del selector es imprescindible guardarla en alguna estructura. El
mapa Interaccion-
Ultima regla est a especicado en el siguiente c odigo:

helper def: mapInteractionLastRule: Map(UML!Interaction, MAUDE!Rule) =
Map{};
4.5. Transformacion modelo a texto
En esta secci on se describira brevemente la transformacion modelo a texto que se
realiza una vez se ha transformado el modelo UML en el modelo Maude. Esta transfor-
maci on est a realizada en Acceleo. Acceleo, adem as de un complemento para Eclipse (vease
97
4.5. Transformaci on modelo a texto
secci on 2.6), es un DSL que permite denir transformaciones de modelo a texto.
Existen otras alternativas a Acceleo, como XTend. Acceleo ha sido escogida porque
sigue el est andar propuesto por la OMG en las transformaciones modelo a texto. Acceleo
utiliza OCL como sem antica operacional con lo que sigue la lnea de las herramientas
usadas en este proyecto.
En cuanto a la transformaci on, b asicamente se establece una correspondencia entre
cada objeto del modelo de entrada, y una cadena de caracteres que conforma la salida.
En este sentido, la mayora de los objetos Maude del modelo de entrada corresponden a
una palabra reservada del lenguaje Maude, o bien a un termino, cuyo operador va denido
por si mismo (en el atributo op).
La transformaci on desarrollada para este proyecto esta muy acoplada al tipo de mode-
los de entrada Maude proporcionados por la transformaci on modelo a modelo desarrollada
en ATL. El motivo es mejorar la legibilidad del c odigo, aspecto en el que se ha hecho un
gran esfuerzo.
El c odigo de la transformacion se puede descargar de la web http://maude.lcc.uma.
es/mOdCL.
98
CAP
ITULO 5
Caso de estudio: RoyalLoyal
5.1. Descripcion del caso de estudio
En este captulo se va a presentar el caso de estudio Royal and Loyal [WK03].
RoyalLoyal es el modelado de un programa software que maneja programas de delidad
para terceras compa nas que desean ofrecer a sus clientes diferentes tipos de bonicaciones.
Estos premios o bonicaciones tienen forma de puntos o servicios adicionales como precios
reducidos, un coche de alquiler m as lujoso por el mismo precio de uno estandar, mejor
servicio en un vuelo de una aerolnea, etc. Cualquier compa na que desee ofrecer estos
servicios podra hacerlo a traves de estos programas de delidad.
En la gura 5.1 se muestra el diagrama de clases UML del sistema que se est a descri-
biendo. En el contexto del DSDM, este representa un modelo al nivel PIM (vease niveles
de abstracci on en la secci on 2.2) ya que no muestra ninguna dependencia con el lenguaje
de programacion donde sera implementado.
La clase central del modelo es LoyaltyProgram. Un sistema que administra un programa
de delidad contendr a s olo una instancia de esta clase. Por otro lado, una compa na
que ofrece a sus clientes asociarse a un programa de delidad es representado por la
clase ProgramPartner. Mas de una compa na pueden entrar en el mismo programa y en
consecuencia, los clientes que entren en el programa de delidad pueden beneciarse de
los servicios de cualquiera de las compa nas participantes.
Cada cliente de un programa ofrecido por una compa na puede entrar en el programa
de delidad obteniendo una tarjeta de socio. Los objetos de la clase Customer representan
99
5.1. Descripci on del caso de estudio
Figura 5.1: Diagrama de clases del caso de uso Royal and Loyal.
los clientes que se benecian de alg un (o varios) programa. La tarjeta CustomerCard es
asociada a una persona. La mayora de los programas permiten a los usuarios almacenar
puntos de bonicacion. Cada programa decide cu antos puntos se generan para una cierta
compra. Estos puntos de bonicaci on pueden ser utilizados para comprar servicios de
una compa na ProgramPartner que ofrece un programa de delidad. Los puntos son alma-
cenados por cada cliente. Con este n, cada clase Membership, que representa la asociaci on
de un cliente a un programa, tiene un objeto de la clase LoyaltyAccount que almacena los
puntos.
100
Captulo 5. Caso de estudio: RoyalLoyal
5.2. Operacion enroll
En este caso de estudio, se va a describir la operacion enroll(Customer) de la clase
LoyaltyProgram. La operacion enroll inscribe al cliente Customer ( unico parametro de la
operaci on) en el programa LoyaltyProgram en el que se invoca dicha operacion. Con esta
nalidad, una clase asociacion Membership es creada y se inicializan todos los atributos y
asociaciones de la asociacion creada.
El diagrama de secuencia principal se muestra en la gura 5.2. Como novedad a las
estructuras ya descritas en el captulo 4, en este caso de estudio se crean objetos con
mensajes Create: en particular un objeto de la clase asociaci on Membership y un objeto de
la clase LoyaltyAccount.
En el diagrama de la gura 5.2, el objeto representado por la lnea de vida LP es de la
clase LoyaltyProgram, el objeto C es de la clase Customer, NewMB de la clase Membership y
nalmente NewLA de la clase LoyaltyAccount.
En primer lugar, en el diagrama de secuencia de la operaci on enroll, se crea una asocia-
ci on, el objeto NewMB, y se a naden a las asociaciones Membership de ambos extremos, LP y
C, con los metodos LoyaltyProgram::addMembership(Membership) y Customer::addMembership(Membership).
A continuaci on se inicializan los dos extremos del objeto creado NewMB con los metodos
Membership::setParticipants(Customer) y Membership::setPrograms(LoyaltyProgram). La opera-
ci on Customer::setCurrentLevel(ServiceLevel) establece el nivel de servicio de la inscripci on de
C al programa de delizaci on LP.
Por ultimo, se crea la cuenta donde se registran las operaciones y datos de la asocia-
ci on al programa de delizaci on. El objeto NewLA de clase LoyaltyAccount es creado con
un mensaje Create. Tras crearlo, se establece como cuenta de la asociaci on al programa
de delizacion NewMB creado con el primer mensaje Create. Posteriormente se inicializan
el atributo currentPoints con la operacion LoyaltyAccount::setPoints(Int), el atributo number
con la operacion LoyaltyAccount::setAccountNumber(Int) y por ultimo el atributo (asocia-
ci on) membership con la operaci on LoyaltyAccount::setMembership(Membership). El atributo
(asociaci on) transactions se inicializa al conjunto vaco Set{} con la operaci on LoyaltyAc-
count::setTransactions(Transaction[*].
101
5.2. Operaci on enroll
Figura 5.2: Diagrama de secuencia de la operacion LoyaltyProgram::enroll(Customer).
102
5.3. Creaci on de objetos
El objetivo de este caso de estudio es mostrar la creaci on de objetos por medio de los
mensajes UML Create Messages. Asumiendo como conocidos los esquemas presentados
en el captulo 4, aqu se va a mostrar el esquema de c odigo Maude que se necesitar a para
la creacion de un objeto.
Un mensaje UML Create Message es una llamada a la creaci on de un objeto repre-
sentado por una lnea de vida (un objeto de la clase Lifeline). Un Create Message tiene
en su atributo messageSort el literal createMessage. Siguiendo el esquema generico de la
transformaci on, para cada mensaje del diagrama de secuencia UML, se crea una regla
Maude que especica el comportamiento de dicho mensaje UML en Maude.
Cada objeto creado en un diagrama de secuencia, tendr a un identicador unico. Con
este n, en el estado Maude en ejecuci on (la sopa de terminos) existir a un mensaje que
tendr a un identicador fresco, declarado como sigue:
op next-Oid : Nat -> Msg [msg] .
El nuevo objeto creado tendr a como identicador Oid el valor natural que tenga el
mensaje next-Oid como par ametro. Para que un valor Nat pueda ser identicador de un
objeto, ha sido necesario incluir el conjunto de terminos de tipo Nat como subconjunto de
Oid:
subsort Int < Oid .
Cada vez que se genere una regla Maude como consecuencia de un mensaje Create
Message, el identicador unico debe ser incrementado:
rl [EXAMPLE-RULE] :
{ [. . .]
next-Oid(NewOid:Integer)
}
=>
{ [. . .]
next-Oid(NewOid:Integer + 1)
} .
El objeto creado debe ser almacenado en el contexto de la ejecuci on de la operaci on.
103
5.3. Creaci on de objetos
Como se describe en el captulo 4, el contexto de la operaci on tendra los par ametros de
la operacion y las variables locales al diagrama de secuencia UML. Un objeto creado,
ser a almacenado por tanto como un argumento (vease seccion 4.2.2) en el contexto. El
nombre del atributo del par, sera el asignado por el usuario como nombre a la lnea de
vida creada. En el caso del primer mensaje en el diagrama de secuencia de la gura 5.2,
el nombre del argumento ser a NewMB. En la regla Maude que especica el mensaje crea-
teMembership() se a nade un par arg(NewMB, NewOid) a la lista de pares del contexto de la
parte derecha RHS.
1 rl [1:CREATEMEMBERSHIP_MESSAGE] :
2 { < ctx : Context | opN : enroll, obj : Self:Oid, args : (arg(customer,
Customer1:OclType), AL-1:ArgsList), seq : [( 1 | 1 )] >
3 < Self:Oid : L:LoyaltyProgram | name : VAR11:String,
4 lastAccNmb : VAR10:Integer, levels : SET4:Collection,
5 partners : SET7:Collection, Membership : SET12:Collection,
6 AS-1:AttributeSet >
7 Cf:Configuration
8 next-Oid(NewOid:Integer)
9 } =>
10 { < ctx : Context | opN : enroll, obj : Self:Oid, args : (arg(customer,
Customer1:OclType), AL-1:ArgsList, arg(NewMB, NewOid:Integer)),
11 seq : [( 1 | 2 )] >
12 < Self:Oid : L:LoyaltyProgram | name : VAR11:String,
13 lastAccNmb : VAR10:Integer, levels : SET4:Collection,
14 partners : SET7:Collection, Membership : SET12:Collection,
15 AS-1:AttributeSet >
16 Cf:Configuration
17 next-Oid(NewOid:Integer + 1)
18 < NewOid:Integer : Membership | level : null, account : null,
19 programs : null, card : null >
20 Cf:Configuration
21 } .
C odigo 5.1: Regla Maude generada a partir del mensaje createMembership().
La regla del c odigo 5.1 corresponde al c odigo transformado del mensaje createMembers-
hip del diagrama de secuencia de la gura 5.2. Observese todas las estructuras genericas
descritas en el captulo 4 as como las estructuras concretas de las reglas que modelan la
creaci on de objetos descritas en esta secci on. El nuevo objeto creado NewOid : Membership
es a nadido al estado en ejecuci on Maude, es decir, a la sopa de terminos, ya que aparece
en la parte derecha de la regla RHS.
104
5.4. Una traza del caso de estudio
Para hacer una traza del caso de estudio Royal and Loyal, se va a proponer un estado
inicial a partir del cual se har a una llamada al metodo LoyaltyProgram::enroll(Customer).
2 eq init-state =
3 < SilverAndGold : LoyaltyProgram | Membership : Set{}, lastAccNmb : 0,
4 partners : Set{}, levels : Set{Silver, Gold}, name : "SilverAndGold" >
5 < Silver : ServiceLevel | program : SilverAndGold >
6 < Gold : ServiceLevel | program : SilverAndGold >
7 < tony : Customer | name : "Tony Smith", Membership : Set{},
8 cards : Set{} >
9 < paul : Customer | name : "Paul Smith", Membership : Set{},
10 cards : Set{} >
11 < jane : Customer | name : "Jane Smith", Membership : Set{},
12 cards : Set{} > .
C odigo 5.2: Estado inicial del caso de estudio Royal and Loyal.
En el c odigo 5.2 se dene el estado inicial de este caso de estudio como constante de
tipo Conguration. Este termino de tipo Conguration est a compuesto por un multi-conjunto
de objetos. El objeto SilverAndGold de tipo LoyaltyProgram, representa el programa de de-
lizaci on con el mismo nombre que el identicador de objeto y con niveles Silver y Gold. Por
otro lado existen tres clientes antonio, pablo y javi, todos sin asociar a ning un programa
de delizacion. Los identicadores de los objetos utilizados son constantes Maude de tipo
Oid.
1 op init-state-ready : -> Configuration .
2 eq init-state-ready =
3 init-state
4 call(enroll, SilverAndGold, (arg(customer, antonio)))
5 next-Oid(1) .
C odigo 5.3: Llamada inicial al metodo LoyaltyProgram::enroll(Customer).
En el c odigo 5.3 se realiza la llamada call a la operaci on enroll y se a nade el operador
next-Oid explicado en la secci on 5.3.
Con la llamada Maude siguiente:
105
rew in ROYAL-LOYAL-VALIDATION-TEST : [ init-state-ready ] .
Se realiza la reescritura del estado inicial que llama a la operaci on LoyaltyProgram::enroll(Customer)
(c odigo 5.3). La salida obtenida es la siguiente:
{ next-Oid(3) resume(enroll, null) < stack : Stack | state : nil >
< SilverAndGold : LoyaltyProgram | Membership : Set{1},
partners : Set{mt-ord}, lastAccNmb : 1,
name : "SilverAndGold", levels : Set{Silver, Gold} >
< Silver : ServiceLevel | program : SilverAndGold >
< Gold : ServiceLevel | program : SilverAndGold >
< tony : Customer | Membership : Set{1}, cards : Set{mt-ord},
name : "Tony Smith" >
< paul : Customer | Membership : Set{mt-ord}, cards : Set{mt-ord},
name : "Paul Smith" >
< jane : Customer | Membership : Set{mt-ord}, cards : Set{mt-ord},
name : "Jane Smith" >
< 1 : Membership | programs : SilverAndGold, account : 2, level : Silver,
participants : tony, card : null >
< 2 : LoyaltyAccount | number : 1, transactions : Set{mt-ord},
membership : 1, currentPoints : 0 >
}
Al haberse creado dos objetos, el operador next-Oid tiene como valor natural 3, el
identicador que correspondera al siguiente objeto creado. El programa de delizaci on
SilverAndGold tiene ahora en su atributo Membership el objeto de asociacion al programa
1 de tipo Membership. Y de forma analoga, el cliente (de tipo Customer) antonio tiene en
su atributo Membership el objeto 1 de tipo Membership. Por otro lado, se ha creado un
objeto de tipo LoyaltyAccount, con identicador 2, que representa la cuenta de puntos
de la asociaci on creada con identicador 1. Todos los atributos han sido correctamente
inicializados.
Como invariantes se han denido los siguientes:
1 op invariant-Membership : -> OclExp .
2 eq invariant-Membership
3 = (context Membership inv
4 (self . account . currentPoints >= 0) or (self . account . currentPoints =
null)
5 or self . account = null) .
C odigo 5.4: Invariante. Puntos de la cuenta de delizacion positivos.
106
En el c odigo 5.4 se especica como restriccion que el atributo currentPoints de cada
objeto de tipo LoyaltyAccount, correspondiente a una asociaci on Membership a un programa
de delizacion, debe ser positivo. Se a nade adem as la posibilidad de que los puntos no
hayan sido inicializados o que la cuenta no haya sido creada para dicha asociaci on. En el
proceso de inicializaci on estos casos se pueden dar.
1 op invariant-LoyaltyProgram1 : -> OclExp .
2 eq invariant-LoyaltyProgram1
3 = (context LoyaltyProgram inv
4 ((self . Membership = Set{}) or
5 self . levels -> includesAll( self . Membership
6 -> collect( $M | $M . level) -
7 -> select( $L | not $L . oclIsUndefined()) -> asSet() ))) .
C odigo 5.5: Invariante. Niveles de asociaci on.
En el c odigo 5.5 e especica que todos los niveles de las asociaciones a un programa de
delizaci on deben ser posibles en dicho programa, es decir, que el nivel de una asociacion
sea ofertado por el programa al que pertenece esta. El select es para ltrar los valores null
en las asociaciones Membership que se est an creando y no ha sido establecido a un el nivel.
1 op invariant-LoyaltyProgram2 : -> OclExp .
2 eq invariant-LoyaltyProgram2
3 = (context LoyaltyProgram inv
4 self . Membership
5 -> collect($M | $M . account) -> isUnique($AC | $AC . number)) .
C odigo 5.6: Invariante. Cuentas de usuario con identicador unico.
En el c odigo 5.6 se especica el invariante que establece que el n umero de una cuenta
de delizaci on de una asociaci on Membership es unico. Es decir, no pueden existir dos
cuentas con el mismo n umero.
Finalmente en el siguiente c odigo se establecen el conjunto de invariantes para esta
ejecuci on:
1 eq inv = invariant-Membership and
2 invariant-LoyaltyProgram1 and
3 invariant-LoyaltyProgram2 .
107
108
CAP
ITULO 6
Caso de estudio: Cinema
6.1. Descripcion del caso de estudio
En este captulo se va a analizar el caso de estudio Cinema. Este caso de estudio trata
sobre el modelado del sistema de compra de entradas de cine.
En la gura 6.1 se muestra el diagrama de clase de este caso de estudio. Un cine, es
decir, un objeto de la clase Cinema tiene asociado un banco con el que trabaja, un objeto
de la clase Bank. Adem as, cada cine Cinema ofertar a un conjunto de sesiones, representadas
por la clase Session. Cada objeto de tipo Session tiene un conjunto de atributos que lo dene,
a destacar el tiempo de inicio startTime : Integer y el tiempo de nalizaci on endTime : Integer.
Un objeto de tipo Bank tiene una colecci on de cuentas bancarias, objetos de tipo Account,
con un atributo balance : Integer que establece el valor de la cuenta bancaria. Un objeto
Account tiene un conjunto de objetos de tipo DebitCard. La clase Client modela un cliente
del sistema. Un cliente tiene un conjunto de cines (objetos Cinema) a los que puede asistir.
Adem as, cada cliente tiene un conjunto de cuentas bancarias (objetos de tipo Account) y
tarjetas de debito asociadas a dichas cuentas (objetos de tipo DebitCard). Un cliente puede
estar asociado a una sesi on Session con la clase asociaci on Ticket, en la que permanecen
como atributos los datos mas relevantes de la entrada a una sesi on de cine.
109
6.1. Descripci on del caso de estudio
Figura 6.1: Diagrama de clases del caso de uso Cinema.
110
Captulo 6. Caso de estudio: Cinema
6.2. Operacion goCinema y auxiliares
En este caso de estudio, se va a describir y ejecutar la operaci on
Client::goCinema(Cinema,Integer):Boolean
en la cual, dado un cine y una hora de inicio (en formato Integer por motivos de simplicar
las estructuras de datos para la representacion de fechas), devuelve true cuando la accion
de ir al cine se ha realizado con exito, y false en otro caso. En la gura 6.2 se muestra
el diagrama de secuencia de la operaci on goCinema.
Figura 6.2: Diagrama de secuencia de la operacion goCinema.
La operacion goCinema se describe con una llamada a la operacion
Cinema::buyTicket(Integer, Client):Ticket
Con la hora de inicio de la sesion como primer parametro y el cliente comprador de
la entrada como segundo par ametro. La operacion devolver a la entrada, objeto Ticket,
generada con la compra o bien null/OclUndened en caso de error. El objeto Ticket devuelto
por la operaci on buyTicket es almacenado en una variable local auxTk. El valor que devuelve
la operacion buyTicket depender a del valor de auxTk en el momento que se produce el
Message Lost del diagrama de secuencia de goCinema (gura 6.2). La expresion mOdCL
que se describe como argumento del Message Lost es la siguiente:
return = not auxTk . oclIsUndened()
La operaci on Cinema::buyTicket(Integer, Client):Ticket est a descrita con el diagrama de se-
cuencia de la gura 6.3. En primer lugar, se llama a la operaci on locateSession(Integer):Session,
111
6.2. Operaci on goCinema y auxiliares
cuyo primer par ametro es el tiempo de inicio de la sesion, para localizar una sesi on cuya
hora de inicio coincida con el parametro de locateSession. El objeto Session resultante se al-
macena en la variable auxiliar auxSession. En caso de no existir ninguna sesi on disponible,
el resultado es null.
A continuaci on se muestra un bloque Combined Fragment opcional, el cual ser a eje-
cutado solo en caso evaluarse la guarda a verdadero. Este bloque devolver a null en caso de
que la sesi on no haya sido encontrada o bien exista pero no tenga capacidad. La expresion
de la guarda del bloque opcional es:
auxSession . oclIsUndened() or auxSession . capacity = auxSession . Ticket -> size()
El comentario mostrado tras el bloque opcional es una anotacion acerca de la poscon-
dici on que se tiene a partir de ese bloque: la sesi on almacenada en la variable auxSession
tiene plazas disponibles para una posible compra de entradas.
Asumiendo la poscondici on indicada en el comentario, se hace el pago con la operacion
Cinema::pay(Integer, Integer):Boolean. La operacion pay devuelve verdadero o true cuando se
realiza con exito el pago de la cantidad del segundo par ametro en la tarjeta de debito,
cuyo n umero se pasa en el primer par ametro, y falso o false en otro caso. El resultado
de la operaci on pay es almacenado en la variable local payStatus, en funcion de la cual se
establecen las guardas del bloque alternativo Combined Fragment. En caso de efectuar el
pago con exito, se crea el nuevo Ticket, se inicializa y se a nade a la lista de entradas del
cliente. Por ultimo se devuelve la entrada creada (objeto Ticket en el diagrama). En caso
contrario se devuelve null.
La operaci on pay se describe en el diagrama de secuencia de la gura 6.4. Una vez
localizada la cuenta, se divide la ejecucion en un bloque Combined Fragment. En el caso
de que no exista una tarjeta de debito con el n umero debitCard : Integer pasado como primer
par ametro de la operaci on, o existe pero la cuenta bancaria asociada no tiene suciente
liquidez para abonar la entrada, la operacion devuelve falso o false. En caso de poderse
efectuar el pago, se reduce el saldo de la cuenta bancaria asociada en la cantidad amount :
Integer que se tiene como segundo par ametro de la operaci on pay y se devuelve verdadero
o true.
112
Figura 6.3: Diagrama de secuencia de la operacion buyTicket.
113
6.2. Operaci on goCinema y auxiliares
Figura 6.4: Diagrama de secuencia de la operacion pay.
114
6.3. El bloque opt
Como novedad en este caso de estudio frente a lo presentado en el captulo 4 y 5, se
mostrar a el bloque Combined Fragment opt. El bloque opcional opt establece un bloque
anidado en el diagrama de secuencia que se ejecutar a si y solo si se da la condici on de
la guarda, especicada en este caso en forma de OpaqueExpression. Como en el caso de los
bloques alt (vease secci on 4.2.4), se tienen tantas reglas Maude condicionales como Inter-
actionOperand tenga el Combined Fragment. A diferencia de este, un bloque opt solo puede
tener un InteractionOperand. En consecuencia, si el bloque es de tipo opt, la regla ATL que
se corresponde con el bloque anidado y el operando, creara dos reglas Maude condicio-
nadas: una con la guarda del operando del bloque opt y cuyo selector permitir a entrar
en el bloque, y otra con la negaci on de la guarda y cuyo selector sera incrementado para
continuar con la regla siguiente de la rama principal, es decir, saltar el bloque opt.
1 crl [RULE-1] :
2 [. . .] seq : [( 1 | n )] >
3 =>
4 [. . .] seq : [( 1 | n + 1 ) ( 1 | 1 )] >
5 if guard .
6
7 crl [RULE-2] :
8 [. . .] seq : [( 1 | n )] >
9 =>
10 [. . .] seq : [( 1 | n + 1 )] >
11 if not guard .
C odigo 6.1: Esquema de reglas Maude generadas a partir de un bloque opt.
En el c odigo 6.1 se muestra un esquema muy simplicado de las dos reglas generadas
a partir de un bloque opt. En el c odigo 6.2 se muestran las dos reglas generadas a partir
del bloque opt de la operaci on buyTicket.
115
6.3. El bloque opt
1 crl [CombinedFragment-1] :
2 { < ctx : Context | opN : buyTicket, obj : Self:Oid, args :
3 (arg(startTime, StartTime3:Integer), arg(client, Client4:OclType),
4 arg(auxSession, VAR38:OclType), AL-1:ArgsList), seq : [( 1 | 3 )] >
5 < Self:Oid : C:Cinema | name : VAR14:String, bank : VAR32:OclType,
6 sessions : SET10:Collection, AS-1:AttributeSet >
7 Cf:Configuration
8 } =>
11 arg(auxSession, VAR38:OclType), AL-1:ArgsList), seq : [( 1 | 4 )( 1 | 1 )] >
14 Cf:Configuration
15 } if evl(auxSession . oclIsUndefined() or
16 auxSession . capacity = auxSession . Ticket -> size(),
17 < ctx : Context | opN : buyTicket, obj : Self:Oid, args :
19 arg(auxSession, VAR38:OclType), AL-1:ArgsList) >
22 Cf:Configuration ) .
23
24 crl [CombinedFragment-ELSE] :
30 Cf:Configuration
31 } =>
37 Cf:Configuration
38 } if evl(not (auxSession . oclIsUndefined() or
39 auxSession . capacity = auxSession . Ticket -> size()),
40 < ctx : Context | opN : buyTicket, obj : Self:Oid, args :
42 arg(auxSession, VAR38:OclType), AL-1:ArgsList) >
45 Cf:Configuration ) .
C odigo 6.2: Reglas generadas a partir del bloque opt.
116
Para hacer una ejecucion del caso de estudio, se va a presentar en el c odigo 6.3 un
escenario inicial a partir del cual se ejecutara la operaci on buyTicket.
2 eq init-state =
3 next-Oid(1)
4 < cinema1 : Cinema | name : "Coronet", bank : bbva, sessions : Set{s1,s2,s3} >
5
6 < s1 : Session | startTime : 1100, endTime : 1150, capacity : 10, price : 5,
7 Ticket : Set{}, clients : Set{} >
12
13 < bob : Client | Ticket : Set{}, debitCards : Set{visa}, cinemas : Set{},
14 sessions : Set{}, accounts : Set{} >
15
16 < visa : DebitCard | number : 111 >
17
18 < bbva : Bank | accounts : Set{acc1, acc2, acc3} >
19
20 < acc1 : Account | balance : 100, debitCards : Set{} >
21 < acc2 : Account | balance : 1000, debitCards : Set{visa} >
22 < acc3 : Account | balance : 10000, debitCards : Set{} >
23
24 call(goCinema, bob, (arg(cinema, cinema1), arg(startTime, 1200))) .
C odigo 6.3: Estado inicial del caso de estudio Cinema.
Como se puede observar en el codigo 6.3, en el estado inicial se presenta un estado
donde hay un cine con nombre Coronet, tres sesiones posibles con capacidad 10 para dicho
cine, un cliente, una tarjeta de debito, un banco y tres cuentas bancarias.
La ejecucion se realiza con el comando Maude rewrite:
rewrite in CINEMA-VALIDATION-TEST : [ init-state ] .
El estado resultante es el siguiente:
117
{ next-Oid(2) resume(goCinema, true) < stack : Stack | state : nil >
< cinema1 : Cinema | sessions : Set{s1, s2, s3}, name : "Coronet",
bank : bbva > < bbva : Bank | accounts : Set{acc1, acc2, acc3} >
< s1 : Session | startTime : 1100, endTime : 1150, capacity : 10,
price : 5, clients : Set{mt-ord}, Ticket : Set{mt-ord} >
< s2 : Session | startTime : 1200,endTime : 1250, capacity : 10,
price : 8, clients : Set{mt-ord}, Ticket : Set{mt-ord} >
< s3 : Session | startTime : 1300, endTime : 1350, capacity : 10,
price : 5, clients : Set{mt-ord},Ticket : Set{mt-ord} >
< bob : Client | sessions : Set{mt-ord}, accounts : Set{mt-ord},
cinemas : Set{mt-ord}, debitCards : Set{visa}, Ticket : Set{1} >
< acc1 : Account | balance : 100, debitCards : Set{mt-ord} >
< acc2 : Account | balance : 992, debitCards : Set{visa} >
< acc3 : Account | balance : 10000, debitCards : Set{mt-ord} >
< visa : DebitCard | number : 111 >
< 1 : Ticket | sessions : s2,clients : bob >
}
Cabe destacar el objeto con identicador 1 de la clase Ticket creado y a nadido en la
asociaci on Ticket del cliente bob. As como el saldo de la cuenta acc2 ha sido reducido en
8 unidades (el precio de la sesi on s2).
Para este caso de estudio se han denido los siguientes invariantes:
1 op seats-available : -> OclExp .
2 eq seats-available
3 = (context Session inv self . capacity >= self . Ticket -> size()) .
C odigo 6.4: Invariante. Sesiones con m as entradas que localidades.
1 op avoid-overlapping : -> OclExp .
2 eq avoid-overlapping
3 = (context Client
4 inv self . Ticket -> forAll($T1 |
5 self . Ticket -> forAll($T2 |
6 (($T1 = $T2)
7 or ($T1 . sessions . endTime < $T2 . sessions . startTime)
8 or ($T2 . sessions . endTime < $T1 . sessions . startTime))))) .
C odigo 6.5: Invariante. Un usuario no puede tener dos sesiones que coincidan en horario.
En el codigo 6.4 se especica el invariante seats-available, que obliga a que todo objeto de
tipo Session que este en el sistema, no tenga m as entradas Tickets asignados que localidades
disponibles en la sala de cine. Por otro lado, en el c odigo 6.5 se especica el invariante
avoid-overlapping, cuyo objetivo es evitar solapamiento en los horarios de las sesiones de
118
cine para las que un cliente Client ha comprado una entrada.
1 eq pre(goCinema)
2 = self . Ticket -> forAll($T | $T . startTime <> startTime) .
3
4 eq post(goCinema)
5 = ((not result) or
6 (self . Ticket -> select($T | $T . sessions . startTime = startTime )
7 -> size() = 1 and
8 self . Ticket pre -> size() = self . Ticket -> size() - 1 )) .
C odigo 6.6: Pre- y poscondici on de la operacion goCinema.
En el codigo 6.6 se especican la pre- y poscondicion de la operaci on goCinema. Como
pre-condici on se exige que no exista una entrada Ticket con la misma hora de inicio.
Como poscondici on, debe haber fracasado la operaci on o bien el cliente self debe tener
una entrada cuya hora de inicio coincida con la hora de inicio que indica el par ametro de
la operacion, y ademas haya una entrada mas que antes de empezar la operaci on.
119
120
CAP
ITULO 7
Conclusi on
En el presente proyecto n de carrera se ha realizado una transformaci on que permite,
de forma automatica, vericar la especicaci on de un sistema dada en el lenguaje UML
con restricciones OCL.
Por un lado, gracias a UML es posible modelar un sistema con sus diferentes diagra-
mas. En particular, la estructura estatica del sistema se dene en UML con un diagrama
de clases. En cambio, para el comportamiento din amico se pueden usar un conjunto de di-
ferentes tipos de diagramas que se complementen. En el caso del intercambio de mensajes
entre objetos, el diagrama que modela este comportamiento es el de secuencia. Adem as,
con OCL es posible completar dichos modelos de un sistema, haciendolos m as precisos.
OCL permite formalizar los estados v alidos del sistema que modelamos con invarian-
tes. Para las operaciones, OCL proporciona mecanismos para especicarlas con precisi on
gracias a la denici on de pre- y poscondiciones.
Por otro lado, Maude ha demostrado ser un entorno formal donde prototipar sistemas,
tanto la estructura como el comportamiento, y con ayuda de sus herramientas realizar
an alisis sobre el modelado del sistema. Una de estas herramientas es mOdCL, un interprete
de OCL ejecutado sobre el entorno Maude. mOdCL especica sobre el entorno Maude
toda la semantica del lenguaje OCL, respetando su sintaxis original. Una cualidad que ha
demostrado tener mOdCL es poder vericar los invariantes y las pre- y poscondiciones de
las operaciones denidas en Maude [RD11]. Para poder realizar la vericaci on din amica
de una operaci on, esta ha de estar denida en Maude para poder utilizar el motor de
reescritura de mOdCL y monitorizar que los estados cumplen la pre- y poscondici on
denida.
121
7.1. Trabajo futuro
Aunque el sistema haya sido modelado en UML, para poder analizar el sistema con la
herramienta mOdCL, el sistema tena que especicarse de nuevo en Maude. Para solven-
tar esta dicultad, se ha realizado una transformacion siguiendo la metodologa DSDM.
Gracias a este trabajo, es posible vericar el comportamiento din amico de un sistema que
ha sido especicado en UML (con diagrama de clases y secuencia).
En la gura 7.1 se presenta un resumen visual del trabajo que engloba este proyecto n
de carrera
1
. Con estas transformaciones, un usuario podr a vericar sus especicaciones
UML sin tener conocimiento de Maude ni de mOdCL. De esta forma, la herramienta
mOdCL es m as accesible al p ublico que desee vericar sus especicaciones UML y realizar
un an alisis de los modelos que denen un sistema en las etapa m as tempranas del desarrollo
software.
Figura 7.1: Esquema nal del PFC.
7.1. Trabajo futuro
Una de las ampliaciones a este proyecto n de carrera que mas impacto tendra es su
integraci on en Eclipse como plugin. De esta forma, y con un trabajo de integraci on en
Papyrus, se lograra que el proceso de transformaci on y vericaci on fuera transparente al
1
Este proyecto n de carrera abarca la transformacion rodeada por el recuadro rojo.
122
Captulo 7. Conclusion
usuario. As se lograra obtener la salida de la vericaci on del sistema una vez que este
haya sido modelado en UML.
Otra ampliacion futura, en lnea con la anterior, es la de transformar diagramas de ob-
jetos a estados iniciales Maude. Con la versi on actual, el estado inicial para la vericacion
del sistema es preciso proporcionarlo.
Adem as del diagrama de objetos de UML, se podran considerar otros diagramas de
UML, como el de actividad, que especica el comportamiento de una operaci on, centrando-
se mas en el funcionamiento de esta y no en la interaccion con los dem as objetos.
Por otro lado, la transformaci on actual no permite que dos objetos tengan una ope-
raci on con el mismo nombre, ni tampoco la sobrecarga de operaciones. Esto se puede
solucionar si en el momento de transformar del diagrama de clases a Maude se asigse un
identicador unico a cada objeto UML Operation. En la transformaci on actual no se ha
llevado a cabo porque sera dicultoso escribir el estado inicial con identicadores de ope-
raciones unicos (recuerdese que el estado inicial debe contener una llamada a la operacion
que se desea vericar).
7.2. Trabajo relacionado
Entre los trabajos relacionados, el mas destacable es e-Motions [RDV09]. e-Motions es
un entorno donde denir un DSL (Domain-Specic Language). Dada su sintaxis abstracta
como un metamodelo Ecore, es posible denir su sintaxis concreta asignando a cada
concepto del lenguaje una imagen. La sem antica del DSL viene dada como reglas de
reescritura, con notaciones de tiempo.
A partir un estado inicial dado como un modelo (conforme al metamodelo que dene
el DSL), dicho modelo se reescribe seg un la semantica descrita por reglas (junto a sus
notaciones de tiempo). La salida es dada como otro modelo. Tanto las condiciones de
las reglas, los helpers y las expresiones que modican los valores de los atributos son
especicados con expresiones OCL
2
.
Para ejecutar el sistema, tanto la sintaxis abstracta como la sem antica del DSL son
transformadas a Maude con una transformacion ATL, al igual que se hace en este pro-
yecto n de carrera. mOdCL es fundamental en e-Motions para poder ejecutar todas las
sentencias OCL con las que se ha especicado la sem antica del lenguaje.
2
Para informacion mas detallada acerca de e-Motions vease [Riv10].
123
7.2. Trabajo relacionado
124
Bibliografa
[BCP12] Marco Bernardo, Vittorio Cortellessa, and Alfonso Pierantonio, editors. For-
mal Methods for Model-Driven Engineering - 12th International School on
Formal Methods for the Design of Computer, Communication, and Software
Systems, SFM 2012, Bertinoro, Italy, June 18-23, 2012. Advanced Lectures,
volume 7320 of Lecture Notes in Computer Science. Springer, 2012. (Citado
en la p agina 14.)
[BCW12] Marco Brambilla, Jordi Cabot, and Manuel Wimmer. Model-Driven Software
Engineering in Practice. Morgan & Claypool, 2012. (Citado en la p agina 8.)
[Bez05] Jean Bezivin. On the unication power of models. Software and System
Modeling, 4(2):171188, 2005. (Citado en las paginas 7 y 8.)
[BM08] Artur Boronat and Jose Meseguer. An algebraic semantics for mof. In Procee-
dings of the Theory and practice of software, 11th international conference on
Fundamental approaches to software engineering, FASE08/ETAPS08, pages
377391, Berlin, Heidelberg, 2008. Springer-Verlag. (Citado en la p agina 52.)
[CDE
+
07] Manuel Clavel, Francisco Duran, Steven Eker, Patrick Lincoln, Narciso Mart-
Oliet, Jose Meseguer, and Carolyn L. Talcott, editors. All About Maude - A
High-Performance Logical Framework, How to Specify, Program and Verify
Systems in Rewriting Logic, volume 4350 of Lecture Notes in Computer Scien-
ce. Springer, 2007. (Citado en las paginas 18, 25, 26 y 28.)
[CH06] K. Czarnecki and S. Helsen. Feature-based survey of model transformation
approaches. IBM Syst. J., 45(3):621645, July 2006. (Citado en la pagina 10.)
[DR] Francisco Duran and Manuel Roldan. Checking mOdCL with a bench-
mark for OCL. Disponible en http://maude.lcc.uma.es/mOdCL/docs/
mOdCL-benchmark.pdf. (Citado en la p agina 34.)
125
[ea] Hugo Bruneliere et al. ATL User Guide. Disponible en http://wiki.
eclipse.org/ATL/User_Guide_-_The_ATL_Language. (Citado en las pagi-
nas 45 y 47.)
[Fou] Eclipse Foundation. Eclipse Modeling Framework Project (EMF). Disponi-
ble en http://www.eclipse.org/modeling/emf/. (Citado en las p aginas 12
y 15.)
[JABK08] Frederic Jouault, Freddy Allilaire, Jean Bezivin, and Ivan Kurtev. Atl: A
model transformation tool. Science of Computer Programming, 72(12):31
39, 2008. Special Issue on Second issue of experimental software and toolkits
(EST). (Citado en la p agina 42.)
[OMG03a] OMG. MDA Guide Version 1.0.1. http://www.omg.org/cgi-bin/doc?omg/
03-06-01.pdf, June 2003. (Citado en la p agina 6.)
[OMG03b] OMG. Model Driven Architecture (MDA) Guide, 2003. OMG doc. ab/2003-
06-01. (Citado en la p agina 7.)
[RD11] Manuel Roldan and Francisco Duran. Dynamic validation of ocl constraints
with modcl. ECEASST, 44, 2011. (Citado en las p aginas 3, 34 y 121.)
[RDV] Jose Rivera, Francisco Dur an, and Antonio Vallecillo. Maude Metamodel. Dis-
ponible en http://atenea.lcc.uma.es/index.php/Main_Page/Resources/
MaudeMM. (Citado en la p agina 31.)
[RDV09] Jose E. Rivera, Francisco Duran, and Antonio Vallecillo. A graphical ap-
proach for modeling time-dependent behavior of DSLs. In Proceedings of the
2009 IEEE Symposium on Visual Languages and Human-Centric Computing
(VL/HCC), VLHCC 09, pages 5155, Washington, DC, USA, 2009. IEEE
Computer Society. (Citado en las paginas 51, 52 y 123.)
[Riv10] Jose E. Rivera. On the Semantics of Real-Time Domain Specic Modeling
Languages. PhD thesis, University of Malaga, 2010. (Citado en las paginas 34
y 123.)
[RRDV07] Jose Ra ul Romero, Jose Eduardo Rivera, Francisco Dur an, and Antonio Va-
llecillo. Formal and tool support for model driven engineering with maude.
Journal of Object Technology, 6(9):187207, 2007. (Citado en la pagina 52.)
[Sel11] Bran Selic. A short catalogue of abstraction patterns for model-based software
engineering. Int. J. Software and Informatics, 5(1-2):313334, 2011. (Citado
en la p agina 6.)
126
[uml05] UML 2.0 Superstructure Specication. Technical report, Object Management
Group (OMG), August 2005. (Citado en las p aginas 56 y 84.)
[WK03] Jos Warmer and Anneke Kleppe. The Object Constraint Language: Getting
Your Models Ready for MDA. Addison-Wesley Longman Publishing Co., Inc.,
Boston, MA, USA, 2 edition, 2003. (Citado en las p aginas 17 y 99.)
127

VDMU MorenoDelgado PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

VDMU MorenoDelgado PDF

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD DE M

ECNICA SUPERIOR DE INGENIER

AMICA DE MODELOS UML

ALAGA, Septiembre de 2013

ECNICA SUPERIOR DE INGENIER

O POR OTORGAR LA CALIFICACI

son terminos del mismo kind y l es la etiqueta. La transici on

). La sintaxis para denir una regla incondicional en Maude es:

Ultima regla. Para el correcto funcionamiento de la pila de mOdCL

Ultima regla est a especicado en el siguiente c odigo:

También podría gustarte