Ocl 1

UNIVERSIDAD COMPLUTENSE DE MADRID
FACULTAD DE INFORM
ATICA
DEPARTAMENTO DE SISTEMAS INFORM
ATICOS Y COMPUTACI
ON
UNA SEM
ANTICA FORMAL EJECUTABLE

PARA OCL CON APLICACIONES
AL AN
ALISIS Y A LA VALIDACI
ON DE MODELOS
Marina Egea Gonzalez
Tesis Doctoral dirigida por el profesor
Dr. Manuel Garca Clavel
Madrid, 2008
2
A mis padres, cuya generosidad, trabajo,
sacricio y cari no son mi ejemplo.
A mi marido e hijos, por vuestro apoyo.
A mis hermanos, Antonia, Candela,
Diego y Loly, porque siempre estais.
A mis cu nados y sobrinos, Marina,
Candela, Adolfo y Sofa, nunca dejeis
de esforzaros por lo que quereis.
Resumen
Una practica est andar en la ingeniera del software es la construcci on de
modelos. Tres son las razones principales que avalan la metodologa de desa-
rrollo de software [Obj03]: en primer lugar, si los modelos se construyen en las
fases iniciales de an alisis de requisitos y de dise no, es posible detectar errores
antes de implementar el sistema; en segundo lugar, los modelos pueden servir
como especicaciones que guen las fases siguientes de desarrollo del sistema; en
tercer lugar, si los modelos son sucientemente formales, es posible utilizarlos
como punto de partida para un proceso riguroso de renamiento que culmi-
ne en la generaci on (al menos parcial) del c odigo que implemente el sistema.
Este ha sido el contexto de la investigacion aqu presentada, a saber, el desarro-
llo de metodos y herramientas formales que permitan la aplicaci on rigurosa de
la metodologa MDA. El presente documento recoge los principales resultados
cientcos, tecnol ogicos y de transferencia de conocimientos a la industria que
se han obtenido.
La evoluci on de los lenguajes de modelado fue constante hasta la aparici on
de UML (Unied Modeling Language) [Obj05b], convertido en la actualidad
en el lenguaje est andar para el modelado de sistemas software. Dentro de este
est andar, OCL (Object Constraint Language) [OCL06] es el lenguaje utilizado
por los modeladores para expresar restricciones que a naden informacion a los
diagramas UML y precisan su signicado. OCL es, ademas, un lenguaje para
realizar consultas (queries) sobre la informacion contenida en los modelos. En
teora, los modeladores pueden utilizar OCL para analizar y validar sus propios
modelos, por tanto, no tienen que pasar esta tarea a otros ingenieros con una
preparacion mas intensa en matematicas o en l ogica formal. Sin embargo, en
la practica los modeladores s olo utilizaran OCL cuando se les proporcionen las
herramientas adecuadas: sin ellas, el esfuerzo y la creatividad necesarios para
analizar y validar sus modelos son incluso superiores a los requeridos para cons-
truir estos modelos. Actualmente son escasas las herramientas que proporcionan
soporte al lenguaje OCL y una de las razones de esta situaci on es la falta de
una semantica formal para el lenguaje OCL que est a paccamente aceptada
por todos los actores dentro de la comunidad UML.
El objetivo principal de esta tesis es la elaboraci on de una semantica ecua-
cional para los diagramas de clase UML con restricciones OCL que permita
ademas la validaci on autom atica de estos diagramas. Esta semantica se dene
en el captulo 2 de este trabajo mediante una (meta-)funci on que, dada una
3
4
expresi on OCL y un diagrama UML, genera un interprete ecuacional capaz de
evaluar la expresi on en el contexto proporcionado por el diagrama: en concre-
to, la (meta-)funcion propuesta construye una especicaci on ecuacional E (el
interprete) y un termino t (la traducci on) tal que la forma canonica de t en E
representa el valor de la expresi on en el contexto proporcionado por el diagrama.
En este mismo captulo se demuestra que esta forma canonica existe y es unica
puesto que las especicaciones ecuacionales generadas por la (meta-)funcion son
siempre Church-Rosser y terminantes.
En el captulo 3 se describe la herramienta desarrollada, llamada ITP/OCL,
que implementa la (meta-)funcion propuesta en el captulo 2 para proporcionar
al usuario un evaluador autom atico de expresiones OCL sobre diagramas de
objetos UML. Recientemente, el ITP/OCL ha sido integrado en una herramienta
graca de modelado, llamada MOVA [CET07a, CET07b].
Como antes se ha mencionado, OCL puede utilizarse tambien para el an alisis
y la validaci on de modelos. En el captulo 4 se describe el uso de una extensi on
de la herramienta ITP/OCL, llamada ITP/OCL+S, para el an alisis de polti-
cas de seguridad en diagramas SecureUML: la idea es realizar consultas OCL
sobre la instancia del metamodelo del lenguaje de modelado (SecureUML) que
corresponde al modelo que est a siendo analizado.
El interes del an alisis de polticas de seguridad radica en el creciente uso
de modelos para la descripcion de los diversos aspectos relacionados con la
seguridad de un sistema: el objetivo es evitar que estos se integren en el sistema
de forma post-hoc, es decir, una vez que el sistema est a ya dise nado. Esta es la
lnea de trabajo esta basada en la propuesta de Basin [BDL06] que consiste en
la construcci on de modelos que integran el dise no del sistema con su poltica
de seguridad. En esta propuesta, las polticas de seguridad pueden incluir tanto
aspectos declarativos (que dependen de informacion predenida: por ejemplo,
de reglas de control de acceso a recursos), como program aticos (que dependen de
informacion dinamica: por ejemplo, de restricciones que tienen que satisfacerse
en los estados concretos). En el captulo 4 se describe c omo el an alisis de estos
modelos puede realizarse de forma rigurosa y autom atica utilizando OCL.
Finalmente, se describe el resultado de un proyecto industrial directamen-
te relacionados con el contexto de esta investigacion: a saber, el desarrollo de
metodos y herramientas formales que permitan la aplicaci on rigurosa de la me-
todologa MDA. Fue rmado con INDRA Sistemas S.A. y tena por objeto el
modelado de un sistema para la conguracion de informes de test y la genera-
cion de c odigo a partir de los modelos construidos. Para este proyecto fueron de
especial utilidad los resultados presentados en el captulo 4.
Agradecimientos
Mi mayor agradecimiento es para mi director de tesis, Manuel, por tantas
cosas que no podra enumerar. Tambien por su paciencia, correcciones, consejos,
disponibilidad y trabajo abnegado durante estos a nos. Por preocuparse de que
sacara de lo bueno, lo mejor. Por su atenci on cari nosa a mi familia. Tambien a
Elena por acudir siempre que haca falta y por sus constantes animos.
Historicamente, mi agradecimiento, en primer lugar, a Werner Altmann, por
animarme a realizar la tesis doctoral en este area y mostrarme que los peque nos
descuidos son, a la larga, fuente de grandes problemas. Por ser desde que nos
conocimos un amigo leal en la distancia y por apostar por nuestro trabajo.
Agradezco tambien su acogida cuando empezaba el doctorado en la Univer-
sidad de Murcia al Grupo de Ingeniera del Software.
De la Universidad Complutense, agradezco a todo el grupo UCMaude su
atenci on y ayuda cada vez que les he necesitado. A Narciso por ofrecerme la
posibilidad de integrarme en su grupo de investigacion y proyectos y por sus
consejos en los momentos clave de estos a nos. A Alberto por su disponibili-
dad y ayuda para ense narme al principio a tratar con Linux y Maude. A Juan
Santacruz, que ha sido un buen compa nero de fatigas durante estos a nos. A
Miguel Palomino, por sus comentarios detallados a los trabajos contenidos en
esta tesis. A Gustavo Santos, por no desaprovechar ocasion de transmitirme su
apoyo y animo. A Ricardo Pe na, Isabel Pita, Clara Segura y Adrian Riesco por
el ambiente de trabajo que crean.
A David Basin, muy en especial, por acogerme tan c alidamente durante mi
estancia en su grupo de Seguridad de la Informaci on en el ETH de Zurich y por
sus sabios consejos profesionales, comprensi on y apoyo.
Tambien en especial a Viviane Torres agradezco sus comentarios tanto al
trabajo como a la herramienta, sus utiles discusiones e ideas, sus animos y
gua en el camino del metamodelado. A Christiano Braga tambien le agradezco
mucho su interes y apoyo.
A Miguel A. Garca que ha sufrido con nosotros los ultimos meses de este
trabajo.
Al personal del IMDEA Software por brindarme un optimo y agradabilsimo
ambiente de trabajo para nalizar esta tesis.
Por ultimo, agradezco tambien su nanciaci on al Ministerio de Educaci on
y Ciencia, que mediante una beca FPI (BES2004-3431) adscrita al proyecto
MIDAS (TIC2003-01000) ha permitido esta investigacion casi en su totalidad.
5
6
Indice general
1. Introducci on 9
1.1. Model Driven Architecture (MDA) en el Desarrollo de Software . 10
1.2. Unied Modeling Language (UML) . . . . . . . . . . . . . . . . . 11
1.3. Object Constraint Language (OCL) . . . . . . . . . . . . . . . . 12
1.4. Metodologa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5. Contribuciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.6. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2. Una Semantica Ecuacional para OCL 19
2.1. El Lenguaje de Modelado UMLMOVA . . . . . . . . . . . . . . . . 20
2.1.1. Diagramas de Clase . . . . . . . . . . . . . . . . . . . . . 20
2.1.2. Diagramas de Objetos . . . . . . . . . . . . . . . . . . . . 23
2.2. El Lenguaje OCLMOVA . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.1. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.2. Usos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.3. Gramatica . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3. El Generador de Interpretes Ecuacionales de OCLMOVA . . . . . . 31
2.3.1. Terminologa . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3.2. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.3. Denicion . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.4. Propiedades . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.4. Extensiones, Trabajo Relacionado y Futuro . . . . . . . . . . . . 59
3. Una Herramienta OCL Basada en Reescritura 65
3.1. Maude como Meta-Herramienta Formal . . . . . . . . . . . . . . 67
3.2. La herramienta ITP/OCL . . . . . . . . . . . . . . . . . . . . . . 68
3.2.1. Estados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.2.2. Comandos . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.2.3. Interacci on . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.2.4. Ejecuci on . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.3. La Herramienta de Validaci on ITP/OCL . . . . . . . . . . . . . . 88
3.4. Trabajo Relacionado . . . . . . . . . . . . . . . . . . . . . . . . . 90
7
8

INDICE GENERAL
4. Aplicaciones de OCL al Analisis de Modelos 93
4.1. Una Metodologa Basada en Metamodelos . . . . . . . . . . . . . 95
4.2. Modelos de dise no con seguridad . . . . . . . . . . . . . . . . . . 98
4.2.1. SecureUML y sus Dialectos . . . . . . . . . . . . . . . . . 98
4.2.2. Diagramas SecureUML . . . . . . . . . . . . . . . . . . . 101
4.2.3. Diagramas SecureUML como Instancias del Metamodelo . 103
4.3. Analizando Modelos de dise no con seguridad . . . . . . . . . . . 106
4.3.1. Sem antica . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.3.2. Operaciones de An alisis . . . . . . . . . . . . . . . . . . . 108
4.3.3. Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.4. La herramienta ITP/OCL+S . . . . . . . . . . . . . . . . . . . . . 111
4.4.1. Estados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
4.4.2. Comandos . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
4.4.3. Interacci on . . . . . . . . . . . . . . . . . . . . . . . . . . 115
4.4.4. Ejecuci on . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
4.5. Extensiones, Trabajo Relacionado y Futuro . . . . . . . . . . . . 126
5. OCL en un Proyecto Industrial 131
5.1. Requisitos del Proyecto . . . . . . . . . . . . . . . . . . . . . . . 133
5.2. Modelando Requisitos Funcionales . . . . . . . . . . . . . . . . . 133
5.3. Modelando Requisitos de Control de Acceso . . . . . . . . . . . . 135
5.4. Generando Aplicaciones Seguras . . . . . . . . . . . . . . . . . . 137
5.5. Lecciones Aprendidas y Trabajo Futuro . . . . . . . . . . . . . . 140
A. Pruebas Auxiliares 151
A.1. Propiedades de la Funci on interpret() . . . . . . . . . . . . . . . 152
A.2. Propiedades de la Funci on interpret+() . . . . . . . . . . . . . . 163
A.3. Propiedades de genRls(T) . . . . . . . . . . . . . . . . . . . . . . 174
B. El Metamodelo de SecureUML+ComponentUML 179
B.1. La Sintaxis Abstracta de SecureUML . . . . . . . . . . . . . . . . 180
B.2. La Sintaxis Abstracta de ComponentUML . . . . . . . . . . . . . 186
B.3. La Sintaxis Abstracta de SecureUML+ComponentUML . . . . . 189
B.4. La Transformacion de Sintaxis Concreta a Abstracta . . . . . . . 192
Captulo 1
Introduccion
9
10 Captulo 1. Introduccion
1.1. Model Driven Architecture (MDA) en el
Desarrollo de Software
Conforme el tiempo pasa, crece la complejidad de los sistemas software obli-
gando a los desarrolladores de software a trabajar en niveles de abstraccion cada
vez mas altos para poder manejarla. Actualmente, el modelado de software cons-
tituye una tecnica clave para que los desarrolladores puedan trabajar en esos
altos niveles. El rol que desempe nan los modelos en los proyectos de software es
comparable al rol que juegan los anteproyectos en los proyectos de ingeniera.
A largo plazo, un modelo detallado ahorra tiempo y dinero porque permite a
los desarrolladores considerar alternativas, seleccionar la mejor opcion, resol-
ver detalles y alcanzar el acuerdo antes de que nadie empiece a construir la
aplicaci on [Obj08b]. En esta lnea, el Object Management Group [Obj08a] ha
propuesto la iniciativa de model driven architecture (arquitectura dirigida por
modelos) (MDA) [Obj03], que muchos consideran el siguiente paso l ogico en la
evoluci on del modelado y de las tecnologas de desarrollo dirigidas por modelos.
MDA se centra en la denici on de modelos a distintos niveles de abstraccion
durante todo el ciclo de vida del sistema software y en relacionarlos mediante
transformaciones de unos a otros con el objetivo de capturar as todo el desa-
rrollo del sistema software (incluido el mantenimiento a largo plazo).
Sin embargo, en la practica dominante actualmente, los modelos tienden a
ser construidos (algunas veces incluso despues de construida la aplicaci on y so-
lamente para prop ositos de documentacion) en varios niveles de abstraccion y
utilizando muchas reglas implcitas que son usadas para (de forma imprecisa)
relacionar los modelos entre ellos y con el c odigo. A este respecto, muchos au-
tores creen que la visi on de MDA, en la que los modelos son artefactos que
hay que mantener al mismo tiempo que el c odigo, solo se realizara si el bene-
cio obtenido al producir los modelos es considerablemente mayor y el esfuerzo
requerido para mantenerlos alineados con el c odigo es considerablemente me-
nor que los necesarios en la practica actual: En un proyecto, muchos modelos
a distintos niveles de abstraccion son creados, evolucionan y son analizados y
transformados. Mantener manualmente el trazado de la variedad de relaciones
entre los modelos (por ejemplo, versiones, renamientos, realizaciones o relacio-
nes de dependencia) a nade una complejidad accidental signicativa al proceso de
desarrollo MDA. Actualmente, las herramientas de modelado no dan un soporte
adecuado para poder manejar efectivamente estas relaciones. [FR07]
En este contexto la tendencia actual hacia la estandarizaci on es considerada
por muchos como un movimiento estrategico crucial. Un estandar es un docu-
mento p ublico que establece especicaciones y procedimientos dise nados para
asegurar que un material, producto, metodo o servicio consiga su prop osito y
realice su uso pretendido. La estandarizaci on permite la integraci on y la inter-
operabilidad entre soluciones de m ultiples vendedores. Tambien crea un marco
abierto en el que una nueva generaci on de soluciones puede surgir para bene-
ciar a la industria en su totalidad e impulsar la colaboraci on entre vendedores
complementarios. De hecho, en el coraz on de la iniciativa MDA los est anda-
1.2. Unied Modeling Language (UML) 11
res OMG son importantes: Unied Modeling Language (UML), Meta Object
Facility (MOF), XML Metadata Interchange (XMI) o Common Warehouse Me-
tamodel (CWM). Estos est andares denen la infraestructura n ucleo de MDA
y han contribuido decisivamente al estado del arte actual en el modelado de
sistemas.
La clave de una adecuada estandarizaci on est a en mantener una distinci on
clara entre la sintaxis y la verdadera semantica. La semantica no es simplemente
un termino que los teoricos usan para demostrar teoremas, sino que ademas sirve
como base para denir las interconexiones entre distintos conceptos notacionales
y diferentes etapas del dise no.
La semantica constituye un elemento extremadamente importante en la de-
nicion de un lenguaje. De hecho, la carencia de una semantica precisa conlleva de
forma inevitable consecuencias indeseables tanto para los desarrolladores como
para los vendedores de herramientas: el alto esfuerzo dedicado al modelado no
siempre redundara en sistemas software de alta calidad.
En este contexto, desde la aparacion de UML se ha llevado a cabo un gran
esfuerzo para dotar a este lenguaje de una semantica formal. Este esfuerzo ha
contribuido enormemente a una comprensi on mas profunda de sus conceptos,
a la deteccion de lagunas e inconsistencias en el est andar y a la denici on de
tecnicas utiles para la validaci on de modelos.
1.2. Unied Modeling Language (UML)
El Unied Modeling Language (UML) es un lenguaje visual de modelado de
prop osito general que se utiliza para especicar, visualizar, construir y documen-
tar los artefactos de un sistema software. UML permite reejar las decisiones de
dise no sobre la estructura est atica y el comportamiento dinamico de un sistema.
Un sistema se modela como una colecci on de objetos discretos que interact uan
para llevar a cabo un trabajo que benecia, en ultimo termino, a un usuario
externo. La estructura est atica dene las categoras de objetos que son impor-
tantes para el sistema y para su implementacion, as como las relaciones entre
los objetos. El comportamiento dinamico dene la historia de los objetos a lo
largo del tiempo y las comunicaciones que se producen entre estos para con-
seguir determinados objetivos. UML contiene tambien elementos organizativos
para ordenar los modelos por paquetes que permitan a los equipos de desarrollo
trabajar en subsistemas mas manejables que el sistema completo, comprender
y controlar las dependencias entre estos paquetes (subsistemas), y manejar el
versionado de unidades del modelo en un entorno de desarrollo complejo. Asimis-
mo, contiene artefactos para representar decisiones de implementacion y para
organizar la futura distribuci on del sistema en componentes.
UML pretende unicar la experiencia pasada en tecnicas de modelado e
incorporar las mejores practicas software en un enfoque est andar. En 1996, la
OMG lanz o una petici on de propuestas para conseguir un enfoque est andar en el
modelado orientado a objetos. Los tres autores (Booch, Jacobson, y Rumbaugh)
que haban propuesto los metodos de trabajo orientados a objetos de mayor
impacto internacional empezaron a trabajar con especialistas en metodologa y
desarrolladores de distintas compa nas para realizar una propuesta de lenguaje
de modelado que fuera atractiva tanto para los miembros de la OMG como
para los vendedores de herramientas, especialistas en procesos y desarrolladores,
quienes en denitiva seran los usuarios nales del est andar.
Finalmente, el trabajo concluyo en la propuesta UML que se envi o a la OMG
en septiembre de 1997. UML fue adoptado un animemente por los miembros de
la OMG como est andar en noviembre de 1997. Despues de algunos a nos de ex-
periencia usando el lenguaje, la OMG requirio propuestas para actualizarlo con
el n de resolver problemas que la experiencia de uso haba mostrado y exten-
der el est andar con capacidades adicionales que eran interesantes para distintos
dominios de aplicaci on. Las propuestas se desarrollaron desde noviembre del
2000 hasta julio de 2003. La especicaci on 2.0 sigui o el proceso de nalizacion
normal de la OMG para resolver errores y problemas que se encontraron en la
implementacion inicial; estos trabajos culminaron en el 2005 [Obj05b]. La ulti-
ma especicaci on adoptada del lenguaje UML 2 es la versi on 2.1.2, disponible
p ublicamente desde noviembre de 2007.
UML ha suplantado efectivamente muchas de las notaciones de modelado
previas tanto en los procesos de desarrollo como en las herramientas de mode-
lado, aunque actualmente se puede observar una creciente tendencia a denir
lenguajes de dominio especco mas peque nos y manejables.
Como es sabido, cuando OCL se utiliza en otros diagramas UML, en concreto
en diagramas de estado y de secuencias [WK03], su semantica es la misma
que cuando se utiliza sobre diagramas de clases, como no poda ser de otro
modo, dada la relacion de coherencia que cabe esperar entre diagramas de clases,
de secuencias y de estados. Como es tambien sabido, en su uso est andar, las
expresiones OCL se eval uan en diagramas de objetos, es decir, en escenarios
de diagramas de clase. Por estas razones, para denir una semantica formal
ejecutable de OCL con aplicaciones al an alisis y la validaci on de modelos que es
el objetivo de la tesis, hemos considerado suciente el considerar el subconjunto
de UML que incluye los diagramas de clase y los diagramas de objetos.
1.3. Object Constraint Language (OCL)
El modelado, especialmente el modelado de software, ha sido tradicional-
mente sin onimo de producir diagramas. La mayora de los modelos consisten en
dibujos de echas y burbujas con alg un texto explicativo. De este modo la
informacion contenida en los modelos suele ser incompleta, informal, imprecisa
y en ocasiones, incluso inconsistente. Muchos de los defectos en un modelo se
deben a las limitaciones de los diagramas que se est an usando. Un diagrama
simplemente no puede expresar las declaraciones que deberan ser parte de una
especicaci on minuciosa. Para especicar los sistemas software, las expresiones
escritas en un lenguaje formal ofrecen un gran n umero de benecios sobre el
uso de diagramas: no son ambiguas y no est an sujetas a m ultiples interpreta-
ciones, por ejemplo, las de un analista y un programador; hacen el modelo mas
1.3. Object Constraint Language (OCL) 13
preciso y detallado; y pueden ser comprobadas por herramientas autom aticas
para asegurar que son correctas y consistentes con otros elementos del modelo.
Por otro lado, un modelo escrito en un lenguaje formal, que usa unicamente
expresiones, con frecuencia no es f acilmente entendido. Lo bueno de los dibujos
con burbujas y echas es que el signicado que se pretende transmitir es facil
de comprender.
La notaci on UML est a fuertemente basada en diagramas. Para dotarlo del
nivel de concisi on y expresividad que son necesarios en ciertos aspectos de un di-
se no se extendio el est andar con la especicaci on del Object Contraint Language
(OCL) [OCL06].
OCL es un lenguaje textual con un estilo notacional similar al de los len-
guajes orientados a objetos. En UML 1.1, OCL aparece como el est andar para
especicar invariantes, precondiciones y postcondiciones. Sin embargo, a partir
de UML 2.0 el uso asignado a OCL es mucho mas amplio [WK03]: actualmente,
OCL es utilizado, por ejemplo, para denir operaciones de consulta, referen-
ciar valores o establecer condiciones especcas del dominio. La primera versi on
ocial de OCL, se hizo p ublica en septiembre de 1997. La versi on actual del
lenguaje es la 2.0 y est a vigente desde mayo de 2006 [OCL06]; esta versi on
est a siendo sometida a revisiones que posiblemente acabar an con la publicaci on
de un nuevo est andar.
OCL es un lenguaje de especicaci on puro: la evaluaci on de una expresi on
OCL es instant anea de modo que cuando una expresi on se eval ua, simplemente
devuelve un valor sin cambiar nada en el modelo. OCL es un lenguaje fuerte-
mente tipado, con una notaci on simple, sin smbolos l ogicos, y que se basa en un
conjunto peque no de conceptos esenciales. Esto es as porque fue dise nado con el
objetivo fundamental de hacerlo ampliamente utilizable: debera ser facilmen-
te escrito y ledo por todos los profesionales de la tecnologa de objetos y por
sus clientes, es decir, gente que no son matematicos o ingenieros en inform ati-
ca [WK03]. Aunque OCL tambien se dise n o como un lenguaje formal, la ex-
periencia ha mostrado que su denici on no es lo sucientemente precisa. Varios
autores han se nalado problemas del lenguaje relacionados con ambig uedades, in-
consistencias o interpretaciones abiertas o circulares [RG02, MB06, CP06]. De
hecho, las cuestiones sobre la ultima especicaci on del lenguaje ascienden a unas
300, que siguen pendientes de aclaracion por parte de los comites de revisi on
(Revision Task Force) [OMG08b] y de nalizacion (Final Task Force) [OMG08a]
nombrados para este n por la OMG. La mayora de estos puntos se nalan alguna
falta de precisi on o completitud en la denici on de alg un aspecto del lenguaje,
desde asuntos menores hasta altamente signicativos. Ejemplos de estas cues-
tiones abiertas son: si todas las expresiones que contienen el valor undened
deberan evaluarse directamente a undened (cuestion 6546); si la operaci on
atten() ha de interpretarse como una operaci on de aplanamiento supercial o
profundo (cuestion 7642 y otras); cu al es la correcta interpretaci on de las opera-
ciones sortedBy o forAll (cuestion 6553); o si las operaciones de downcast como
asSet(), asSequence(), o asBag() deberan denirse sobre el tipo de colecci on
generico (cuestion 4451).
Durante los ultimos a nos, el ambito de aplicaci on de los lenguajes de mode-
lado y del modelado en general ha evolucionado para incluir cuestiones como la
denici on de metamodelos de dominio especco, la transformaci on de modelos,
el testing de modelos de dise no, o la validaci on y la simulaci on de modelos. La
mayora de estas nuevas aplicaciones hacen un uso intensivo de OCL e inclu-
so requieren extensiones no triviales del lenguaje [Obj05a]. En esta situaci on,
una especicaci on completa y no ambigua de OCL es claramente deseable y se
convierte en una necesidad si se quiere dotar de soporte autom atico, mediante
herramientas, a los distintos usos del lenguaje
1.4. Metodologa
En este trabajo pretendemos abordar algunos de los temas que son obje-
to de discusi on frecuente en la literatura cientca dentro de la comunidad de
OCL [Baa06, SB07, MPT08], incluyendo: si OCL es realmente un lenguaje for-
mal; si hay necesidad a un de este lenguaje; si OCL puede hacerse ejecutable;
c omo puede OCL aplicarse a lenguajes de dominio especco; o c omo construir
herramientas que promuevan el uso de este lenguaje. Una caracterstica distinti-
va de nuestro trabajo es que pretendemos tratar estos temas de un modo riguroso
y uniforme. Desde un punto de vista metodol gico, las hip otesis de partida para
nuestra investigacion son:
1. Que es posible dar una semantica formal para un subconjunto signicati-
vo de OCL. Por signicativo entendemos un subconjunto que permita la
formalizaci on de restricciones y consultas no triviales sobre modelos.
2. Que esta semantica formal puede denirse asociando de forma autom atica
a cada escenario y a cada consulta OCL sobre ese escenario una teora
ecuacional Church-Rosser y terminante, de forma que el signicado (la
semantica) de la expresi on sobre el escenario sea la forma canonica de la
expresi on en la teora ecuacional asociada.
3. Que la semantica formal as denida puede implementarse de forma directa
en lenguajes de programacion basados en la l ogica ecuacional, y utilizarse
de forma efectiva para la construcci on de herramientas que permitan la
evaluaci on de expresiones OCL, y el an alisis y la validaci on rigurosa de
modelos.
4. Que la semantica formal as denida permite, ademas, la utilizaci on de
herramientas formales ya existentes con el n de demostrar la consistencia
de modelos con restricciones OCL (en forma de invariantes, o en forma de
pre- y postcondiciones) o la terminaci on de operaciones denidas en OCL
por el usuario.
Tambien desde un punto de vista metodol ogico, consideramos parte de nues-
tra investigacion la validaci on de los resultados obtenidos y, en concreto, la
comprobaci on del uso efectivo de lenguaje OCL para el cual se proporcione
una semantica formal, y de las herramientas y metodologas de modelado que
1.5. Contribuciones 15
se construyan, en proyectos de desarrollo de software dirigido por modelos de
alcance industrial.
1.5. Contribuciones
A continuaci on resumimos las contribuciones mas relevantes de nuestra inves-
tigacion, organizadas por captulos. Para facilitar la valoraci on de los resultados
en el contexto de la investigacion mas reciente sobre los temas que abordan,
incluiremos al nal de los captulos una secci on especca sobre trabajos rela-
cionados.
En el captulo 2 proponemos una semantica formal para un subconjunto
signicativo de OCL que est a basada en una transformaci on original de
modelos UML con expresiones OCL a teoras ecuacionales. Denimos esta
transformaci on como una (meta-) funci on interpret () que, dada una expre-
si on OCL expression y un diagrama UML T, genera un interprete ecuacio-
nal para expression. M as formalmente, la funci on interpret () devuelve una
especicaci on ecuacional (, E) (el interprete), que es Church-Rosser y
terminante, y un -termino t (la traducci on) tal que la forma canonica
de t en (, E) representa el valor de expression sobre T. Por tanto, nuestra
funci on interpret() dene una semantica para OCL que es a la vez formal
y ejecutable.
En el captulo 3 presentamos una herramienta, llamada ITP/OCL, que pue-
de utilizarse para validar autom aticamente diagramas de clase UML con
respecto a invariantes OCL, usando la funci on interpret (). La herramien-
ta est a escrita completamente en Maude [CDE
+
07] y su implementacion
hace un uso intensivo de las capacidades reexivas de Maude para, en
primer lugar, evaluar ecientemente las expresiones OCL reescribiendo
sus correspondientes traducciones en los interpretes generados por la
funci on interpret () y, en segundo lugar, ofrecer una interfaz amigable
al usuario, para el que la semantica ecuacional subyaciente permanece
escondida. El objetivo de la herramienta es servir como metodo formal
ligero para ayudar a los modeladores de software a encontrar defectos en
los modelos en etapas tempranas del proceso de desarrollo de software.
Tambien sirve como metodo formal pr actico, directamente utilizable por
los modeladores.
Los principales resultados tecnicos de este captulo se presentaron en el
11th International Conference on Algebraic Methodology and Software Te-
chnology (AMAST06) [CE06a], que se celebr o en Kuressare (Estonia) en
julio de 2006, y en el 1st International Workshop on Algebraic Foundations
for OCL and Applications (WAFOCA06) [CE06b], celebrado en Valencia
en marzo de 2006. La herramienta ITP/OCL (junto con su IDE en Java) fue
presentada en el Academic Posters and Demonstrations Session of MO-
DELS 2007 [CET07a], que se celebr o en Nashville (EE.UU.) en octubre
de 2007, y en el Tools Demonstrations Session of JISBD 2007 [CET07b],
que se celebr o en Zaragoza en septiembre de 2007.
En el captulo 4 proponemos un metodo basado en metamodelos para
analizar propiedades de modelos mediante el uso de OCL. En sntesis, ex-
presamos las propiedades como consultas en OCL y las evaluamos sobre
las instancias del metamodelo que corresponden a los modelos dise nados
por el usuario. Mostramos c omo puede hacerse esto de una forma semanti-
camente precisa y signicativa y demostramos, a traves de ejemplos, que
este enfoque puede usarse para formalizar y comprobar propiedades de
seguridad no triviales de modelos de dise no junto con seguridad. Tam-
bien presentamos una herramienta, llamada ITP/OCL+S, que implementa
nuestro metodo basado en metamodelos para analizar polticas de segu-
ridad. Esta herramienta tambien est a completamente implementada en
Maude como una extensi on de la herramienta ITP/OCL.
Los principales resultados tecnicos de este captulo se presentaron en el
10th International Conference on Model Driven Engineering Languages
and Systems (MODELS07) [BCDE07], celebrado en Nashville (EE.UU.)
en octubre de 2007. Un artculo que extiende estos resultados [BMDE08]
ha sido aceptado para su publicaci on en la revista Information and Sof-
tware Technology Journal, en el n umero 4853 que es un especial sobre
desarrollo dirigido por modelos para sistemas de informacion seguros.
Finalmente, en el captulo 5, narramos nuestra experiencia al usar OCL en
un proyecto de software industrial en el que tenamos que modelar tanto los
requisitos funcionales como los de seguridad de un sistema de conguracion
de informes de tests. El proyecto fue nanciado por la empresa INDRA
Sistemas a traves de un contrato de artculo 83. Los resultados principales
de esta experiencia se presentaron en el Fourth European Conference on
Model Driven Architecture Foundations and Applications (ECMDA-FA
2008) [CSBE08], celebrado en Berln (Alemania) en julio de 2008.
1.6. Conclusiones
El trabajo aqu presentado es parte de una iniciativa mas amplia llevada
a cabo en el IMDEA Software Institute y en la Universidad Complutense de
Madrid para integrar el desarrollo riguroso de software basado en modelos y so-
portado por herramientas tanto en la ense nanza academica de la ingeniera del
software como en su aplicaci on industrial. El objetivo del trabajo es la denici on
de una semantica formal ejecutable para OCL y la implementacion de herra-
mientas que soporten la validaci on y el an alisis de los modelos basados en esta
semantica. Los lenguajes, metodos y herramientas desarrollados en este trabajo
han sido validados en proyectos industriales de desarrollo de software y han si-
do utilizados en cursos de ingeniera del software impartidos en la Universidad
Complutense de Madrid.
1.6. Conclusiones 17
En este trabajo hemos mostrado que nuestra semantica ecuacional para OCL
proporciona una base rigurosa para la construcci on de herramientas que posi-
bilitan la validaci on de modelos UML y el an alisis de las polticas de acceso
especicadas en modelos SecureUML. Tambien hemos indicado c omo es posi-
ble utilizar esta semantica formal en herramientas de gesti on de modelos para
comprobar la conformidad de los modelos con respecto a sus metamodelos. He-
mos igualmente se nalado que nuestra semantica ecuacional permite tambien la
utilizaci on de herramientas de demostracion de teoremas para comprobar las
relaciones l ogicas entre distintas expresiones OCL que restringen el signicado
de los modelos por ejemplo, entre invariantes, precondiciones y postcondicio-
nes. En esta lnea, forma parte de nuestro trabajo futuro la denici on formal de
las propiedades de consistencia de los modelos UML/OCL para un un mismo
sistema en concreto, de sus diagramas de clase, de secuencia y de estado y
la construcci on de herramientas formales que permitan la demostracion de estas
propiedades. En esta misma lnea, pretendemos tambien desarrollar en el futuro
herramientas que posibiliten la demostracion de propiedades de seguridad en
modelos SecureUML/OCL mas all a del an alisis de polticas de acceso que pode-
mos realizar con la metodologa y herramientas que hemos desarrollado en este
trabajo. Tambien hemos se nalado que la semantica ecuacional que denimos
para OCL permite el an alisis de la terminaci on de las deniciones recursivas
de operaciones que utilizan OCL. En esta lnea, forma parte de nuestro trabajo
futuro la integraci on de herramientas de terminaci on en entornos de desarrollo
de software basados en modelos que den soporte a OCL.
Finalmente, las herramientas que hemos desarrollado en este trabajo tiene
car acter de prototipos, que han probado su validez en el contexto academido
investigacion y ense nanza y tambien en proyectos pilotos en el contexto
industrial. Su objetivo, en cualquier caso, es mostrar que nuestra semantica
ecuacional puede ser implementada en herramientas que den soporte a OCL y
que esta implementacion es, ademas, directa en el lenguaje Maude, permitiendo
entonces la utilizaci on de otras herramientas formales del entorno Maude para
comprobar las relaciones l ogicas entre restricciones OCL o la terminaci on de
operaciones OCL denidas por el usuario aunque esta posibilidad, como se ha
mencionado anteriormente, no se explora en el presente trabajo. Sin embargo,
no creemos que el sistema Maude sea apropiado en terminos de eciencia
para implementar herramientas OCL que den soporte a los usos actuales del
lenguaje en entornos industriales por ejemplo, para la evaluaci on de consultas
en escenarios con un n umero muy elevado de objetos y enlaces [CED08b]. En
esta lnea, forma parte de nuestro trabajo actual [CED08a] la implementacion
de herramientas OCL que, basadas en las ideas contenidas en nuestra semantica
ecuacional, proporcionen sin embargo una performance m as adecuada a los
usos actuales de OCL en el contexto del desarrollo industrial de software dirigido
por modelos.
Captulo 2
Una Semantica Ecuacional
para OCL
19
20 Captulo 2. Una Sem antica Ecuacional para OCL
En este captulo denimos una funci on interpret() que, dada una expresi on
OCL y un diagrama UML, genera un evaluador para la expresi on sobre el dia-
grama: mas concretamente, la funci on interpret() devuelve un termino t y una
especicaci on ecuacional ejecutable 1. Debido a que la forma canonica de t en
1 correspondera al valor de la expresi on sobre el diagrama, decimos que t y
1 son, repectivamente, la traducci on y el interprete de la expresi on en el
contexto que el diagrama proporciona. Tambien probamos las propiedades que
garantizar an la ejecutabilidad de las especicaciones ecuacionales 1 generadas
por la funci on interpret (): a saber, las especicaciones ecuacionales generadas
son Church-Rosser y terminantes.
Nuestra denici on de la funci on interpret () no cubre los lenguajes UML y
OCL en su totalidad; de hecho, s olo est a denida para expresiones y diagramas
que pertenecen a ciertos subconjuntos de los metamodelos de UML y OCL,
a los que llamamos, respectivamente UMLMOVA y OCLMOVA.
1
Con todo, estos
subconjuntos contienen los principales elementos de modelado denidos en los
metamodelos UML y OCL y la funci on interpret() podra ser extendida de forma
natural para cubrir el resto.
El captulo est a organizado de la siguiente forma. En la secci on 2.1 introduci-
mos el lenguaje de modelado UMLMOVA y describimos sus usos principales. En la
secci on 2.2 introducimos el lenguaje OCLMOVA, describimos sus usos principales
y denimos su gram atica concreta. Finalmente, en la seccion 2.3 denimos la
funci on interpret () y probamos sus principales propiedades.
2.1. El Lenguaje de Modelado UMLMOVA
En esta secci on damos una descripcion informal del lenguaje UMLMOVA y
resaltamos sus diferencias con respecto al lenguaje est andar UML. El meta-
modelo MOF 2.0 del lenguaje UMLMOVA puede encontrarse en la p agina web
http://maude.sip.ucm.es/~marina/pubs/.
UMLMOVA es un subconjunto b asico del est andar UML. Los diagramas UML
que se mantienen en UMLMOVA son aquellos esenciales para el prop osito que nos
hemos marcado aqu: es decir, la denici on de una semantica formal y ejecutable
para OCL. Especcamente, UMLMOVA solamente incluye el lenguaje necesario
para denir diagramas de clases y objetos: los diagramas de clases proveen el
contexto en el que las expresiones OCL se escriben mientras que los diagramas
de objetos proveen los contextos de evaluaci on para las expresiones OCL. Los
diagramas UMLMOVA corresponden a los Modelos Objeto con sus estados, tal y
como son descritas en Semantics [OCL06, Apendice A.1].
2.1.1. Diagramas de Clase
Los diagramas de clase se usan para modelar la vista estructural de un
sistema. Esta vista es est atica, esto es, no describe el comportamiento del sistema
1
MOVA es el nombre de una herramienta en Java que proporciona una interfaz gr aca para
la herramienta ITP/OCL que presentaremos en el captulo 3.
2.1. El Lenguaje de Modelado UMLMOVA 21
Figura 2.1: Diagrama de Clases TRAIN-WAGON
que depende del tiempo. Cuando se modela un sistema, los diagramas de clase
son los primeros que se desarrollan y sobre ellos se completa el resto del dise no.
Alrededor de las clases se organiza la vista estructural de un modelo; el resto
de elementos bien pertenecen o bien se relacionan con estas clases.
Los elementos de modelado que se permiten en los diagramas de clase del
lenguaje UMLMOVA son un subconjunto de los que se describen en el est andar
UML: en particular, solamente pueden contener clases (posiblemente con atri-
butos), clases de enumeraci on, asociaciones y generalizaciones. La Figura 2.1
muestra un diagrama UMLMOVA que modela un sistema ferroviario simple. Un
tren (Train) puede poseer vagones (Wagon) y los vagones pueden estar conec-
tados a otros vagones (sus vagones predecesores y sucesores). Los trenes pueden
ser de dos tipos (TypesOfTrain): monorral (monorail ) o de alta velocidad (high-
speed). Los trenes se identican mediante una cadena de caracteres (identier)
y los vagones pueden ser de fumadores o no fumadores (smoking). Ademas
existe una categora especial de vagones que son los vagones de primera clase
(FirstClassWagon).
Ahora, describiremos restricciones adicionales que impone UMLMOVA al uso
normal de clases, clases de enumeraci on, atributos, asociaciones y generalizacio-
nes.
Clases Se usan para clasicar objetos y para especicar las caractersticas de
la estructura y el comportamiento de estos objetos. Los objetos pertenecientes
a una clase son sus instancias. Los atributos son las unicas caractersticas que
pueden especicarse en UMLMOVA. Ejemplos de clases en la Figura 2.1 son Train,
Wagon y FirstClassWagon.
Clases de Enumeraci on Se usan para clasicar algunos valores: sus instan-
cias son los valores que enumera. En UMLMOVA, las clases de enumeraci on deben
contener al menos un literal de enumeraci on. En la Figura 2.1, TypesOfTrain es
un ejemplo de clase de enumeraci on que contiene dos literales de enumeraci on:
monorail y high-speed.
Atributos Se usan para describir la estructura de los objetos de una clase.
Cada atributo tiene un nombre y un tipo que especica el dominio de los valores
de los atributos. UMLMOVA solamente permite atributos monovaluados. Los tipos
de los atributos solo pueden ser tipos primitivos de UML, en concreto Boolean,
Integer, y String, o tipos enumerados. Ejemplos de atributos en la Figura 2.1 son
typesOfTrain, identier, smoking, numberOfPassengers y hasBar.
Asociaciones Se usan para describir relaciones estructurales entre clases. Ca-
da conexion de una asociaci on a una clase se llama extremo de asociaci on. La
mayora de la informacion sobre una asociaci on se encuentra en sus extremos:
por ejemplo, un extremo de asociaci on puede tener un nombre, al que se llama
rol porque describe el papel que desempe na esa clase en la asociaci on. UMLMOVA
solamente admite asociaciones binarias que tengan los roles de las clases decla-
rados expltamente. La otra informacion importante que contienen los extremos
de asociaci on son sus multiplicidades. En la Figura 2.1, Ownership y Order son
ejemplos de asociaci on y train, wagon, succ y prec son ejemplos de roles en los
extremos de asociaci on.
Multiplicidades Se usan para indicar cu antas instancias de la clase que
est a conectada al extremo de asociaci on pueden relacionarse a una instancia
de la clase que est a conectada al otro extremo de la asociaci on. La multiplicidad
* signica 0 o mas instancias y es la multiplicidad por defecto asociada a un
extremo de asociaci on. Las multiplicidades pueden denirse tambien mediante
intervalos de la forma [a..b] de n umeros naturales, con b mayor que a, o mediante
intervalos de la forma [a..*], en los que el lmite superior es ilimitado. UMLMOVA
admite las multiplicidades UML. En la Figura 2.1, 1, *, y 0..1 son ejemplos de
multiplicidades.
Generalizaciones Se usan para describir una relacion taxon onomica entre
dos clases. Una generalizaci on especializa una clase general en otra mas espec-
ca. Especializacion y generalizaci on son diferentes vistas del mismo concepto.
Cada instancia de la clase especca es tambien una instancia indirecta de la
clase general: por tanto, la clase especca hereda las caractersticas de la clase
mas general y puede contener informacion adicional. UMLMOVA admite las gene-
ralizaciones. En la Figura 2.1 existe una relacion de generalizaci on entre Wagon
y FirstClassWagon.
2.1. El Lenguaje de Modelado UMLMOVA 23
2.1.2. Diagramas de Objetos
Un sistema adopta estados diferentes porque va cambiando a lo largo del
tiempo. Un diagrama de objetos modela el estado de un sistema en un mo-
mento particular. Sirve principalmente como herramienta para realizar an alisis,
validaciones y comprobaciones sobre el modelo est atico. Tambien puede usarse
para comprender un problema documentando ejemplos del dominio del proble-
ma.
Los elementos de modelado permitidos en los diagramas de objetos UMLMOVA
son b asicamente aquellos que proporciona el est andar UML: esto es, objetos
(posiblemente con atributos y sus valores) e instancias de asociaciones (enlaces).
La Figura 2.2 muestra un diagrama de objetos de UMLMOVA. Modela un estado
concreto del sistema ferroviario de la Figura 2.1, aunque probablemente sea un
escenario indeseable puesto que describe un tren que posee dos vagones ligados
entre s de forma cclica.
Train1:Train
type : Monorail
identifier : HG340
Wagon1:Wagon
numberOfPassengers = 80
smoking = false
Wagon2:Wagon
numberOfPassengers = 80
smoking = true
Ownership
Ownership
Order
pred
succ
Order
pred
succ
Figura 2.2: El Diagrama de Objetos TRAIN-WAGON-1.
A continuaci on, describimos las restricciones adicionales que impone el len-
guaje UMLMOVA al uso de objetos y enlaces.
Objetos Un objeto es una instancia de una clase. Los objetos pueden tener
valores asignados a cualquiera de los atributos que pertenecen a o que son he-
redados por sus clases.
En UMLMOVA, los atributos en los objetos siempre tienen un valor, posible-
mente el valor por defecto. El valor por defecto de un atributo de tipo Integer es
0; para un atributo de tipo Boolean su valor por defecto es true; para un atributo
de tipo String su valor por defecto es la cadena vaca; nalmente, para un atri-
buto de tipo enumerado su valor por defecto es el primer literal de enumeraci on
de la clase de enumeraci on. En la Figura 2.2, Train1, Wagon1 y Wagon2 son
ejemplos de objetos.
Instancias de Asociacion o Enlaces Un enlace es una instancia de una
asociaci on. Los objetos no pueden ligarse mediante dos instancias identicas de
la misma asociaci on. En UMLMOVA un enlace puede solamente relacionar dos
objetos (no necesariamente distintos) puesto que las asociaciones son binarias.
Ademas, la colecci on de objetos ligados a un solo objeto en un extremo de
asociaci on particular siempre forma un conjunto, ya que las asociaciones no
pueden est ar cualicadas. En la Figura 2.2, las lneas dibujadas son instancias
de las asociaciones Ownership y Order.
2.2. El Lenguaje OCLMOVA
En esta secci on damos una descripcion informal del lenguaje OCLMOVA y
subrayamos sus diferencias con respecto al lenguaje OCL est andar. El meta-
modelo MOF 2.0 del lenguaje OCLMOVA puede encontrarse en la p agina web
http://maude.sip.ucm.es/~marina/pubs/.
OCLMOVA es un subconjunto del lenguaje OCL que est a denido en Seman-
tics [OCL06, Apendice A.2]. Los tipos y las operaciones del est andar de OCL
que se mantienen en OCLMOVA son sucientes para nuestro prop osito, a saber,
para denir una semantica formal y ejecutable para un subconjunto signicativo
de OCL.
2.2.1. Descripcion
OCL es un lenguaje contextualizado: sus expresiones se escriben en el con-
texto que proporciona un modelo contextual. Ademas, cada expresi on OCL se
escribe en el contexto de una instancia de un tipo especco: la palabra reser-
vada self se usa para referirse a esta instancia contextual. OCL es tambien un
lenguaje tipado: las expresiones bien formadas tienen un tipo. Los tipos se or-
ganizan en una jerarqua de tipos, que determina cu ando dos tipos distintos son
conformes. Se dice que un tipo tipo1 es conforme con un tipo tipo2 cuando una
instancia del tipo1 puede utilizarse en cada lugar donde se espera una instancia
del tipo2. La relacion de ser conforme es transitiva.
Tipos Basicos OCL tiene los tipos Integer, Real, Boolean y String como los
tipos b asicos predenidos. Tambien tiene operaciones predenidas sobre estos
tipos. Los valores mas b asicos en OCL son aquellos que estan en sus tipos pre-
denidos. Los tipos b asicos predenidos que tiene OCLMOVA son Integer, Boolean
y String. Las operaciones OCL sobre los tipos b asicos predenidos que propor-
ciona OCLMOVA est an descritas informalmente en el Cuadro 2.1.
Otros tipos b asicos en OCL son las clases y las clases de enumeraci on que se
hayan denido en el modelo contextual. Estos tipos introducen valores b asicos
denidos por el usuario, es decir, las instancias de las clases y los valores enu-
merados. La regla de conformancia de tipos para los tipos de clase es simple:
cada tipo es conforme con cada uno de sus supertipos.
2.2. El Lenguaje OCLMOVA 25
Integer
+ (i:Integer):Integer El valor de la suma de self e i.
(i:Integer):Integer El valor de la sustracion de self e i.
(i:Integer):Integer El valor de la multiplicacion de self e i.
Boolean
or (b:Boolean):Boolean Verdadero si self o b es verdadero.
and (b:Boolean):Boolean Verdadero si tanto self como b son ver-
daderos.
not:Boolean Verdadero si self es falso.
implies (b:Boolean):Boolean Verdadero si self es falso, o si self y b
son verdaderos.
Cuadro 2.1: Operaciones OCLMOVA sobre Integer y Boolean.
OclType
= (object:OclType):Boolean Verdadero si self es el mismo objeto que
object.
<> (object:OclType):Boolean Verdadero si self es un objeto diferente
de object.
allInstances():Bag(T) Devuelve todas las instancias de self. El
tipo T es igual al de self.
Cuadro 2.2: Operaciones OCLMOVA sobre OclType.
OCLMOVA proporciona tanto tipos de clase como enumerados. Las propieda-
des de una clase, es decir, sus atributos y extremos de asociaci on, as como las
operaciones denidas en la clase, son operaciones OCL sobre el tipo de clase
correspondiente: sus valores son los valores de las propiedades correspondientes
sobre la instancia contextual. OCLMOVA proporciona las operaciones OCL que
corresponden a las propiedades de las clases.
Finalmente, OCL dene como tipos especiales OclType, OclModelElement y
OclAny, cuyos valores dependen tambien del modelo contextual. Los valores del
tipo OclType son las clases del modelo. Los valores del tipo OclModelElement
son los elementos de modelado dibujados en el modelo objeto (incluida la repre-
sentacion del estado del sistema) que no son tipos de clase. El tipo OclAny es
el supertipo de todos los tipos que proporciona el modelo contextual y los tipos
predenidos: por tanto, incluye los valores incluidos en cualquier tipo b asico.
Las operaciones OCL sobre los tipos OclType, OclModelElement y OclAny que
proporciona OCLMOVA se describen de modo informal en los Cuadros 2.2, 2.3
y 2.4. OCL proporciona otros tipos especiales como OclVoid y OclMessage que
no se discuten aqu puesto que OCLMOVA no los incluye.
Tipos Coleccion OCL proporciona tipos para diferentes clases de coleccio-
nes: bolsas (bags), conjuntos (sets), conjuntos ordenados (ordered sets) y se-
cuencias (sequences). Una bolsa es una colecci on de elementos en la que se
permiten duplicados: un objeto puede ser un elemento de una bolsa muchas
OclModelElement
= (object:OclType):Boolean Verdadero si self es el mismo objeto que
object.
<> (object:OclType):Boolean Verdadero si self es un objeto diferente
de object.
Cuadro 2.3: Operaciones OCLMOVA sobre OclModelElement.
OclAny
= (object:OclAny):Boolean Verdadero si self es el mismo objeto que
object.
<> (object:OclAny):Boolean Verdadero si self y object son objetos di-
ferentes.
oclAsType(typename:OclType):T Eval ua a self, donde self es del tipo que
identica typename.
oclType():T Eval ua a T si el tipo de self es el tipo de
T.
oclIsTypeOf(typename:OclType):Boolean Eval ua a verdadero si self es del tipo que
identica typename.
oclIsKindOf(typename:OclType):Boolean Eval ua a verdadero si self es conforme
con el tipo que identica typename.
Cuadro 2.4: Operaciones OCLMOVA sobre OclAny.
veces. Ademas, los elementos de una bolsa no est an ordenados. Un conjunto
es una colecci on de elementos donde no se permiten duplicados. Un conjunto
ordenado es un conjunto cuyos elementos est an ordenados. Una secuencia es
una bolsa cuyos elementos est an ordenados. Los tipos colecci on son realmente
tipos plantilla con un par ametro: un tipo colecci on concreto resulta al sustituir
un tipo por el par ametro. Las reglas de ser conforme entre tipos colecci on son
las esperadas: Bag(T1) (resp. Set(T1) y Sequence(T1)) es conforme con Bag(T2)
(resp. Set(T2) y Sequence(T2)) si T1 es conforme con T2. Los unicos tipos colec-
cion que incluye OCLMOVA son Bag(T) y Set(T), siendo T un tipo primitivo, uno
enumerado o un tipo de clase. Las colecciones se representan delimitando los
elementos de la colecci on mediante llaves: los elementos de la colecci on est an
separados por comas y el tipo de la colecci on se escribe antes de las llaves.
OCL posee numerosas operaciones para manipular colecciones, para compro-
bar propiedades de estas colecciones y para generar nuevas colecciones a partir
de otras existentes. Es util distinguir entre operaciones iteradoras y operaciones
no iteradoras; las primeras consisten en coleccionar primero el valor de una ex-
presi on dada sobre cada uno de los elementos de la colecci on original y entonces
comprobar una cierta propiedad sobre la colecci on resultante. Las operaciones
OCL tanto iteradoras como no iteradoras que incluye OCLMOVA se describen in-
formalmente en los Cuadros 2.5 y 2.6. OCLMOVA no incluye la forma mas general
de operador iterador en OCL, a saber, iterate.
OCL tambien incluye tipos tupla que, sin embargo, no son considerados en
OCLMOVA.
Bag(T)
size():Integer El n umero de elementos en la coleccion
self.
includes(object:T):Boolean Verdadero si object es un elemento de
self ; falso en otro caso.
excludes(object:T):Boolean Verdadero si object no es un elemento de
self ; falso en otro caso.
includesAll(c:Bag(T)):Boolean Verdadero si self contiene todos los ele-
mentos de c.
excludesAll(c:Bag(T)):Boolean Verdadero si self no contiene ninguno de
los elementos de c.
isEmpty():Boolean Verdadero si self es vaco.
notEmpty():Boolean Verdadero si self no es vaco.
= (bag:Bag(T)):Boolean Verdadero si self y bag contienen los mis-
mo elementos el mismo n umero de veces.
union(bag:Bag(T)):Bag(T) La union multiconjunto de self y bag.
including(object:T):Bag(T) La bolsa que contiene todos los elemen-
tos de self mas object.
excluding(object:T):Bag(T) La bolsa que contiene todos los elemen-
tos de self excepto todas las ocurrencias
de object.
asSet():Set(T) El conjunto que contiene todos los ele-
mentos de self, una vez eliminados los
duplicados.
Cuadro 2.5: Las operaciones no iteradoras de OCLMOVA
Bag(T)
exists(body:Boolean):Boolean Devuelve verdadero si body eval ua a ver-
dadero para al menos un elemento en la
coleccion self.
forAll(body:Boolean):Boolean Devuelve verdadero si body eval ua a ver-
dadero para cada uno de los elementos
de la coleccion self ; en caso contrario,
devuelve falso.
collect(body:T2):Bag(T2) Las bolsas de elementos que resultan de
evaluar body para cada miembro de la
coleccion self.
collect(body:Bag(T2)):Bag(T2) El resultado se devuelve aplanado.
select(body:Boolean):Bag(T) La coleccion formada por los elementos
de self para los que body eval ua a verda-
dero.
reject(body:Boolean):Bag(T) La coleccion formada por los elementos
de self para los que body eval ua a falso.
Cuadro 2.6: Las operaciones iteradoras de OCLMOVA.
2.2.2. Usos
OCL es tanto un lenguaje de restricciones como de consultas. Como lenguaje
de restricciones se usa para precisar la informacion que contienen los modelos
mediante la especicaci on de invariantes de clase, pre- y poscondiciones de ope-
raciones, o valores iniciales o derivados para los atributos. Un invariante es una
expresi on OCL que restringe las instancias validas de una clase a aquellas so-
bre las que el valor de la expresi on es cierto. Por ejemplo, el modelo ferroviario
mostrado en la Figura 2.1 no precisa si los trenes deben tener o no un vagon
de fumadores. A nadiendo el siguiente invariante OCL a la clase Train, pode-
mos incluir este requisito, a saber, que los trenes posean al menos un vagon de
fumadores.
self.wagons>exists(smoking)
Una precondicion es una expresi on OCL que restringe las instancias de una
clase sobre las que esta operaci on puede llamarse a aquellas sobre las que la
expresi on es verdadera. De modo similar, una poscondicion es una expresi on
OCL que restringe los posibles resultados de una operaci on a aquellos sobre los
cuales la expresi on es verdadera. Las poscondiciones usan con frecuencia la ope-
racion @pre que no es soportada por OCLMOVA. Finalmente, los valores iniciales y
derivados de los atributos pueden denirse tambien mediante expresiones OCL.
Como lenguaje de consultas, OCL se usa para analizar los modelos y para
validarlos sobre los escenarios seleccionados (estados del sistema), como veremos
en los captulos 3 y 4.
2.2.3. Gramatica
En esta secci on denimos la gram atica de OCLMOVA. Las reglas de produccion
se escriben usando el formalismo EBNF, en el que [ signica eleccion y ? signica
opcionalidad. En algunos casos, la sintaxis de los smbolos lexicos no se hace
explcita y es indicada por <String> en su lugar.
OclExpressionCS ::= PropertyCallExpCS
[ VariableExpCS
[ LiteralExpressionCS
[ IfExpCS
VariableExpCS ::= simpleNameCS
simpleNameCS ::= <String>
LiteralExpCS ::= EnumLiteralExpCS
[ CollectionLiteralExpCS
[ PrimitiveLiteralExpCS
EnumLiteralExpCS ::= simpleNameCS
CollectionLiteralExpCS ::= Bag CollectionLiteralPartsCS?
CollectionLiteralPartsCS ::= OclExpressionCS ( , CollectionLiteralPartsCS )?
PrimitiveLiteralExpCS ::= IntegerLiteralExpCS
[ StringLiteralExpCS
[ BooleanLiteralExpCS
IntegerLiteralExpCS ::= <String>
StringLiteralExpCS ::= <String>
BooleanLiteralExpCS ::= true
[ false
PropertyCallExpCS ::= ModelPropertyCallExpCS
[ IteratorExpCS
IteratorExpCS ::= OclExpressionCS -> collect
( VariableDeclarationCS [ OclExpressionCS )
[ OclExpressionCS -> select
[ OclExpressionCS -> reject
[ OclExpressionCS -> forAll
[ OclExpressionCS -> exists
VariableDeclarationCS ::= simpleNameCS : typeCS
typeCS ::= simpleNameCS
[ Bag ( simpleNameCS )
ModelPropertyCallExpCS ::= OperationCallExpCS
[ AttributeCallExpCS
[ AssociationEndCallExpCS
OperationCallExpCS ::=
not OclExpressionCS
[ OclExpressionCS or OclExpressionCS
[ OclExpressionCS and OclExpressionCS
[ OclExpressionCS implies OclExpressionCS
[ OclExpressionCS = OclExpressionCS
[ OclExpressionCS < OclExpressionCS
[ OclExpressionCS OclExpressionCS
[ OclExpressionCS > OclExpressionCS
[ OclExpressionCS + OclExpressionCS
[ OclExpressionCS . oclIsKindOf ( OclExpressionCS )
[ OclExpressionCS . oclIsTypeOf ( OclExpressionCS )
[ OclExpressionCS . oclAsType ( OclExpressionCS )
[ OclExpressionCS . oclType()
[ OclExpressionCS . allInstances()
[ OclExpressionCS -> excludes ( OclExpressionCS )
[ OclExpressionCS -> includes ( OclExpressionCS )
[ OclExpressionCS -> excluding ( OclExpressionCS )
[ OclExpressionCS -> including ( OclExpressionCS )
[ OclExpressionCS -> excludesAll ( OclExpressionCS )
[ OclExpressionCS -> includesAll ( OclExpressionCS )
[ OclExpressionCS -> union ( OclExpressionCS )
[ OclExpressionCS -> isEmpty()
[ OclExpressionCS -> notEmpty()
[ OclExpressionCS -> size()
[ OclExpressionCS -> asSet()
AttributeCallExpCS ::=
OclExpressionCS . simpleNameCS
AssociationEndCallExpCS ::=
OclExpressionCS . simpleNameCS
IfExpCS ::= if OclExpression
then OclExpression
else OclExpression
endif
2.3. El Generador de Interpretes Ecuacionales de OCLMOVA 31
2.3. El Generador de Interpretes Ecuacionales
de OCLMOVA
En esta secci on denimos una traducci on de modelos UMLMOVA que poseen
expresiones OCLMOVA a teoras ecuacionales. La traducci on proporciona una
semantica formal ejecutable para expresiones OCL. Esta secci on se organiza de
la siguiente forma: empezamos jando el signicado de las nociones tecnicas
usadas en la denici on y en las pruebas; entonces resaltamos los aspectos clave
de la denici on y de la traducci on para facilitar su comprensi on; nalmente,
damos la denici on formal y probamos sus principales propiedades.
2.3.1. Terminologa
Las siguientes nociones se usan en la secci on 2.3.3 para denir formalmente la
transformaci on desde modelos UMLMOVA que poseen expresiones OCLMOVA a es-
pecicaciones ecuacionales. Una signatura es un conjunto de pares (, i)
iN
tal que, para cualesquiera pares diferentes (, n), (
, m) , ,
. Cada par
(, n) declara un operador, donde es su smbolo y n es el n umero de sus argu-
mentos. El n umero de argumentos de un operador (, n), denotado por arity(),
se llama su aridad. Un operador con cero argumentos se llama constante.
Sea una signatura. Denotamos con ()
op
= [(, n) al conjunto
de smbolos declarados en . En las secciones siguientes utilizamos la nocion de
smbolo etiquetado con una posici on, que no es sino un caso particular de smbo-
lo. Una posici on es una secuencia de n umeros positivos separados por un punto.
Sean p y p
posiciones. Entonces, p
est a bajo p, denotado por p p
, si y solo si
existe una posici on p
tal que p
p.p
. Un smbolo etiquetado
p
es un smbolo
seguido por una posici on p. Sea un smbolo; si es un smbolo etiquetado,
es decir,
p
, denimos label () = p; en caso contrario, label () = 0. Sea
una signatura (que incluye, posiblemente, smbolos etiquetados), entonces,
labels() = label () [ ()
op
label () > 0.
Sea una signatura y X un conjunto de variables, tales que X ()
op
= .
Entonces, denotamos T
(X) al conjunto de terminos, inductivamente denidos

con las siguientes clausulas:
1. Cualquier x X pertenece a T
(X); esto es, las variables son terminos.

2. Cualquier ()
op
con arity() = 0 pertenece a T
(X); esto es, las

constantes son terminos.
3. Para cualquier smbolo ()
op
con arity() = n, n > 0, y cualesquiera
terminos t
i
T
(X), 1 i n, (t
1
, . . . , t
n
) pertenece a T
(X); esto
es, un operador aplicado al n umero correcto de subterminos produce un
nuevo termino.
Sea una signatura y X un conjunto de variables. Una sustituci on es una
funci on : X T
(X) y (t) denota el termino que resulta de sustituir simul-

taneamente cada variable x X en t por el termino (x).
Sea una signatura. Una -precedencia es un orden bien fundado, estricto
y parcial sobre , y un -estatus es una funci on que asigna a cada o
el valor mul o el valor lex
, para alguna permutacion sobre 1, ..., n, donde

n = arity().
Una -ecuaci on es una expresi on (X)l = r, donde X es un conjunto nito
de variables disjuntas de ()
op
, y l y r son terminos en T
(X).
Una especicaci on ecuacional es un par (, E), donde es una signatura y
E es un conjunto de -ecuaciones.
Las siguientes nociones se usan para probar la propiedad de terminaci on de
las especicaciones ecuacionales generadas por la transformaci on denida en la
secci on 2.3.3.
Una -ecuaci on orientada es una ecuaci on (X)l = r transformada en una
regla de reducci on (l r).
Un sistema de reescritura de terminos (TRS) es un par (, R) donde R es
un conjunto de -ecuaciones orientadas.
Sea (, R) un TRS. Entonces, un termino s reduce a un termino t en R,
denotado por s
R
t, cuando hay una secuencia de terminos s
1
, . . . , s
n
, tal que
s
1
s, s
n
t, y para cualquier i, 1 i < n hay una regla de reduccion (l r)
en R tal que s
i
es una instancia de l y s
i+1
es la correspondiente instancia de r.
Un termino s es reducible cuando existe un termino t tal que s
R
t; en
caso contrario, decimos que s es irreducible. Si s
R
t y t es irreducible, t es
una forma can onica de s.
Un TRS es terminante si y solo si no hay en el una cadena de reducciones
descendiente innita a
0
a
1
. . ..
Un orden estricto es una relacion transitiva e irreexiva. Un orden estricto >
sobre T
(X) es un orden de reescritura si y solo si

1. es compatible con : para todo s
1
, s
2
T
(X), f con aridad(f) = n,

n 0, si s
1
> s
2
entonces
f(t
1
, . . . , t
i1
, s
1
, t
i+1
, . . . , t
n
) > f(t
1
, . . . , t
i1
, s
2
, t
i+1
, . . . , t
n
)
para todo i, 1 i n, y todo t
1
, . . . , t
i1
, t
i+1
, . . . , t
n
T
(X).
2. es cerrado bajo sustituciones: para todo s
1
, s
2
T
(X) y todas las susti-

tuciones para T
(X), s
1
> s
2
implica que (s
1
) > (s
2
).
Un orden de reducci on sobre T
(X) es un orden de reescritura bien fundado.

Un orden de reduccion < sobre T
es compatible con un TRS (, R) si r < l

para cada regla de reduccion (l r) en R.
Un TRS (, R) es terminante si y solo si admite un orden de reduccion <
compatible sobre T
(X).
La nocion de orden de reduccion utilizada para probar la propiedad de ter-
minacion de las especicaciones ecuacionales generadas por la transformaci on
denida en la secci on 2.3.3. es la de rpo-orden de reduccion (ver la Denicion 3
en el apendice A.2). La propiedad interesante de estos ordenes es que, dada una
precedencia y un estatus sobre , existe exactamente un rpo-orden de reduccion
sobre T
.
Las siguientes nociones se usan para probar la propiedad de Church-Rosser
de las especicaciones ecuacionales generadas por la transformaci on denida en
la secci on 2.3.3.
Una regla de reduccion l r es lineal en la izquierda si ninguna variable
aparece repetida en l.
Sean l
i
r
i
, i = 1, 2 dos reglas cuyas variables se han renombrado para que
su interseccion sea vaca, X
l1r1
X
l2r2
= . Sea p una posici on en l
1
tal
que l
1
[p no es una variable. Si existe un unicador mas general para l
1
[p y l
2
,
entonces decimos que las reglas l
i
r
i
, i = 1, 2 generan un par crtico.
Un TRS se dice que es ortogonal si es lineal en la izquierda y no tiene pares
crticos. Todo TRC ortogonal es conuente y, por tanto, tiene la propiedad de
Church-Rosser.
2.3.2. Descripcion
Denimos la transformaci on de los modelos de dise no UMLMOVA con expre-
siones OCLMOVA a teoras ecuacionales como una funci on interpret () que, dada
una expresi on OCLMOVA expression y un diagrama T de UMLMOVA, genera un
interprete para expression. M as especcamente, la funci on interpret () devuelve
una especicaci on ecuacional Church Rosser y terminante (, E) (el interpre-
te) y un -termino t (la traducci on) tal que la forma canonica de t en (, E)
representa el valor de expression en T. Subrayamos aqu los aspectos clave de
la transformaci on:
La funci on interpret () se dene por recursi on sobre la estructura sint actica
de expression. M as especcamente:
Toma cinco argumentos: una signatura , un conjunto de ecuaciones E,
expression, una lista de variables

X y una etiqueta p. El primer y segun-
do argumentos contienen, respectivamente, la signatura genSign(T) que
se muestra en el Cuadro 2.7 y el conjunto de ecuaciones genRls(T), que
se muestra en los Cuadros 2.8, 2.9, y 2.10. La signatura genSign(T) pro-
porciona los smbolos para traducir todos los operadores de expression
excepto los iteradores, y las ecuaciones en genRls(T) denen el interprete
para todos los smbolos en genSign(T).
Devuelve tres elementos: una signatura
, un
-termino t
, y un conjunto
de
-ecuaciones E
. La signatura
contiene a la signatura genSign(T)

mas los smbolos necesarios para traducir todos los operadores iteradores
de expression. El conjunto E
incluye las ecuaciones de genRls(T) mas las

ecuaciones que denen el interprete para todos los nuevos smbolos de
.
La funci on interpret () genera un interprete diferente para cada expression y
diagrama T pero estos interpretes comparten la misma interpretaci on para los
operadores no iteradores sobre las colecciones (ver Cuadro 2.5) y sobre los tipos
predenidos (ver Cuadro 2.1); ademas, las expresiones sobre el mismo diagrama
comparten la misma interpretaci on para los atributos y extremos de asociaci on
y para las operaciones sobre los tipos OclType (ver Cuadro 2.2), OclAny (ver
Cuadro 2.4) y OclModelElement (ver Cuadro 2.3). M as concretamente, sean o,
c, at , rl y enum, respectivamente, el identicador de un objeto o, de una clase c,
de un atributo at , de un extremo de asociaci on rl y de una enumeraci on enum
en el diagrama T. Entonces, la funci on interpret() traduce los operadores de
expression tal y como ilustramos a continuaci on.
Empezamos por los operadores de genSign(T). Hay tres tipos de operadores
en genSign(T), todos ellos no iteradores:
Operadores que traducen operaciones que pertenecen a OCLMOVA, inde-
pendientemente del contexto, y que retienen su signicado tambien in-
dependientemente del contexto. Las ecuaciones que denen el interprete
para ellos se muestran en el Cuadro 2.8. Como ejemplo, la operaci on size()
de OCLMOVA se traduce al smbolo de funci on unario size que est a denido
en genRls(T) mediante las siguientes ecuaciones.
size(nil) = 0
size(col(x, xs)) = 1 + size(xs)
donde col y nil son los constructores usados para traducir colecciones.
Operadores que traducen operaciones que pertenecen a OCLMOVA indepen-
dientemente del contexto pero que obtienen su signicado del contexto. Las
ecuaciones que denen el interprete para estos operadores se muestran en
el Cuadro 2.10. Como ejemplo, supongamos que T contiene n clases. En-
tonces, la operaci on allInstances() de OCLMOVA se transforma en el smbolo
de funci on de un solo argumento allInstances denido en genRls(T) me-
diante las siguientes ecuaciones:
allInstances(c
1
) = col(o
11
, . . . , col(o
1
k
, nil) . . .)

allInstances(c
n
) = col(o
n1
, . . . , col(o
n
k
, nil) . . .)
donde o
i1
, . . . , o
ij
son las instancias de la clase c
i
(o de cualquiera de sus
subclases) contenidas en T.
Los operadores que traducen operaciones que se a naden a OCLMOVA por
el contexto. Son los identicadores de clase y de objeto, y los atributos
y extremos de asociaci on dibujados en T. Estos operadores se traducen
mediante smbolos de funci on que se generan especcamente para cada
contexto. Las ecuaciones que denen el interprete para ellos se muestran
en el Cuadro 2.9. Como ejemplo, supongamos que la clase c aparece en
el diagrama T, con un atributo at , y que existen n instancias de esta
clase dibujadas en el diagrama. Entonces, la operaci on at de OCLMOVA se
traduce mediante el smbolo de funci on at , que est a denido en genRls(T)
mediante las siguientes ecuaciones:
at (o
1
) = v
1

at (o
n
) = v
n
donde o
i
es una instancia de la clase c y v
i
es el termino que traduce el
valor v
i
del atributo at sobre estas instancias.
Ahora pasamos a describir la traducci on de las operaciones iteradoras. La
funci on interpret () genera un nuevo smbolo de funci on para cada operaci on
iteradora, que es unico y cuyo n umero de argumentos depende del n umero de
variables introducidas por las expresiones iteradoras (si las hubiera) que esten
por encima de expression. M as especcamente:
La etiqueta p que interpret () toma como quinto argumento se usa para
generar un unico smbolo de funci on para cada operaci on iteradora de
expression. La unicidad es un requisito puesto que el interprete para una
operaci on iteradora depende del cuerpo de la expresi on iteradora corres-
pondiente. La etiqueta p es una secuencia de n umeros positivos separados
por puntos.
La lista de variables

X que toma interpret () como tercer argumento se
usa para determinar los argumentos adicionales que pueden requerir los
smbolos de funci on generados para traducir las operaciones iteradoras.
La lista

X contiene las variables iteradoras que introducen las expresiones
iteradoras (si las hay) que est an por encima de expression. Cada uno de es-
tos argumentos adicionales contiene el valor asignado a la correspondiente
variable iteradora.
Las ecuaciones que denen el interprete para el smbolo de funci on gene-
rado para traducir las operaciones iteradoras dependen de su clase y de su
cuerpo. Como ejemplo, supongamos que la funci on interpret () es llamada,
con variables x
1
, . . . , x
n
y etiqueta p, sobre expression>forAll(x[ body); la
expresi on iteradora es traducida mediante el termino forAll
p
(x
1
, . . . , x
n
, t),
donde t es el termino recursivamente obtenido (junto con su interprete) lla-
mando recursivamente a interpret() sobre expression, y el smbolo forAll
p
es una funci on 1 + n-aria que est a denida por las siguientes ecuaciones:
forAll
p
(x
1
, . . . , x
n
, nil) = true
forAll
p
(x
1
, . . . , x
n
, col(x, xs)) =
ifThenElse(b(x
1
, . . . , x
n
, x), forAll
p
(x
1
, . . . , x
n
, xs), false)
donde b es el termino obtenido (junto con su interprete) llamando recursi-
vamente a la funci on interpret (), ahora con la variable adicional x, sobre
el cuerpo, en este caso la expresi on body, de la expresi on iteradora.
2.3.3. Denicion
En esta secci on damos la denici on formal de interpret(). Recordamos de la
descripcion informal que la funci on se dene recursivamente sobre la estructura
sint actica de expression. Por tanto, para cada una de las reglas de la gram atica
OCLMOVA hay una cla usula en la denici on de interpret(). Recordamos tambien
genSign(T)
arity() comentarios
c 0 para cada clase c en T
o 0 para cada objeto o en T
at 1 para cada atributo at en T
enm 0 para cada literal de enumeracion enm en T
rl 1 para cada extremo de asociacion rl en T
nil 0
col 2
i 0 para cada entero i
st 0 para cada cadena st
true, false 0
not 1
or, and, implies 2
equal 2
<, , >, 2
+, , 2
oclIsKindOf 2
oclIsTypeOf 2
oclAsType 2
allInstances 1
excludes 2
includes 2
excluding 2
including 2
excludesAll 2
includesAll 2
union 2
isEmpty 1
notEmpty 1
size 1
asSet 1
ifThenElse 3
Cuadro 2.7: La signatura genSign(T).
genRls(T)
ecuaciones
nil No tiene ecuaciones
col No tiene ecuaciones
i No tiene ecuaciones
st No tiene ecuaciones
true, false No tiene ecuaciones
not Es un operador predenido
or, and, implies Son operadores predenidos
equal equal(nil, nil) = true
equal(nil, col(x, xs)) = false
equal(col(x, xs), nil) = false
equal(col(x, xs), col(y, ys)
= and(equal(x, y), equal(xs, ys))
<, , >, Son operadores predenidos
+, , Son operadores predenidos
excludes excludes(xs, y) = not(includes(xs, y))
includes includes(nil,y) = false
includes(col(x,xs),y) = ifThenElse(equal(x, y), true, inclu-
des(xs, y))
excluding excluding(col(x, xs), y) =
ifThenElse(equal(x, y), excluding(xs, y), col(x, exclu-
ding(xs, y)))
including including(xs, x) = col(x, xs)
excludesAll excludesAll(xs, col(y, ys)) = and(excludes(xs, y), exclude-
sAll(xs, ys))
includesAll includesAll(xs, nil) = true
includesAll(xs, col(y, ys)) = and(includes(xs, y), include-
sAll(xs, ys))
union union(nil, xs) = xs
union(x, xs) = col(x, xs)
union(col(x, xs), ys) = col(x, union(xs, ys))
isEmpty isEmpty(nil) = true
isEmpty(col(x,xs)) = false
notEmpty notEmpty(nil) = false
notEmpty(col(x,xs)) = true
size size(nil) = 0
size(col(x, xs)) = 1 + size(xs)
asSet asSet(nil) = nil
asSet(col(x,xs)) = ifThenElse(includes(xs, x), asSet(xs),
col(x, asSet(xs)))
ifThenElse ifThenElse(true, x, y) = x
ifThenElse(false, x, y) = y
Cuadro 2.8: El conjunto de ecuaciones genRls(T) (I).
genRls(T)
ecuaciones
c No tiene ecuaciones
o No tiene ecuaciones
at at(o) = v, para cada objeto o cuyo atributo at tenga valor
v en T
enm No tiene ecuaciones
rl rl (o) = col(o1, . . . , col(on, nil) . . .), para cada objeto o liga-
do a los objetos o1, . . . , on en el extremo de asociacion rl
en T
Cuadro 2.9: El conjunto de ecuaciones genRls(T) (II).
genRls(T)
ecuaciones
equal equal(o,o) = true, para cada objeto o en T
equal(o,o
) = false, para cada par de objetos o, o
en T,
tal que o ,= o
equal(c,c) = true, para cada clase c en T

equal(c,c
) = false, para cada par de clases c, c
en T, tales
que c ,= c
oclIsKindOf oclIsKindOf(o, c) = includes(allInstances(c), o), para cada

objeto o y clase c en T
oclIsTypeOf oclIsTypeOf(o, c) = equal(oclType(o), c), para cada ob-
jeto o y clase c en T
oclAsType oclAsType(o, c) = o, para cada objeto o y clase c en T tal
que o pertenece a la clase c o a una subclase de c
oclType oclType(o) = c, para cada objeto o de la clase c en T
allInstances allInstances(c) = col(o1, . . . , col(on, nil) . . .), para cada cla-
se c, que tenga como instancias o1, . . . , on en T.
Cuadro 2.10: El conjunto de ecuaciones genRls(T) (y III).
que la funci on interpret() devuelve, junto con la traducci on de expression, las
ecuaciones que denen el interprete para los smbolos que traducen los opera-
dores iteradores que contenga. Estas ecuaciones est an generadas por las funcio-
nes auxiliares genCollectRls(), genForAllRls(), genExistsRls(), genSelectRls(),
y genReject Rls(), cuya denici on se puede encontrar mas abajo. La funci on
interpret() utiliza estas funciones cuando expression es una expresi on con ite-
radores. Cada una de estas funciones toma cuatro argumentos: la etiqueta p
que genera el smbolo unico para traducir el operador iterador de expression;
la lista de variables

X que traduce las variables iteradoras introducidas por las
expresiones iteradoras que hubiera por encima de expression; la variable que
traduce la variable iteradora de expression; y el termino que traduce el cuerpo
de expression. En las ecuaciones siguientes asumiremos que xs es una variable
completamente nueva.
genCollectRls(p,

X, x, t)
collect
p
(x
1
, . . . , x
n
, nil) = nil ,
collect
p
(x
1
, . . . , x
n
, col(x, xs))
= union(t, collect
p
(x
1
, . . . , x
n
, xs))
genForAllRls(p,

X, x, t)
forAll
p
(x
1
, . . . , x
n
, nil) = true ,
forAll
p
(x
1
, . . . , x
n
, col(x, xs))
= ifThenElse(t, forAll
p
(x
1
, . . . , x
n
, xs), false)
genExistsRls(p,

X, x, t)
exists
p
(x
1
, . . . , x
n
, nil) = false ,
exists
p
(x
1
, . . . , x
n
col(x, xs))
= ifThenElse(t, true, exists
p
(x
1
, . . . , x
n
, xs))
genSelectRls(p,

X, x, t)
select
p
(x
1
, . . . , x
n
, nil) = nil ,
select
p
(x
1
, . . . , x
n
col(x, xs))
= ifThenElse(t, col(x, select
p
(x
1
, . . . , x
n
, xs)),
select
p
(x
1
, . . . , x
n
, xs))
genRejectRls(p,

X, x, t)
reject
p
(x
1
, . . . , x
n
, nil) = nil ,
reject
p
(x
1
, . . . , col(x, xs))
= ifThenElse(t, reject
p
(x
1
, . . . , x
n
, xs),
col(x, reject
p
(x
1
, . . . , x
n
, xs)))
Usaremos ademas las siguientes funciones auxiliares en la denici on de la

funci on interpret (). Sean extSign(), extRls(), extTerm() las funciones proyeccion:
extSign(, E, t)) , extRls(, E, t)) E y extTerm(, E, t)) t.
Tambien, sea asVar() la funci on que traduce una cadena por una variable.
An alogamente, sean asInt () y asStr() las funciones que traducen una cadena
por una constante (representando, respectivamente un entero y una cadena).
Denicion 1. Sea T un diagrama UMLMOVA, una signatura, E un conjunto
de ecuaciones,

X una lista de variables y p una posici on. La funci on interpret()
sobre las expresiones de OCLMOVA se dene mediante las siguientes cl ausulas:
VariableExpCS
interpret(, E,

X, simpleNameCS, p) , E, asVar(simpleNameCS)) .
EnumerationLiteralExpCS
interpret(, E,

X, simpleNameCS, p) , E, simpleNameCS) .
CollectionLiteralExpCS
interpret(, E,

X, Bag, p) , E, nil) .
interpret(, E,

X, Bag CollectionLiteralPartsCS , p)
interpretAux(, E,

X, CollectionLiteralPartsCS, p).
CollectionLiteralPartsCS
interpretAux(, E,

X, OclExpressionCS, p)

1
, E
1
, col(t
1
, nil)) ,
donde
1
= extSign(interpret(, E,

X, OclExpressionCS, p.1)),
E
1
= extRls(interpret(, E,

X, OclExpressionCS, p.1)), y
t
1
= extTerm(interpret(, E,

X, OclExpressionCS, p.1)).
interpretAux(, E,

X, (OclExpressionCS , CollectionLiteralPartsCS), p)

1

2
, E
1
E
2
, col(t
1
, t
2
))
donde
1

X, OclExpressionCS, p.1),
E
1

t
1

2
= extSign(interpretAux(, E,

X, CollectionLiteralPartsCS, p.2)),
E
2
= extRls(interpretAux(, E,

X, CollectionLiteralPartsCS, p.2)), y
t
2
= extTerm(interpretAux(, E,

X, CollectionLiteralPartsCS, p.2)).
IntegerLiteralExpCS
interpret(, E,

X, String, p) , E, asInt(String)) .
StringLiteralExpCS
interpret(, E,

X, String, p) , E, asStr(String)) .
BooleanLiteralExpCS
interpret(, E,

X, true, p) , E, true) .
interpret(, E,

X, false, p) , E, false) .
IteratorExpCS
interpret(, E,

X,
OclExpressionCS
1
-> collect (simpleName : typeCS [
OclExpressionCS
2
), p)
(collect
p
, [X[ + 1)
1

2
,
genCollectRls(p,

X, asVar(simpleName), t
2
) E
1
E
2
,
collect
p
(
X, t
1
)) ,
donde, para 1 i 2,
i

X
, OclExpressionCS
i
, p.i)),
E
i

X
, OclExpressionCS
i
, p.i)), y
t
i

X
, OclExpressionCS
i
, p.i)),
con X
= X asVar(simpleName) si i = 2, y X
= X en otro caso.
interpret(, E,

X,
OclExpressionCS
1
-> forAll (simpleName : typeCS [
OclExpressionCS
2
), p)
(forAll
p
, [X[ + 1)
1

2
,
genForAllRls(p,

2
) E
1
E
2
,
forAll
p
(
X, t
1
)) ,
donde, para 1 i 2,
i
y E
i
se denen como antes.
interpret(, E,

X,
OclExpressionCS
1
-> exists (simpleName : typeCS [
OclExpressionCS
2
), p)
(exists
p
, [X[ + 1)
1

2
,
genExistsRls(p,

2
) E
1
E
2
,
exists
p
(

X, t
1
))
donde, para 1 i 2,
i
y E
i
interpret(, E,

X,
OclExpressionCS
1
-> select (simpleName : typeCS [
OclExpressionCS
2
), p)
(select
p
, [X[ + 1)
1

2
,
genSelectRls(p,

2
) E
1
E
2
,
select
p
(
X, t
1
)) ,
donde, para 1 i 2,
i
y E
i
interpret(, E,

X,
OclExpressionCS
1
-> reject (simpleName : typeCS [
OclExpressionCS
2
), p)
(reject
p
, [X[ + 1)
1

2
,
genRejectRls(p,

2
) E
1
E
2
,
reject
p
(

X, t
1
)) ,
donde, para 1 i 2,
i
y E
i
OperationCallExpCS
interpret(, E,

X, (not OclExpressionCS), p)

1
, E
1
, not(t
1
)) ,
donde
1

X, OclExpressionCS, p.1)),
E
1

X, OclExpressionCS, p.1)), y
t
1

X, OclExpressionCS, p.1)).
interpret(, E,

X,
(OclExpressionCS
1
or OclExpressionCS
2
), p)

1

2
, E
1
E
2
, (t
1
or t
2
)) ,
donde, para 1 i 2,
i

X, OclExpression
i
, p.i)),
E
i

X, OclExpression
i
, p.i)), y
t
i

X, OclExpression
i
, p.i)).
interpret(, E,

X,
(OclExpressionCS
1
and OclExpressionCS
2
), p)

1

2
, E
1
E
2
, (t
1
and t
2
))
donde, para 1 i 2,
i
, E
i
y t
i
interpret(, E,

X,
(OclExpressionCS
1
implies OclExpressionCS
2
), p)

1

2
, E
1
E
2
, (t
1
implies t
2
)) ,
donde, para 1 i 2,
i
, E
i
y t
i
interpret(, E,

X,
(OclExpressionCS
1
= OclExpressionCS
2
), p)

1

2
, E
1
E
2
, equal(t
1
, t
2
)) ,
donde, para 1 i 2,
i
, E
i
, y t
i
interpret(, E,

X,
(OclExpressionCS
1
< OclExpressionCS
2
), p)

1

2
, E
1
E
2
, (t
1
< t
2
)) ,
donde, para 1 i 2,
i
, E
i
y t
i
interpret(, E,

X,
(OclExpressionCS
1
OclExpressionCS
2
), p)

1

2
, E
1
E
2
, (t
1
t
2
)) ,
donde, para 1 i 2,
i
, E
i
y t
i
interpret(, E,

X,
(OclExpressionCS
1
> OclExpressionCS
2
), p)

1

2
, E
1
E
2
, (t
1
> t
2
)) ,
donde, para 1 i 2,
i
, E
i
y t
i
interpret(, E,

X,
(OclExpressionCS
1
OclExpressionCS
2
), p)

1

2
, E
1
E
2
, (t
1
t
2
)) ,
donde, para 1 i 2,
i
, E
i
y t
i
interpret(, E,

X,
(OclExpressionCS
1
+ OclExpressionCS
2
), p)

1

2
, E
1
E
2
,

X, (t
1
+ t
2
)) ,
donde, para 1 i 2,
i
, E
i
y t
i
interpret(, E,

X,
(OclExpressionCS
1
OclExpressionCS
2
), p)

1

2
, E
1
E
2
,

X, (t
1
t
2
)) ,
donde, para 1 i 2,
i
, E
i
y t
i
interpret(, E,

X,
(OclExpressionCS
1
OclExpressionCS
2
), p)

1

2
, E
1
E
2
, (t
1
t
2
)) ,
donde, para 1 i 2,
i
, E
i
y t
i
interpret(, E,

X,
(OclExpressionCS
1
. oclIsKindOf ( OclExpressionCS
2
), p)

1

2
, E
1
E
2
, oclIsKindOf(t
1
, t
2
)) ,
donde, para 1 i 2,
i
, E
i
y t
i
interpret(, E,

X,
(OclExpressionCS
1
. oclIsTypeOf ( OclExpressionCS
2
), p)

1

2
, E
1
E
2
, oclIsTypeOf(t
1
, t
2
)) ,
donde, para 1 i 2,
i
, E
i
y t
i
interpret(, E,

X,
(OclExpressionCS
1
. oclAsType ( OclExpressionCS
2
), p)

1

2
, E
1
E
2
, oclAsType(t
1
, t
2
)) ,
donde, para 1 i 2,
i
, E
i
y t
i
interpret(, E,

X, (OclExpressionCS
1
. oclType()), p)

1
, E
1
, oclType(t
1
)) ,
donde
1
, E
1
y t
1
interpret(, E,

X, (OclExpressionCS
1
. allInstances()), p)

1
, E
1
, allInstances(t
1
)) ,
donde
1
, E
1
y t
1
interpret(, E,

X,
(OclExpressionCS
1
-> excludes ( OclExpressionCS
2
), p)

1

2
, E
1
E
2
, excludes(t
1
, t
2
)) ,
donde, para 1 i 2,
i
, E
i
y t
i
interpret(, E,

X,
(OclExpressionCS
1
-> includes ( OclExpressionCS
2
), p)

1

2
, E
1
E
2
, includes(t
1
, t
2
)) ,
donde, para 1 i 2,
i
, E
i
y t
i
interpret(, E,

X,
(OclExpressionCS
1
-> excluding ( OclExpressionCS
2
), p)

1

2
, E
1
E
2
, excluding(t
1
, t
2
)) ,
donde, para 1 i 2,
i
, E
i
y t
i
interpret(, E,

X,
(OclExpressionCS
1
-> including ( OclExpressionCS
2
), p)

1

2
, E
1
E
2
, including(t
1
, t
2
)) ,
donde, para 1 i 2,
i
, E
i
y t
i
interpret(, E,

X,
(OclExpressionCS
1
-> excludesAll ( OclExpressionCS
2
), p)

1

2
, E
1
E
2
, excludesAll(t
1
, t
2
)) ,
donde, para 1 i 2,
i
, E
i
y t
i
interpret(, E,

X,
(OclExpressionCS
1
-> includesAll ( OclExpressionCS
2
), p)

1

2
, E
1
E
2
, includesAll(t
1
, t
2
)) ,
donde, para 1 i 2,
i
, E
i
y t
i
interpret(, E,

X,
(OclExpressionCS
1
-> union ( OclExpressionCS
2
), p)

1

2
, E
1
E
2
, union(t
1
, t
2
)) ,
donde, para 1 i 2,
i
, E
i
y t
i
interpret(, E,

X, (OclExpressionCS
1
-> isEmpty()), p)

1
, E
1
, isEmpty(t
1
)) ,
donde
1
, E
1
y t
1
interpret(, E,

X, (OclExpressionCS
1
-> notEmpty()), p)

1
, E
1
, notEmpty(t
1
)) ,
donde
1
, E
1
y t
1
interpret(, E,

X, (OclExpressionCS
1
-> size()), p)

1
, E
1
, size(t
1
)) ,
donde
1
, E
1
y t
1
interpret(, E,

X, (OclExpressionCS
1
-> asSet()), p)

1
, E
1
, asSet(t
1
)) ,
donde,
1
, E
1
y t
1
AttributeCallExpCS
interpret(, E,

X, (OclExpressionCS . simpleNameCS), p)

1
, E
1
, simpleNameCS(t
1
)) ,
donde
1

X, OclExpressionCS, p.1)
E
1

t
1

X, OclExpressionCS, p.1) .
AssociationEndCallExpCS
interpret(, E,


1
, E
1
, simpleNameCS(t
1
)) ,
donde
1

E
1

t
1

X, OclExpressionCS, p.1) .
IfExpCS
interpret(, E,

X,
(if OclExpressionCS
1
then OclExpressionCS
2
else
OclExpressionCS
3
endif), p)

1

2

3
, E
1
E
2
E
3
,
ifThenElse(t
1
, t
2
, t
3
)) ,
donde, para 1 i 3,
i

X, OclExpression
i
, p.i))
E
i

X, OclExpression
i
, p.i))
t
i

X, OclExpression
i
, p.i))
Ejemplo 1. Consideremos la siguiente expresi on OCLMOVA atLeastOneSmo-
king en el contexto del diagrama de objetos UMLMOVA TRAIN-WAGON-1 que
se muestra en la Figura 2.2. Informalmente, atLeastOneSmoking expresa que
todos los trenes tienen al menos un vag on en el que est a permitido fumar.
Train.allInstances>forall(t[t.wagon>exists(w[w.smoking))
Supongamos que la funci on interpret() se llama sobre atLeastOneSmoking
con genSign( TRAIN-WAGON-1), genRls( TRAIN-WAGON-1), [] y 1 como su pri-
mer, segundo, tercer, y quinto argumentos. Entonces, devolver a el termino
forAll
1
(allInstances(Train))
ecuaciones
forAll1 forAll1(nil) = true
forAll1(col(t, xs))
= ifThenElse(exists1,2(t, wagon(t)), forAll1(xs), false)
exists1,2 exists1,2(t, nil) = false
exists1,2(t, col(w, xs))
= ifThenElse(smoking(w), true, exists1,2(t, xs))
allInstances allInstances(Train) = col(Train1, nil)
allInstances(Wagon)
= col(Wagon1, col(Wagon2, nil))
smoking smoking(Wagon1) = false
smoking(Wagon2) = true
wagon wagon(Train1) = col(Wagon1, col(Wagon2, nil))
wagon(Train2) = col(Wagon3, nil)
succ succ(Wagon1) = col(Wagon2, nil)
succ(Wagon2) = col(Wagon1, nil)
pred pred(Wagon1) = col(Wagon2, nil)
pred(Wagon2) = col(Wagon1, nil)
Cuadro 2.11: El interprete para atLeastOneSmoking (parcial).
como la traducci on de atLeastOneSmoking, junto con los smbolos y ecuaciones
que denen su interprete, que incluyen, entre otros, aquellos que se muestran en
el Cuadro 2.11. La forma can onica del termino forAll
1
(allInstances(Train)) es
true, que es precisamente la traducci on del valor de atLeastOneSmoking sobre
el diagrama de objetos TRAIN-WAGON-1.
Terminamos esta secci on con dos propiedades que se usan en la secci on 2.3.4
para probar las propiedades de terminaci on y Church-Rosser de las especica-
ciones ecuacionales generadas por la traducci on. La primera proposici on es sobre
la signatura que devuelve la funci on interpret (). Sea w una expresi on OCLMOVA.
Entonces, free(w) denota el conjunto de variables que son libres en w, es decir,
aquellas que no ocurren bajo el ambito de una variable iteradora. Sea tambien
X una lista de variables (x

1
, . . . , x
n
) y sea una signatura. Entonces X denota
el conjunto x
1
, . . . , x
n
y X denota el conjunto X ()
op
. La primera
proposici on dice que si interpret (, E,

X, w, p) devuelve
, E
, t), entonces
es una extensi on de que a nade a solamente smbolos que est an etiquetados

y cuyas etiquetas representan posiciones que son iguales o que est an bajo p.
Tambien dice que t es ademas un
(X)-termino.
Proposici on 1. Sea T un diagrama UMLMOVA, sea una signatura tal que
genSign(T) , sea E una especicaci on ecuacional,

X una lista de variables
tales que X = , w una expresi on OCLMOVA tal que free(w) X, y p una
posici on tal que para cualquier p
labels(), ocurre que p
p. Entonces, se
cumple que
interpret(, E,

X, w, p) =
, E
, t)
donde
1.
es una signatura que cumple que
y, para cualquier (
)
op
, p _ label(), y
2. t es un
(X)-termino.
Demostraci on. Por inducci on estructural sobre w. Ver Apendice A.
La segunda proposici on es sobre el conjunto de ecuaciones que devuelve la
funci on interpret (). De nuevo, sea interpret(, E,

X, w, p) =
, E
, t). Enton-
ces, esta proposici on dice que E
es una extensi on de E que a nade las ecuaciones

que denen los smbolos que
a nade a . Usa la nocion de -top especicaci on

ecuacional que denimos como sigue: E es una -top especicaci on ecuacional
si y solo si, para cualquier ecuaci on (X)l = r de E, o bien l f(t
1
, . . . , t
n
) y
f ()
op
, o bien l c y c ()
op
.
Proposici on 2. Sea T un diagrama UMLMOVA, sea una signatura que cumple
que genSign(T) , E una -especicaci on ecuacional tal que genRls(T) E,
X una lista de variables tales que X = , w una expresi on OCLMOVA tal

que free(w) X, y p una posici on tal que para cualquier p
labels(), p
p.
Entonces, se cumple que
interpret(, E,

X, w, p) =
, E
, t)
donde E
es una
-especicaci on ecuacional tal que E E
y (E
E) es una
(
)-top especicaci on ecuacional.

2.3.4. Propiedades
En esta secci on probamos que dada una expression OCLMOVA y un diagra-
ma UMLMOVA T, la especicaci on ecuacional (el interprete) generado por la
funci on interpret () es Church-Rosser y terminante. La propiedad de termina-
cion garantiza que el termino (la traducci on) generada por interpret () para
traducir expression tiene al menos una forma canonica. La propiedad de Church-
Rosser garantiza, ademas, que esta forma canonica es unica. La combinaci on de
ambas propiedades garantiza que la unica forma canonica de la traducci on pue-
de obtenerse autom aticamente por reescritura de terminos usando como reglas
de reescritura las ecuaciones que hay en el interprete. Por tanto, la funci on
interpret() proporciona ademas una semantica ejecutable para OCLMOVA. No
probamos, sin embargo, la correccion de la funci on interpret (), esto es, que la
unica forma canonica de la traducci on representa de hecho el valor de expression
sobre T. Esta prueba requerira un meta-razonamiento detallado que implicara
tanto la denici on formal de las teoras ecuacionales como sistemas de rees-
critura de terminos como la denici on de la semantica formal est andar para
OCL. Sin embargo, es discutible que exista tal semantica formal est andar de
OCL: aunque [OCL06, Apendice A] incluya una semantica formal para una
parte del lenguaje basada en teora de conjuntos, se dice explcitamente que
esta semantica es no normativa. Por estas razones, podemos decir que la fun-
cion interpret () proporciona una semantica formal para una parte signicativa
de OCL, es decir, para OCLMOVA, con la ventaja de ser al mismo tiempo una
semantica ejecutable: cada expresi on tiene un signicado preciso y el signicado
de cada expresi on puede obtenerse autom aticamente.
En adelante, sin perdida de generalidad, vamos a suponer que todas las
variables iteradoras que aparecen en una expresion OCLMOVA son distintas.
Propiedad de Church-Rosser
Para probar que las especicaciones ecuacionales generadas por la funci on
interpret () son Church-Rosser, probamos primero la siguiente proposici on:
Proposici on 3. Sea T un diagrama UMLMOVA, sea una signatura tal que
genSign(T) y sea E una -especicaci on ecuacional tal que genRls(T)
E y E no incluye ecuaciones cuyos smbolos top de funci on de la parte de la
izquierda sean collect, forAll, exists, select, o reject, seguidos por una posici on.
Sea tambien

X una lista de variables tal que X = y X no contiene variables
repetidas. Sea w una expresi on OCLMOVA tal que free(w) X y ninguna de las
variable iteradoras en w est an en X. Sea p una posici on tal que para cualquier
p
labels(), p
p. Entonces, se cumple que

interpret(, E,

X, w, p) =
, E
, t)
donde (E
E) es un conjunto de ecuaciones tal que sus partes izquierdas son

todas instancias diferentes de los siguientes dos patrones:
1. iterator
q
(x
1
, . . . , x
n
, nil)
2. iterator
q
(x
1
, . . . , x
n
, col(x, xs))
donde iterator collect, forAll, exists, select, reject y q es cualquier secuencia
de n umeros positivos separados por puntos, y x y xs son distintas y no est an
contenidas en la lista X.
Obtenemos el resultado deseado como consecuencia de la proposici on an-
terior y de las siguientes propiedades que cumplen los TRS denidos para los
diagramas T de UMLMOVA por la funci on genRls(T).
Proposici on 4. Sea T un diagrama UMLMOVA. Entonces, el conjunto de ecua-
ciones genRls(T) es lineal en la izquierda y, adem as:
no incluye ecuaciones en las que sus smbolos top de funci on en sus la-
dos izquierdos sean ninguno entre col, nil, o iterator
p
, donde iterator
collect, forAll, exists, select, reject, y p es cualquier secuencia de enteros
positivos separados por puntos;
no incluye ecuaciones cuyos lados izquierdos contengan simbolos iterator
p
,
donde iterator collect, forAll, exists, select, reject, y p es cualquier se-
cuencia de enteros positivos separados por puntos; y
no incluye ecuaciones cuya lados izquierdos produzcan pares crticos.
Demostraci on. Por la denici on de genRls(T). Recordemos que en los diagramas
UMLMOVA los nombres de clases, atributos, extremos de asociaci on y objetos son
todos unicos.
Teorema 1. Sea T un diagrama UMLMOVA y w una expresi on OCLMOVA con-
textualizada por T, tal que free(w) = . Entonces,
extRls(interpret (genSign(T), genRls(T), , w, 1))
es un sistema de reescritura de terminos que cumple la propiedad Church-Rosser.
Demostraci on. Por la Proposi on 4 sabemos que genRls(T) es una especicaci on
ecuacional que satisface los requisitos relativos a E en la Proposici on 3. Ademas,
por la denici on de la funci on genSign(), sabemos que labels(genSign(T)) =
y que, por tanto, la posici on 1 tambien satisface los requisitos relativos a p en
la Proposici on 3. Ahora, aplicando la Proposici on 3 sabemos, en primer lugar,
que
(extRls(interpret(genSign(T), genRls(T), , w, 1)) genRls(T))
es un conjunto de ecuaciones entre las que no puede haber pares crticos y que
son lineales en la izquierda. En segundo lugar, por la Proposici on 4, sabemos
que genRls(T) tampoco contiene ecuaciones que produzcan pares crticos y sus
ecuaciones son lineales en la izquierda. Finalmente, como consecuencia de las
Proposici ones 3 y 4 tambien sabemos que no puede haber pares cr
ticos entre las

ecuaciones en (extRls(interpret (genSign(T), genRls(T), , w, 1)) y las ecuaciones
en genRls(T). En denitiva,
extRls(interpret (genSign(T), genRls(T), , w, 1))
es un sistema de reescritura ortogonal y, por tanto, podemos concluir que tiene
la propiedad Church-Rosser.
Terminacion
Para probar que las especicaciones ecuacionales que son generadas por
la funci on interpret () son terminantes, mostramos que para cada especica-
cion ecuacional (
, E
) devuelta por esta funci on existe una funci on de
-
precedencia T
y una funci on de
-estatus T
tal que el rpo-orden de reduccion

inducido por T
y T
sobre es compatible con el sistema de reescritura de

terminos denido por las ecuaciones de E
. Para hacerlo, introducimos una

funci on interpret +() que es identica a interpret () excepto en que toma dos ar-
gumentos adicionales T y T y devuelve dos valores adicionales T
y T
, tales
que:
1. T y T son, respectivamente, una funci on de precedencia y una funci on
de estatus sobre la signatura que interpret +() toma como su primer
argumento;
2. T
y T
son, respectivamente, una funci on de precedencia y una funci on

de estatus sobre la signatura
que devuelve interpret +(); y

3. cuando el orden de reduccion inducido por T y T es compatible con el TRS
denido por las ecuaciones en el conjunto E que interpret +() toma como
su segundo argumento, entonces el orden de reduccion inducido por T
y
T
es compatible con el TRS denido por las ecuaciones en el conjunto E
devuelto por interpret +().

La idea es que T
y T
son generadas recursivamente por interpret +() mientras

se generan los smbolos en
y las ecuaciones en E
. El caso interesante es el de
los valores de precedencia asignados a los smbolos de funci on de
que traducen
las operaciones iteradoras. Estos valores satisfacen la siguiente propiedad: el
valor de precedencia asignado a un smbolo de funci on que traduce un operador
iterador es siempre mayor que los valores asignados a los smbolos generados para
traducir el cuerpo de la expresi on iteradora correspondiente y la colecci on sobre
la que itera. Usaremos las siguientes funciones de proyeccion en la denici on de
la funci on interpret +():
extPrec(, T, T , E, t)) T y extStat(, T, T , E, t)) T .
Denicion 2. Sea T un diagrama UMLMOVA, sea una signatura, sea E un
conjunto de ecuaciones, T una -precedencia, T una funci on de -estatus,

X
una lista de variables y p una secuencia de n umeros positivos separados por
puntos. La funci on interpret+() sobre expresiones OCLMOVA se dene mediante
las siguientes cl ausulas:
VariableExpCS
interpret+(, E, T, T ,

X, simpleNameCS, p)
, E
, T, T , t
) ,
donde
, E
y t
son como en la Denici on 1.


X, simpleNameCS, p)
, E
, T, T , t
) ,
donde
, E
y t


X, Bag, p)
, E
, T, T , t
) ,
donde
, E
y t


interpretAux+(, E, T, T ,

CollectionLiteralPartsCS

X, OclExpressionCS, p)

, E
, T
1
, T
1
, t
) ,
donde
, E
y t
son como en la Denici on 1, y

T
1
= extPrec(interpret+(, E, T, T ,

X, OclExpressionCS, p.1) y
T
1
= extStat(interpret+(, E, T, T ,

X, OclExpressionCS, p.1).

X, (OclExpressionCS , CollectionLiteralPartsCS), p)

, E
, T
1
T
2
, T
1
T
2
, t
) ,
donde
, E
y t

T
1

T
1

T
2
= extPrec(interpretAux+(, E, T, T ,

X, CollectionLiteralPartsCS, p.2), y
T
2
= extStat(interpretAux+(, E, T, T ,

X, CollectionLiteralPartsCS, p.2).
IntegerLiteralExpCS

X, String, p)
, E
, T, T , t
) .
donde
, E
y t

StringLiteralExpCS

X, String, p)
, E
, T, T , t
) .
donde
, E
y t

BooleanLiteralExpCS

X, true, p)
, E
, T, T , t
) .
donde
, E
y t


X, false, p)
, E
, T, T , t
) .
donde
, E
y t

IteratorExpCS

X,
OclExpressionCS
1
OclExpressionCS
2
), p)
(
, E
,
(collect
p
, max(T
1
T
2
) + 1) T
1
T
2
,
(collect
p
, lex) T
1
T
2
, t
) ,
donde
, E
y t
son como en la Denici on 1, y para 1 i 2,

T
i

X
, OclExpressionCS
i
, p.i)) y
T
i

X
, OclExpressionCS
i
, p.i)),
con X
= X en otro caso.

X,
OclExpressionCS
1
-> forAll (simpleName : typeCS [
OclExpressionCS
2
), p)
(
, E
,
(forAll
p
, max(T
1
T
2
) + 1) T
1
T
2
,
(forAll
p
, lex) T
1
T
2
, t
) ,
donde
, E
y t
son como en la Denici on 1, y, para 1 i 2,

T
i

X
, OclExpressionCS
i
, p.i)) y
T
i

X
, OclExpressionCS
i
, p.i)),
con X
= X en otro caso.

X,
OclExpressionCS
1
-> exists (simpleName : typeCS [
OclExpressionCS
2
), p)
(
, E
,
(exists
p
, max(T
1
T
2
) + 1) T
1
T
2
,
(exists
p
, lex) T
1
T
2
, t
) ,
donde
, E
y t

T
i

X
, OclExpressionCS
i
, p.i)) y
T
i

X
, OclExpressionCS
i
, p.i)),
con X
= X en otro caso.

X,
OclExpressionCS
1
-> select (simpleName : typeCS [
OclExpressionCS
2
), p)
(
, E
,
(select
p
, max(T
1
T
2
) + 1) T
1
T
2
,
(select
p
, lex) T
1
T
2
, t
) ,
donde
, E
y t

T
i

X
, OclExpressionCS
i
, p.i)) y
T
i

X
, OclExpressionCS
i
, p.i)),
con X
= X en otro caso.

X,
OclExpressionCS
1
-> reject (simpleName : typeCS [
OclExpressionCS
2
)
, p)
(
, E
,
(reject
p
, max(T
1
T
2
) + 1) T
1
T
2
,
(reject
p
, lex) T
1
T
2
, t
) ,
donde
, E
y t

T
i

X
, OclExpressionCS
i
, p.i)) y
T
i

X
, OclExpressionCS
i
, p.i)),
con X
= X en otro caso.
OperationCallExpCS

X, (not OclExpressionCS), p)

, E
, T
1
, T
1
, t
) ,
donde
, E
y t

T
1

X, OclExpressionCS, p,1) y
T
1

X, OclExpressionCS, p,1).

X,
(OclExpressionCS
1
or OclExpressionCS
2
), p)

, E
, T
1
T
2
, T
1
T
2
, t
) ,
donde
, E
y t

T
i

X, OclExpressionCS
i
, p.i) y
T
i

X, OclExpressionCS
i
, p.i).

X,
(OclExpressionCS
1
and OclExpressionCS
2
), p)

, E
, T
1
T
2
, T
1
T
2
, t
) ,
donde
, E
y t
son como en la Denici on 1, y para 1 i 2, T

i
y T
i
se
denen como antes.

X,
(OclExpressionCS
1
implies OclExpressionCS
2
), p)

, E
, T
1
T
2
, T
1
T
2
, t
) ,
donde
, E
y t

i
y T
i
se
denen como antes.

X,
(OclExpressionCS
1
= OclExpressionCS
2
), p)

, E
, T
1
T
2
, T
1
T
2
, t
) ,
donde
, E
y t

i
y T
i
se
denen como antes.

X,
(OclExpressionCS
1
< OclExpressionCS
2
), p)

, E
, T
1
T
2
, T
1
T
2
, t
) ,
donde
, E
y t

i
y T
i
se
denen como antes.

X,
(OclExpressionCS
1
OclExpressionCS
2
), p)

, E
, T
1
T
2
, T
1
T
2
, t
) ,
donde
, E
y t

i
y T
i
se
denen como antes.

X,
(OclExpressionCS
1
> OclExpressionCS
2
), p)

, E
, T
1
T
2
, T
1
T
2
, t
) ,
donde
, E
y t

i
y T
i
se
denen como antes.

X,
(OclExpressionCS
1
OclExpressionCS
2
), p)

, E
, T
1
T
2
, T
1
T
2
, t
) ,
donde
, E
y t

i
y T
i
se
denen como antes.

X,
(OclExpressionCS
1
+ OclExpressionCS
2
), p)

, E
, T
1
T
2
, T
1
T
2
, t
) ,
donde
, E
y t

i
y T
i
se
denen como antes.

X,
(OclExpressionCS
1
OclExpressionCS
2
), p)

, E
, T
1
T
2
, T
1
T
2
, t
) ,
donde
, E
y t

i
y T
i
se
denen como antes.

X,
(OclExpressionCS
1
OclExpressionCS
2
), p)

, E
, T
1
T
2
, T
1
T
2
, t
) ,
donde
, E
y t

i
y T
i
se
denen como antes.

X,
(OclExpressionCS
1
. oclIsKindOf ( OclExpressionCS
2
), p)

, E
, T
1
T
2
, T
1
T
2
, t
) ,
donde
, E
y t

i
y T
i
se
denen como antes.

X,
(OclExpressionCS
1
. oclIsTypeOf ( OclExpressionCS
2
), p)

, E
, T
1
T
2
, T
1
T
2
, t
) ,
donde
, E
y t

i
y T
i
se
denen como antes.

X,
(OclExpressionCS
1
. oclAsType ( OclExpressionCS
2
), p)

, E
, T
1
T
2
, T
1
T
2
, t
) ,
donde
, E
y t

i
y T
i
se
denen como antes.

X, (OclExpressionCS
1
. oclType()), p)

, E
, T
1
, T
1
, t
) ,
donde
, E
y t
son como en la Denici on 1, y T

1
y T
1

X, (OclExpressionCS
1
. allInstances()), p)

, E
, T
1
, T
1
, t
) ,
donde
, E
y t

1
y T
1

X,
(OclExpressionCS
1
-> excludes ( OclExpressionCS
2
), p)

, E
, T
1
T
2
, T
1
T
2
, t
) ,
donde
, E
y t

i
y T
i
se
denen como antes.

X,
(OclExpressionCS
1
-> includes ( OclExpressionCS
2
), p)

, E
, T
1
T
2
, T
1
T
2
, t
) ,
donde
, E
y t

i
y T
i
se
denen como antes.

X,
(OclExpressionCS
1
-> excluding ( OclExpressionCS
2
), p)

, E
, T
1
T
2
, T
1
T
2
, t
) ,
donde
, E
y t

i
y T
i
se
denen como antes.

X,
(OclExpressionCS
1
-> including ( OclExpressionCS
2
), p)

, E
, T
1
T
2
, T
1
T
2
, t
) ,
donde
, E
y t

i
y T
i
se
denen como antes.

X,
(OclExpressionCS
1
-> excludesAll ( OclExpressionCS
2
), p)

, E
, T
1
T
2
, T
1
T
2
, t
) ,
donde
, E
y t

i
y T
i
se
denen como antes.

X,
(OclExpressionCS
1
-> includesAll ( OclExpressionCS
2
), p)

, E
, T
1
T
2
, T
1
T
2
, t
) ,
donde
, E
y t

i
y T
i
se
denen como antes.

X,
(OclExpressionCS
1
-> union ( OclExpressionCS
2
), p)

, E
, T
1
T
2
, T
1
T
2
, t
) ,
donde
, E
y t

i
y T
i
se
denen como antes.

X, (OclExpressionCS
1
-> isEmpty()), p)

, E
, T
1
, T
1
, t
) ,
donde
, E
y t

1
y T
1

X, (OclExpressionCS
1
-> notEmpty()), p)

, E
, T
1
, T
1
, t
) ,
donde
, E
y t

1
y T
1

X, (OclExpressionCS
1
-> size()), p)

, E
, T
1
, T
1
, t
) ,
donde
, E
y t

1
y T
1

X, (OclExpressionCS
1
-> asSet()), p)

, E
, T
1
, T
1
, t
) ,
donde
, E
y t

1
y T
1
AttributeCallExpCS


, E
, T
1
, T
1
, t
) ,
donde
, E
y t

T
1

T
1



, E
, T
1
, T
1
, t
) ,
donde
, E
y t

T
1

T
1

IfExpCS

X,
(if OclExpressionCS
1
2
else
OclExpressionCS
3
endif), p)

, E
, T
1
T
2
T
3
, T
1
T
2
T
3
, t
) ,
donde para 1 i 3,
T
i

X, OclExpression
i
, p.i))
T
i

X, OclExpression
i
, p.i)).
Para probar que se cumple la propiedad de terminaci on en todas las especi-
caciones ecuacionales generadas por la funci on interpret +() (y consecuentemen-
te, por la funci on interpret ()), probamos primero una proposici on que dice que,
si la funci on interpret +(, E, T, T ,

X, w, p) devuelve
, E
, T
, T
, t), entonces
T
es una extensi on de T que a nade solamente las asignaciones que denen los
valores de precedencia de los smbolos que
a nade a ; y que an alogamente T
es una extensi on de T que a nade solamente aquellas asignaciones que denen

los valores de estatus de los smbolos que
a nade a .
que genSign(T) , sea E una especicaci on ecuacional, T una -precedencia,
T una funci on de -estatus, sea

X una lista de variables tales que X = ,
sea w una expresi on OCLMOVA tal que free(w) X, y p una posici on tal que
para cualquier p
labels(), p


X, w, p) =
, E
, T
, T
, t)
donde
1. T
es una
-precedencia tal que T T
y (T
T) es una (
)-
precedencia y
2. T
es una funci on de
-estatus tal que T T
y (T
T ) es una funci on
de (
)-estatus.
A continuaci on probamos la siguiente proposici on:
que genSign(T) , E una especicaci on ecuacional, sea T una -precedencia,
T una funci on de -estatus,

X una lista de variables tales que X = , sea w
una expresi on OCLMOVA tal que free(w) X, y sea p una posici on tal que para
cualquier p
labels(), p
p. Adem as, supongamos que (, E) es compatible

con el rpo-orden de reducci on inducido por T y T . Entonces, se cumple que

X, w, p) =
, E
, T
, T
, t)
donde E
es compatible con el rpo-orden de reducci on inducido por T
y T
.
Demostraci on. Por inducci on estructural sobre w. Vease el Apendice A.
Finalmente, obtenemos el resultado deseado como consecuencia de la pro-
posici on 5 y el hecho de que para cualquier diagrama T de UMLMOVA, podemos
denir una genSign(T)-precedencia genPrec(T) y una funci on de genSign(T)-
estatus genStat(T) tales que el TRS denido por genRls(T) sea compatible
con el rpo-orden de reduccion inducido por genPrec(T) y genStat(T). La fun-
cion de precedencia genPrec(T) viene denida en el Cuadro 2.12 como si-
gue: para cualquier ,
genSign(T), >
en genPrec(T) si y solo si
genPrec() > genPrec(
) en el Cuadro 2.12. La funci on de estatus genStat(T)

tambien est a denida en el Cuadro 2.12.
Proposici on 7. Sea T un diagrama UMLMOVA. Entonces, el TRS genRls(T) es
compatible con el rpo-orden de reducci on inducido por genPrec(T) y genStat(T).
Demostraci on. Primero, mostramos que genPrec(T) est a bien fundada. Enton-
ces, probamos que para cualquier ecuaci on l = r en genRls(T) se cumple que
l >
rpo
r. Ver Apendice A.
Teorema 2. Sea T un diagrama y sea w una expresi on cuyo contexto es T, tal
que free(w) = . Entonces,
extRls(interpret+(genSign(T), genRls(T), genPrec(T), genStat(T), , w, 1))
es un sistema de reescritura de terminos terminante.
Demostraci on. Esto es consecuencia de la Proposici on 6 y de la Proposici on 7.
2.4. Extensiones, Trabajo Relacionado y Futuro 59
genPrec() genStat()
c 0
o 0
at 1
enm 0
rl 2 |1
nil 0
col 1 mul
i 0
st 0
true, false 0
not 1
and 2 |1,2
or, implies
equal 3 |1,2
<,,>,
+, , 2
,
oclIsKindOf 4
oclIsTypeOf 3
oclAsType 1
oclType 1
allInstances 2
excludes 4
includes 3 |2,1
excluding 3 |2,1
including 3
excludesAll 4 |1,2
includesAll 4 |1,2
union 2 mul
isEmpty 1
notEmpty 1
size 3
asSet 4
ifThenElse 1
Cuadro 2.12: La precedencia genPrec(T) y la funci on de estatus genStat(T).
2.4. Extensiones, Trabajo Relacionado y Futuro
Extensiones El lenguaje OCL puede extenderse mediante operaciones de-
nidas por el usuario. La denici on de estas operaciones facilita enormemente la
tarea de formalizar restricciones OCL sobre modelos UML, puesto que pueden
encapsular consultas que son largas o de uso frecuente. Una operaci on denida
por el usuario se declara junto con su contexto, argumentos, tipo y cuerpo. El
cuerpo es una expresi on OCL que dene el valor de la operaci on sobre cada ins-
tancia contextual. Puesto que las operaciones pueden denirse recursivamente,
la operaci on que se est a deniendo puede ser referenciada en el cuerpo de la ope-
racion. Para tratar con operaciones denidas por el usuario, solo tenemos que
llamar a la funci on interpret() con los argumentos apropiados. En efecto, sea f
una funci on denida por el usuario que tiene n argumentos y que viene deni-
da mediante una expresi on body en OCLMOVA. Para obtener un interprete para
cualquier expresi on OCLMOVA expression que usa f, procedemos como sigue.
Primero, creamos un nuevo smbolo de funci on
f
con n argumentos. Entonces,
aplicamos la funci on interpret () sobre body, incluyendo a
f
en la signatura que
interpret () toma como primer argumento y pas andole una lista de n variables
como tercer argumento. Para esta aplicaci on extendemos la denici on de la fun-
cion interpret () para que use el smbolo
f
para traducir cualquier ocurrencia de
f en el body, pero no generaremos ecuaciones para este smbolo. Como resulta-
do, obtenemos el termino t
body
, que traduce el body, y las ecuaciones E
body
, que
denen los smbolos en t
body
excepto
f
. Finalmente, para obtener el interprete
para expression, llamamos a la funci on interpret() sobre expression, incluyendo
a
f
en la signatura que interpret () toma como primer argumento e incluyendo
tambien E
body
f
(x
1
, . . . , x
n
) = t
body
en el conjunto de ecuaciones que toma
como su segundo argumento. La ecuaci on
f
(x
1
, . . . , x
n
) = t
body
es la deni-
cion real de f. Puesto que hemos usado el smbolo
f
para traducir cualquier
ocurrencia de f en body, cuando f est a denida recursivamente tambien lo es-
tar a
f
. Por la misma raz on, si f es no terminante, la funci on
f
tampoco lo
ser a.
Trabajo Relacionado
Formalizaciones de UML En un intento de proporcionar un marco for-
mal para razonar sobre las propiedades est aticas y dinamicas de los mode-
los UML, diferentes autores han propuesto distintas semanticas formales pa-
ra UML, utilizando para ello, entre otros formalismos, CASL-LTL [RCA00],
Z [Fra99], Object Z [KC99], PVS [OSR92], diagramas EER [GR98], l ogica de
reescritura [FA02], l ogica descriptiva [SSJM04], programacion con restriccio-
nes [CCGM07] y B [SB00]. Estos trabajos han contribuido decisivamente a pre-
cisar y corregir en muchos aspectos la especicaci on original del lenguaje UML.
En relacion con nuestro trabajo, sin embargo, ninguna de las formalizaciones
anteriores se ocupan del lenguaje OCL.
Formalizaciones de OCL El estudio formal de las distintas especica-
ciones de OCL, desde [OCL97] hasta [OCL06], ha suscitado igualmente una
abundante literatura cientca. Cabe destacar, por su relacion mas o menos di-
recta con nuestro trabajo, los artculos [CK01a, CKM
+
02, HCH
+
98, HHK98,
MB06, Ric02, RG02, Kya06, CP06, Bor07, Bru07] en los que se proponen dis-
tintas semanticas formales para este lenguaje y/o se se nalan las inconsistencias
o lagunas detectadas en su especicaci on. La mayora de estas propuestas se
reeren, en cualquier caso, a la especicaci on de OCL 1.x.
Entre los trabajos antes citados el mas relevante sin duda, por su impac-
to ulterior, es la formalizaci on de la semantica de OCL utilizando teora de
conjuntos que realizo M. Richters en su tesis doctoral [Ric02]. Este trabajo, con
algunas extensiones, pas o a ser el apendice semantico no normativo de la ultima
especicaci on del lenguaje OCL [OCL06, Apendice A]. A pesar de su indudable
valor, esta semantica nos resulta en diversos aspectos demasiado abstracta: no
se denen, por ejemplo, los universos de valores y tipos que han de proporcio-
nar la interpretaci on de nociones b asicas como tipo, estado y modelo; tampoco
se denen las reglas que determinan los tipos de las diversas operaciones. En
cualquier caso, en relacion con nuestro trabajo, la semantica formal de OCL
propuesta en [Ric02] no es ciertamente ejecutable, ni es posible, por ello mismo,
implementarla directamente en herramientas OCL.
Entre los trabajos arriba citados, un grupo interesante lo forman aquellos que
proporcionan una semantica formal para OCL utilizando formalismos para los
que existen herramientas de demostracion (semi-)automaticas. El interes de es-
tas propuestas radica precisamente en las posibilidades que ofrecen para razonar
sobre las implicaciones l ogicas entre las distintas expresiones OCL que pueden
aparecer en, o en relacion con, modelos UML. En [BKS02, ABB
+
05, BHS07],
en concreto, se utiliza la l ogica de predicados de primer orden para traducir,
fundamentalmente, restricciones OCL sobre diagramas de clase UML dentro del
sistema KeY, convenientemente dotado de heursticas para hacer mas autom ati-
co el proceso de demostracion. Otro trabajo en este mismo grupo lo constituye
la tesis doctoral de M. Kyas [Kya06], en la que se utiliza el lenguaje del de-
mostrador de teoremas PVS [OSR92] para denir la semantica de OCL sobre
diversos diagramas UML y, de manera especial, el signicado de las expresiones
de mensajes en OCL. Para ello, se codica la l ogica de tres valores de OCL en
una l ogica de dos valores, reduciendo las funciones parciales a funciones totales
sobre dominios restringidos; la traducci on de OCL en el formalismo de PVS
es autom atica. Finalmente, dentro del grupo de propuestas que estamos con-
siderando, la tesis doctoral de A. D. Brucker [Bru07] dene un embebimiento
conservativo plano de OCL en la l ogica Isabelle/HOL, garantiz andose la con-
sistencia del resultado por construcci on. Ademas, se desarrolla un entorno de
prueba interactivo, HOL-OCL [BW07], basado en esta traducci on, para diagra-
mas UML con restricciones OCL. En relacion con nuestro trabajo, ninguna de
las semanticas formales consideradas en este grupo son ejecutables. En cambio,
como explicaremos a continuaci on, s es posible utilizar nuestra semantica formal
ejecutable para OCL para demostrar implicaciones l ogicas entre las distintas ex-
presiones OCL que pueden aparecer en, o en relacion con, modelos UML; esto
queda, en cualquier caso, como trabajo futuro de nuestra investigacion.
Otro grupo entre los trabajos arriba citados lo constituyen las propuestas que
utilizan, directa o indirectamente, el propio lenguaje OCL para dar semantica
a OCL [MB06, CP06]. Nos parece que estas propuestas estan limitadas por su
propia circularidad, como reconocen algunos de sus autores [MB06].
Formalizaciones de OCL en l ogica ecuacional Entre las propuestas
arriba citadas, la que guarda mayor relacion con nuestra semantica formal para
OCL es la contenida en la tesis doctoral de A. Boronat [Bor07], por lo que la
analizaremos en profundidad. A pesar de las apariencias, las similitudes entre
ambas propuestas se reducen al formalismo elegido para denir la semantica
de OCL la l ogica ecuacional y al sistema utilizado para desarrollar herra-
mientas basadas en esta semantica el sistema Maude. Los objetivos de ambas
propuestas son, sin embargo, claramente distintos, como reconoce el propio A.
Boronat en su trabajo [Bor07, Seccion 3.2.1].
Respecto al formalismo utilizado, aunque ambas propuestas utilizan la l ogi-
ca ecuacional en distintos sabores, por cierto: la l ogica ecuacional de per-
tenencias en el caso de [Bor07] y la l ogica ecuacional multi-tipada en nuestro
caso, las traducciones de los diagramas UML con expresiones OCL a la l ogica
ecuacional son completamente distintas. En el caso de la propuesta [Bor07], he-
redera en este punto de las ideas contenidas en la tesis doctoral de J. Fern andez-
Alem an [FA02], los diagramas UML se traducen a terminos y la semantica de las
expresiones OCL viene dada, b asicamente, por una funci on evaluadora que toma
como argumento el termino que representa el contexto de evaluaci on; para cada
expresi on OCL, la denici on de esta funci on evaluadora se obtiene mediante dos
(meta-)funciones, getExpTheory y getTermTheory, denidas en [Bor07, Captu-
lo 7]. Respecto de estas (meta-)funciones se arma en [Bor07] que las ecuaciones
que generan son siempre ejecutables, pero no se aporta la demostracion formal
de este resultado.
2
En nuestro caso, sin embargo, los diagramas UML con expre-
siones OCL se traducen a especicaciones ecuacionales, que son las que denen
directamente es decir, sin pasar por una funci on evaluadora la semantica de
las expresiones OCL. En este trabajo, ademas, hemos demostrado formalmente
que esta semantica para OCL es de hecho ejecutable: en concreto, hemos proba-
do que la especicaci on ecuacional asociada a cada escenario y a cada expresi on
OCL es siempre Church-Rosser y terminante.
No cabe esperar, por otra parte, que la evaluaci on de expresiones OCL, o
la demostracion de sus relaciones l ogicas con otras expresiones OCL, resulte
mas eciente o mas natural en el marco proporcionado por [Bor07] que en el
proporcionado en este trabajo: en su caso, tanto la evaluaci on como la demos-
traci on pasa por ejecutar, o demostrar las propiedades de, la funci on evaluadora
cuando toma como argumento el diagrama UML que proporciona el contexto
de las expresiones OCL de que se trate. Es decir, en [Bor07] tanto la evaluaci on
de una expresi on OCL como la demostracion de sus propiedades l ogicas est an
penalizadas por un nivel de interpretaci on, mientras que en nuestro caso el
valor de una expresi on OCL en un escenario se calcula como la forma canonica
de su traducci on en la especicaci on ecuacional asociada y, como veremos en la
secci on de trabajo futuro, sus propiedades l ogicas son precisamente las que se
2
Tampoco nos parece que, en el estado actual de las herramientas asociadas al sistema
Maude [CDE
+
07], la demostraci on de las propiedades de Church-Rosser y terminaci on de
las ecuaciones generadas para denir, en cada caso, la funci on evaluadora puedan hacerse a
posteriori, teniendo en cuenta los elementos formales utilizados en [Bor07] para dar sem antica
a los diagramas UML y las limitaciones actuales de estas herramientas.
derivan de las ecuaciones presentes en esa especicaci on ecuacional.
Como hemos dicho anteriormente, los objetivos de una y otra propuesta
son, en cualquier caso, claramente distintos. En el caso de [Bor07] su objetivo es
construir un marco formal para la gesti on de modelos (a formal framework for
model management): con este objetivo en mente, es perfectamente razonable
representar los diagramas como terminos, de forma que las distintas operaciones
de gesti on de modelos se puedan especicar como funciones ecuacionalmente de-
nidas sobre estos terminos. La necesidad de incluir una semantica ecuacional
para OCL en este marco formal radica en el hecho de que un modelo es tal es
conforme con solo si satisface las invariantes OCL asociadas a su metamode-
lo. Para capturar en su marco formal la nocion de conformidad, la propuesta
de [Bor07, Captulo 7] consiste, b asicamente, en utilizar un axioma condicio-
nal de pertenencia para denir el tipo (sort) de los terminos que representan
los modelos que son conformes con un metamodelo dado: las condiciones de
este axioma comprueban que, para cada invariante del metamodelo, la corres-
pondiente funci on evaluadora devuelve true cuando toma como argumento el
termino que representa el modelo para el cual se quiere determinar su conformi-
dad con el metamodelo. En el caso de este trabajo, nuestro objetivo es denir
una semantica formal ejecutable para OCL: es decir, la cuesti on que nos interesa
resolver, de forma autom atica, es cu al es el valor de una expresi on arbitraria
OCL es decir, no s olo invariantes en una instancia de un modelo. Son por
tanto dos propuestas con objetivos claramente distintos. Es interesante advertir
sin embargo que, como se reconoce en [Bor07, Seccion 3.2.1], nuestra semanti-
ca formal puede utilizarse tambien para decidir, aunque de una forma distinta,
cu ando un modelo es conforme con su metamodelo: basta con considerar el me-
tamodelo como un diagrama de clase y evaluar entonces su invariantes sobre
la instancia del metamodelo que corresponde al modelo en cuesti on es decir,
sobre la representacion del modelo en sintaxis abstacta; si en todos los casos
el resultado de estas evaluaciones es true, se puede armar que el modelo es
conforme con su metamodelo.
Para terminar, es relevante se nalar que las (meta-) funciones denidas en
la propuesta [Bor07] no proporcionan, en su formulaci on actual, una semanti-
ca ecuacional para las operaciones denidas por el usuario utilizando OCL. En
nuestra propuesta, como se ha discutido anteriormente, la semantica de estas
operaciones tambien cuando se denen recursivamente viene dada por la
especicaci on ecuacional generada a partir de la expresi on OCL que constitu-
ye el body de su denici on. En el caso de [Bor07], dado que sus objetivos
incluyen la denici on de la relacion de conformidad entre modelos y metamo-
delos, esta limitaci on que entendemos que no obedece a razones tecnicas
es relevante, puesto que las invariantes de los metamodelos y ciertamen-
te en el caso del metamodelo de UML tpicamente se expresan utilizando
operaciones denidas recursivamente en OCL: sirva como ejemplo la operaci on
allParents() = self.parents()>union(self.parents()>collect(p [ p.allParents())) que se
utiliza, directa o indirectamente, en numerosas invariantes del metamodelo de
UML.
Trabajo Futuro Planeamos usar nuestra semantica formal para razonar in-
ductivamente sobre propiedades est aticas de modelos UMLMOVA que tengan res-
tricciones OCLMOVA. La idea intuitiva es la siguiente. Primero, para cada in-
variante inv de un modelo T, a nadiremos el axioma (X)interpret(inv) = true
al interprete (, E) generado al llamar a la funci on interpret () sobre T e inv,
donde interpret (inv) es la traducci on del invariante inv generada por la fun-
cion interpret (). Entonces, formalizaremos la propiedad est atica que queramos
demostrar como una expresi on prop en OCLMOVA y extenderemos de nuevo el
interprete (, E) con las ecuaciones generadas al llamar a interpret () sobre T
y prop. Finalmente, probaremos en el modelo inicial del interprete resultante la
formula (X)interpret (prop) = true, donde de nuevo interpret (prop) denota la
traducci on de la propiedad prop generada por la funci on interpret(). Otra direc-
cion de investigacion interesante es probar, mediante herramientas existentes,
la terminaci on de una expresi on OCLMOVA denida por el usuario bas andonos
en la terminaci on del interprete generado por la funci on interpret() para esta
operaci on.
Captulo 3
Una Herramienta OCL
Basada en Reescritura
65
66 Captulo 3. Una Herramienta OCL Basada en Reescritura
En este captulo presentamos la herramienta ITP/OCL, una herramienta ba-
sada en reescritura que soporta la evaluaci on autom atica de consultas OCLMOVA
sobre diagramas de objetos UMLMOVA de forma eciente. La herramienta ITP/-
OCL implementa la transformaci on de diagramas UMLMOVA y de expresiones
OCLMOVA a especicaciones ecuacionales que se dene en el captulo 2.
La herramienta ITP/OCL est a dise nada para usarse como metodo formal
ligero: debera ayudar a los modeladores de software a validar, analizar y encon-
trar defectos en sus modelos en las etapas tempranas del proceso de desarrollo
software. Est a dise nada tambien como metodo formal pr actico: debera ser di-
rectamente utilizable por modeladores que no tengan un conocimiento especial
de matematicas o l ogica.
La herramienta ITP/OCL est a completamente escrita en Maude [CDE
+
07].
Su implementacion hace un uso intensivo de las capacidades reexivas de Mau-
de para evaluar ecientemente las expresiones OCLMOVA mediante reescritura de
terminos y para proporcionar una interfaz amigable para el usuario gracias a la
cual la semantica ecuacional subyacente en la herramienta ITP/OCL permanece
escondida al usuario. La herramienta ITP/OCL es, en cualquier caso, un pro-
totipo: no cabe esperar, tanto por el dise no reexivo de la herramienta, como
por las propias caractersticas del sistema Maude, que sus tiempos de ejecuci on
sean competitivos cuando se trate de evaluar expresiones OCL sobre escenarios
con cientos de miles de objetos y enlaces [CED08b]. Para estas aplicaciones,
es conveniente implementar (ya de forma menos directa) la semantica formal
propuesta en el captulo 2 utilizando otros lenguajes de programacin [CED08a].
Nuestro objetivo al desarrollar ITP/OCL no es otro que mostrar c omo se
puede realizar una implementacion directa de la semantica formal para OCL
denida en el Captulo 2, es decir, con la mnima distancia posible entre la
semantica formal y su implementacion (en un sistema como Maude), y utilizar
esta implementacion de forma efectiva para la construcci on de una herramienta
que permita la validaci on rigurosa de modelos. Las mismas tecnicas explicadas
en este captulo pueden utilizarse para implementar en Maude otras herramien-
tas basadas en nuestra semantica formal para OCL que permitan, por ejemplo,
el razonamiento sobre la consistencia de modelos con invariantes OCL (como
una extensi on del demostrador de teoremas ITP [Cla08]) o la demostracion de
la terminaci on de operaciones OCL denidas por el usuario utilizando recur-
si on (como una extensi on en este caso de las herramientas de terminaci on de
Maude [CDE
+
07]).
La ultima versi on de la herramienta ITP/OCL, con su documentacion y una
colecci on de ejemplos, est a disponible en http://maude.sip.ucm.es/itp/ocl/.
Este captulo est a organizado de la siguiente manera. Primero, en la sec-
cion 3.1, resumimos material cuyo conocimiento es relevante para usar Maude
como una meta-herramienta formal para implementar otras herramientas for-
males interactivas. Despues, en la secci on 3.2, discutimos la implementacion de
la herramienta ITP/OCL en Maude. En la secci on 3.3 explicamos c omo la he-
rramienta ITP/OCL proporciona soporte al an alisis y a la validaci on de modelos
UMLMOVA. Finalmente, hablamos sobre posibles extensiones de la herramienta
ITP/OCL y sobre trabajo relacionado y futuro. A lo largo de este captulo asu-
3.1. Maude como Meta-Herramienta Formal 67
mimos que el lector est a familiarizado con la sint axis y la semantica del lenguaje
Maude: en particular asumimos que el lector conoce sus caractersticas reexivas
y el estilo de metaprogramacion funcional que soporta.
3.1. Maude como Meta-Herramienta Formal
Maude [CDE
+
07] es un lenguaje de alto nivel y un sistema de alto rendi-
miento que proporciona soporte tanto a la especicaci on ejecutable como a la
programacion declarativa en l ogica de reescritura [Mes92].
Como la l ogica de reescritura contiene a la l ogica ecuacional, Maude tambien
da soporte a la programacion y a la especicaci on ecuacional. La l ogica ecuacio-
nal implementada en Maude es la l ogica ecuacional de pertenencia [Mes98a], una
versi on expresiva de la l ogica ecuacional que incluye tipos, subtipos, sobrecarga
de operadores y parcialidad. En Maude, las unidades b asicas de especicaci on y
programacion se llaman m odulos, que son de dos tipos: modulos funcionales pa-
ra las epecicaciones en l ogica ecuacional de pertenencia y modulos de sistema
para las especicaciones en l ogica de reescritura.
Una propiedad muy importante de la l ogica de reescritura es que es reexiva
[Cla03, CM02, CMP07] en el sentido de que puede expresar su propia metal ogica
al nivel objeto. De hecho, la reexion es sistem aticamente explotada en Maude
proporcionando al lenguaje poderosas capacidades de metaprogramacion. Las
caractersticas reexivas de Maude incluyen signaturas predenidas para meta-
rrepresentar modulos, tipos y terminos. Tambien incluye funciones built-in (pre-
denidas) para acceder a la funcionalidad interna del sistema, como las funciones
metaReduce y metaParse. La funci on metaReduce toma la metarrepresentacion
de un modulo y la metarrepresentacion de un termino, y devuelve la metarrepre-
sentacion de la forma reducida de este termino usando el motor de reescritura
de Maude. La funci on metaParse toma la metarrepresentacion de un modulo,
una lista de identicadores precedidos por ap ostrofo y la metarrepresentacion
de un tipo y, si la lista de identicadores precedidos por ap ostrofo resulta ser
sint acticamente un termino de este tipo usando el analizador sint actico de Mau-
de, entonces devuelve la metarrepresentacion de este termino; en caso contrario,
devuelve un termino que indica la causa del fallo del an alisis sint actico.
Las capacidades reexivas de Maude, junto con las buenas propiedades de
la l ogica de reescritura como marco l ogico y semantico [Mes98b], pueden explo-
tarse sistem aticamente para usarlo como meta-herramienta en la que muchas
otras herramientas pueden implementarse de forma facil y eciente. Normalmen-
te, la implementacion de una herramienta interactiva en Maude comprende las
siguientes tareas: denir un bucle read-eval-print; denir la sintaxis para los
comandos; denir la interacci on con el bucle; y denir el procesado de los coman-
dos. Terminamos esta secci on discutiendo brevemente cada una de estas tareas.
El bucle read-eval-print Maude proporciona un sistema general de entra-
da/salida a traves de su modulo predenido LOOP-MODE. Este modulo introduce
terminos de la forma [input,state,output ] a los que llamamos objetos bucle: cada
objeto bucle contiene una cadena de entrada input (como primer argumento)
una cadena de salida output (como tercer argumento), y un estado state (como
segundo argumento). Cuando Maude est a ejecutando el modulo LOOP-MODE (o
un modulo que lo incluya), si la entrada est a escrita entre parentesis, es inme-
diatamente convertida a una lista de identicadores precedidos por ap ostrofo y
situada en la cadena de entrada input del objeto bucle; en la otra direcci on, si
una lista de identicadores precedidos por ap ostrofo es situada en la cadena de
salida output del objeto bucle, esta lista es directamente proporcionada como
salida despues de quitar los ap ostrofos a cada uno de los identicadores de la
lista.
La sintaxis de los comandos Maude proporciona gran exibilidad para
denir la sintaxis de los comandos gracias a que admite sintaxis arbitraria y el
uso de bubbles (cualquier lista no vaca de identicadores en Maude). En muchas
herramientas interactivas, los comandos aceptan datos escritos siguiendo una
sintaxis denible por el usuario. En esos casos, la sintaxis de los comandos
es denida realmente en dos niveles diferentes: la sintaxis de alto-nivel de la
herramienta y la sintaxis denible por el usuario. Las bubbles proporcionan una
forma de reejar esta dualidad en Maude. Caractersticas similares proporciona
ASF+SDF [Deu94].
La interacci on con el bucle Maude proporciona una forma general de im-
plementar la interacci on con el bucle, mediante la denici on de reglas de re-
escritura sobre los objetos bucle. Estas reglas detectan cu ando una petici on
valida se ha situado en la cadena de entrada input del objeto bucle y denen
c omo debe procesarse; en la otra direcci on, detectan cu ando un resultado valido
ha sido situado en la cadena de salida del objeto bucle y denen c omo debe
proporcionarse como salida.
El procesado de los comandos Finalmente, Maude tambien proporciona
una forma general de implementar la ejecuci on de los comandos mediante la
denici on de ecuaciones sobre el estado de los objetos bucle.
3.2. La herramienta ITP/OCL
En esta secci on discutimos la implementacion de la herramienta ITP/OCL en
Maude: es decir, los estados de sus objetos bucle, la sintaxis de sus comandos,
la interacci on con su bucle y el procesado de sus comandos. La ultima versi on
de ITP/OCL comprende unas 7.000 lneas de c odigo. Para facilitar la lectura de
esta secci on y la comprensi on de las ideas principales, aqu unicamente mostra-
remos y explicaremos los fragmentos mas signicativos del c odigo. Como ya se
ha comentado, el c odigo completo de la herramienta ITP/OCL est a libremente
disponible en http://maude.sip.ucm.es/itp/ocl.
3.2. La herramienta ITP/OCL 69
3.2.1. Estados
En la herramienta ITP/OCL el estado de un objeto bucle es un termino
de tipo State construido con el operador state, que toma como argumentos
una colecci on de atributos. Las colecciones de atributos son terminos de tipo
OCLAttrSet que se construyen con el operador attrs; este operador se de-
clara asociativo, conmutativo y con elemento identidad, a saber, la constante
emptyAttrSet. Cada atributo es un termino de tipo OCLAttr. En concreto, los
atributos del estado de un objeto bucle son: su base de datos (el argumento del
operador odb), sus invariantes (el argumento del operador invs), sus operacio-
nes (el argumento del operador ops), su entrada (el argumento del operador
input), y sus salidas (el argumento del operador output). La base de datos
representa los diagramas de clases y objetos introducidos por el usuario; los in-
variantes representan los invariantes introducidos; las operaciones representan
las operaciones denidas; la entrada representa el ultimo comando introducido;
y la salida representa el resultado del ultimo comando ejecutado. En particular,
el ultimo comando se representa mediante la metarrepresentacion del comando
en sintaxis ITP/OCL (vease la secci on 3.2.2). El resultado del ultimo comando
est a representado por una lista de identicadores precedidos por ap ostrofo; los
diagramas de clases y objetos est an representados de la siguiente forma:
subsort OCLAttr < OCLAttrSet .
op emptyAttrSet : -> OCLAttrSet .
op attrs : OCLAttrSet OCLAttrSet -> OCLAttrSet
[assoc comm id: emptyAttrSet] .
op state : OCLAttrSet -> State .
op input :_ : TermList -> OCLAttr .
op output :_ : QidList -> OCLAttr .
op odb :_ : OCLDatabase -> OCLAttr .
op invs :_ : InvDatabase -> OCLAttr .
op ops :_ : OpsDatabase -> OCLAttr .
Diagramas de clases Cada diagrama de clases UMLMOVA que el usuario in-
troduce es guardado en una 6-tupla de la forma classDiagramName, classList,
attributeList, associationList, generalizationList, enumerationList) que contiene
el nombre del diagrama de clases y sus clases, atributos, asociaciones, genera-
lizaciones y clases de enumeraci on. El classDiagramName es un identicador
que representa el nombre del diagrama de clases. Un classList es una lista de
identicadores c
i
, donde cada identicador representa el nombre de una clase.
Un attributeList es una lista de triplas at
i
, c
i
, t
i
), donde cada tripla represen-
ta un atributo en una clase: at
i
es un identicador que representa el nombre
del atributo; c
i
es un identicador que representa el nombre de la clase a la
que pertenece el atributo; y t
i
es un identicador t
i
que representa el tipo del
atributo. Una associationList es una lista de 4-tuplas c
i
, r
i
, r
i
, c
i
), donde cada
4-tupla representa una asociaci on entre dos clases: c
i
y c
i
son identicadores que
representan el nombre de las clases asociadas a traves de la asociaci on, mien-
tras que r
i
y r
i
son identicadores que representan los roles jugados por estas
clases en la asociaci on. Las multiplicidades est an representadas como invarian-
tes de las clases correspondientes. Una generalizationList es una lista de pares
c
i
, c
i
), donde cada par representa una generalizaci on entre dos clases: c
i
y c
i
son identicadores que representan, respectivamente, los nombres de las sub-
y super-clases implicadas en la generalizaci on. Finalmente, una enumeration-
List es una lista de pares e
i
, literalList
i
), donde cada par representa una clase
de enumeraci on: e
i
es un identicador que representa el nombre de la clase de
enumeraci on y literalList
i
es una lista de identicadores l
ij
, donde cada uno
representa el nombre de un literal de la clase de enumeraci on.
Diagramas de Objetos Cada diagrama de objetos UMLMOVA introducido
por el usuario se guarda en una 5-tupla objectDiagramName, classDiagramNa-
me, objectList, attributeValueList, linkList) que contiene el nombre del diagrama
de objetos y de su diagrama de clases, los objetos, los valores de sus atributos
y los enlaces que se declaran en el diagrama. Un objectDiagramName es un
identicador que representa el nombre del diagrama de objetos. Un classDia-
gramName es un identicador que representa el nombre del diagrama de clases
del que el diagrama de objetos es una instancia. Un objectList es una lista de
pares c
i
, o
i
), donde cada par representa un objeto: c
i
y o
i
son identicadores
que representan, respectivamente, el nombre de la clase del cual el objeto es una
instancia y el nombre del objeto mismo. Un attributeValueList es una lista de
5-tuplas at
i
, c
i
, t
i
, o
i
, v
i
), donde cada 5-tupla representa el valor de un atributo
en un objeto: at
i
es un identicador que representa el nombre del atributo; t
i
es
un identicador que representa el tipo del atributo; c
i
y o
i
son identicadores
que representan, respectivamente, el nombre de la clase de la que el objeto es
una instancia y el nombre del objeto mismo; y v
i
es un identicador que repre-
senta el valor del atributo en el objeto. Una linkList es una lista de 6-tuplas
c
i
, r
i
, r
i
, c
i
, o
i
, o
i
), donde cada 6-tupla representa un enlace entre dos objetos:
c
i
y c
i
son identicadores que representan el nombre de las clases de los que los
objetos son instancias; r
i
y r
i
son identicadores que representan los roles que
juegan las clases en la asociaci on de la que el enlace es una instancia; y o
i
y o
i
son identicadores que representan el nombre de los objetos.
Ejemplo 2. Consideremos el diagrama de clases de la Figura 2.1. Su repre-
sentaci on en la base de datos de ITP/OCL es una 6-tupla classDiagramName,
classList, attributeList, associationList, generalizationList, enumerationList) don-
de:
classDiagramName = TRAIN-WAGON
classList = Train, Wagon, FirstClassWagon )
attributeList = typesOfTrain, Train, TypesOfTrain ),
smoking, Wagon, Boolean ),
identifier, Train, String ),
numberOfPassengers, Wagon, Integer ),
hasBar, FirstClassWagon, Boolean ) )
associationList = Train, train, wagon, Wagon),
Wagon, pred, succ, Wagon) )
generalizationList = FirstClassWagon, Wagon ) )
enumerationList = TypesOfTrain, Monorail, HighSpeed ) )
Consideremos ahora el diagrama de objetos de la Figura 2.2. La representa-
ci on de este diagrama en la base de datos de ITP/OCL viene dada por una 5-
tupla objectDiagramName, classDiagramName, objectList, attributeValueList,
linkList) donde:
objectDiagramName = TRAIN-WAGON-1 )
classDiagramName = TRAIN-WAGON )
objectList = Train, Train1 ), Wagon, Wagon1 ), Wagon, Wagon2 ) )
attributeValueList =
typesOfTrain, Train, TypesOfTrain, Train1, Monorail ),
identifier, Train, String, Train1, HG340 ),
smoking, Wagon, Boolean, Wagon1, false ),
smoking, Wagon, Boolean, Wagon2, true ),
numberOfPassengers, Wagon, Integer, Wagon1, 80 ),
numberOfPassengers, Wagon, Integer, Wagon2, 80 ) )
linkList = Train, train, wagon, Wagon, Train1, Wagon1 ),
Train, train, wagon, Wagon, Train1, Wagon2 ),
Wagon, pred, succ, Wagon, Wagon1, Wagon2 ),
Wagon, pred, succ, Wagon, Wagon2, Wagon1 ) )
3.2.2. Comandos
En ITP/OCL, la sintaxis para los comandos es una sintaxis combinada a
dos niveles: la sintaxis de alto nivel, que proporciona el lenguaje necesario pa-
ra expresar las acciones que quieran los usuarios, por ejemplo, para crear un
diagrama, para a nadir una clase, para insertar una operaci on, etc.; y la sintaxis
denible por el usuario que proporciona el lenguaje para expresar los argumentos
de estas acciones, por ejemplo, el nombre del diagrama que vaya a ser creado,
el nombre de la clase que vaya a ser a nadida, la expresi on que vaya a insertarse
como invariante, etc.
Las bubbles proporcionan una forma de reejar esta dualidad: permiten en-
capsular porciones del texto en sintaxis denible por el usuario. En particular,
la sintaxis para los comandos ITP/OCL se dene con la ayuda de tres tipos de
bubbles: Token para bubbles de longitud uno; NeTokenList para bubbles de
cualquier longitud mayor que uno; y Bubble para bubbles de cualquier longitud
mayor o igual que uno. Para explicar los comandos ITP/OCL distinguimos entre
comandos de diagrama y comandos de expresion.
Comandos de Diagrama Se usan para crear diagramas de clases y de ob-
jetos UMLMOVA y para insertar, borrar y modicar elementos en los diagramas.
op create-class-diagram_. : Token -> Input .
op create-object-diagram_:_. : Token Token -> Input .
op insert-class_:_. : Token Token -> Input .
op insert-enum-class_:_. : Token Token -> Input .
op insert-enum-value_:_-_. : Token Token Token -> Input .
op insert-attr_:_(_,_). : Token Token Token Token -> Input .
op insert-assoc_:_:_:_<->_:_:_. : Token Token Token
Multi Multi Token Token -> Input .
op insert-subclass_:_->_. : Token Token Token -> Input .
op insert-object_:_:_. : Token Token Token -> Input .
op insert-link_|_:_<->_:_|_<->_. : Token Token Token Token
Token Token Token -> Input .
op insert-attr-value_:_:_:_:_->_. : Token Token Token Token
Token Token -> Input .
Cuadro 3.1: Comandos de Diagrama de ITP/OCL.
(create-class-diagram TRAIN-WAGON .)
(insert-class TRAIN-WAGON : Train .)
(insert-class TRAIN-WAGON : Wagon .)
(insert-class TRAIN-WAGON : FirstClassWagon .)
(insert-subclass TRAIN-WAGON : FirstClassWagon -> Wagon .)
(insert-enum-class TRAIN-WAGON : TypesOfTrain .)
(insert-enum-value TRAIN-WAGON : TypesOfTrain - Monorail .)
(insert-enum-value TRAIN-WAGON : TypesOfTrain - HighSpeed .)
(insert-attr TRAIN-WAGON : Train (typesOfTrain, TypesOfTrain) .)
(insert-attr TRAIN-WAGON : Train (identifier, String) .)
(insert-attr TRAIN-WAGON : Wagon (smoking, Boolean) .)
(insert-attr TRAIN-WAGON : Wagon (numberOfPassengers, Integer) .)
(insert-attr TRAIN-WAGON : FirstClassWagon (hasBar, Boolean) .)
(insert-assoc TRAIN-WAGON : Train : train : < 1 > <->
< * > : wagon : Wagon .)
(insert-assoc TRAIN-WAGON : Wagon : succ : < 0,1 > <->
< 0,1 > : pred : Wagon .)
Cuadro 3.2: Comandos para cargar el diagrama TRAIN-WAGON.
Sint acticamente, los comandos de diagrama son terminos de tipo Input cons-
truidos con operadores como los que se muestran en el Cuadro 3.1. Como los
nombres de los diagramas y los de los elementos que se insertaran, borrar an
o modicar an est an declarados por los usuarios, estos operadores toman ar-
gumentos de tipo Token. Los terminos Multi representan multiplicidades. La
semantica precisa de estos comandos se da en la subsecci on 3.2.4.
Ejemplo 3. Consideremos el diagrama de clases de la Figura 2.1. Usamos los
comandos mostrados en el Cuadro 3.2 para cargarlo en la herramienta ITP/OCL.
An alogamente, consideremos el diagrama de objetos de la Figura 2.2. Usamos
los comandos que se muestran en el Cuadro 3.3 para cargar este diagrama en la
herramienta ITP/OCL.
(create-object-diagram TRAIN-WAGON : TRAIN-WAGON-1 .)
(insert-object TRAIN-WAGON-1 : Train : Train1 .)
(insert-object TRAIN-WAGON-1 : Wagon : Wagon1 .)
(insert-object TRAIN-WAGON-1 : Wagon : Wagon2 .)
(insert-attr-value TRAIN-WAGON-1 : Train : Train1 :
type : TypesOfTrain -> Monorail .)
(insert-attr-value TRAIN-WAGON-1 : Train : Train1 :
identifier : String -> HG340 .)
(insert-attr-value TRAIN-WAGON-1 : Wagon : Wagon1 :
smoking : Boolean -> false .)
numberOfPassengers : Integer -> 80 .)
smoking : Boolean -> true .)
numberOfPassengers : Integer -> 80 .)
(insert-link TRAIN-WAGON-1 | Wagon : pred <-> succ : Wagon |
Wagon1 <-> Wagon2 .)
(insert-link TRAIN-WAGON-1 | Wagon : pred <-> succ : Wagon |
Wagon2 <-> Wagon1 .)
(insert-link TRAIN-WAGON-1 | Train : train <-> wagon : Wagon |
Train1 <-> Wagon1 .)
(insert-link TRAIN-WAGON-1 | Train : train <-> wagon : Wagon |
Train1 <-> Wagon2 .)
Cuadro 3.3: Comandos para cargar el diagrama TRAIN-WAGON-1.
Comandos de Expresion En el contexto de los diagramas UMLMOVA, son
usados para insertar y comprobar invariantes OCLMOVA, para evaluar consultas
OCLMOVA y para denir operaciones OCLMOVA. Sint acticamente, los comandos de
expresi on son terminos de tipo Input construidos con operadores como los que
se muestran en el Cuadro 3.4. Como las expresiones que se usan en invariantes,
consultas y operaciones est an declaradas por los usuarios, estos operadores to-
man argumentos de tipo Bubble. La semantica precisa de estos comandos viene
dada en la subsecci on 3.2.4.
3.2.3. Interaccion
En ITP/OCL la interacci on con el objeto bucle se dene mediante reglas
de reescritura [in] y [out]. La regla [in] usa la operaci on built-in metaParse
para comprobar si una lista de identicadores precedidos por ap ostrofo, situados
en la cadena de entrada del objeto bucle, corresponden a un comando ITP/OCL.
La sintaxis de alto nivel de los comandos ITP/OCL se declara en el modulo
COMMANDS-GRAMMAR, que contiene entre otros los operadores declarados en los
Cuadros 3.1 y 3.4. Si la lista de identicadores precedidos por ap ostrofo son de
hecho un termino de tipo Input en el modulo COMMANDS-GRAMMAR, la regla [in]
situa la metarrepresentacion de este termino en el atributo input del estado del
objeto bucle. La constante COMMANDS-GRAMMAR denota la metarrepresentacion
del modulo COMMANDS-GRAMMAR. Para la direcci on inversa de la interacci on, la
regla [out] comprueba cu ando el atributo output del estado del objeto bucle
op query-in_:_:_. : Token Token Bubble -> Input .
op insert-invariant_:_:_. : Token Token Bubble -> Input .
op insert-invariant_::_. : Token Bubble -> Input .
op check-invariants_:_. : Token Token -> Input .
op insert-oper_:_(_,_)_. : Token Token Token
Token Bubble -> Input .
op insert-oper_:_(_,_,_)_. : Token Token Token
NeTokenList Token Bubble -> Input .
op insert-oper_::(_,_)_. : Token Token Token Bubble -> Input .
op insert-oper_::(_,_,_)_. : Token Token
Cuadro 3.4: Comandos de Expresi on ITP/OCL.
contiene una respuesta que haya de usarse como salida, es decir, una cadena no
vaca de identicadores precedidos por ap ostrofo, y la sit ua en la cadena output
del objeto bucle.
crl [in] :
[QIL, state(attrs(input : empty, output : nil, Atts)), QIL]
=>
[nil,
state(attrs(input : getTerm(metaParse(COMMANDS-GRAMMAR,
QIL, Input)),
output : nil, Atts)),
QIL]
if QIL =/= nil /\ metaParse(COMMANDS-GRAMMAR,
QIL, Input): ResultPair .
crl [out] :
[QIL,
state(attrs(input : TL, output : QIL, Atts)),
QIL]
=> [QIL,
state(attrs(input : TL, output : nil, Atts)),
(QIL QIL)]
if QIL =/= nil .
3.2.4. Ejecucion
En ITP/OCL la ejecuci on de cada comando viene denida por ecuaciones
condicionales sobre el estado del objeto bucle que se est a ejecutando. Estas
ecuaciones especican c omo el procesado de la entrada input que corresponde a
cada comando modica la base de datos y la salida output del estado; sus con-
diciones especican las propiedades que deben satisfacer los argumentos de los
comandos para que estos sean admisibles. Recordamos que los argumentos de
los comandos contienen datos proporcionados por el usuario, sin restricciones
sint acticas particulares: por ejemplo, el usuario puede usar en principio cual-
quier identicador para nombrar una clase de un diagrama; sin embargo, no
ser a admisible insertar una clase en un diagrama que tenga un nombre que
este usando otra clase del diagrama. A continuaci on presentamos las ecuacio-
nes condicionales para los comandos ITP/OCL declarados en los Cuadros 3.1
(comandos de diagrama) y 3.4 (comandos de expresi on). ITP/OCL tambien pro-
porciona comandos para borrar y modicar elementos en los diagramas, que
est an denidos de manera completamente an aloga.
El Procesado de los Comandos de Diagrama
Podemos agrupar los comandos de diagrama declarados en el Cuadro 3.1 por
categoras.
Commandos que crean un diagrama Son los siguientes:
(create-class-diagram cnm .) y
(create-object-diagram cnm : onm .).
El comando (create-class-diagram cnm .) crea un diagrama de clase
cnm.
Est a implementado por la funci on createClassDiagram que a nade la 6-
tupla cnm, nil, nil, nil, nil, nil) a la base de datos del estado. La funci on
booleana isClassDiagramIn? comprueba que no existe otro diagrama de clases
en la base de datos del estado que tenga como nombre cnm.
ceq state(attrs(
odb : ODB,
input : (create-class-diagram_.[token[T]]),
output : nil, Atts))
= state(attrs(
odb : createClassDiagram(ODB, nameCD),
input : empty,
output : (OK: The class diagram nameCD has been
created .), Atts))
if nameCD := downQid(T)
/\ isClassDiagramIn?(nameCD, ODB) = false .
El comando (create-object-diagram cnm : onm .) crea un diagrama de
objetos onm como una instancia del diagrama de clases cnm. Est a implementado
por la funci on createObjectDiagram, que a nade la 5-tupla onm, cnm, nil, nil,
nil) a la base de datos del estado. La funci on booleana isObjectDiagramIn?
comprueba que no existe otro diagrama de objetos en la base de datos del estado
que tenga como nombre onm y sea instancia del diagrama de clases cnm.
ceq state(attrs(
odb : ODB,
input : (create-object-diagram_:_.[token[T1], token[T2]]) ,
= state(attrs(
odb : createObjectDiagram(ODB, downQid(T1), downQid(T2))
input : empty,
output : (OK: The object diagram nameOD of the
class diagram nameCD
has been created .), Atts))
if nameCD := downQid(T1)
/\ nameOD := downQid(T2)
/\ isClassDiagramIn?(nameCD, ODB) = true
/\ isObjectDiagramIn?(nameOD, ODB) = false .
Comandos que insertan un elemento en un diagrama Estos son los
siguientes comandos:
(insert-class cnm : c .),
(insert-enum-class cnm : e .),
(insert-enum-class-value cnm : e - l .),
(insert-attr cnm : c (at ,t ) .),
(insert-assoc cnm : c : r : m <-> m : r : c .),
(insert-subclass cnm : c -> c .),
(insert-object onm : c : o .),
(insert-link onm | c : r <-> r : c | o <-> o .) y
(insert-attr-value onm : c : a : at : t -> v .)
El comando (insert-class cnm : c .) inserta la clase c en el diagrama
de clases cnm. Est a implementado con la funci on insertClass, que modi-
ca la 6-tupla cnm, classList, attributeList, associationList, generalizationList,
enumerationList) en la base de datos del estado a nadiendo un identicador
c a classList. La funci on getClassDRepr devuelve la 6-tupla cnm, classList,
attributeList, associationList, generalizationList, enumerationList). La funci on
getClassList devuelve classList. La funci on getEnumClassList devuelve enu-
merationList. La funci on booleana isClassIn? comprueba que no hay otra clase
con nombre c en la lista classList. La funci on booleana isEnumClassIn? com-
prueba que no hay otra clase de enumeraci on con nombre c en la lista enume-
rationList.
ceq state(attrs(
odb : ODB,
input : (insert-class_:_.[token[T1], token[T2]]),
= state(attrs(
odb : insertClass(ODB, nameCD, nameC),
input : empty,
output : (OK: The class nameC has been inserted in
the class diagram nameCD .), Atts))
/\ nameC := downQid(T2)
/\ reprCD := getClassDRepr(nameCD, ODB)
/\ isClassIn?(nameC, getClassList(reprCD)) = false
/\ isEnumClassIn?(nameC, getEnumClassList(reprCD)) = false .
El comando (insert-enum-class cnm : e .) inserta la clase de enume-
racion e en el diagrama de clases cnm. Est a implementado con la funci on
insertEnumClass que modica la 6-tupla cnm, classList, attributeList, asso-
ciationList, generalizationList, enumerationList) en la base de datos del estado
a nadiendo el par e, nil) a la lista enumerationList.
ceq state(attrs(
odb : ODB,
input : (insert-enum-class_:_.[token[T1], token[T2]]),
= state(attrs(
odb : insertEnumClass(ODB, nameCD, nameC),
input : empty,
output : (OK: The enumeration class nameC has
been inserted in the class
diagram nameCD .), Atts))
/\ isEnumClassIn?(nameC, getEnumClassList(reprCD)) = false .
El comando (insert-enum-class-value cnm : e - l .) a nade el literal l
a la clase de enumeraci on e en el diagram de clases cnm. Est a implementado
con la funci on insertEnumValues que modica la 6-tupla cnm, classList, at-
tributeList, associationList, generalizationList, enumerationList) en la base de
datos del estado modicando el par e, literalList ) de la lista enumerationList
con la inserci on del identicador l en la lista literalList. La funci on booleana
isEnumValueIn? comprueba que la clase e no contiene ya el literal l.
ceq state(attrs(
odb : ODB,
input : (insert-enum-value_:_-_.[token[T1],
token[T2], token[T3]]) ,
= state(attrs(
odb : insertEnumValues(ODB, nameCD, nameC, downQid(T3)),
input : empty,
output : (OK: The enumeration value nameV
for class nameC has
been inserted in the class
diagram nameCD . ), Atts))
/\ nameV := downQid(T3)
/\ isEnumClassIn?(nameC, getEnumClassList(reprCD)) = true
/\ isEnumValueIn?(nameC, nameV,
getEnumClassList(reprCD)) = false .
El comando (insert-attr cnm : c (at ,t) .) a nade el atributo at del ti-
po t a la clase de c en el diagrama de clases cnm. Est a implementado con la
funci on insertAttr que modica la 6-tupla cnm, classList, attributeList, asso-
ciationList, generalizationList, enumerationList) en la base de datos del estado
a nadiendo la tripla at , c, t) a la lista attributeList. La funci on getAtList devuel-
ve attributeList. La funci on getGeList devuelve generalizationList. La funci on
booleana isAtInGen? comprueba que la clase c no contiene ya el atributo at, te-
niendo tambien en consideracion los atributos que hereda. La funci on booleana
isBT? comprueba que t es un tipo predenido.
ceq state(attrs(
odb : ODB,
input : (insert-attr_:_(_,_).[token[T1], token[T2],
token[T3], token[T4]]),
= state(attrs(
odb : insertAttr(ODB, nameCD, nameC, nameA, nameT),
input : empty,
output : (OK: The attribute nameA has been inserted
in the class
nameC of the class diagram nameCD . ), Atts))
/\ nameA := downQid(T3)
/\ nameT := downQid(T4)
/\ isAtInGen?(at(nameA, nameC, nameT),
getAtList(reprCD),
getGeList(reprCD),
getGeList(reprCD)) = false
/\ (isEnumClassIn?(nameT, getEnumClassList(reprCD))
or isBT?(bt(nameT), getBtList(reprCD))) = true .
El comando (insert-assoc cnm : c : r : m <-> m
: r
: c
.) a nade una
asociaci on entre las clases c y c
en el diagrama de clases cnm, donde c y c
juegan respectivamente, los roles r y r
, con multiplicidades m y m
. Est a im-
plementado mediante la funci on insertAssoc, que modica la 6-tupla cnm,
classList, attributeList, associationList, generalizationList, enumerationList) en
la base de datos del estado, a nadiendo la 4-tupla c, r, r
, c
), a la lista associa-
tionList. La funci on getAssocList devuelve associationList. La funci on boolea-
na isAssocInGen? comprueba que entre c y c
no existe ya una asociaci on con

roles r y r
, teniendo tambien en consideracion las asociaciones heredadas. La

funci on insertInvariantMulti inserta los invariantes que corresponden a las
multiplicidades m y m
.
ceq state(attrs(
odb : ODB,
input : (insert-assoc_:_:_:_<->_:_:_.[token[T1], token[T2],
token[T3], M1, M2, token[T4], token[T5]]),
= state(attrs(
odb : insertInvariantMulti(
insertAssoc(ODB, nameCD, nameC1, nameR1,
nameR2, nameC2),
nameCD, nameC1, nameR1, nameR2, nameC1, M1, M2),
input : empty,
output : (OK: The association
nameC1 : nameR1 <-> nameR2 : nameC2
has been inserted in the
class diagram nameCD .),
Atts))
/\ nameC1 := downQid(T2)
/\ nameR1 := downQid(T3)
/\ isAssocInGen?(as(nameC1, nameR1, nameR2, nameC2),
getAssocList(reprCD),
getGeList(reprCD),
getGeList(reprCD)) = false.
El comando (insert-subclass cnm : c -> c
.) a nade una generalizaci on

entre las clases c y c
en el diagrama de clases cnm, donde c es la subclase y c
es la
superclase. Est a implementado mediante la funci on insertSubclass, que modi-
ca la 6-tupla cnm, classList, attributeList, associationList, generalizationList,
enumerationList) en la base de datos del estado, a nadiendo el par c, c
), a la
lista generalizationList. La funci on getAssocList devuelve associationList. La
funci on booleana isGeinGen? comprueba que c no es ya una subclase de c
(y
vice-versa), teniendo en cuenta tambien las superclases heredadas.
ceq state(attrs(
odb : ODB,
input : (insert-subclass_:_->_.[token[T1], token[T2],
token[T3]]) ,
= state(attrs(
odb : insertSubclass(ODB, nameCD, nameC1, nameC2),
input : empty,
output : (OK: The class nameC1 has been
inserted in the class diagram nameC2
as a subclass of nameC2 .),
Atts))
/\ isClassIn?(nameC1, getClassList(reprCD)) = true
/\ isGeInGen?(ge(nameC1, nameC2),
getGeList(reprCD),
getGeList(reprCD)) = false
/\ isGeInGen?(ge(nameC2, nameC1),
getGeList(reprCD),
getGeList(reprCD)) = false .
El comando (insert-object onm : c : o .) inserta el objeto o como ins-
tancia de la clase c en el diagrama de objetos onm. Est a implementado me-
diante la funci on insertObject, que modica la 5-tupla objectDiagramName,
classDiagramName, objectList, attributeValueList, linkList) en la base de da-
tos del estado, a nadiendo el par c, o) a la lista objectList y, para cada atri-
buto at de tipo t
i
, o bien perteneciente o bien heredado por c, la 5-tupla
at
i
, c, t
i
, o, defaultValue(t
i
)) a la lista attributeValueList. La funci on defaultValue
devuelve 0 para el tipo Integer; true para el tipo Boolean; la cadena vaca para
el tipo String; y el primer literal de la enumeraci on para un tipo enumerado.
La funci on getObjectDRepr devuelve la 5-tupla objectDiagramName, classDia-
gramName, objectList, attributeValueList, linkList). La funci on getItsClassD
devuelve classDiagramName. La funci on getCoupleList devuelve objectList. La
funci on booleana isObjInGen? comprueba que no hay otra instancia de c, o de
alguna de sus superclases heredadas que tenga nombre o.
ceq state(attrs(
odb : ODB,
input : (insert-object_:_:_.[token[T1], token[T2],
token[T3]]) ,
= state(attrs(
odb : insertObject(ODB, downQid(T1), downQid(T2),
downQid(T3)),
input : empty,
output : (OK: The object nameO of the class nameC
object diagram nameOD .), Atts))
if nameOD := downQid(T1)
/\ isObjectDiagramIn?(nameOD, ODB) = true
/\ reprOD := getObjectDRepr(nameOD, ODB)
/\ reprCD := getClassDRepr(getItsClassD(reprOD), ODB)
/\ isClassIn?(nameC, getClassList(reprCD)) = true
/\ nameO := downQid(T3)
/\ isObjInGen?(cobj(nameC, nameO), getCoupleList(reprOD),
getGeList(reprCD), getGeList(reprCD)) = false .
El comando (insert-link onm | c : r <-> r
: c
| o <-> o
.) a nade un
enlace entre los objetos o y o
en el diagrama de objetos onm como una instancia

de la asociaci on en la que las clases c y c
juegan, respectivamente, los roles r

y r
. Est a implementado mediante la funci on insertLink, que modica la 5-

tupla objectDiagramName, classDiagramName, objectList, attributeValueList,
linkList) en la base de datos del estado a nadiendo la 6-tupla c, r, r
, c
, o, o
) a
la lista linkList. La funci on booleana isLinkInGen? comprueba que o y o
no
est an ya ligados mediante una instancia de la asociaci on dada o mediante una
instancia de una asociaci on en la que las clases c y c
jueguen debido a roles de

generalizaci on, respectivamente, los roles r y r
.
ceq state(attrs(
odb : ODB,
input : (insert-link_|_:_<->_:_|_<->_.[token[T1],
token[T2], token[T3], token[T4],
token[T5], token[T6], token[T7]]) ,
= state(attrs(
odb : insertLink(ODB, nameOD,
as(nameC1, nameR1, nameR2, nameC2),
nameO1, nameO2),
input : empty,
output : (OK: The link downQid(T6) <-> downQid(T7)
of the association downQid(T2) :
downQid(T3) <-> downQid(T4) : downQid(T5)
has been inserted .), Atts))
/\ isAssocInGen?(as(nameC1, nameR1, nameR2, nameC2),
getAssocList(reprCD),
getGeList(reprCD), getGeList(reprCD)) = true
/\ nameO1 := downQid(T6)
/\ isObjInGen?(cobj(nameC1, nameO1), getCoupleList(reprOD),
/\ nameO2 := downQid(T7)
/\ isObjInGen?(cobj(nameC2, nameO2), getCoupleList(reprOD),
/\ isLinkInGen?(as(nameC1, nameR1, nameR2, nameC2),
nameO1, nameO2,
getLinkList(reprOD), getGeList(reprCD),
getGeList(reprCD)) = false .
El comando (insert-attr-value onm : c : o : at : t -> v .) asigna
el valor v al atributo at de tipo t en el objeto o, que es una instancia de la
clase c. Est a implementado mediante la funci on insertAttrValue, que mo-
dica la 5-tupla objectDiagramName, classDiagramName, objectList, attribu-
teValueList, linkList) en la base de datos del estado reemplazando la 5-tupla
at , c, t, o, v
) que contiene attributeValueList con at , c, t, o, v), donde v
era el
valor previo del atributo (posiblemente el asignado por defecto). La funci on
booleana isValueInType? comprueba que v es un valor valido del tipo t.
ceq state(attrs(
odb : ODB,
input : (insert-attr-value_:_:_:_:_->_.[token[T1],
token[T2], token[T3], token[T4],
token[T5], token[T6]]),
= state(attrs(
odb : insertAttrValue(ODB,
downQid(T1), downQid(T2), downQid(T3), downQid(T4),
downQid(T5), downQid(T6)),
input : empty,
output : (OK: The attribute value downQid(T6) for
the attribute downQid(T4) has been
inserted in the object downQid(T3)
in the object diagram downQid(T1).), Atts))
/\ isClassIn?(nameC, getClassList(reprCD)) = true
/\ nameO := downQid(T3)
/\ isObjInGen?(cobj(nameC, nameO), getCoupleList(reprOD),
/\ nameA := downQid(T4)
/\ nameT := downQid(T5)
/\ isAtInGen?(at(nameA, nameC, nameT), getAtList(reprCD),
/\ nameV := downQid(T6)
/\ isValueInType?(nameV, nameT, getEnumClassList(reprCD)) = true .
Procesando los Comandos de Expresion
Podemos agrupar los comandos de expresi on declarados en el Cuadro 3.4
en las siguientes categoras: comandos que sirven para hacer consultas sobre
un diagrama, que insertan un invariante, que validan invariantes y que denen
operaciones. Para simplicar la presentacion, explicaremos el procesado de los
comandos de expresi on en el contexto de diagramas que no tienen asociadas
operaciones denidas por el usuario. En general, por supuesto, las operacio-
nes denidas por el usuario deben tenerse en cuenta cuando se procesan los
comandos de expresi on. ITP/OCL implementa la metodologa explicada en la
secci on 2.4 [Extensiones] para tratar con operaciones denidas por el usuario
que se utilizan en consultas, invariantes o en otras deniciones de operaciones.
Comandos para hacer consultas a un diagrama El comando (query-in
cnm : onm : expr .) pregunta el valor de la expresi on expr sobre el diagrama
de objetos onm que es instancia del diagrama de clases cnm. Est a implementado
mediante la funci on queryIn que usa la funci on predenida metaReduce sobre
la especicaci on ecuacional y el termino que devuelve la funci on interpret.
La funci on interpret implementa la funci on interpret (), esto es, la transfor-
maci on de los diagramas UMLMOVA con expresiones OCLMOVA a especicaciones
ecuacionales que se deni o en la secci on 2.3. Recordemos que expr es una bub-
ble, es decir, una lista arbitraria de tokens. Para obtener el argumento real de
la funci on interpret, la funci on predenida metaParse se llama para analizar
sint acticamente expr en el modulo generado por la funci on extOCLGrammar.
ceq state(attrs(odb : ODB, input : (query-in_:_:_.[token[T1],
token[T2], bubble[T3]]) ,
= state(attrs(odb : ODB,
input : empty,
output : queryIn(interpret("1.0", reprCD, reprOD,
getTerm(parsedBubble))),
Atts))
/\ nameOD := downQid(T2)
/\ parsedBubble := metaParse(extOCLGrammar(reprCD, reprOD),
downQidList(T3), anyType)
/\ isWellParsed?(parsedBubble) = true .
La funci on extOCLGrammar b asicamente genera el modulo que contiene la signa-
tura que corresponde a la gram atica denida para OCLMOVA en la secci on 2.2.3,
con diferencias menores debidas sobre todo a razones tecnicas
1
. En particu-
lar, las siguientes reglas adicionales se aplican cuando escribimos una expresi on
OCLMOVA en ITP/OCL:
1
Estas diferencias podran suprimirse mediante una denici on m as precisa de las bubbles y
tokens v alidos para ITP/OCL en el m odulo COMMANDSGRAMMAR, que no hemos hecho
por comodidad y por el car acter todava provisional de la implementaci on actual de tokens y
bubbles en Maude.
Para denotar la colecci on de objetos asociados al rol de un objeto, el usua-
rio debe prejar el smbolo # al nombre del rol. Cuando el rol est a aso-
ciado a un extremo de asociaci on que est a restringido por multiplicidad
<1>, el usuario debe tambien poner el smbolo @ posjo al nombre del
rol.
Para denotar el atributo de una clase, el usuario debe prejar el smbolo
# al nombre del atributo.
El usuario tambien ha de prejar el smbolo # a allInstances, oclIs-
KindOf, oclIsTypeOf y oclAsType.
El usuario debe insertar un espacio en blanco antes de cada token, a menos
que el car acter previo sea un parentesis.
Ejemplo 4. Tras cargar en ITP/OCL los diagramas TRAIN-WAGON y TRAIN-
WAGON-1 (vease Ejemplo 3), podemos usar el siguiente comando para preguntar
si en TRAIN-WAGON-1 los sucesores de un vag on pertenecen tambien al tren al
que este vag on pertenece.
(query-in TRAIN-WAGON : TRAIN-WAGON-1 :
(Wagon #allInstances)->forAll(w1:Wagon |
(w1:Wagon #succ)->notEmpty()
implies (w1:Wagon #succ)->forAll(w2:Wagon |
(w2:Wagon #train@ = w1:Wagon #train@))) .)
Cuando se procesa este comando, la funci on interpret traduce la consulta
al termino forAll@1(allInstances(Wagon)) y genera el interprete correspon-
diente, cuyas principales ecuaciones se muestran en Figura 3.1. Por tanto, la
funci on queryIn devuelve, en este caso, true, que es la forma can onica de
forAll@1(allInstances(Wagon)) en el interprete que genera interpret.
Comandos que insertan un invariante en un diagrama Estos son los
comandos:
(insert-invariant cnm :: expr .) y
(insert-invariant cnm : c : expr .)
Los invariantes introducidos por el usuario en un diagrama de clases se guar-
dan en una lista invariantList asociada al nombre del diagrama de clases. El
comando (insert-invariant cnm :: expr .) inserta la expresi on expr como
invariante en el diagrama de clases cnm. Est a implementada por la funci on
insertInvariant que modica la lista invariantList asociada al diagrama de
clases cnm a nadiendole a la lista invarianteList el termino que devuelve la fun-
cion predenida metaParse cuando es llamada para comprobar la sintaxis de
expr en el modulo generado por la funci on extOCLGrammar y tiene exito en la
comprobaci on.
eq ifThenElse(true, x, y) = x .
eq ifThenElse(false, x, y) = y .
eq notEmpty(nil) = false
eq notEmpty(col(x, xs)) = true .
eq allInstances(Train) = col(Train1, nil) .
eq allInstances(Wagon) = col(Wagon1, col(Wagon2, nil)) .
eq allInstances(FirstClassWagon) = nil .
eq equal(Train1, Train1) = true .
eq equal(Wagon1, Wagon1) = true .
eq equal(Wagon1, Wagon2) = false .
eq equal(Wagon2, Wagon1) = false .
eq type(Train1) = Monorail .
eq identifier(Train1) = HG340 .
eq wagon(Train1) = col(Wagon1, col(Wagon2, nil)) .
eq numberOfPassengers(Wagon1) = 80 .
eq smoking(Wagon1) = false .
eq pred(Wagon1) = col(Wagon2, nil) .
eq succ(Wagon1) = col(Wagon2, nil) .
eq train(Wagon1) = Train1 .
eq numberOfPassengers(Wagon2) = 80 .
eq smoking(Wagon2) = true .
eq pred(Wagon2) = col(Wagon1, nil) .
eq succ(Wagon2) = col(Wagon1, nil) .
eq train(Wagon2) = Train1 .
eq forAll@1(nil) = true .
eq forAll@1(col(x,xs)) =
ifThenElse(implies(notEmpty(succ(x)),
forAll@1.1(x, succ(x))),
forAll@1(xs),
false) .
eq forAll@1.1(x,nil) = true .
eq forAll@1.1(x, col(x, xs)) =
ifThenElse(equal(train(x), train(x)),
forAll@1.1(x, xs),
false) .
Figura 3.1: El interprete para una consulta (parcial).
ceq state(attrs(odb : ODB,
input :
(insert-invariant_::_.[token[T1], bubble[T3]]),
inv : IV,
inv : insertInvariant(IV, nameCD,
input : empty,
output : (OK: The invariant downQidList(T3)
class diagram downQid(T1)
.),
Atts))
/\ parsedBubble := metaParse(extOCLGrammar(reprCD),
El comando (insert-invariant cnm : c : expr .) inserta la expresi on expr
como invariante de la clase c en el diagrama de clases cnm. Est a implementada
tambien mediante la funci on insertInvariant. En este caso, sin embargo, el
termino a nadido a la lista invariantList asociada al diagrama de clases cnm es
el que devuelve la funci on metaParse cuando es llamada para analizar sint acti-
camente la expresi on
(c #allInstances)->forAll(self:c | expr)
en el modulo generado por la funci on extOCLGrammar.
input :
(insert-invariant_:_:_.[token[T1], token[T2],
bubble[T3]]),
inv : IV,
inv : insertInvariant(IV, nameCD,
input : empty,
output : (OK: The invariant downQidList(T3)
.),
Atts))
( downQid(T2) #allInstances ) ->forAll (
qid("self:" + string(downQid(T2))) |
replaceOCLTypes(downQidList(T3)) )
Comandos que validan invariantes El comando (check-invariants cnm
: onm .) devuelve el resultado de consultar sobre el diagrama de objetos onm
si cada invariante de la lista invarianteList asociada al diagrama de clases cnm
se cumple o no. Est a implementado llamando a la funci on queryIn sobre cada
uno de los elementos de invariantList.
Comandos que denen operaciones Son los comandos:
(insert-oper cnm : c(oper, t ) body.),
(insert-oper cnm : c(oper, t
1
t
n
,t ) body.),
(insert-oper cnm :: (oper, t ) body.) y
(insert-oper cnm ::(oper, t
1
t
n
,t ) body.)
Las operaciones denidas por el usuario en el contexto de un diagrama de
clases se guardan en una lista operationList asociada al nombre del diagrama
de clases. El comando mas general para denir operaciones es (insert-oper
cnm : c(oper, t
1
t
n
,t ) body.). Est a implementado mediante la funci on
insertOperation que modica la lista operationList asociada al diagrama de
clases cnm a nadiendo a operationList la signatura y la denici on de la operaci on
oper: la primera est a compuesta por su nombre oper, los tipos de sus argumentos
t
1
, . . . , t
n
, y su propio tipo t; y la ultima es el termino que devuelve metaParse
cuando se le pide analizar sint acticamente body en el modulo generado por la
funci on extOCLGrammar.
input :
(insert-oper_:_(_,_,_)_.[token[T1],
token[T2], token[T3],
neTokenList[T4], token[T5],
bubble[T6]])
ops : OP,
ops : insertOperation(OP, nameCD, downQid(T2),
downQid(T3), downQidList(T4),
downQid(T5),
input : empty,
output : (OK: The operation downQid(T3)
.),
Atts)
3.3. La Herramienta de Validacion ITP/OCL
La importancia clave de la validaci on y el testing en el desarrollo de sof-
tware han sido reconocidos desde hace mucho tiempo. Hay muchas formas de
encarar el problema de la validaci on: simulaci on, prototipado r apido, etc. En el
contexto del desarrollo de software dirigido por modelos, un modelo es validado
comprobando si ciertas instancias prototpicas del sistema, tambien llamadas
instant aneas (snapshots), realmente cumplen las restricciones del modelo. El
resultado puede tener distintas consecuencias para el dise no. Primero, si hay
instant aneas razonables (es decir, estados del sistema) que no satisfacen las res-
tricciones, esto podra indicar que las restricciones son demasiado fuertes o que
el modelo no es adecuado en general. Por tanto, el modelo debe revisarse, por
ejemplo, para relajar las restricciones. Por otro lado, las restricciones podran
ser excesivamente debiles y permitir instant aneas indeseables para el sistema.
En este caso, las restricciones deben cambiarse para ser mas restrictivas. A un
as, una situaci on en la que instant aneas indeseables se detectan e instant aneas
deseadas pasan todas las restricciones no permite realizar una asercion general
sobre la correccion de un modelo en el sentido formal. Tan solo permite decir
que el modelo es correcto con respecto a las instant aneas analizadas.
Existen varias herramientas CASE que facilitan el dibujo y la documentacion
de modelos UML. Sin embargo, existen muy pocas herramientas para realizar
la validaci on de modelos durante la etapa de dise no y menos cuando se incluyen
restricciones escritas en OCL. La importancia de OCL viene reconociendose
desde hace tiempo pero tan solo se hace un uso ocasional de especicaciones OCL
en aplicaciones reales, debido principalmente a que se carece de herramientas
apropiadas que soporten el lenguaje [CBC05a]. En la practica, los modeladores
solo usaran OCL si existe un soporte apropiado con herramientas: de otro modo,
el an alisis y la validaci on de modelos podra requerir incluso mas esfuerzo e
ingenio que la misma tarea de modelado en s. La herramienta ITP/OCL es parte
de un esfuerzo mas amplio para integrar la validaci on y el modelado riguroso
dentro del currculo de la ingeniera del software y del proceso de ingeniera del
software industrial. Aunque todava es una herramienta experimental, ITP/OCL
proporciona un soporte efectivo para la validaci on de modelos UMLMOVA con
3.3. La Herramienta de Validaci on ITP/OCL 89
invariantes OCLMOVA.
Ejemplo 5. Consideremos de nuevo el diagrama TRAIN-WAGON de la Figu-
ra 2.1. Recordemos que modela un sistema ferroviario simple: b asicamente un
tren puede tener vagones y los vagones pueden estar conectados a otros vagones
(sus predecesores y sucesores). Claramente, este modelo no captura todos los
requisitos del sistema: en particular, no especica las siguientes restricciones:
1. Un vag on y su sucesor deben pertenecer al mismo tren.
2. No existen dos vagones distintos ligados entre s de foma cclica.
Para renar el modelo, tras cargar el diagrama TRAIN-WAGON (vease el
Ejemplo 3), insertamos (1) y (2) como invariantes de las clases Train y Wagon.
La restricci on (1) se a nade al diagrama TRAIN-WAGON mediante el siguien-
te comando:
(insert-invariant TRAIN-WAGON : WAGON :
(self:Wagon #succ)->notEmpty()
implies (self:Wagon #succ)->forAll(w:Wagon |
(self:Wagon #train@ = w:Wagon #train@))) .)
Ahora especicamos la restricci on (2). Es util denir primero una opera-
ci on predPlus que devuelva todos los predecesores (no solo los inmediatos) de
un vag on dado. Aqu, predPlus se dene con la ayuda de otra operaci on auxiliar
predPlusOnBag que devuelve todos los predecesores (de nuevo, no solo los inme-
diatos) de una bolsa de vagones. Los comandos que denen estas operaciones
son los siguientes:
(insert-oper TRAIN-WAGON : Wagon
(predPlusOnBag, s:Bag(Wagon), Bag(Wagon))
if ((s:Bag(Wagon) ->collect(s1:Wagon | s1:Wagon #pred))
->exists(w:Wagon | s:Bag(Wagon) ->excludes(w:Wagon))
then (self:Wagon #predPlusOnBag(
s:Bag(Wagon) ->union(
s:Bag(Wagon)->collect(s2:wagon |s2:Wagon #pred)))
else s:Bag(Wagon) fi
(insert-oper TRAIN-WAGON : Wagon (predPlus, Bag(Wagon))
self:Wagon #predPlusOnBag(self:Wagon #pred) .)
Una vez que predPlus est a denida, la restricci on (2) se a nade al diagrama
TRAIN-WAGON mediante el siguiente comando:
(insert-invariant TRAIN-WAGON : Train :
(self:Train #wagon)->forAll(w:Wagon |
(w:Wagon #predPlus)->excludes(w:Wagon)) .)
Para validar que el modelo renado TRAIN-WAGON captura correctamente
(1) y (2), comprobamos los invariantes correspondientes sobre instant aneas tan-
to indeseables como aceptables del modelo: las primeras no deberan satisfacer
alguno de los invariantes, mientras que las ultimas deberan satisfacerlos todos.
Consideremos, por ejemplo, el diagrama TRAIN-WAGON-1 de la Figura 2.2. Es
una instancia indeseable de TRAIN-WAGON puesto que modela un estado del
sistema en el que hay dos vagones ligados de forma cclica. As, el comando
(check-invariant TRAIN-WAGON : TRAIN-WAGON-1 .)
devuelve la siguiente informaci on:
---------------------------------
invariant:(self:Train #wagon)->
forAll(w:Wagon |(w:Wagon #predPlus)->excludes(w:Wagon))
---------------------------------
checking .......... failed
+++++++++++++++++++++++++++++++++
---------------------------------
invariant:(self:Wagon #succ)->notEmpty()
implies(self:Wagon #succ)->forAll(w:Wagon |
(self:Wagon #train@)=(w:Wagon #train@))
---------------------------------
checking .......... ok
+++++++++++++++++++++++++++++++++
3.4. Trabajo Relacionado
Existen numerosas herramientas CASE que facilitan la construcci on y la
documentacion de diagramas UML (una lista representativa puede encontrar-
se en http://uml-directory.omg.org/vendor/list.htm). Sin embargo no es
tan amplio el abanico de herramientas que permiten validar modelos en la eta-
pa de dise no y a un menos aquellas que admiten la validaci on de restricciones
OCL. Los esfuerzos mas signicativos en este campo son: el Dresden Toolkit 2.0
Parser [Kon05], que puede analizar sint acticamente y comprobar los tipos de
expresiones OCL teniendo en cuenta los tipos del modelo; HOL-OCL [BW07]
y la herramienta KeY [ABB
+
05, BHS07], que son demostradores interactivos
preparados para probar si la especicaci on denida por un modelo que est a res-
tringida por expresiones OCL es satisfactible; y las herramientas USE [Gro06]
y RoclET [BM07], que como ITP/OCL son evaluadores de expresiones OCL
2
.
La herramienta USE recibe como entrada una descripcion textual de un modelo
y sus restricciones en OCL. Los objetos y enlaces pueden entonces ser creados
2
Otra herramienta interesante en esta lnea es OCLE [CBC
+
05b], un evaluador desarrollado
en el Laboratorul de Cercetare in Informatica (Universidad de Babes-Bolyai); sin embargo,
OCLE no se desarrolla de una manera planicada desde enero de 2003 (Comunicaci on personal
con Dan Chiorean, jefe del proyecto de OCLE.)
3.4. Trabajo Relacionado 91
gracamente. En cada estado del sistema, las restricciones pueden ser compro-
badas autom aticamente. La herramienta RoclET es un plugin para Eclipse.
Proporciona editores gracos para dibujar diagramas UML de clase y objetos,
un analizador sint actico, de tipos y un evaluador para restricciones OCL que
esten anotadas sobre el modelo. La semantica subyacente de ITP/OCL, basada
en reescritura, es muy diferente de las de USE [Ric02, GBR07]. Finalmente,
existen tambien diferencias en terminos de eciencia. El Cuadro 3.5 muestra el
tiempo (en segundos) que consumen USE e ITP/OCL para validar restricciones
sobre un diagrama de objetos, TRAINWAGON-10x100, que es una instancia del
diagrama de clases TRAINWAGON. Este diagrama de objetos contiene 10 trenes
y 1000 vagones, cada tren tiene 100 vagones propios, que est an ligados de la
forma esperada; cada vagon tiene un predecesor y un sucesor, excepto el primer
y el ultimo vagon. Incluimos en esta comparaci on unicamente la herramienta
USE porque USE es, por el momento, la unica otra herramienta de evaluaci on
de OCL con una semantica formal publicada. La semantica subyacente de IT-
P/OCL, basada en la l ogica ecuacional, es muy diferente sin embargo de la
de USE [Ric02], basada en teora de grafos. Ademas, a diferencia de USE, la
implementacion de ITP/OCL se basa directamente en su semantica formal sub-
yacente: es decir, la evaluaci on de las expresiones se realiza de hecho mediante
reescritura de terminos. Sin embargo, a pesar de tratarse de una implemen-
tacion directa, en un lenguaje de programacion declarativo como Maude, su
eciencia es comparable a la de USE en escenarios no triviales. El Cuadro 3.5
recoge los tiempos de evaluaci on para ambas herramientas. Hemos considerado
las siguientes restricciones:
Todos los trenes tienen al menos un vag on.
context Train inv atLeastOnewagon:
self.wagon size() >= 1
Un vag on y su sucesor pertenecen al mismo tren.
context Wagon inv belongToTheSameTrain:
self.succ>notEmpty() implies
self.succ>forAll(w [
w.train = self.train)
Todos los trenes tienen el mismo n umero de vagones.
context Train inv sameNumberOfWagons:
Train.allInstances>forAll(t1 [
(self <> t1 implies
(self.wagon>size() = t1.wagon>size()))
No existen dos vagones diferentes ligados entre s de foma cclica.
context Wagon inv notInCyclicWay:
not(Wagon.allInstances>exists(w1 [
self <> w1
TRAINWAGON-10x100 USE ITP/OCL
atLeastOnewagon 2s 1s
belongToTheSameTrain 4s 2s
sameNumberOfWagons 3s 2s
notInCyclicWay 27s 8s
Cuadro 3.5: Tiempos de Validaci on.
and (self.succ)>includes(w1)
and (w1.succ)>includes(succ)))
El diagrama de objetos TRAINWAGON-10x100 satisface nuestras cuatro res-
tricciones. Las comparaciones se han realizado en un port atil con un procesa-
dor Pentium a 1.7GHz y 1 GB RAM. Como se esperaba, validar la restricci on
notInCyclicWay consume mas tiempo, dado que, esencialmente, tiene que hacer
100 100 comparaciones.
La herramienta ITP/OCL es, en cualquier caso, un prototipo: no cabe es-
perar, tanto por el dise no reexivo de la herramienta, como por las propias
caractersticas del sistema Maude, que sus tiempos de ejecuci on sean competi-
tivos cuando se trate de evaluar expresiones OCL sobre escenarios con cientos
de miles de objetos y enlaces [CED08b]. Para estas aplicaciones, es conveniente
implementar (ya de forma menos directa) la semantica formal propuesta en el
captulo 2 utilizando otros lenguajes de programacin [CED08a].
Por ultimo, la implementacion en Maude del trabajo de Boronat [Bor07], sir-
ve de base para una herramienta formal de transformaci on de modelos llamada
MOMENT (A framework for MOdel ManagemENT) [CRBG08], que actualmen-
te consta de tres aplicacion: MOMENT Case, que es un marco de modelado que
da soporte al metamodelo de UML2 y a un metamodelo relacional; MOMENT
QVT, que es un prototipo que maneja el lenguaje relacional QVT; y y MO-
MENT OCL, que es una herramienta que proporciona evaluaci on de consultas
OCL. Como el evaluador MOMENT OCL se apoya directamente en el trabajo
de [Bor07], referimos al lector a la secci on 2.4 donde realizamos una compara-
cion detallada con ese trabajo. Desde un punto de vista mas tecnico, MOMENT
est a integrado en la plataforma Eclipse. y utiliza analizador sint actico y de ti-
pos que proporciona la herramienta KMF. De acuerdo con la informacion que
tenemos, la herramienta MOMENT no est a todava disponible en [CRBG08].
Captulo 4
Aplicaciones de OCL al
Analisis de Modelos
93
94 Captulo 4. Aplicaciones de OCL al An alisis de Modelos
En este captulo proponemos una metodologa basada en metamodelos para
analizar el signicado de los diagramas usando el lenguaje OCL. El problema
general que acometemos es el siguiente. Algunos lenguajes de modelado explican
el signicado de sus diagramas usando lenguaje natural. Por supuesto, en esta
situaci on, analizar los modelos dibujados en los diagramas solo puede hacerse
de modo informal y no cabe esperar ning un soporte riguroso por parte de herra-
mientas. Otros lenguajes de modelado explican el signicado de los diagramas
usando una sem antica formal : esto es, denen una funci on de interpretaci on []
que asocia estructuras matematicas [M] a diagramas bien formados M. Esto
es de hecho lo que hicimos en el Captulo 2 para el caso de diagramas de clase
UML con restricciones OCL. En general, dado un lenguaje de modelado con una
semantica formal, uno puede razonar sobre sus diagramas utilizando los signi-
cados proporcionados por la semantica del lenguaje. Un modelo dibujado en
un diagrama M tiene una propiedad P (expresada como una formula en alg un
lenguaje l ogico) si y solo si [M] [= P. Aunque esta metodologa es est andar,
requiere maquinaria deductiva para razonar sobre la semantica de los diagra-
mas, lo cual tpicamente no puede hacerse autom aticamente. Esto constituye un
requisito exigente y un obst aculo para muchas aplicaciones practicas. Nuestra
metodologa basada en metamodelos reduce deducci on a evaluaci on. En pocas
palabras, expresamos las propiedades deseadas como consultas OCL y evalua-
mos estas consultas sobre las instancias del metamodelo que corresponden a los
diagramas bajo consideracion. Desde un punto de vista practico, la metodologa
descrita en este captulo tiene una aplicaci on directa en la fase de dise no para la
deteccion temprana de errores en un sistema de desarrollo de software basado
en modelos, especcamente en el caso de sistemas que incorporen polticas de
seguridad, tal y como se discutir a en el captulo 5.
El captulo est a organizado como sigue. Primero, claricamos la metateora
requerida para que realizar la evaluaci on de consultas este formalmente bien
denida. Esto requiere, en particular, deniciones precisas del metamodelo del
lenguaje de modelado y la transformaci on de los diagramas a las correspon-
dientes instancias de este metamodelo. Como veremos, ser explcito sobre los
metamodelos y las transformaciones usadas requiere una considerable atenci on
al detalle. Sin embargo, el benecio que se obtiene es substancial: los diagra-
mas pueden analizarse autom aticamente de una forma semanticamente precisa.
Segundo, mostramos la viabilidad de este enfoque aplic andolo a un ejemplo no
trivial: un lenguaje de modelado de dise no con seguridad tomado de [BDL06],
que combina SecureUML con un lenguaje de modelado de componentes llamado
ComponentUML. Tercero, demostramos que las expresiones OCL pueden usarse
para formalizar y comprobar propiedades de seguridad no triviales de modelos
de dise no con seguridad. Damos algunos ejemplos que ilustran la expresividad
de esta metodologa para razonar sobre propiedades que dependen de la poltica
de control de acceso que se haya modelado. Finalmente, presentamos una ex-
tensi on de la herramienta basada en reescritura presentada en el Captulo 3 que
implementa nuestro metodo. Todos los ejemplos presentados en este captulo se
han comprobado usando esta herramienta. La idea de formular consultas OCL
sobre polticas de control de acceso no es nueva. Nuestro trabajo est a inspirado
4.1. Una Metodologa Basada en Metamodelos 95
por [AS01, SAGM05], que exploraron en primer lugar el uso de OCL para con-
sultar polticas RBAC; comentaremos las diferencias con nuestro trabajo en la
secci on concluyente. A lo largo del captulo usaremos con frecuencia los terminos
diagrama y modelo indistintamente.
4.1. Una Metodologa Basada en Metamodelos
Un lenguaje de modelado proporciona un vocabulario (conceptos y relacio-
nes) para construir modelos, a la vez que notaci on para representarlos graca-
mente como diagramas. Con frecuencia, el lenguaje de modelado tambien pro-
porciona un vocabulario para describir instancias de modelos (tambien llamadas
instant aneas), junto con notaci on para representarlas gracamente. Los dia-
gramas que dibujan modelos (o instancias de modelos) deben ser conformes al
metamodelo del lenguaje de modelado. Un metamodelo es un diagrama cuyos
elementos formalizan los conceptos y relaciones proporcionados por el lenguaje
de modelado y cuyos invariantes, normalmente escritos en OCL, especican res-
tricciones que los modelos y las instancias de los metamodelos han de cumplir
para estar bien formados.
Para dar una descripcion mas detallada de nuestro enfoque para analizar
modelos basado en metamodelos, revisaremos primero los elementos implicados
en la utilizaci on de OCL para realizar consultas sobre los modelos represen-
tados diagram aticamente. Consideremos la organizaci on en cuatro capas de la
arquitectura de UML representada en la Figura 4.1.
Como lenguaje de consulta, OCL puede usarse para analizar una instancia
de un modelo en el nivel M0, usando los tipos y el vocabulario introducido
por el modelo al nivel M1. Los tipos corresponden a las clases en el mode-
lo y el vocabulario corresponde a las propiedades (atributos, roles y opera-
ciones) declarados para estas clases. Por ejemplo, en OCL se puede pregun-
tar por el n umero de personas (Person.allInstances()>size()) o por el nombre
de una persona como Mike (Mike.name). Dado que los metamodelos son tam-
bien modelos, OCL puede usarse tambien para consultar los modelos en el nivel
M1, usando los tipos y el vocabulario introducido por su metamodelo al nivel
M2. Por ejemplo, en OCL se puede preguntar por todas las clases del modelo
(Class.allInstances()) o por el n umero de atributos que posee una clase particular
como Person (Person.ownedAttribute>size()).
Una observaci on crucial es que, aunque las expresiones OCL hablan sobre
instancias de (meta)modelos, son de hecho evaluadas sobre las representaciones
de estas instancias; la idea es que, en estas representaciones, el signicado de
los tipos y el vocabulario introducido por los (meta)modelos nunca es ambiguo.
Consideremos la expresi on Person.ownedAttribute. Cual es el signicado preten-
dido de la propiedad ownedAttribute? Incluye tambien el conjunto de atributos
que posee la clase heredados de sus superclases o solamente aquellos que se
declaran explcitamente en ella?
1
. Cualquiera que sea la manera elegida para
1
En principio, estas dos deniciones son posibles para la propiedad ownedAttribute. De
Figura 4.1: La Arquitectura en Cuatro Capas de UML.
representar los modelos UML como instancias del metamodelo de UML, esta
tiene que proporcionar una interpretaci on no ambigua de ownedAttribute a la vez
que el resto del vocabulario introducido por el metamodelo de UML. En UML,
la forma est andar de representar instancias de (meta)modelos es a traves de
diagramas de objetos. En lo que sigue, denotaremos como modelos gr acos los
modelos M que el modelador ve y con los que trabaja, y como modelos abstrac-
tos M los diagramas de objetos que representan los modelos M como instancias
del metamodelo.
Ahora podemos dar una descripcion mas precisa de nuestra metodologa
basada en metamodelos. Sea un lenguaje de modelado /. Para analizar las
propiedades de los modelos (y de las instancias de los modelos) M, primero
formalizamos las propiedades deseadas como consultas OCL usando los tipos y
el vocabulario que proporciona el metamodelo /, y entonces evaluamos estas
consultas sobre las instant aneas correspondientes M del metamodelo de /.
Para que esta metodologa tenga sentido, requeriremos que la transformaci on
que relaciona los modelos gracos M con los modelos abstractos M, junto con
la evaluaci on de las expresiones OCL, interact ue correctamente con la funci on
de interpretaci on []: es decir, si f es una funci on sobre el dominio semantico y
exp
f
es una expresi on que pretende formalizar f en OCL, requeriremos que el
siguiente diagrama conmute:
hecho, [UML07] tiene que claricar que la referencia de la propiedad ownedAttribute no
incluye atributos heredados.
4.1. Una Metodologa Basada en Metamodelos 97
modelo modelo dominio
abstracto graco semantico
M M [M]

ev(exp
f
, M) f([M])
En este diagrama, la echa que baja en la parte de la izquierda denota la evalua-
cion de la expresi on OCL exp
f
, el resultado del cual es denotado por la funci on
ev(, ). La echa que baja en la parte de la derecha corresponde a la evaluaci on
de la funci on f en el dominio semantico. El requisito de correccion dice que la
expresi on OCL exp
f
puede usarse para analizar el comportamiento de f si y so-
lo si [ev(exp
f
, M)] = f([M]). En sntesis, esto signica que una expresi on OCL
puede usarse correctamente para comprobar una propiedad P si y solo si, para
modelos arbitrarios (o instancias de los modelos) M, el resultado de evaluar esta
expresi on sobre M corresponde al valor de la propiedad P en [M]. Probar rigu-
rosamente esta correspondencia requiere de un meta-razonamiento complejo y
arduo que implica la semantica del sistema formal elegido, la semantica formal
de OCL, las transformaciones de los modelos gracos a los modelos abstractos
y a su interpretaci on semantica, y la denici on completa de la traducci on des-
de los terminos del dominio semantico a las expresiones OCL. Sin embargo, en
muchos casos practicos, para justicar la correccion de nuestra metodologa ba-
sada en metamodelos es suciente con proporcionar una denici on precisa del
metamodelo del lenguaje de modelado y de la transformaci on subyaciente de
sus modelos gracos a los modelos abstractos. De hecho, en este trabajo hemos
optado por hacer esto ultimo y, en consecuencia, hemos proporcionado en las
secciones 4.2.1 y 4.2.3 y en el apendice B las deniciones precisas del meta-
modelo de nuestro lenguaje de modelado y de las transformaciones de modelos
gracos a instancias del metamodelo.
Nuestra metodologa basada en metamodelos tiene un varias ventajas sobre
metodos deductivos mas tradicionales. Primero, el metamodelo de un lenguaje
de modelado est a siempre bien denido y debera ser conocido por los modelado-
res. Por tanto, para analizar sus modelos, los modeladores no necesitan aprender
nuevos conceptos y relaciones (no est andares). En su lugar, pueden usar el mis-
mo lenguaje que usan para modelar su sistema. Segundo, OCL est a denido
como un lenguaje formal est andar a nadido a UML. Como se dice en [WK03],
OCL debera ser facilmente ledo y escrito por todos los que hacen tecnologa
de objetos y por sus clientes, es decir, gente que no son matematicos o cientcos
de la computacion. Por tanto, el an alisis de los modelos podran llevarlo a cabo
aquellos que los construyen, y no s olo aquellos ingenieros de vericaci on que
tienen un conocimiento l ogico y matematico avanzado. Para nalizar, existen
ya herramientas que pueden evaluar autom aticamente expresiones OCL, como
la herramienta basada en reescritura ITP/OCL que presentamos en el captu-
lo 3. Por tanto, los modeladores podran usar tecnologas push-button, que
est an ya disponibles en el ambito academico y en el industrial. Las limitaciones
de nuestro metodo son tambien claras: puede haber propiedades interesantes
que no puedan expresarse de modo natural en OCL o que no puedan probarse
simplemente evaluando estas expresiones sobre instant aneas seleccionadas.
4.2. Modelos de dise no con seguridad
SecureUML [BDL06] es un lenguaje de modelado de seguridad, que est a muy
relacionado con el Control de Acceso Basado en Roles (RBAC) [FSG
+
01]. Secu-
reUML puede combinarse (tanto sint actica como semanticamente) con diferen-
tes lenguajes de dise no, para crear lenguajes que permitan formalizar modelos
de dise no con seguridad, esto es, modelos que especican dise nos de sistemas
teniendo en cuenta en estos dise nos tambien los requisitos de seguridad. La
preocupaci on principal en [BDL06] estaba en la denici on del lenguaje y en
la generaci on de infraestructuras de control de acceso a partir de los modelos
de dise no con seguridad. En particular, aunque la semantica formal para Secu-
reUML se deni o ya en [BDL06], no se propuso entonces ning un metodo para
formalizar y analizar mec anicamente las propiedades de seguridad de los mode-
los de dise no con seguridad. En esta secci on mostraremos que tales propiedades
pueden expresarse como formulas en OCL y que pueden evaluarse, de modo
completamente autom atico, en el contexto del metamodelo del lenguaje para
denir modelos de dise no con seguridad. Demostraremos ademas, a traves de
ejemplos, que este metodo puede usarse para formalizar y comprobar propie-
dades de seguridad no triviales. Por ultimo, este metodo ha sido implementado
en la herramienta ITP/OCL+S, una extensi on de ITP/OCL; de hecho todos los
ejemplos presentados se han comprobado usando esta herramienta.
4.2.1. SecureUML y sus Dialectos
El lenguaje de Control de Acceso Basado en Roles (RBAC) [FSG
+
01] es
un lenguaje para formalizar requisitos de control de acceso. En RBAC los per-
misos especican los roles que tienen permiso para realizar ciertas operaciones.
Estos roles representan tpicamente funciones de trabajo dentro de una orga-
nizaci on. Los usuarios adquieren permisos mediante su asignaci on a los roles
apropiados, basados en sus competencias y responsabilidades en la organiza-
cion. RBAC permite adicionalmente que los roles puedan organizarse seg un una
jerarqua a traves de la cual pueden heredar permisos. De este modo, la poltica
de seguridad puede describirse en terminos de la estructura jerarquica de una
organizaci on. Sin embargo, no es posible especicar polticas que dependan de
las propiedades dinamicas del estado del sistema, por ejemplo, permitir una
operaci on unicamente durante los das laborables.
SecureUML [BDL06] extiende RBAC con restricciones de autorizaci on para
resolver esta limitaci on. Puede usarse, por tanto, para formalizar decisiones de
control de acceso que dependen de dos clases de informacion:
1. decisiones de control de acceso declarativas que dependen de informacion
est atica, es decir, de las asignaciones de usuarios y permisos a roles; y
4.2. Modelos de dise no con seguridad 99
2. decisiones de control de acceso program atico que dependen de informacion
dinamica, es decir, de la satisfacci on de las restricciones de autorizaci on
en el estado actual del sistema.
M as concretamente, SecureUML proporciona un lenguaje para modelar ro-
les (roles), permisos (permissions), acciones (actions) (at omicas (atomic) y
compuestas (composite)), recursos (resources), y restricciones de autorizaci on
(authorization constraints), junto con sus asignaciones (assignments), es de-
cir, que permisos est an asignados a que roles, que acciones est an asignadas a
que permisos, que recursos est an asignados a que acciones, y que restricciones
est an asignadas a que permisos. La Figura 4.2 muestra el metamodelo de Secu-
reUML. La lista completa de invariantes del metamodelo de SecureUML viene
dado en el Apendice B. Es especialmente interesante que SecureUML deja ines-
pecicado cu ales son recursos protegidos y cu ales son las acciones que estos ofre-
cen a los clientes. Ambos tendran que ser especicados en los llamados dialectos
y dependender an de los constructores primitivos de los lenguajes de modela-
do de dise no subyacentes en cada caso. Aqu consideraremos ComponentUML,
un lenguaje simple para el modelado de sistemas basados en componentes que,
esencialmente, proporciona un subconjunto de modelos de clases UML. Las enti-
dades (entities) pueden estar relacionadas mediante asociaciones (associations)
y pueden tener atributos (attributes) y metodos (methods). El metamodelo de
ComponentUML est a representado en la parte marcada de la Figura 4.3, a la
derecha.
La conexion entre SecureUML y el lenguaje de modelado de dise no lo pro-
porciona el metamodelo del dialecto. En concreto, un metamodelo de dialecto
especica:
1. Los tipos de elementos del lenguaje de modelado de dise no que represen-
tan recursos protegidos. Estos tipos de elementos est an modelados como
especializaciones de la clase Resource.
2. Las acciones que estos tipos de recursos ofrecen y las jerarquas que clasi-
can estas acciones. Esto se realiza en dos etapas: primero, introduciendo
los diferentes tipos de acciones como especializaciones de las clases Com-
positeAction y AtomicAction; y segundo, a nadiendo invariantes al meta-
modelo para restringir que recursos son accesibles desde las acciones y
que acciones est an subordinadas a que acciones compuestas.
3. La poltica de control de acceso por defecto para las acciones para las que
no esten denidos permisos de forma explcita. Esto se realiza especican-
do si el rol por defecto posee el permiso por defecto (ambos se distinguen
porque el valor de su atributo default es true). La existencia de un permiso
por defecto, al que solo puede asign arsele el rol por defecto y cuya restric-
cion de autorizaci on se satisface siempre, es garantizada por los siguientes
invariantes del metamodelo de SecureUML:
context Permission
inv existsADefaultPermission:
Permission.allInstances()>select(p[p.default)>size() = 1
inv defaultPermissionAssignedToDefaultRole:
self.default implies
self.givesaccess>forAll(r[r.default)
inv constraintByTrue:
self.default implies self.isconstraintby.body = true
El metamodelo de SecureUML+ ComponentUML se compone del metamo-
delo que se muestra en la Figura 4.3 junto con el resto del metamodelo de
SecureUML que se muestra en la Figura 4.2. Con la ayuda de los invariantes
OCL listados en el Apendice B se especica en este metamodelo que para el
dialecto SecureUML+ ComponentUML:
1. Los recursos protegidos son las entidades (entities), as como sus atributos
(attributes), metodos (methods), y extremos de asociaci on (association-
Ends) (pero no las asociaciones (associations) como tales).
2. Las acciones ofrecidas por estos recursos protegidos son aquellas mostradas
en la siguiente tabla. Las acciones que aparecen subrayadas son acciones
compuestas.
Recursos Acciones
Entidades create (crear), read (leer),
update (modicar), delete (borrar),
full access (acceso completo).
Atributos read, update, full access
Metodos execute (ejecutar)
Estremos de asociaci on read, update, full access
Para especicar estas restricciones los invariantes del dialecto del meta-
modelo incluyen, por ejemplo, las siguientes restricciones, que garantizan
que las acciones AttributeFullAccess act uan sobre Attributes y contienen
las acciones de lectura y de actualizacion sobre los atributos correspon-
dientes.
context AttributeFullAccess
inv targetsAnAttribute:
self.resource.oclIsTypeOf(Attribute)
inv containsSubactions:
self.subordinatedactions = self.resource.action
>select(a[a.oclIsTypeOf(AtomicUpdate))
>union(self.resource.action
>select(a[a.oclIsTypeOf(AtomicRead)))
3. El acceso se permite por defecto. Para especicar esta poltica de acceso
por defecto, los invariantes del dialecto del metamodelo incluyen la si-
guiente restricci on que dice que el rol por defecto tiene el permiso por
defecto.
Figura 4.2: Metamodelo de SecureUML.
Figura 4.3: Metamodelo del Dialecto para ComponentUML.
context Role
inv defaultAccess:
self.default implies
self.haspermission>exists(p[p.default)
4.2.2. Diagramas SecureUML
Para ilustrar la sintaxis concreta de SecureUML+Component UML, usamos
un sistema simple de gesti on de reuniones (meetings) como ejemplo gua. Una
reunion tiene un propietario (owner), una lista de participantes (participants),
una fecha y un tiempo asignados. Los usuarios pueden llevar a cabo operaciones
est andar con el gestor de reuniones, como crear, leer, editar y borrar reuniones.
Un usuario puede tambien cancelar una reunion, lo cual la borra y notica su
cancelacion a todos los participantes por correo electronico. El sistema debe
implementar la poltica de seguridad que se describe (informalmente) a conti-
nuaci on:
Todos los usuarios del sistema pueden crear nuevas reuniones y leer todos
los datos de las reuniones gestionadas por el sistema.
El propietario de una reunion puede cambiar los datos de la reunion,
cancelarla o borrarla.
Un supervisor puede cancelar cualquier reunion.
Un administrador del sistema puede leer los datos de las reuniones gestio-
nadas por el sistema y gestionar los usuarios dados de alta en el sistema.
Figura 4.4: Ejemplo de Poltica de Seguridad.
Un supervisor (pero no un administrador del sistema) es tambien un usua-
rio del sistema.
La Figura 4.4 formaliza esta poltica de seguridad usando el perl (prole
2
) de
UML para SecureUML y ComponentUML denido en [BDL06].
Un rol se representa mediante una clase UML con el estereotipo ((Role)) y
una relacion de herencia entre dos roles se dene utilizando una relacion de ge-
neralizaci on de UML. El rol referenciado por la cabeza de la echa de la relacion
de generalizaci on se considera el superrol del rol referenciado por la cola de la
echa. Un permiso junto con sus relaciones a roles y acciones, se dene utilizan-
do un unico elemento UML: a saber, una clase de asociaci on con el estereotipo
((Permission)). La clase de asociaci on conecta un rol con una clase UML, que es
designado como el recurso raz (root resource) del permiso. Las acciones a las
que se reere tal permiso pueden ser acciones sobre el recurso raz o sobre los
subrecursos del recurso raz. Cada atributo de la clase de asociaci on representa
la asignaci on de una accion al permiso, donde la accion est a identicada por el
nombre y el tipo del atributo. Los estereotipos para estos atributos de permisos
especican a que tipo de accion se reere este atributo y est an denidos como
parte del dialecto. El estereotipo ((entityaction)), por ejemplo, especica que un
atributo de permiso se reere a una accion sobre una entidad. El nombre de un
atributo de un permiso especica el nombre de la entidad, atributo, metodo o
2
De acuerdo con la especicaci on de UML, un perl dene extensiones limitadas a un me-
tamodelo de referencia con el objetivo de adaptar el metamodelo a una plataforma o dominio
especco [UML07].
extremo de asociaci on con el que se relaciona este permiso. El tipo del atributo
del permiso especica la accion (por ejemplo, leer, actualizar o acceso comple-
to) que permite este permiso. Las expresiones que restringen la autorizaci on se
adjuntan a las clases de asociaci on de los permisos.
Las entidades de ComponentUML est an representadas mediante clases UML
con el estereotipo ((Entity)). Cada metodo, atributo o extremo de asociaci on que
posea una clase es autom aticamente considerado como un metodo, atributo o
extremo de asociaci on de la entidad.
4.2.3. Diagramas SecureUML como Instancias del Meta-
modelo
Recordemos que en nuestro enfoque la especicaci on de polticas de seguri-
dad usando OCL depende directamente de la transformaci on de los modelos a
instancias del metamodelo. Esto es as porque las expresiones que formalizan
las propiedades no se evaluar an sobre los modelos gracos sino sobre sus corres-
pondientes modelos abstractos. Por supuesto, la transformaci on debe satisfacer
la siguiente propiedad: si M es un modelo graco bien formado, entonces M es
un modelo abstracto que satisface todos los invariantes del metamodelo. En lo
que sigue nombraremos a los objetos creados por la transformaci on siguiendo
las siguientes convenciones:
Los objetos que representan usuarios, roles, permisos y entidades se nom-
bran mediante su nombre en el modelo graco. Por ejemplo, el objeto
que representa al rol SystemUser como una instancia de la clase Rol es
nombrado tambien SystemUser en el modelo abstracto.
Los objetos que representan acciones son nombrados mediante el nombre
del recurso sobre el que act uan seguido por su tipo. Por ejemplo, el obje-
to que representa una accion de actualizacion atomica que act ua sobre el
atributo start de la entidad Meeting se nombra MeetingstartAtomicUpda-
te.
La denici on completa de la transformaci on de los modelos gracos de Secu-
reUML+ComponentUML a sus correspondientes modelos abstractos viene dada
en el Apendice B. Hasta cierto punto, esta transformaci on es directa: los ele-
mentos del modelo UML con los estereotipos apropiados son transformados a
instancias de los elementos del metamodelo correspondientes y las asociaciones
entre los elementos del modelo UML son transformados a enlaces entre las ins-
tancias de los correspondientes elementos del metamodelo. Por ejemplo, cada
rol en un diagrama es representado por medio de un objeto de la clase Rol en
la correspondiente instancia del metamodelo.
En algunos casos, sin embargo, la transformaci on es menos directa. En ta-
les casos, dar explcitamente la transformaci on es absolutamente necesario para
evitar interpretaciones incorrectas o ambiguas y para garantizar que los mo-
delos abstractos resultantes cumplir an los invariantes del metamodelo. Esto es
Figura 4.5: Ejemplo de Modelo Abstracto.
particularmente importante cuando la notaci on proporciona al modelador cier-
tas abreviaciones convenientes. A continuaci on, describimos las caractersticas
menos inmediatas de esta transformaci on. Ademas, para ilustrar el resultado de
nuestra transformaci on, en la Figura 4.5 mostramos la instancia del metamo-
delo que corresponde a un modelo graco que incluye unicamente una entidad
Meeting, con un solo atributo start, y un rol SystemAdministrator.
Sea M un modelo SecureUML+ComponentUML, entonces la transformaci on
construye una instancia M que contiene (entre otros) los siguientes elementos.
Primero, la transformaci on crea objetos unicos por defecto del tipo Role, Autho-
rizationConstraint y Permission, con ciertas propiedades especcas. Notemos
que los roles, las restricciones de autorizaci on y los permisos por defecto no est an
representados en M. Por ejemplo, el rol por defecto que crea la transformaci on
es asignado a todo usuario que se dibuje en M, y es declarado superrol de todo
otro rol que se dibuje en M. Como resultado, se garantiza que los siguientes
invariantes del metamodelo de SecureUML se cumplen en M:
context Role
inv existsADefaultRole:
self.allInstances()>select(r[r.default)>size() = 1
inv allRolesInheritFromDefaultRole:
self.superrolePlus()>exists(r[r.default)
context User
inv allUsersAssignedDefaultRole:
self.hasrole>exists(r[r.default)
An alogamente, el objeto por defecto del tipo AuthorizationConstraint creado
por la transformaci on tiene el valor true como valor de su atributo body. La
transformaci on tambien crea enlaces entre los objetos por defecto del tipo Rol,
AuthorizationConstraint y Permission, y entre el objeto por defecto del tipo
Permission y los objetos de los subtipos de Action. Por ejemplo, la transfor-
maci on crea un enlace de ConstraintAssignment entre la restricci on de auto-
rizacion y el permiso por defecto, as como un enlace PermissionAssignment
entre el permiso por defecto y el rol por defecto. Como resultado, se garantiza
(parcialmente) que los invariantes del metamodelo de SecureUML defaultPer-
missionAssignedToDefaultRole y constraintByTrue, antes discutidas, se cumplen
en M. A continuaci on, la transformaci on crea objetos de los subtipos de Action
que corresponden a las acciones que ofrecen los recursos, y enlaces entre estos
objetos y los objetos correspondientes de los subtipos de Resource.
Notemos que se crean objetos para todas las posibles acciones, no solo para
aquellas mencionadas en los atributos de los permisos dibujados en M. Para
ilustrarlo consideremos el modelo de la Figura 4.4. Los objetos creados duran-
te la transformaci on representar an las acciones de leer o actualizar el atributo
name de la entidad Person, as como la composici on de estas dos acciones, aun-
que ninguna de estas acciones aparece explcitamente referenciada por ning un
permiso en la Figura 4.4; ademas, la transformaci on crea los enlaces correspon-
dientes a la asociaci on ResourceAssignment entre estos objetos y el objeto que
representa el atributo name. Como resultado, se garantiza el cumplimiento en
M, para el atributo name, del siguiente invariante del metamodelo; este inva-
riante formaliza las acciones denidas en SecureUML+ComponentUML sobre
los atributos de las entidades:
context Attribute inv areAccessedBy:
self.action>size() = 3 and
self.action>exists(a[
a.oclIsTypeOf(AttributeFullAccess)) and
self.action>exists(a[a.oclIsTypeOf(AtomicRead)) and
self.action>exists(a[a.oclIsTypeOf(AtomicUpdate))
Finalmente, la transformaci on crea enlaces entre los objetos del tipo Atomi-
cAction y los objetos correspondientes del tipo CompositeAction. Por ejemplo, la
transformaci on para el modelo de la Figura 4.4 crea un enlace ActionHierarchy-
link entre el objeto del tipo CompositeAction que representa la accion de lectura
de la entidad Person y el objeto del tipo AtomicAction que representa la accion
de lectura de su atributo name. Como resultado, se garantiza (parcialmente) que
el siguiente invariante del metamodelo, que formaliza parte de la jerarqua de
acciones denidas en SecureUML+ComponentUML, se cumple, para la entidad
Person, para la jerarqua de acciones denida en SecureUML+ComponentUML
en la instancia M:
context EntityRead inv containsSubactions:
self.subordinatedactions =
self.resource.oclAsType(Entity).hasattribute.action
>select(a[a.oclIsTypeOf(AtomicRead))
>union(self.resource.oclAsType(Entity)
.hasassociationend.action
>union(self.resource.oclAsType(Entity).hasmethod
>select(me[me.isQuery).action
>select(a[a.oclIsTypeOf(AtomicExecute)))
4.3. Analizando Modelos de dise no con seguri-
dad
En esta secci on denimos operadores OCL en el contexto del metamodelo
de SecureUML+ComponentUML que formalizan diferentes aspectos de la infor-
maci on de control de acceso contenida en los modelos. Usamos estos operadores
como parte de un lenguaje, basado en OCL, preparado para analizar decisio-
nes de control de acceso que dependen de informacion est atica, es decir de la
asignaci on de usuarios y permisos a roles. Para ilustrar nuestro metodo, inclui-
mos ejemplos que muestran el resultado de evaluar nuestros operadores OCL
sobre la poltica de seguridad modelada en la Figura 4.4. En lo que sigue, sea
SCHEDULER la instant anea del metamodelo de SecureUML+ComponentUML
que corresponde al modelo dibujado en la Figura 4.4 de acuerdo con la trans-
formaci on denida en la secci on 4.2.3.
4.3.1. Semantica
Recordemos primero la semantica formal denida para los modelos de Secu-
reUML+ ComponentUML en [BDL06], puesto que, con respecto a esta semanti-
ca formal, armaremos en varias observaciones que nuestras operaciones OCL
capturan correctamente la informacion de control de acceso contenida en los mo-
delos. En esta semantica, las estructuras que especican las conguraciones de
control de acceso tienen signaturas
RBAC
= (o
RBAC
,
RBAC
, T
RBAC
, T
RBAC
),
donde o
RBAC
es un conjunto de tipos,
RBAC
es un orden parcial sobre o
RBAC
,
T
RBAC
es un conjunto tipado de smbolos de funci on y T
RBAC
es un conjunto
tipado de smbolos de predicado. En concreto
o
RBAC
=
Users, Roles, Permissions,

AtomicActions, Actions
,
donde Actions
RBAC
AtomicActions. Ademas T
RBAC
= y
T
RBAC
=
Roles
: Roles Roles ,
Actions
: Actions Actions,
UA : Users Roles ,
PA : Roles Permissions ,
AA : Permissions Actions
.
Dado un modelo M de SecureUML+ComponentUML, la
RBAC
-estructura
RBAC
que especica formalmente la informacion contenida en M se dene
4.3. Analizando Modelos de dise no con seguridad 107
como sigue: los conjuntos que interpretan los tipos Users, Roles, Permissions,
AtomicActions y Actions tienen un elemento por cada elemento que tiene el mo-
delo M de los tipos correspondientes del metamodelo. Igualmente, las relaciones
UA, PA y AA tienen una tupla por cada instancia de las correspondientes aso-
ciaciones del metamodelo, a saber, UserAsssignment, PermissionAssignment y
ActionAssignment. La relacion
Roles
se dene como la clausura reexiva tran-
sitiva de las instancias de la asociaci on RoleHierarchy del metamodelo, y escri-
bimos los subroles (roles que tienen privilegios adicionales) en la parte izquierda
(m as abierta) del smbolo . Por ultimo, >
Actions
se dene como la clausura
transitiva de las instancias de la asociaci on ActionHierarchy del metamodelo,
y escribimos a
1
>
Actions
a
2
, para indicar que a
2
es una accion subordinada de
a
1
. De acuerdo con esta semantica, un usuario u tiene permiso para efectuar
la accion a si y s olo si la formula siguiente, denotada como
RBAC
(u, a), se
satisface:
p Permissions :
User
(u, p)
Action
(p, a),
donde
User
(u, p) denota que u tiene un permiso p y
Action
(p, a) denota que p
es un permiso para la accion a; mas formalmente,
User
(u, p) :=
r, r
Roles : UA(u, r) r
Roles
r
PA(r
, p) ,
y
Action
(p, a) :=
a
Actions : AA(p, a
) a
>
Actions
a .
Observacion 1. Sea
RBAC
la
RBAC
-estructura denida por un modelo M.
Entonces para cualquier u en Users, r en Roles, p en Permissions y a en Ac-
tions, el Cuadro 4.1 recoge la correspondencia b asica entre la satisfacci on en
RBAC
y la evaluaci on de expresiones OCL en M.
se satisface en
RBAC
eval ua a true en M
UA(u, r) u.hasroleincludes(r)
PA(r, p) r.haspermissionincludes(p)
AA(p, a) p.accessesincludes(a)
Cuadro 4.1: Correspondencia b asica entre satisfacci on y evaluaci on.
En la siguiente secci on veremos de que forma se puede capturar mediante
expresiones OCL la satisfactibilidad de las formulas
User
(u, p),
Action
(p, a) y
RBAC
(u, a) y con ellas tambien se captura la semantica de los modelos Secu-
reUML+ComponentUML.
4.3.2. Operaciones de Analisis
Denimos ahora diferentes operaciones de consulta en OCL que son utiles
para analizar las propiedades de seguridad de los modelos formalizados usando
SecureUML+ComponentUML.
Para analizar la relacion
Roles
en la
RBAC
-estructura
RBAC
denida por
un modelo M, denimos la operaci on Role::superrolePlus():Set(Role) que devuelve
la colecci on de roles (directamente o indirectamente) encima de un rol dado en
la jerarqua de roles, incluyendose a s mismo.
context Role::superrolePlus():Set(Role) body:
self.superrolePlusOnSet(self.superrole)
context Role::superrolePlusOnSet(rs:Set(Role)):Set(Role)
body:
if rs.superrole>exists(r[rs>excludes(r))
then self.superrolePlusOnSet(rs
>union(rs.superrole)>asSet())
else rs>including(self)
endif
Por ejemplo, sobre SCHEDULER, la consulta Supervisor.superrolePlus() eval ua a
Set|defaultRole, SystemUser, Supervisor.
An alogamente, denimos la operaci on Role::subrolePlus():Set(Role) que devuelve
los roles (directa o indirectamente) bajo un rol dado en la jerarqua de ro-
les, incluyendose a s mismo. Ademas, podemos denir tambien la operaci on
Role::allPermissions():Set(Permission) que devuelve la colecci on de permisos (direc-
ta o indirectamente) asignados a un rol.
context Role::allPermissions():Set(Permission) body:
self.superrolePlus().haspermission>asSet()
Por ejemplo, sobre SCHEDULER la consulta Supervisor.allPermissions() eval ua a
Set|defaultPermission, OwnerMeeting, UserMeeting, SupervisorCancel.
Inversamente, denimos Permission::allRoles(): Set(Role), que devuelve la colecci on
de roles que est an (directa o indirectamente) asignados al permiso dado.
Para analizar la relacion >
Actions
en la
RBAC
-estructura
RBAC
denida
por un modelo M, denimos la operaci on Action::subactionPlus():Set(Action) que
devuelve la colecci on de acciones (directa o indirectamente) subordinadas a una
accion.
context Action::subactionPlus():Set(Action) body:
if self.oclIsKindOf(AtomicAction)
then Set|self
else self.oclAsType(CompositeAction)
.subordinatedactions.subactionPlus()
endif
4.3. Analizando Modelos de dise no con seguridad 109
Por ejemplo, sobre SCHEDULER la consulta MeetingEntityUpdate.subactionPlus()
eval ua a
Set|MeetingstartAtomicUpdate,MeetingdurationAtomicUpdate,
MeetingcancelAtomicExecute, MeetingnotifyAtomicExecute,
MeetingownerAtomicUpdate, MeetingparticipantsAtomicUpdate
An alogamente, denimos Action::compactionPlus():Set(Action) que devuelve la colec-
cion de acciones a las que una accion est a (directa o indirectamente) subor-
dinada. Ademas, denimos la operaci on Permission::allActions():Set(Action) que
devuelve la colecci on de acciones cuyo acceso est a (directa o indirectamente)
garantizado por un permiso.
context Permission::allActions():Set(Action) body:
self.accesses.subactionPlus()>asSet()
Por ejemplo, sobre SCHEDULER la consulta OwnerMeeting.allActions() eval ua a
Set|MeetingAtomicDelete, MeetingstartAtomicUpdate,
MeetingdurationAtomicUpdate,
MeetingcancelAtomicExecute,
MeetingnotifyAtomicExecute,
MeetingownerAtomicUpdate,
MeetingparticipantsAtomicUpdate
A la inversa, denimos la operaci on Action::allAssignedPermissions(): Set(Permission),
que devuelve la colecci on de permisos que (directa o indirectamente) garantizan
el acceso a una accion.
Observacion 2. Sea
RBAC
la
RBAC
estructura denida por un modelo M.
Entonces, para cualquier u en Users, r, r
1
, r
2
en Roles, p en Permissions, y a,
a
1
, a
2
en Actions, el Cuadro 4.2 muestra algunas correspondencias adicionales
no triviales entre la satisfacci on en
RBAC
y la evaluaci on de expresiones OCL
en M.
se satisface en
RBAC
eval ua a true en M
r
1

Roles
r
2
r
1
.superrolePlus()includes( r
2
)
r
2
.subrolePlus()includes( r
1
)
r
2
Roles. r
1
.allPermissions()includes( p )
r
1

Roles
r
2
PA(r
2
, p) p .allRoles()includes( r
1
)
a
1
>
Actions
a
2
a
1
.subactionPlus()includes( a
2
)
a
2
.compactionPlus()includes( a
1
)
User
(u, p) u .hasrole.allPermissions()includes( p )
p .allRoles()includes( u )
Action
(p, a) p .allActions()includes( a )
a .allAssignedPermisssions() includes( p )
Cuadro 4.2: Otras correspondencias no triviales entre satisfacci on y evaluaci on.
4.3.3. Ejemplos
Finalmente, damos ejemplos que ilustran c omo se pueden analizar modelos
SecureUML+ ComponentUML usando las operaciones OCL denidas en la sec-
cion 4.3.2.
Dado un rol, cu ales son las acciones at omicas que un usuario que tenga
este rol puede realizar?
context Role::allAtomics():Set(Action) body:
self.allPermissions().allAction()>asSet()
>select(a[a.oclIsKindOf(AtomicAction))
Por ejemplo, sobre SCHEDULER, la consulta SystemAdministrator.allAtomics() eval ua
a
Set|MeetingstartAtomicRead,MeetingdurationAtomicRead,
MeetingownerAtomicRead,MeetingparticipantsAtomicRead,
PersonnameAtomicUpdate, PersonmeetingAtomicUpdate,
PersoneventsAtomicUpdate,PersonnameAtomicRead,
PersonmeetingAtomicRead,PersoneventsAtomicRead,
PersonAtomicCreate, PersonAtomicDelete
Existen dos roles que tengan asociado el mismo conjunto de acciones at omi-
cas?
context Role::duplicateRoles():Boolean body:
Role.allInstances()
>exists(r1, r2[ r1.allAtomics() = r2.allAtomics())
Por ejemplo, la consulta duplicateRoles() evalua a true sobre SCHEDULER puesto
que los permisos que tienen SystemUser y Supervisor les dan acceso (aunque
con distintas restricciones) a las mismas acciones atomicas (ver la Figura 4.4
y la jerarqua de acciones en el Apendice B.3: en concreto, n otese que entity
update incluye el permiso de ejecutar los metodos que no son simples consultas:
en este caso, cancel y notify).
Dados dos permisos, se solapan?
context Permission::overlapsWith(p:Permission):Boolean
body: self.allActions()
>intersection(p.allActions())>notEmpty()
Por ejemplo, la consulta OwnerMeeting.overlapsWith(SupervisorCancel) eval ua a true
sobre SCHEDULER porque ambos permisos, por las razones antes expuestas,
dan acceso (aunque con distintas restricciones) a las acciones atomicas cancel y
notify.
Existen dos permisos que se solapen y que esten asociados a roles diferen-
tes?
context Permission::existOverlapping():Boolean body:
4.4. La herramienta ITP/OCL+S 111
Permission.allInstances()>exists(p1,p2[
p1 <> p2 y p1.overlapsWith(p2)
and not(p1.allRoles()>includesAll(p2.allRoles())))
Por ejemplo, la consulta existOverlapping() eval ua a true sobre SCHEDULER puesto
que, por razones identicas a las antes expuestas, SupervisorCancel y OwnerMee-
ting tambien se solapan pero SupervisorCancel no est a asociado a uno de los
roles a los que est a asociado OwnerMeeting: a saber, el rol SystemUser.
Existen acciones at omicas que todos los roles, excepto el default, puedan
realizar?
context AtomicAction::accessAll():Boolean body:
AtomicAction.allInstances()>exists(a[
Role.allInstances()>forAll(r[
not(r.default) implies
r.allAtomics()>includes(a)))
Por ejemplo, sobre SCHEDULER la consulta accessAll() eval ua a true porque tanto
SystemUser, como Supervisor y SystemAdministrator tienen asignado (directa
o indirectamente) un permiso que da acceso a la accion atomica read sobre el
atributo start de cualquier reunion.
4.4. La herramienta ITP/OCL+S
En esta secci on presentamos una herramienta para analizar diagramas Se-
cureUML+ComponentUML cuya implementacion est a basada en las transfor-
maciones presentados en la secci on 4.3. La herramienta, llamada ITP/OCL+S,
es una extensi on de la herramienta ITP/OCL presentada en el captulo 3. M as
especcamente, ITP/OCL+S extiende la herramienta ITP/OCL con comandos
para construir diagramas SecureUML+ComponentUML y para evaluar consul-
tas OCL, que usan, entre otras, las operaciones de an alisis introducidas en la
secci on 4.3.2 (los usuarios pueden, por supuesto, denir otras operaciones de
an alisis adicionales). La ultima versi on de la herramienta ITP/OCL+S puede
encontrarse en http://maude.sip.ucm.es/securemova, junto con la documen-
tacion disponible y ejemplos.
4.4.1. Estados
En ITP/OCL+S el objeto bucle tiene los mismos atributos que en el caso de
ITP/OCL. Su base de datos contiene, sin embargo, un unico diagrama de clases, a
saber, la representacion del metamodelo de SecureUML+ComponentUML, jun-
to con los diagramas de objetos que representan las instant aneas de este metamo-
delo objeto del an alisis. El Cuadro 4.3 muestra la 6-tupla classDiagramName,
classList, attributeList, associationList generalizationList, enumerationList) que
representa el metamodelo de SecureUML+ComponentUML en la base de datos
de ITP/OCL+S.
classDiagramName = SecureUMLMetamodel
classList = AtomicDeleteInstance, AtomicDelete, AtomicExecute,
AtomicRead, AtomicCreate, AtomicUpdate, Action, User,
AuthorizationConstraint, AssociationEndFullAccess,
AttributeFullAccess, AtomicAction, EntityUpdate,
EntityRead, EntityFullAccess, CompositeAction,
Resources, Permission, Role, Method, Attribute,
AssociationEnd, Entity )
attributeList =
language, AuthorizationConstraint, String),
name, AuthorizationConstraint, String),
body, AuthorizationConstraint, String),
default, Permission, Boolean),
default, Role, Boolean),
isQuery, Method, Boolean ) )
associationList =
Action, subordinatedactions, compositeaction, CompositeAction),
Resources, resource, action, Action),
Role, subrole, superrole, Role),
Permission, isassigned, accesses, Action),
Role, givesaccess, haspermission, Permission ),
User, includes, hasrole, Role ),
AuthorizationConstraint, isconstraintby, constrains, Permission),
Entity, associationendof, hasassociationend, AssociationEnd),
Entity, methodof, hasmethod, Method),
Entity, attributeof, hasattribute, Attribute) )
generalizationList =
AtomicExecute, AtomicAction),
AtomicDelete, AtomicAction),
AtomicUpdate, AtomicAction),
AtomicRead, AtomicAction),
AtomicCreate, AtomicAction),
CompositeAction, Action),
AtomicAction, Action),
AssociationEndFullAccess, CompositeAction),
AttributeFullAccess, CompositeAction ),
EntityUpdate, CompositeAction),
EntityRead, CompositeAction),
EntityFullAccess, CompositeAction),
AssociationEnd, Resources),
Entity, Resources),
Method, Resources),
Attribute, Resources) )
enumerationList= ())
Cuadro 4.3: El diagrama de clases metamodelo de SecureUML +-
ComponentUML.
op create-security-diagram_. : Token -> Input .
op insert-role_:_. Token Token -> Input .
op insert-entity_:_. : Token Token -> Input .
op insert-attribute_:_(_,_). : Token Token -> Input .
op insert-association_:_:_:_<->_:_:_. : Token Token Token Multi
Multi Token Token -> Input .
op insert-query_:_:_. : Token Token Token -> Input .
op insert-non-query _:_:_. : Token Token Token -> Input .
op insert-permission _:_. : Token Token -> Input .
op insert-permission-assignment_:_:_. : Token Token Token -> Input .
op insert-entity-full-access_:_:_. : Token Token Token -> Input .
op insert-entity-update_:_:_. : Token Token Token -> Input .
op insert-entity-read_:_:_. : Token Token Token -> Input .
op insert-atomic-create_:_:_. : Token Token Token -> Input .
op insert-atomic-delete_:_:_. : Token Token Token -> Input .
op insert-attribute-full-access_:_:_:_. : Token Token Token
Token -> Input .
op insert-atomic-read_:_:_:_. : Token Token Token Token -> Input .
op insert-atomic-update_:_:_:_. : Token Token Token Token -> Input .
op insert-association-end-full-access_:_:_:_. : Token Token
Token Token -> Input .
op insert-atomic-read _:_:_:_. : Token Token Token Token-> Input .
op insert-atomic-update_:_:_:_. : Token Token Token Token -> Input .
op insert-atomic-execute_:_:_:_. : Token Token Token Token -> Input .
Cuadro 4.4: Los comandos de diagrama de ITP/OCL+S.
4.4.2. Comandos
Como en el caso de la herramienta ITP/OCL, la sintaxis de los comandos
ITP/OCL+S es una sintaxis combinada a dos niveles diferentes: la sintaxis de alto
nivel, que proporciona el lenguaje para expresar las acciones que los usuarios
pueden realizar: por ejemplo, crear un diagrama de seguridad, a nadir un rol,
una entidad, realizar una consulta, etc.; y la sintaxis denible por el usuario,
que proporciona el lenguaje para expresar los argumentos de estas acciones: por
ejemplo, el nombre del diagrama que va a crearse, el nombre del rol que va a
a nadirse, la consulta que va a realizarse, etc.
Comandos de Diagrama Se usan para crear diagramas SecureUML+Com-
ponentUML y para insertar, borrar y modicar elementos en los diagramas.
Sint acticamente, los comandos de diagrama son terminos de tipo Input cons-
truidos con los operadores que se muestran en el Cuadro 4.4. Como son los
usarios quienes declaran los nombres de los diagramas y los nombres de los
elementos que van a ser insertados, borrados o modicados, estos operadores
toman argumentos de tipo Token. La semantica precisa de estos comandos se
da en la secci on 4.4.4.
Ejemplo 6. Consideremos el modelo de dise no con seguridad dibujado en la
Figura 4.4. Usaremos los comandos que se muestran en el Cuadro 4.5 para
cargar este diagrama en la herramienta ITP/OCL+S.
(create-security-diagram SCHEDULER .)
(insert-role SCHEDULER : SystemAdministrator .)
(insert-role SCHEDULER : Supervisor .)
(insert-role SCHEDULER : SystemUser .)
(insert-role-hierarchy SCHEDULER |
Supervisor <-> SystemUser .)
(insert-entity SCHEDULER : Meeting .)
(insert-entity SCHEDULER : Person .)
(insert-attribute SCHEDULER : Meeting : start : Integer .)
(insert-attribute SCHEDULER : Meeting : duration : Integer .)
(insert-attribute SCHEDULER : Person : name : String .)
(insert-association SCHEDULER : Meeting :
meeting : < * > <-> < 1 > : owner : Person .)
(insert-non-query-method SCHEDULER : Meeting : cancel .)
(insert-non-query-method SCHEDULER : Meeting : notify .)
(insert-permission SCHEDULER : OwnerMeeting .)
(insert-permission SCHEDULER : UserMeeting .)
(insert-permission SCHEDULER : SupervisorCancel .)
(insert-permission SCHEDULER : UserManagement .)
(insert-permission SCHEDULER : ReadMeeting .)
(insert-permission-assignment SCHEDULER :
OwnerMeeting : SystemUser .)
UserMeeting : SystemUser .)
SupervisorCancel : Supervisor .)
UserManagement : Supervisor .)
ReadMeeting : SystemAdministrator .)
(insert-entity-update SCHEDULER : OwnerMeeting : Meeting .)
(insert-entity-read SCHEDULER : UserMeeting : Meeting .)
(insert-atomic-delete SCHEDULER : OwnerMeeting : Meeting .)
(insert-atomic-create SCHEDULER : UserMeeting : Meeting .)
(insert-atomic-execute SCHEDULER :
SupervisorCancel : Meeting : cancel .)
(insert-atomic-execute SCHEDULER :
SupervisorCancel : Meeting : notify .)
(insert-entity-full-access SCHEDULER :
UserManagement : Person .)
(insert-entity-read SCHEDULER : ReadMeeting : Meeting .)
Cuadro 4.5: Comandos para cargar SCHEDULER.
op query-in_:_. : Token Token Bubble -> Input .
op insert-oper_(_,_)_. : Token Token Token
op insert-oper_(_,_,_)_. : Token Token Token
op insert-oper (_,_)_. : Token Token
op insert-oper (_,_,_)_. : Token Token
Cuadro 4.6: Comandos de Expresi on de ITP/OCL+S.
Comandos de Expresion En el contexto de los diagramas SecureUML+
ComponentUML, se usan para evaluar las consultas y para denir operaciones
de an alisis adicionales. Sint acticamente, los comandos de expresi on son terminos
de tipo Input construidos con los operadores que se muestran en el Cuadro 4.6.
Por las razones ya discutidas al explicar la sint axis de los comandos relacionados
de ITP/OCL, estas operaciones toman argumentos de tipo Bubble. La semantica
precisa de estos comandos se da en la secci on 4.4.4.
4.4.3. Interaccion
En ITP/OCL+S la interacci on con el objeto bucle se dene con reglas de
reescritura [in] y [out], al igual que se hizo en el caso de ITP/OCL, excepto
que ahora la gram atica usada para comprobar si las entradas del usuario son
terminos de tipo Input es la que proporciona el modulo COMMANDS+S-GRAMMAR,
que contiene, entre otros los operadores declarados en los Cuadros 4.4 y 4.6.
4.4.4. Ejecucion
A continuaci on introducimos los comandos ITP/OCL que implementan cada
uno de los comandos ITP/OCL+S declarados en los Cuadros 4.4 (comandos de
diagrama) y 4.6 (comandos de expresi on). ITP/OCL+S tambien proporciona
comandos para borrar y modicar elementos en los diagramas de dise no con
seguridad, que se denen de manera completamente an aloga.
Procesando Comandos de Diagrama
Los comandos ITP/OCL+S que crean un diagrama de dise no con seguridad
y que insertan elementos en el est an implementados por comandos ITP/OCL
que internamente a naden o modican un diagrama de objetos en la base de
datos, a saber, el diagrama de objetos que representa la instancia del metamo-
delo de SecureUML+ComponentUML que corresponde al diagrama de dise no
con seguridad creado o modicado en caso caso por los comandos introducidos
por el usuario. Esta correspondencia es la descrita en la secci on 4.2.3, y que,
recordamos, est a denida de forma completa en el Apendice B.4.
(create-object-diagram SecureUMLMetamodel : snm .)
(insert-object snm : Role : defaultRole .)
(insert-object snm : Permission : defaultPermission .)
(insert-object snm : AuthorizationConstraint :
defaultAuthorizationConstraint .)
(insert-link snm | Role : givesaccess <->
haspermission : Permission |
defaultRole <->defaultPermission .)
(insert-link snm | AuthorizationConstraint :
isconstraintby <->constrains : Permission |
defaultAuthorizationConstraint <->defaultPermission .)
(insert-attr-value snm : Role : defaultRole :
default : Boolean ->true .)
(insert-attr-value snm : Permission :
defaultPermission : default : Boolean ->true .)
(insert-attr-value snm : AuthorizationConstraint :
defaultAuthorizationConstraint :
language : String ->OCL .)
(insert-attr-value snm : AuthorizationConstraint :
defaultAuthorizationConstraint :
body : String ->true .)
Cuadro 4.7: Los comandos ITP/OCL usados para crear un diagrama de dise no
con seguridad.
Podemos agrupar los comandos de diagrama declarados en la Cuadro 4.4 en
las siguientes categoras:
Comandos que crean un diagrama de dise no con seguridad El coman-
do
(create-security-diagram snm .)
crea un diagrama de seguridad snm. Est a implementado por la ejecuci on se-
cuencial de los comandos de ITP/OCL que se muestran en el Cuadro 4.7.
Comandos que insertan un elemento en un diagrama de dise no con
seguridad. Son los siguientes comandos:
(insert-entity snm : e .),
(insert-attribute snm : e (at , t).),
(insert-query snm : e : m .),
(insert-non-query snm : e : m .),
(insert-association snm : e : r : m <-> m
: r
: e
.),
(insert-role snm : r .),
(insert-permission snm : p .),
(insert-permission-assignment snm : r : p .),
(insert-entity-full-access snm : p : e .),
(insert-entity-read snm : p : e .),
(insert-entity-update snm : p : e .),
(insert-atomic-create snm : p : e .),
(insert-atomic-delete snm : p : e .),
(insert-attribute-full-access snm : p : e : at .),
(insert-atomic-read snm : p : e : at .),
(insert-atomic-update snm : p : e : at .),
(insert-association-end-full-access snm : p : e : itr .),
(insert-atomic-update snm : p : e : r .),
(insert-atomic-read snm : p : e : r .),
(insert-atomic-execute snm : p : e : m .),
El comando (insert-entity snm : e .) inserta una entidad e en el dia-
grama de seguridad snm. Est a implementado mediante la ejecuci on secuencial
de los comandos ITP/OCL que se muestran en el Cuadro 4.8.
El comando (insert-attribute snm : e(at, t).) a nade el atributo at a
la entidad e en el diagrama de seguridad snm. Est a implementado por la ejecu-
cion secuencial de los comandos ITP/OCL que se muestran en los Cuadros 4.9
y 4.10.
El comando (insert-query snm : e : m .) a nade una operaci on consul-
ta m a la entidad e en el diagrama de seguridad snm. Est a implementado por
la ejecuci on secuencial de los comandos ITP/OCL mostrados en el Cuadro 4.11.
El comando (insert-non-query snm : e : m .) a nade una operaci on m
a la entidad e en el diagrama de seguridad snm. Est a implementada mediante
El comando (insert-association snm : e:r:m <-> m
:r
:e
.), a nade
una asociaci on as entre las entidades e y e del diagrama de seguridad snm.
Est a implementado por la ejecuci on secuencial de los comandos ITP/OCL mos-
trados en los Cuadros 4.13 y 4.14.
El comando (insert-role snm : r .) inserta un rol r en en el diagra-
ma de seguridad snm. Est a implementado por la ejecuci on secuencial de los
comandos ITP/OCL mostrados en el Cuadro 4.15.
El comando (insert-permission snm : p .) inserta el permiso p en el
diagrama de seguridad snm. Est a implementado por la ejecuci on secuencial de
los comandos ITP/OCL que se muestran en el Cuadro 4.16.
El comando (insert-permission-assignment snm : r : p .) asigna el
permiso p al rol r en el diagrama de seguridad snm. Est a implementado mediante
la ejecuci on de los comandos ITP/OCL que se muestran en el Cuadro 4.17.
El comando (insert-entity-full-access snm : p : e .) asigna la ac-
cion full-access sobre la entidad e al permiso p en el diagrama de seguridad
snm. Est a implementado por la ejecuci on secuencial de los comandos ITP/OCL
que se muestran en el Cuadro 4.18.
El comando (insert-entity-read snm : p : e .) asigna la accion read
sobre la entidad e al permiso p en el diagrama de seguridad snm. Est a imple-
(insert-object snm : Entity : e .)
(insert-object snm : EntityFullAccess : efa(e) .)
(insert-object snm : EntityUpdate : eu(e) .)
(insert-object snm : EntityRead : er(e) .)
(insert-object snm : EntityCreate : ac(e) .)
(insert-object snm : EntityDelete : ad(e) .)
(insert-link snm | Resources : resource <->
action : Action | e <-> efa(e) .)
action : Action | e <-> eu(e) .)
action : Action | e <-> er(e) .)
action : Action | e <-> ac(e) .)
action : Action | e <-> ad(e) .)
(insert-link snm | Action : subordinatedactions <->
compositeaction : CompositeAction |
eu(e) <-> efa(e) .)
er(e) <-> efa(e) .)
ac(e) <-> efa(e) .)
ad(e) <-> efa(e) .)
(insert-link snm | Permission : isassigned <->
accesses : Action | defaultPermission <-> ac(e) .)
accesses : Action | defaultPermission <-> ad(e) .)
Cuadro 4.8: Los comandos ITP/OCL que se usan para insertar una entidad.
(insert-object snm : Attribute : at .)
(insert-object snm : AttributeFullAccess : afa(at) .)
(insert-object snm : AtomicUpdate : au(at) .)
(insert-object snm : AtomicRead : ar(at) .)
action : Action | at <-> afa(at) .)
action : Action | at <-> au(at) .)
action : Action | at <-> ar(at) .)
Cuadro 4.9: Los comandos ITP/OCL que se usan para insertar un atributo (I).
compositeaction : CompositeAction | au(at) <-> afa(at) .)
compositeaction : CompositeAction | ar(at) <-> afa(at) .)
compositeaction : CompositeAction | au(at) <-> eu(e) .)
compositeaction : CompositeAction | ar(at) <-> er(e) .)
(insert-link snm | Entity : attributeof <->
hasattribute : Attribute | e <-> at .)
accesses : Action | defaultPermission <-> au(at) .)
accesses : Action | defaultPermission <-> ar(at) .)
Cuadro 4.10: Los comandos ITP/OCL que se usan para insertar un atributo (y
II).
(insert-object snm : Method : m .)
(insert-object snm : AtomicExecute : ae(m) .)
(insert-attr-value snm : Method : m :
isQuery : Boolean ->true .)
action : Action | m <-> ae(m) .)
compositeaction : CompositeAction | ae(m) <-> eu(e) .)
(insert-link snm | Entity : methodof <->
hasmethod : Method | e <-> m .)
accesses : Action | defaultPermission <-> ae(m) .)
Cuadro 4.11: Los comandos ITP/OCL que se usan para insertar un metodo
consulta.
(insert-object snm : Method : m .)
(insert-object snm : AtomicExecute : ae(m) .)
(insert-attr-value snm : Method : m :
isQuery : Boolean ->false .)
action : Action | m <-> ae(m) .)
compositeaction : CompositeAction | ae(m) <-> eu(e) .)
(insert-link snm | Entity : methodof <->
hasmethod : Method | e <-> m .)
accesses : Action | defaultPermission <-> ae(m) .)
Cuadro 4.12: Los comandos ITP/OCL para insertar un metodo no de consulta.
(insert-object snm : AssociationEnd : r .)
(insert-object snm : AssociationEndFullAccess : dfa(r) .)
(insert-object snm : AtomicUpdate : au(r) .)
(insert-object snm : AtomicRead : ar(r) .)
(insert-object snm : AssociationEnd : r
.)
(insert-object snm : AssociationEndFullAccess : dfa(r
) .)
(insert-object snm : AtomicUpdate : au(r
) .)
(insert-object snm : AtomicRead : ar(r
) .)
(insert-link snm | Resources : resource <->action : Action |
r <-> dfa(r) .)
r <-> au(r) .)
r <-> ar(r) .)
r
<-> dfa(r
) .)
r
<-> au(r
) .)
r
<-> ar(r
) .)
(insert-link snm | Action : subordinatedactions <->compositeaction :
CompositeAction | au(r) <-> dfa(r) .)
CompositeAction | ar(r) <-> dfa(r) .)
CompositeAction | au(r) <-> eu(e
) .)
CompositeAction | ar(r) <-> er(e
) .)
CompositeAction | au(r
) <-> dfa(r
) .)
CompositeAction | ar(r
) <-> dfa(r
) .)
CompositeAction | au(r
) <-> eu(e) .)
CompositeAction | ar(r
) <-> er(e) .)
Cuadro 4.13: Los comandos ITP/OCL usados para insertar una asociaci on (I).
(insert-link snm | Entity : associationendof <->hasassociationend :
AssociationEnd | e <-> r
.)
(insert-link snm | Entity : associationendof <->hasassociationend :
AssociationEnd | e
<-> r .)
(insert-link snm | Permission : isassigned <->accesses : Action |
defaultPermission <-> au(r) .)
defaultPermission <-> ar(r) .)
defaultPermission <-> au(r
) .)
defaultPermission <-> ar(r
) .)
Cuadro 4.14: Los comandos ITP/OCL usados para insertar una asociaci on (y
II).
(insert-object snm : Role : r .)
(insert-attr-value snm : Role : r : default :Boolean ->false .)
(insert-link snm | Role : subrole <->superrole : Role |
r <-> defaultRole .)
Cuadro 4.15: Los comandos ITP/OCL que se usan para insertar un rol.
(insert-object snm : Permission : m .)
(insert-attr-value snm : Permission :
defaultPermission : default : Boolean ->false .)
Cuadro 4.16: Los comandos ITP/OCL que se usan para insertar un permiso.
(insert-link snm | Role : givesaccess <->
haspermission : Permission | r <-> p .)
Cuadro 4.17: El comando ITP/OCL que inserta una asignaci on de permiso.
(insert-link snm | Permission : isassigned <->accesses :
Action | p <-> efa(e) .)
(delete-link snm | Permission : isassigned <->accesses :
Action | defaultPermission <-> ac(e) .)
Action | defaultPermission <-> ad(e) .)
Cuadro 4.18: Los comandos ITP/OCL para insertar un permiso de acceso entity
full-access.
Action | p <-> er(e) .)
Action | defaultPermission <-> ar(a) .)
Action | defaultPermission <-> ae(m) .)
Action | defaultPermission <-> ar(r) .)
Cuadro 4.19: El comando ITP/OCL para insertar un permiso de acceso entity
read-access.
Action | p <-> eu(e) .)
Action | defaultPermission <-> au(a) .)
Action | defaultPermission <-> au(r) .)
Cuadro 4.20: Los comandos ITP/OCL para insertar un permiso de acceso entity
update-access.
mentado por la ejecuci on secuencial de los comandos ITP/OCL que se muestran
en el Cuadro 4.19, donde los comandos para borrar la asignaci on del permiso
default son ejecutados para cada atributo at , metodo de consulta m y extremo
de asociaci on r previamente insertados en la entidad e.
El comando (insert-entity-update snm : p : e .) asigna la accion up-
date sobre la entidad e al permiso p en el diagrama de seguridad snm. Est a im-
plementado por la ejecuci on secuencial de los comandos ITP/OCL mostrados en
el Cuadro 4.20, donde los comandos para borrar el permiso default asignado
son ejecutados para cada atributo at , metodo de no consulta m y extremo de
asociaci on r previamente insertados en la entidad e.
El comando (insert-atomic-create snm : p : e .) asigna la accion crea-
te sobre la entidad e al permiso p en el diagrama de seguridad snm. Est a im-
el Cuadro 4.21.
El comando (insert-atomic-delete snm : p : e .) asigna la accion de-
lete sobre la entidad e al permiso p en el diagrama de seguridad snm. Est a im-
el Cuadro 4.22.
El comando (insert-attribute-full-access snm : p : e : at .) asigna la
accion full-access sobre el atributo at de la entidad e al permiso p en el dia-
grama de seguridad snm. Est a implementado por la ejecuci on secuencial de los
Action | p <-> ac(e) .)
Action | defaultPermission <-> ac(e) .)
Cuadro 4.21: Los comandos ITP/OCL para insertar un permiso de acceso create-
access.
Action | p <-> ad(e) .)
Action | defaultPermission <-> ad(e) .)
Cuadro 4.22: Los comandos ITP/OCL para insertar un permiso de acceso atomic
delete-access.
El comando (insert-atomic-read snm : p : e : at .) asigna la accion
atomica read sobre atributo at de la entidad e al permiso p en el diagrama de
seguridad snm. Est a implementado por la ejecuci on secuencial de los comandos
ITP/OCL mostrados en el Cuadro 4.24.
El comando (insert-atomic-update snm : p : e : at .) asigna la ac-
cion atomica update sobre el atributo at de la entidad e al permiso p en el
diagrama de seguridad snm. Est a implementado por la ejecuci on secuencial de
los comandos ITP/OCL mostrados en el Cuadro 4.25.
El comando de asignaci on (insert-association-end-full-access snm
: p: e: r .) asigna la accion full-access sobre el extremo de asociaci on r de la
entidad e al permiso p en el diagrama de seguridad snm. Est a implementado por
El comando (insert-atomic-update snm : p : e : r .) asigna la ac-
cion atomica update sobre el extremo de asociaci on r de la entidad e al permiso
p en el diagrama de seguridad snm. Est a implementado por la ejecuci on secuen-
cial de los comandos ITP/OCL mostrados en el Cuadro 4.27.
Action | p <-> afa(at) .)
Action | defaultPermission <-> au(at) .)
Action | defaultPermission <-> ar(at) .)
Cuadro 4.23: Los comandos ITP/OCL para insertar un permiso de acceso attri-
bute full-access.
Action | p <-> ar(at) .)
Action | defaultPermission <-> ar(at) .)
bute read-access.
Action | p <-> au(at) .)
Action | defaultPermission <-> au(at) .)
bute update-access.
Action | p <-> dfa(r) .)
Cuadro 4.26: Los comandos ITP/OCL para insertar un permiso de acceso
association-end full-access.
Action | p <-> au(r) .)
association-end update-access.
Action | p <-> ar(r) .)
association-end read-access.
Action | p <-> ae(m) .)
Cuadro 4.29: Los comandos ITP/OCL para insertar un permiso de acceso method
execute-access.
El comando (insert-atomic-read snm : p : e : r .) asigna la accion
atomica read sobre el extremo de asociaci on r de la entidad e al permiso p en
el diagrama de seguridad snm. Est a implementado por la ejecuci on secuencial
de los comandos ITP/OCL mostrados en el Cuadro 4.28.
El comando (insert-atomic-execute snm : p : e : m .) asigna la ac-
cion atomica execute sobre el metodo m de la entidad e al permiso p en el dia-
grama de seguridad snm. Est a implementado por la ejecuci on secuencial de los
Procesando Comandos de Expresion
Los comandos ITP/OCL+S que consultan diagramas de dise no con seguri-
dad o que denen operaciones de an alisis para ser usadas en estas consultas se
implementan usando los correspondientes comandos de expresi on ITP/OCL. La
unica diferencia entre los comandos de expresi on de ITP/OCL+S y de ITP/OCL
es que los comandos de expresi on ITP/OCL+S no toman como argumento el
diagrama de clases que proporciona el contexto para las expresiones puesto que
este es siempre el metamodelo de SecureUML+ComponentUML.
Comandos que consultan un diagrama El comando (query-in snm :
expr .) pregunta el valor de la expresi on expr sobre la instancia del metamodelo
que corresponde al modelo de dise no con seguridad snm. Est a implementado por
(query-in SecureUMLMetamodel : snm : expr .)
Cuadro 4.30: El comando ITP/OCL para consultar un diagrama de dise no con
seguridad.
(insert-oper SecureUMLMetamodel : c(oper, t) body.),
(insert-oper SecureUMLMetamodel : c(oper, t1 tn,t) body.),
(insert-oper SecureUMLMetamodel :: (oper, t) body.), y
(insert-oper SecureUMLMetamodel ::(oper, t1 tn,t) body.)
Cuadro 4.31: Los comandos ITP/OCL que denen operaciones de an alisis.
Comandos que denen operaciones de analisis Son los comandos:
(insert-oper c(oper, t ) body.),
(insert-oper c(oper, t
1
t
n
,t ) body.),
(insert-oper (oper, t ) body.) y
(insert-oper (oper, t
1
t
n
,t ) body.)
Cada uno de estos comandos est a implementado por la ejecuci on del correspon-
diente comando ITP/OCL en el Cuadro 4.31.
Ejemplo 7. Mostramos en la Figura 4.6 los comandos ITP/OCL+S que de-
nen las operaciones de an alisis superrolePlusOnSet, superrolePlus, allPermissions,
subactionPlus, y allActions, introducidas en la secci on 4.3.2.
4.5. Extensiones, Trabajo Relacionado y Futuro
Extensiones En [BMDE08] hemos extendido nuestro enfoque basado en me-
tamodelos para analizar modelos de dise no con seguridad con el n de ana-
lizar tambien escenarios, esto es instancias que representan estos modelos en
ejecuci on. Como resultado, las polticas que pueden analizarse incluyen tanto
aspectos declarativos, es decir, informacion de control de acceso est atico (como
la asignaci on de usuarios y permisos a roles), como aspectos program aticos,
que dependen de informacion dinamica, a saber, de la satisfacci on de las res-
tricciones de autorizaci on en el escenario dado. La idea es que el metamodelo
de SecureUML+ComponentUML formaliza en este enfoque extendido tanto la
estructura de los modelos bien formados como de sus instancias. Esto permite
formalizar consultas sobre las relaciones entre usuarios, roles, permisos, acciones
y los estados del sistema. Una consulta tpica sobre una poltica de seguridad
es existen dos roles tales que uno incluye el conjunto de acciones del otro
pero estos no est an relacionados en la jerarqua de roles?. Un ejemplo tpico
de consulta que implica un estado del sistema es que roles pueden asign arsele
a un usuario en un escenario dado para que pueda realizar una accion sobre un
recurso concreto?. En ambos casos, de acuerdo con nuestro enfoque, obtendre-
mos las respuestas evaluando las correspondientes expresiones OCL sobre las
instancias del metamodelo que representan los modelos de dise no con seguridad
(o sus escenarios) objeto del an alisis.
(insert-oper Role (superrolePlusOnSet, rs:RoleCol, RoleCol)
(if (((rs:RoleCol)->collect(r1:Role |
r1:Role #superrole))->exists(r:Role |
(rs:RoleCol ->excludes(r:Role))))
then (self:Role #superrolePlusOnSet(rs:RoleCol
->union((rs:RoleCol)->collect(r1:Role |
(r1:Role)#superrole))))
else (rs:RoleCol ->including(self:Role)) fi) .)
(insert-oper Role (superrolePlus, RoleCol)
(self:Role #superrolePlusOnSet(self:Role #superrole)) .)
(insert-oper Role (allPermissions,PermissionCol)
((((self:Role) #superrolePlus)->collect((r:Role )|
((r:Role) #haspermission)))->asSet()) .)
(insert-oper Action (subactionPlus,ActionCol)
(if ((self:Action) #oclIsKindOf (AtomicAction ) )
then (col(self:Action, (nil).ActionCol ) )
else ((((self:Action) #oclAsType (CompositeAction))
#subordinatedactions)
->collect ((a:Action)|
((a:Action) #subactionPlus))) fi) .)
(insert-oper Permission (allActions,ActionCol)
((((self:Permission) #accesses) ->collect ( (a:Action )|
((a:Action) #subactionPlus ) )) ->asSet ( )) .)
Figura 4.6: Ejemplo: la denici on de algunas operaciones de an alisis en IT-
P/OCL+S.
Trabajo Relacionado En la actualidad se investiga muy activamente en tres
campos que pueden contribuir a mejorar notablemente la construcci on de sis-
temas con restricciones de seguridad: a saber, i) c omo integrar en el nivel de
dise no del sistema los requisitos de seguridad; ii) c omo vericar y validar estos
modelos de dise no que integran requisitos de seguridad; y iii) c omo integrar en
la implementacion de un sistema sus requisitos de seguridad (en especial, explo-
rando las posibilidades que ofrece la programacion orientada a aspectos). Las
investigaciones mas relacionadas con nuestro trabajo se desarrollan en el primer
y en el segundo campo, aunque su grado de relacion depende l ogicamente del
tipo de requisitos de seguridad que abordan.
Modelado y analisis de seguridad en sistemas distribuidos UML-
sec [J
02, J
03] extiende UML para permitir el modelado de requisitos de seguri-

dad que son particularmente relevantes para sistemas distribuidos: entre otros, el
intercambio justo, que impide que las partes se enga nen durante una transaccion
comercial; la condencialidad, que permite unicamente a las partes legtimas ac-
ceder a determinados datos; el ujo seguro de la informaci on, que se preocupa
por el problema de la revelaci on parcial o indirecta de informacion en ausencia
de una revelaci on completa de los datos; y el enlace de comunicaci on seguro,
que asegura que un canal de comunicacion especca entre partes del sistema
sea seguro con respecto a modelos de amenaza concretos. Se han desarrollado
ya varios plugins para UMLsec que permiten analizar algunos de estos requi-
sitos, utilizando para ello herramientas formales como el model-checker SPIN.
AUTOFOCUS [Bro] es una propuesta similar a UMLSec, en la medida en que
se preocupa fundamentalmente de requisitos de seguridad de sistemas distri-
buidos. Proporciona, ademas, una herramienta CASE que permite a usuarios
no expertos en metodos formales modelar y analizar estos requisitos [WW01].
Chan y Kwok [CK01b], por su parte, denen algunos estereotipos UML para
modelar clases con restricciones especcas de seguridad, que tienen que ver, por
ejemplo, con vulnerabilidades o impacto de perdidas.
Modelado y analisis de polticas de acceso Las investigaciones mas
relacionadas con el contenido de este captulo son sin duda, las contenidas
en [AS01, SAGM05, WZCY04] puesto que utilizan OCL para analizar las polti-
cas de seguridad en modelos RBAC, de los que los modelos SecureUML son,
como hemos explicado, una extensi on. Hay, sin embargo, diferencias fundamen-
tales entre nuestro trabajo y las investigaciones antes citadas.
Una caracterstica distinta de nuestra propuesta (en su conjunto, incluyendo
por tanto tambien [BMDE08]) es que seguimos una metodologa bien denida
que garantiza que tiene sentido (con respecto a la semantica de los modelos) el
uso de OCL para realizar las consultas que constituyen el an alisis de los mode-
los. Nuestra metodologa requiere, en particular, deniciones precisas tanto del
metamodelo del lenguaje de modelado como de la transformaci on de modelos y
escenarios a las correspondientes instancias de este metamodelo. Estas denicio-
nes hacen posible razonar rigurosamente sobre el signicado de las expresiones
OCL usadas para especicar o analizar las polticas de seguridad. Para subrayar
la importancia de tal metodologa consideremos un ejemplo simple: especicar
dos roles mutuamente exclusivos como accounts payable manager y pur-
chasing manager. Exclusi on mutua, en este contexto, signica que a ning un
individuo pueden asign arsele ambos roles. En [AS01, SAGM05, WZCY04] esta
restricci on est a especicada usando OCL de la siguiente manera:
context User inv:
let M : Set = ||accounts payable manager,
purchasing manager, ... in
M>select(m [ self.role>intersection(m)>size > 1)
>isEmpty()
Sin embargo, la restricci on anterior especica correctamente la exclusi on
mutua solamente si el extremo de asociaci on role devuelve todos los roles
asignados a un usuario. Estos deberan incluir todas las asignaciones de ro-
les explcitamente dibujadas a la vez que aquellas implcitamente asignadas a
los usuarios a traves de la jerarqua de roles. El signicado real del extremo de
asociaci on role depende, por supuesto, de la transformaci on entre los modelos
y las correspondientes instancias del metamodelo. Como la denici on preci-
sa de esta transformaci on no se da en [AS01, SAGM05, WZCY04], tanto los
lectores como los usuarios de la herramienta se ven obligados a especular so-
bre el signicado de tales expresiones (notemos que si la transformaci on usada
en [AS01, SAGM05, WZCY04] es la directa, entonces el extremo de asociaci on
role solo devolvera los roles explcitamente asignados a un usuario). En nues-
tro marco, la exclusi on mutua puede especicarse usando la siguiente expresi on
OCL:
context User inv:
let M : Set = ||accounts payable manager,
purchasing manager, ...
in M>select(m [ self.hasrole.superrolePlus()
>intersection(m)>size > 1)
>isEmpty()
De nuestra denici on de superrolePlus() en la secci on 4.3.2 queda claro que
esta operaci on denota todos los roles asignados a un usuario, incluyendo aquellos
implcitamente asignados bajo la jerarqua de roles especicada.
Una segunda diferencia importante de nuestra propuesta est a relacionada
con el hecho de que el lenguaje de modelado SecureUML incluye la posibilidad
de restringir permisos mediante las restricciones de autorizaci on. En nuestro
enfoque, es posible determinar autom aticamente la satisfacci on de estas restric-
ciones con respecto a los escenarios dados. Esto nos permite consultar, ademas de
las propiedades de la conguracion est atica RBAC del sistema, las propiedades
del sistema en ejecuci on, es decir, las propiedades de las instancias particulares
del modelo de dise no con seguridad.
Trabajo Futuro
Como ya hemos explicado, el manejo de escenarios en nuestro enfoque nos
permite realizar consultas que implican analizar estados concretos del siste-
ma. Sin embargo, sera atractivo poder realizar consultas sobre la existencia
de estados que satisfagan restricciones o, mas en general, consultas en las que
los estados mismos est an existencial o universalmente cuanticados. Un ejem-
plo de esto ultimo sera que acciones son posibles en los das laborables que
son imposibles los nes de semana?. Alternativamente, en un modelo de ban-
ca, podramos preguntar que acciones son posibles en cuentas que est an en
n umeros rojos? Nuestro enfoque actual no puede tratar estas consultas puesto
que requieren razonar sobre las consecuencias de formulas OCL: es decir, im-
plican la demostracion de teoremas en contraposici on a la determinacion de la
satisfactibilidad de formulas en un modelo concreto.
Otra direcci on interesante sera usar nuestra metodologa como base para
analizar la consistencia de distintas vistas del sistema. SecureUML puede com-
binarse con lenguajes de modelado diferentes (por ejemplo, ComponentUML o
ControllerUML [BDL03]) para formalizar distintas vistas de arquitecturas mul-
ticapa. En este marco, el control de acceso podra implementarse tanto en la
capa intermedia (que implementa un controlador para, digamos, una aplicaci on
web) como en la capa base (que implementa la persistencia). Si las polticas
para estas dos capas se modelan formalmente, podramos considerar cuestiones
del tipo es posible que el controlador de acceso a un estado en el que la capa
de persistencia tenga que lanzar una excepcion de seguridad?. De nuevo, esta
es una consulta sobre la existencia (la alcanzabilidad) de los estados y su res-
puesta requerir a en cualquier caso la demostracion de teoremas u otras formas
de deducci on como la resolucion de restricciones o la b usqueda de estados.
Captulo 5
OCL en un Proyecto
Industrial
131
132 Captulo 5. OCL en un Proyecto Industrial
La arquitectura dirigida por modelos (Model-Driven Architecture) (MDA)
[KBW03]) promete reducir el tiempo de desarrollo de un sistema a la vez que
mejorar la calidad de los productos resultantes. Este enfoque deende que la
construcci on de los modelos durante la etapa de dise no y de an alisis de un siste-
ma mejorar a la calidad de los sistemas resultantes, proporcionando as una base
para la deteccion temprana de errores; ademas, los modelos construidos en las
fases de an alisis y dise no servir an como especicaciones para las fases posteriores
de desarrollo y, cuando sean sucientemente formales, tambien servir an de base
para el renamiento hasta el c odigo a traves de funciones de transformaci on de
modelos.
La seguridad dirigida por modelos (Model-Driven Security) (MDS) [BDL06])
es una especializacion propuesta recientemente dentro del enfoque MDA. En
esta, los dise nadores especican modelos de un sistema junto con sus requisitos
de seguridad y usan herramientas que generan autom aticamente la arquitectura
de este sistema desde sus modelos incluyendo sus infraestructuras de control
de acceso. Se argumenta que este enfoque resuelve el salto entre el an alisis
de seguridad y la integraci on de los mecanismos de control de acceso en los
sistemas nales. Ademas, integra los modelos de seguridad con los modelos de
dise no, dando lugar a una nueva clase de modelos, llamados modelos de dise no
con seguridad.
En este captulo informamos del uso con exito de MDS y OCL en un pro-
yecto industrial MDA de tama no medio. El proyecto fue nanciado por INDRA
Sistemas
1
y tena un doble objetivo: por un lado, estaba dirigido a mejorar la
interfaz de usuario para la conguracion de informes de las pruebas realizadas
autom aticamente en un banco de pruebas de prop osito general que la compa na
desarrolla y comercializa. Por otro lado, estaba concebido como un proyecto
piloto para evaluar los posibles benecios de MDA en proyectos de desarrollo
de software propios de la compa na.
Para este proyecto usamos el lenguaje ComponentUML (ya presentado en el
captulo anterior) para modelar los requisitos funcionales de la interfaz de con-
guracion de informes y SecureUML [BDL06] para modelar los requisitos de la
poltica de control de acceso en la aplicaci on para la conguracion de informes.
De hecho, hemos combinado estos dos lenguajes para producir el modelo con
dise no de seguridad de la utilidad para la conguracion de informes. Aqu nos
interesa destacar que, para precisar la informacion contenida en estos modelos,
hemos usado intensivamente el lenguaje OCL [OCL06]: primero, para especicar
los invariantes sobre las clases del sistema (incluyendo las precondiciones y las
poscondiciones de sus metodos), y segundo, para formular las restricciones de
autorizaci on asociadas con los permisos de acceso al sistema. Finalmente, hemos
denido un metodo para construir, desde nuestro modelo de dise no con seguri-
dad, la infraestructura de control de acceso de la aplicaci on para la conguracion
1
La empresa est a entre las tres primeras companas europeas en el sector de Tecnologa de
la Informaci on de acuerdo a la capitalizaci on en bolsa, y es una de las empresas espa nolas que
m as invierte en I+D. En el 2007, sus benecios superaron los 2.150Me, de los que un tercio
procede del mercado internacional. La compa na emplea a m as de 23.000 profesionales y tiene
clientes en m as de 80 pases.
5.1. Requisitos del Proyecto 133
de informes.
Este captulo est a organizado como sigue: primero, en la secci on 5.1 resumi-
mos los requisitos del proyecto. Despues en las secci ones 5.2 y 5.3 explicamos
nuestro enfoque MDS para especicar los requisitos funcionales y de control
de acceso en modelos de dise no con seguridad, mientras que en la secci on 5.4
describimos nuestra funci on de transformaci on MDS para construir aplicaciones
conscientes de la seguridad desde los modelos de dise no con seguridad. Final-
mente, en la secci on 5.5 resumimos las lecciones aprendidas con este proyecto.
5.1. Requisitos del Proyecto
Al comienzo del proyecto nos dieron un documento de dos p aginas que ex-
plicaba las caractersticas generales de la aplicaci on inform atica que se usaba
para la conguracion de informes de pruebas y las mejoras que se esperaban
como resultado de nuestro trabajo. Estas mejoras se describan en un documen-
to de cinco p aginas en el que se listaban cincuenta clausulas escritas (en ingles)
por el ingeniero de software jefe del equipo de desarrollo del banco de pruebas.
En sntesis, la utilidad mejorada para la conguracion de informes debera per-
mitir a los usuarios seleccionar (y posiblemente modicar) las conguraciones
(llamadas TRCs) para sus informes de los resultados de las pruebas. Para ello,
los usuarios podran elegir entre varias conguraciones de pruebas disponibles,
incluyendo conguraciones privadas, globales y por defecto, estas ultimas aso-
ciadas con programas de pruebas individuales o con familias de programas de
pruebas. Los permisos para crear, editar, borrar o aplicar conguraciones de in-
formes tendran que depender tanto del rol del usuario como de las propiedades
actuales (incluyendo su autora) de las conguraciones. En el cuadro 5.1 mos-
tramos las clausulas a las que haremos referencia en este captulo para ilustrar
nuestra aplicaci on del enfoque MDS en este proyecto.
5.2. Modelando Requisitos Funcionales
Siguiendo el enfoque MDS, primero construimos un modelo de dise no de la
aplicaci on para la conguracion de informes de pruebas basada exclusivamente
en los requisitos funcionales incluidos en el documento de requisitos. Para esta
tarea usamos el lenguaje de modelado ComponentUML. Para a nadir precisi on
a nuestros modelos, imponemos, usando el lenguaje OCL, invariantes sobre las
clases y pre y poscondiciones sobre los metodos.
Para ilustrar nuestro enfoque mostramos el modelo ComponentUML en la
Figura 5.1 que corresponde (parcialmente) a los requisitos funcionales enume-
rados en el Cuadro 5.1. Primero, modelamos la parte est atica de la utilidad
para la conguracion de informes de pruebas con una clase TRC que tiene los
atributos owner (propietario), name (nombre) y scope ( ambito) y los metodos
create (crear) y delete (borrar). Entonces, especicamos (la primera parte de)
la Cl ausula#8.4, es decir,
Clausula#1 Existira un repositorio de TRCs en el sistema.
Clausula#6 El ambito (scope) de un TRC podra ser: Global (Global): el TRC
estara accesible para lectura para todos los usuarios; Privado
(Private): el TRC estara accesible para lectura y escritura solo
para su propietario (owner).
Clausula#7 Cada TRC tiene un unico propietario. El usuario que crea un
TRC es su propietario.
Clausula#8.1 Cualquier usuario que tenga privilegios de Supervisor o de Ad-
ministrador puede crear un TRC.
Clausula#8.4 Todo TRC estara identicado unvocamente tanto para el usuario
como para el sistema. Esta identicacion incluira el propietario y
el nombre, de forma que ning un usuario podra denir dos TRCs
con el mismo nombre.
Clausula#8.5 Los usuarios que esten en los grupos de Test Supervisor o de
Test Administrator podran crear TRCs de ambito Global o Pri-
vado. En el momento de la creacion, el usuario establecera el
ambito del TRC. Los usuarios que no esten en ninguno de los
grupos anteriores solo podran crear TRCs de ambito Privado.
Clausula#9 Un TRC de ambito Global estara accesible para lectura para to-
dos los usuario. Un TRC que tenga ambito Privado estara accesi-
ble para lectura y escritura para su propietario y para cualquier
usuario que tenga privilegios de Supervisor o Administrador.
Clausula#11.1 Solamente los usuarios que tengan acceso para escritura sobre un
TRC podran borrar ese TRC.
Cuadro 5.1: Algunos requisitos de la aplicaci on para la conguracion de informes
de prueba.
Todo TRC estar a identicado unvocamente tanto para el usuario
como para el sistema. Esta identicacion incluir a el propietario y el
nombre [...].
con el siguiente invariante de clase OCL:
context TRC inv uniqueIdentifier:
TRC.allInstances->forAll(trc |
trc<>self implies (trc.owner<>self.owner or trc.name<>self.name))
que restringe el conjunto de instancias validas de nuestro modelo a aquellas
donde cada TRC tiene un identicador unico, a saber, el nombre de su propie-
tario seguido por su propio nombre. Despues, especicamos la segunda parte de
la Cl ausula#8.4, es decir,
[La identicaci on incluir a el propietario y el nombre,] de forma que
ning un usuario podra denir dos TRCs con el mismo nombre.
mediante las siguientes pre y poscondicion en OCL:
context TRC::create(p scope:TypeOfScope,p owner:String,p name:String)
5.3. Modelando Requisitos de Control de Acceso 135
pre: TRC.allInstances->forAll(trc|trc.owner<>p owner or trc.name<>p name)
post: self.scope = p scope and self.owner=p owner and self.name=p name
que garantiza que el metodo create preserva el invariante uniqueIdentier.
N otese, sin embargo, que la poscondicion de arriba solamente especica parcial-
mente la segunda parte de la Cl ausula#7, es decir,
El usuario que crea un TRC es su propietario.
El problema es que para especicar completamente esta restricci on, tambien
tenemos que especicar que el metodo create siempre es llamado con el nombre
del usuario que quiere crear un TRC como su segundo argumento. Sin embargo,
puesto que un diagrama de ComponentUML solamente modela la parte est ati-
ca del sistema, el usuario que llama en tiempo de ejecuci on al metodo create
(el caller) no puede modelarse aqu y, consecuentemente, tampoco podemos
referirnos a el en una expresi on OCL escrita en este contexto. En la siguien-
te secci on, veremos c omo esta restricci on se puede especicar en el diagrama
SecureUML+ComponentUML.
TRC
+owner: String
+scope: TypeOfScope
+name: String
+create(p_scope:TypeOfScope,p_owner:String,
p_name:String)
+delete()
<<Enumerate>>
TypeOf Scope
+Private
+Global
context TRC inv:
TRC.allInstances->forAll(trc|trc<>self implies (trc.owner<>self.owner or trc.name<>self.name))
context TRC::create(p_scope:TypeOfScope,p_owner:String,p_name:String)
pre: TRC.allInstances->forAll(trc|trc.owner<>p_owner or trc.name<>p_name)
post: self.scope=p_scope and self.owner=p_owner and self.name=p_name
Figura 5.1: Modelando (parcialmente) los requisitos funcionales.
5.3. Modelando Requisitos de Control de Acce-
so
Siguiendo el enfoque MDS, construimos un modelo de dise no con seguridad
de la aplicaci on para la conguracion de informes de pruebas. Para ello, modela-
mos la poltica de control de acceso denida en el documento de requisitos sobre
el modelo que describe la parte est atica del sistema. Para esta tarea usamos el
lenguaje de modelado SecureUML+ComponentUML, que requiere del uso de
OCL para expresar las restricciones de autorizaci on que restringen los permisos
de acceso
2
.
Para ilustrar nuestro enfoque, mostramos el modelo SecureUML+Component-
UML que corresponde (parcialmente) a la poltica de control de acceso para la
creacion de los TRCs denida en el Cuadro 5.1 en la Figura 5.2. Especica-
mos los grupos de usuarios mediante tres roles jerarquicamente organizados:
Test Operator, Test Supervisor y Test Administrator. Entonces, especicamos
la Cl ausula#8.5 y la segunda parte de la Cl ausula#7, es decir,
Los usuarios que esten en los grupos de Test Supervisor o de
Test Administrator podran crear TRCs de ambito Global o Privado.
En el momento de la creacion, el usuario establecer a el ambito del
TRC. Los usuarios que no esten en ninguno de los grupos anteriores
solo podran crear TRCs de ambito Privado.
El usuario que crea un TRC es su propietario.
con los permisos NewPrivate y NewGlobal. Estos permisos est an asignados, res-
pectivamente, a los roles Test Operator y Test Supervisor. N otese que los per-
misos NewPrivate y NewGlobal est an ambos restringidos por la expresi on OCL
p owner = caller.name
que autoriza la ejecuci on del metodo create solamente si es llamado con el nom-
bre del usuario que intenta crear el TRC como su segundo argumento. Con esta
restricci on de autorizaci on, junto con la poscondicion de create, garantizamos
que el usuario que cree un TRC es su propietario.
N otese tambien que el permiso NewPrivate est a restringido ademas por la
expresi on OCL
p scope = Private.
Con esta restricci on de autorizaci on, junto con la poscondicion de create,
garantizamos que los usuarios que no est an en los grupos Test Supervisor o
Test Administrator solamente puedan crear TRCs de ambito privado.
Finalmente, n otese que, como Test Supervisor es un subrol de Test Operator,
los usuarios en el grupo de Test Supervisor heredan el permiso NewPrivate.
An alogamente, como Test Administrator es un subrol de Test Supervisor, los
usuarios en el grupo de Test Administrator heredan los permisos NewPrivate y
NewGlobal. Por tanto, garantizamos que los usuarios en los grupos TestSuper-
visor o TestAdministrator puedan crear TRCs de ambito tanto privado como
global.
2
En una restriccion de autorizaci on OCL, la variable caller se reere al usuario que intenta
acceder al recurso, mientras que la variable self se reere al recurso que est a siendo accedido.
Asumiremos en adelante que los usuarios tienen un nombre name.
5.4. Generando Aplicaciones Seguras 137
<<Role>>
Test _Operat or
<<Role>>
Test_Supervi sor
<<Role>>
Test _Admi ni st rat or
<<Entity>>
TRC
+owner: String
+scope: TypeOfScope
+name: String
+create(p_scope:TypeOfScope,p_owner:String,
p_name:String)
+delete()
<<Permission>>
NewPr i vat e
+create: AtomicExecute
p_owner = caller.name and p_scope = Private
<<Permission>>
NewGl obal
+create: AtomicExecute
p_owner = caller.name
Figura 5.2: Modelando (parcialmente) los requisitos de control de acceso.
5.4. Generando Aplicaciones Seguras
Como parte de nuestra aplicaci on del enfoque MDS, denimos una funci on de
transformaci on T desde modelos SecureUML+ComponentUML a c odigo C++.
3
Es bien conocido que las funciones de transformaci on entre modelos y, en ultimo
termino, desde modelos a c odigo son un componente clave de MDA. En nuestro
proyecto, la funci on de transformaci on T fue crucial no solo para implementar la
poltica de control de acceso denida en el documento de requisitos original, sino
tambien para modicar esta implementacion cuando el cliente introduca re-
namientos o cambios en el documento original, como ocurri o en varias ocasiones
a lo largo del proyecto.
4
Como se esperaba, la funci on de transformaci on T tiene en cuenta (y en
consecuencia est a limitada por ella) la tecnologa usada por nuestro cliente para
implementar polticas de control de acceso, que incluye en particular:
Un documento XML especco, llamado UserRights, en el que se puede
denir la relacion entre los grupos de usuarios y los llamados t opicos (to-
pics), as como la jerarqua entre los grupos de usuarios. Los t opicos pueden
tener diferentes signicados: nosotros los usamos para denotar permisos.
Un metodo especco llamado isServiceGranted(topic), con el cual se
puede comprobar si el usuario que esta utilizando el sistema pertenece
3
En [BDL06] los autores denen dos funciones de transformaci on diferentes para traducir
modelos de dise no con seguridad a tecnologa EJB y .NET.
4
Es interesante notar que estos renamientos o cambios surgan en su mayora de las
implicaciones no pretendidas de las cla usulas contenidas en el documento original, y que
salan a la luz al analizar el modelo con dise no de seguridad correspondiente.
(directa o indirectamente) al grupo asociado con topic en el documento
XML UserRights; este metodo lo proporciona el componente software
IUserAdmGet.
Nuestra funci on de transformaci on T permite utilizar la siguiente metodo-
loga para implementar en C++ la poltica de control de acceso modelada en
un diagrama SecureUML+ComponentUML; de hecho, aunque no tenamos una
implementacion de la funci on T (debido tanto a restricciones de tiempo como
a la naturaleza experimental del proyecto: como mencionamos anteriormente
el proyecto fue concebido por la compa na como un proyecto piloto), en este
proyecto seguimos los pasos abajo descritos para implementar la poltica de
control de acceso en la aplicaci on mejorada para la conguracion de informes
de pruebas.
Paso 1 Denir como grupos en el documento UserRights los roles dibujados
en el diagrama as como su jerarqua. Por ejemplo, el siguiente c odigo
XML es parte del documento UserRights que hemos usado para traducir
el modelo dibujado en la Figura 5.2.
5
<VIRTUAL_USER_GROUPS>
<VIRTUAL_USER_GROUP name="L1">
<USER_GROUP name="Test_Administrator"/>
</VIRTUAL_USER_GROUP>
<USER_GROUP name="Test_Supervisor"/>
<VIRTUAL_USER_GROUP_REF name="L1"/>
<USER_GROUP name="Test_Operator"/>
</VIRTUAL_USER_GROUPS>
Paso 2 Denir como t opicos en el documento UserRights los permisos dibu-
jados en el diagrama, asociando a cada t opico el grupo ligado al permiso
correspondiente. Por ejemplo, el siguiente c odigo XML es parte del docu-
mento UserRights que hemos usado para traducir el modelo dibujado en
la Figura 5.2.
6
.
5
En un documento XML de UserRights, la etiqueta VIRTUAL USER GROUP se usa para de-
clarar un grupo: su atributo name proporciona una referencia a este. El nombre del grupo
se declara usando la etiqueta USER GROUP. Una relaci on de subordinaci on jer arquica con otro
grupo se declara usando la etiqueta VIRTUAL USER GROUP REF: su atributo name reere el nom-
bre del grupo de arriba en la jerarqua. Finalmente, las declaraciones VIRTUAL USER GROUP
deben ocurrir dentro de la etiqueta VIRTUAL USER GROUPS.
6
En un documento XML de UserRights la etiqueta TOPIC se usa para declarar un t opico. Un
t opico est a relacionado con un grupo dado por medio de la etiqueta VIRTUAL USER GROUP REF:
su atributo name se reere al nombre del grupo. Esta asociaci on debe declararse dentro de una
etiqueta RIGHTS
5.4. Generando Aplicaciones Seguras 139
<TOPIC name="NewPrivate">
<RIGHTS>
</RIGHTS>
</TOPIC>
<TOPIC name="NewGlobal">
<RIGHTS>
</RIGHTS>
</TOPIC>
Para explicar el siguiente paso, introducimos primero alguna notaci on. Para
cada metodo method en el diagrama de seguridad, sea PRM(method) el conjunto
de permisos que garantizan acceso (con o sin condiciones) para ejecutar method.
Tambien, para cada permiso permission en el diagrama, sea CTR(permission) la
expresi on OCL que restringe permission (o simplemente true si no hay ninguna
restricci on de autorizaci on asociada a permission). Ademas, para cada method
en el diagrama, sea PRE(method) la expresi on OCL que (pre-)condiciona la
ejecuci on de method, (o simplemente true si la ejecuci on de method no tiene
ninguna precondicion). Finalmente, para cualquier expresi on booleana expres-
sion en OCL, sea C++(expression) la funci on booleana en C++ que implementa
expression.
Paso 3 Hacer que la ejecuci on de cada metodo method del diagrama dependa
de la satisfacci on de su precondicion y de su poltica de control de acceso.
Para ello, se hace que la ejecuci on de method dependa de la satisfac-
cion de la funci on C++(PRE(method)), y de la funci on CHK(method),
que es una funci on booleana (tpicamente con los mismos par ametros
que method) que devuelve true si y solo si existe un permiso permis-
sion en PRM(method) tal que isServiceGranted(permission) as como
C++(CTR(permission)) devuelven true.
Es facil generar, para cada metodo method en un diagrama, una prime-
ra implementacion de CHK(method). Sea PRM(method) = p
i
1in
.
Entonces, el siguiente c odigo C++ implementa CHK(method), donde la
variable m uag referencia el objeto de tipo IUserAdmGet que encapsula la
informacion sobre el usuario actual del sistema.
if (m uag->isServiceGranted(p
1
) && C++(CTR(p
1
)))
return true;

if (m uag->isServiceGranted(p
n
) && C++(CTR(p
n
)))
return true;
return false
Por supuesto, es posible generar una implementacion mas eciente del
metodo CHK(method) si tenemos en cuenta la jerarqua de roles y/o las
implicaciones l ogicas entre las restricciones de autorizaci on (omitiremos
aqu los detalles). Por ejemplo, el siguiente c odigo C++ es parte de la
funci on CHK( create) que hemos usado para traducir el modelo dibujado
en la Figura 5.2:
m_uag->GetUser(user_name);
if (m_uag->isServiceGranted(NewPrivate))
if (p_scope = Private && p_owner = user_name)
return true;
else
if (m_uag->isServiceGranted(NewGlobal)
&& p_owner = user_name)
return true;
return false
N otese que, como cada usuario en el grupo Test Supervisor (o Test -
Administrator) es tambien un usuario del grupo Test Operator, nuestra
(versi on eciente de la) funci on CHK( create) directamente devuelve false
si el usuario actual del sistema no pertenece al grupo asociado al t opico
NewPrivate (es decir, al grupo Test Operator).
5.5. Lecciones Aprendidas y Trabajo Futuro
La aplicaci on mejorada para la conguracion de informes de pruebas fue en-
tregada a nuestro cliente en el tiempo acordado. SecureUML+ComponentUML
con OCL fue sucientemente expresivo como para modelar la poltica de con-
trol de acceso denida en el documento original de requisitos proporcionados por
nuestro cliente. El exito de este proyecto proporciona nuevas evidencias de los
benecios potenciales de aplicar MDS y del interes industrial del uso de OCL:
principalmente, es posible producir modelos que capturan los aspectos de seguri-
dad de un sistema, que son independientes de la tecnologa, y con ellos reusables
y evolucionables; y es posible, ademas, construir aplicaciones con seguridad que
son consistentes con esos modelos. A pesar de este potencial, la carencia actual
de un adecuado soporte de herramientas diculta su aplicabilidad en proyectos
industriales de gran taman no.
5.5. Lecciones Aprendidas y Trabajo Futuro 141
Lecciones Aprendidas Concluimos este informe con un breve resumen de
las lecciones que hemos aprendido con respecto a las iniciativas MDA y MDS:
Primero, con respecto a la iniciativa MDA:
La construcci on de modelos durante las fases de an alisis de requisitos y
de dise no del sistema proporciona una base para el an alisis y la detecci on
temprana de errores. El an alisis de los modelos construidos a partir del
documento original nos llev o a renar aquellos requisitos que eran ambi-
guos, a eliminar aquellos que estaban duplicados o eran implicados por
otros, y a formalizar aquellos que estaban ausentes. Como ejemplo, en-
contramos que los requisitos originales no especicaban si un TRC con
ambito Global poda borrarse (y por quien) y tampoco especicaban de
forma no ambigua si el usuario que modicaba un TRC poda convertirse
en su propietario.
Los modelos construidos en las fases de an alisis de requisitos y de dise no
proporcionan una base para el renamiento hasta el c odigo. La genera-
cion del c odigo C++ siguiendo nuestra funci on de transformaci on T nos
ayud o a implementar correctamente (y a modicar) la poltica de con-
trol de acceso en la utilidad para la conguracion de informes de pruebas.
Como ejemplo, en varias ocasiones a lo largo del proyecto el cliente re-
n o (o modic o) la poltica de control de accesso del sistema para resolver
inconsistencias y ambig uedades que detectamos en el documento original;
para adaptar nuestro c odigo a los nuevos requisitos, simplemente modi-
camos los modelos y aplicamos de nuevo sobre ellos nuestra funci on de
transformaci on T.
Ahora con respecto al enfoque MDS:
Los modelos de dise no con seguridad integran modelos de seguridad con
modelos de dise no de sistemas, permaneciendo al mismo tiempo indepen-
dientes de la tecnologa, reusables y f acilmente modicables. En una pri-
mera fase, los modelos de dise no y los modelos de seguridad nos ayudaron
a comprender (y discutir) el documento original de requisitos y nos per-
mitieron modelar por separado cada cla usula de acuerdo con su contenido
principal (funcional o relacionada con la seguridad). Despues, los modelos
de dise no con seguridad nos ayudaron a integrar los modelos funciona-
les y de seguridad resultantes, sin tener que comprometernos todava con
ninguna tecnologa en especca.
Los modelos de dise no de seguridad son comprensibles para aquellos fa-
miliarizados con la notaci on UML. Los modelos de dise no con seguridad
se convirtieron de hecho en la lengua franca utilizada en las discusiones
entre los ingenieros de software y de requisitos (de la compa nia) y los
desarrolladores de software (de nuestro grupo).
Trabajo Futuro Las polticas de control de acceso no son los unicos requi-
sitos de seguridad que pueden encontrarse en las especicaciones industriales.
En un futuro proximo, planeamos aplicar el enfoque MDS a otros requisitos de
seguridad, lo cual puede exigirnos el uso (o incluso la denici on) de otros len-
guajes de modelado y herramientas. Tambien planeamos dise nar estos proyectos
para poder recopilar resultados mas cuantitativos sobre los benecios de aplicar
MDS en el desarrollo de sistemas.
Bibliografa
[ABB
+
05] W. Ahrendt, T. Baar, B. Beckert, R. Bubel, M. Giese, R. H ahnle,
W. Menzel, W. Mostowski, A. Roth, S. Schlager y P. H. Schmitt.
The KeY tool. Software and System Modeling, 4:3254, 2005.
[AS01] G. J. Ahn y M. E. Shin. Role-Based authorization constraints speci-
cation using Object Constraint Language. En WETICE 01: Pro-
ceedings of the Tenth IEEE International Workshops on Enabling
Technologies, p aginas 157162. IEEE Computer Society, 2001.
[Baa06] T. Baar, editor. Tool Support for OCL and Related Formalisms
Needs and Trends MoDELS05 Conference Workshop, Technical
Report Lgl-Report-2005-001. EPFL, Montego Bay, Jamaica, 2006.
[BCDE07] D. Basin, M. Clavel, J. Doser y M. Egea. A metamodel-based ap-
proach for analyzing security-design models. En MODELS 07: Pro-
ceedings of the Tenth International Conference on Model Driven En-
gineering Languages and Systems, volumen 4735 de LNCS, p aginas
420435. Springer-Verlag, 2007.
[BDL03] D. Basin, J. Doser y T. Lodderstedt. Model driven security for
Process-Oriented systems. En SACMAT 03 : Proceedings of the
Eighth ACM Symposium on Access Control Models and Technolo-
gies, p aginas 100109. ACM Press, 2003. ISBN 1-58113-681-1.
[BDL06] D. Basin, J. Doser y T. Lodderstedt. Model driven security: From
UML models to access control infrastructures. ACM Transactions
on Software Engineering and Methodology, 15(1):3991, 2006.
[BHS07] B. Beckert, R. H ahnle y P. H. Schmitt, editores. Verication of
Object-Oriented Software: The KeY Approach, volumen 4334 de
LNCS. Springer-Verlag, 2007.
[BKS02] B. Beckert, U. Keller y P. Schmitt. Translating the object cons-
traint language into rst-order predicate logic. En In Proceedings,
VERIFY, Workshop at Federated Logic Conferences (FLoC. 2002.
143
144 Bibliografa
[BM07] T. Baar y S. Markovic. The RoclET-Refactoring OCL Expressions
by Transformations tool. http://www.roclet.org/index.php,
2007.
[BMDE08] D. Basin, M.Clavel, J. Doser y M. Egea. Automated analysis of
security-design models. Information and Software Technology, 4853,
2008. To appear in the special issue on Model Based Development
for Secure Information Systems.
[Bor07] A. Boronat. A Formal Framework for MOdel ManageMENT. Tesis
Doctoral, Universidad Politecnica de Valencia, 2007.
[Bro] M. Broy. AUTOFOCUS. http://autofocus.in.tum.de.
[Bru07] A. D. Brucker. An Interactive Proof Environment for Object Orien-
ted Specications. Tesis Doctoral, ETH Zurich, 2007.
[BW07] A. D. Brucker y B. Wol. The HOL-OCL Tool.
http://www.brucker.ch/projects/hol-ocl/, 2007. Institu-
to Federal Suizo de Tecnologa de Zurich.
[CBC05a] D. Chiorean, M. Bortes y D. Corutiu. Proposals for a widespread
use of OCL. En Tool Support for OCL and Related Formalisms -
Needs and Trends MoDELS05 Conference Workshop, p aginas 68
82. 2005.
[CBC
+
05b] D. Chiorean, M. Bortes, D. Corutiu, C. Botiza y A. Carcu. An OCL
environment (OCLE) 2.0.4. http://lci.cs.ubbcluj.ro/ocle/,
2005. Laboratorul de Cercetare in Informatica, Universidad de
BABES-BOLYAI.
[CCGM07] M. Cadoli, D. Calvanese, G. D. Giacomo y T. Mancini. Finite model
reasoning on UML class diagrams via constraint programming. En
R. Basili y M. T. Pazienza, editores, AI*IA 07: Proceedings of the
Tenth Congress of the Italian Association for Articial Intelligence,
volumen 4733 de LNCS, p aginas 3647. Springer, 2007.
[CDE
+
07] M. Clavel, F. Dur an, S. Eker, P. Lincoln, N. Mart-Oliet, J. Meseguer
y C. L. Talcott, editores. All About Maude - A High-Performance
Logical Framework, How to Specify, Program and Verify Systems in
Rewriting Logic, volumen 4350 de LNCS. Springer, 2007.
[CE06a] M. Clavel y M. Egea. ITP/OCL: A rewriting-based validation tool
for UML+OCL static class diagrams. En AMAST06: 11th Interna-
tional Conference on Algebraic Methodology and Software Techno-
logy, volumen 4019 de LNCS. Springer-Verlag, Kuressaare, Estonia,
Julio 2006.
Bibliografa 145
[CE06b] M. Clavel y M. Egea. Using Reection to Implement in Maude a
Rewriting-Based Validation Tool for UML+OCL Static Class Dia-
grams. En 1st International Workshop on Algebraic Foundations for
OCL and Applications. Valencia, Espa na, Marzo 2006.
[CED08a] M. Clavel, M. Egea y M. G. de Dios. Building and e-
cient component for OCL evaluation. En Programa Prelimi-
nar de 8th OCL Workshop at the UML/MoDELS Conferen-
ce: OCL Concepts and Tools: From Implementation to Eva-
luation and Comparison, ECEASST. Tolouse, Septiembre 2008.
http://maude.sip.ucm.es/~marina/pubs/ClaEgGar08.pdf.
[CED08b] M. Clavel, M. Egea y M. G. de Dios. Maude as
a Formal Meta-Tool: Lets Get Real!, Julio 2008.
http://maude.sip.ucm.es/~marina/pubs/RedMaude08.pdf.
[CET07a] M. Clavel, M. Egea y V. Torres. MOVA: A tool for modeling, mea-
suring and validating UML class diagrams. Academic Posters and
Demonstrations Session of MODELS 2007, 2007.
[CET07b] M. Clavel, M. Egea y V. Torres. The MOVA tool: A rewriting-based
UML modeling, measuring, and validation tool. Tools Demostra-
tions Session of JISBD 2007, 2007.
[CK01a] M. Cengarle y A. Knapp. A formal semantics for OCL 1.4. En
M. Gogolla y C. Kobryn, editores, UML 2001: The Unied Mode-
ling Language. Modeling Languages, Concepts, and Tools. 4th In-
ternational Conference, volumen 2185 de LNCS, p aginas 118133.
Springer, 2001.
[CK01b] M. Chan y L. Kwok. Integrating security design into the software
development process for E-Commerce systems. Information Mana-
gement and Computer Security Journal , 9(3):112122, 2001.
[CKM
+
02] S. Cook, A. Kleppe, R. Mitchell, B. Rumpe, J. Warmer y A. Wills.
The Amsterdam manifesto on OCL. En Object Modeling with the
OCL, The Rationale behind the Object Constraint Language, p aginas
115149. Springer-Verlag, Londre, Reino Unido, 2002.
[Cla03] M. Clavel. Strategies and user interfaces in Maude at work. Elec-
tronic Notes in Theoretical Computer Science, 86(4), 2003.
[Cla08] M. Clavel. The ITP Tool Home: An inductive theorem prover for
membership equational specications in Maude, 2008.
[CM02] M. Clavel y J. Meseguer. Reection in conditional rewriting logic.
TCS, 285(2):245288, 2002. ISSN 0304-3975.
146 Bibliografa
[CMP07] M. Clavel, J. Meseguer y M. Palomino. Reection in members-
hip equational logic, many-sorted equational logic, horn logic with
equality, and rewriting logic. Theoretical Computer Science, 373(1-
2):7091, 2007. ISSN 0304-3975.
[CP06] J. Chiarada y C. Pons. Improving the OCL semantics denition by
applying dynamic meta modeling and design patterns. En T. Mar-
garia, J. Padberg y G. Taentzer, editores, 6th OCL Workshop: OCL
for (Meta) Models in Multiple Application Domains, volumen 5 de
Electronic Communications of the EASST. 2006. ISSN 18632122.
[CRBG08] J. Cars, I. Ramos, A. Boronat y A. Gomez. The
MOMENT: MOdel manageMENT framework project.
http://moment.dsic.upv.es/content/section/7/75/, 2008.
[CSBE08] M. Clavel, V. Silva, C. Braga y M. Egea. Model-driven security in
practice: An industrial experience. En I. Schieferdecker y A. Hart-
man, editores, ECMDA-FA 08: Proceedings of Model Driven Archi-
tecture - Industrial Track, volumen 5095 de LNCS, p aginas 327338.
Springer-Verlag, BerlinHeidelberg, 2008.
[Deu94] A. V. Deursen. Executable Language Denitions. Tesis Doctoral,
Universidad de Amsterdam, 1994.
[FA02] J. Fern andez-Alem an. Formalizaci on de la arquitectura en cuatro
capas de UML. Tesis Doctoral, Departamento de Informatica y Sis-
temas, Universidad de Murcia, Abril 2002.
[FR07] R. France y B. Rumpe. Model-driven Development of Complex
Software: A Research Roadmap. En FOSE 07: Future of Software
Engineering, p aginas 3754. IEEE Computer Society, Washington,
DC, USA, 2007. ISBN 0-7695-2829-5.
[Fra99] R. France. A problem-oriented analysis of basic UML static mo-
deling concepts. En OOPSLA99: Conference on Object-Oriented
Programming, Systems, Languages, and Applications, volumen 34-
10 de ACM SIGPLAN notices. ACM Press, 1999.
[FSG
+
01] D. F. Ferraiolo, R. S. Sandhu, S. Gavrila, D. R. Kuhn y R. Chan-
dramouli. Proposed NIST standard for Role-Based access control.
ACM Transactions on Information and System Security, 4(3):224
274, 2001.
[GBR07] M. Gogolla, F. B uttner y M. Richters. USE: A UML-based spe-
cication environment for validating UML and OCL. Science of
Computer Programming, 69:2734, 2007.
[GR98] M. Gogolla y M. Richters. On constraints and queries in UML. En
M. Schader y A. Korthaus, editores, The Unied Modeling Langua-
ge: Technical Aspects and Applications, p aginas 109121. Physica-
Verlag, 1998.
Bibliografa 147
[Gro06] D. S. Group. The UML specication environment (USE) tool, 2006.
http://www.db.informatik.uni-bremen.de/projects/USE/.
[HCH
+
98] A. Hatnic, F. Civcllo, J. Howse, S. Kent y R. Mitchell. Reections on
the object constraint language. En S. Berlin-Heidelberg, editor, The
Unied Modeling Language. UML98: Beyond the Notation, volumen
1618 de LNCS, p aginas 162172. 1998.
[HHK98] A. Hamie, J. Howse y S. Kent. Interpreting the Ob-
ject Constraint Language. En Proceedings of Asia Pacic
Conference in Software Engineering. IEEE Press, Julio 1998.
http://www.cs.kent.ac.uk/pubs/1998/784.
[J
02] J. J urgens. UMLsec: Extending UML for secure systems develop-

ment. En UML02 : International Conference on the Unied Mo-
deling Language, volumen 2460 de LNCS, p aginas 19. Springer-
Verlag, Octubre 2002.
[J
03] J. J urgens. Developing safety-critical systems with UML. En UML03

: International Conference on the Unied Modeling Language, vo-
lumen 2847 de LNCS, p aginas 360372. Springer-Verlag, Octubre
2003.
[KBW03] A. Kleppe, W. Bast y J. B. Warmer. MDA Explained: The Model
Driven ArchitecturePractice and Promise. Addison-Wesley, 2003.
[KC99] S. Kim y D. Carrington. Formalizing the UML class diagram using
Object-Z. En R. France y B. Rumpe, editores, Unied Modeling
Language 1999, volumen 1723 de LNCS, p aginas 8398. Springer,
1999.
[Kon05] A. Konermann. The parser subsystem of the Dresden OCL 2.0 Tool-
kit - Design and implementation. Informe tecnico, Universidad de
Dresden, 2005.
[Kya06] M. Kyas. Verifying OCL specications of UML models. Tesis Doc-
toral, Universidad de Leiden-Holanda, 2006.
[MB06] S. Markovic y T. Baar. An OCL Semantics Specied with QVT. En
MoDELS06, volumen 4199 de LNCS, p aginas 661676. 2006.
[Mes92] J. Meseguer. Conditional rewriting logic as a unied model of con-
currency. Theoretical Computer Science, 96(1):73155, 1992.
[Mes98a] J. Meseguer. Membership algebra as a logical framework for equa-
tional specication. En F. Parisi-Presicce, editor, Recent Trends in
Algebraic Development Techniques, 12th International Workshop,
WADT97, Selected Papers, volumen 1376 de LNCS, p aginas 18
148 Bibliografa
[Mes98b] J. Meseguer. Research directions in rewriting logic. En U. Berger
y H. Schwichtenberg, editores, Computational Logic, Proceedings of
the NATO Advanced Study Institute on Computational Logic held
in Marktoberdorf, Germany, July 29August 6, 1997, volumen 165
de NATO ASI Series F: Computer and Systems Sciences, p aginas
[MPT08] T. Margaria, J. Padberg y G. Taentzer, editores. OCL4All: Modeling
Systems with OCL, volumen 9. Electronic Communications of the
EASST, 2008.
[Obj03] Object Management Group. Model Driven Architec-
ture guide v. 1.0.1. Informe tecnico, OMG, 2003.
http://www.omg.org/docs/omg/03-06-01.pdf.
[Obj05a] Object Management Group. MOF-Queries, Views and Transforma-
tions (QVT)-Final adopted specication. Informe tecnico, OMG,
2005. www.omg.org/docs/ptc/05-11-01.pdf.
[Obj05b] Object Management Group. Unied Modeling Language speci-
cation. Informe tecnico, OMG, Frammingam, Mass, Julio 2005.
http://www.omg.org/spec/UML/2.0.
[Obj08a] Object Management Group. Object Management Group, 2008.
http://www.omg.org.
[Obj08b] Object Management Group. Unied Modeling Language site, 2008.
http://www.uml.org.
[OCL97] Object Management Group. Object Constraint Language specica-
tion version 1.1, Septiembre 1997. Documento OMG disponible en
http://www.omg.org/cgi-bin/doc?formal/2006-05-01.
[OCL06] Object Management Group. Object Constraint Language speci-
cation version 2.0, Mayo 2006. Documento OMG disponible en
[OMG08a] OMGOCL 2 Finalization Task Force. List of open issues, 2008.
http://www.omg.org/issues/ocl2-ftf.open.html.
[OMG08b] OMGOCL 2 Revision Task Force. List of open issues, 2008.
http://www.omg.org/issues/ocl2-rtf.open.html.
[OSR92] S. Owre, N. Shankar y J. Rushby. Pvs specication and verication
system. http://pvs.csl.sri.com/, 1992.
[RCA00] G. Reggio, M. Cerioli y E. Astesiano. An algebraic semantics of
uml supporting its multiview approach. En D. Heylen, A.
Nijholt y
G. Scollo, editores, AMiLP 2000: Workshop on Language Techno-
logy, 16. Universidad de Twente, 2000.
Bibliografa 149
[RG02] M. Richters y M. Gogolla. OCL: Syntax, semantics, and tools. En
T. Clark y J. Warmer, editores, Object Modeling with the OCL: The
Rationale behind the Object Constraint Language, p aginas 4268.
Springer, 2002. ISBN 3-540-43169-1.
[Ric02] M. Richters. OCL Constraints. Tesis Doctoral, Universidad de Bre-
men, Berlin, Alemania, 2002.
[SAGM05] K. Sohr, G. J. Ahn, M. Gogolla y L. Migge. Specication and
validation of authorisation constraints using UML and OCL. En
ESORICS 05 : Proceedings of the Tenth European Symposium on
Research in Computer Security, volumen 3679 de LNCS, p aginas
[SB00] C. Snook y M. Butler. Verifying dynamic properties of UML
models by translation to the B method and toolkit. In-
forme tecnico DSSE-TR-00-12, Departamento de Electroni-
ca e Informatica, Universidad de Southhampton, 2000.
http://www.dsse.ecs.soton.ac.uk/techreports/.
[SB07] Springer-Berlin/Heidelberg, editor. OCLApps 2006: Proceedings of
the Sixth OCL Workshop OCL for (Meta-)Models in Multiple Ap-
plication Domains, volumen 4364 de LNCS. 2007. ISBN 978-3-540-
69488-5.
[SSJM04] J. Simmonds, R. V. D. Straeten, V. Jonckers y T. .Mens. Maintai-
ning consistency between UML models using description logic. Serie
Lobjet - logiciel, base de donnees, reseaux, 10(2-3):231244, 2004.
[UML07] Object Management Group. Unied Modeling Language: Infras-
tracture, Version 2.1.1, 2007. Documento OMG disponible en
[WK03] J. Warmer y A. Kleppe. The Object Constraint Language: Get-
ting Your Models Ready for MDA. Addison-Wesley, 2 edici on, 2003.
ISBN 0321179366.
[WW01] G. Wimmel y A. Wibpt. Extended description techniques for se-
curity engineering. En IFIP SEC2001: 16th International Confe-
rence on Information Security: Trusted Information: the New Deca-
de Chanllenge, p aginas 470485. Kluwer Academic Publisher, Junio
2001.
[WZCY04] H. Wang, Y. Zhang, J. Cao y J. Yang. Specifying Role-Based access
constraints with Object Constraint Language. En APWeb 04: Pro-
ceedings of the Sixth Asia-Pacic Web Conference, volumen 3007 de
LNCS, p aginas 687696. Springer-Verlag, 2004.
150 Bibliografa
Apendice A
Pruebas Auxiliares
151
152 Apendice A. Pruebas Auxiliares
A.1. Propiedades de la Funcion interpret()
En esta secci on probamos propiedades sobre la funci on interpret() que se
usan en la Seccion 2.3.4 para probar la propiedad Church-Rosser de las especi-
caciones ecuacionales generadas por esta funci on. En particular, probamos las
Proposiciones 1, 2, y 3.
Empezamos con algunas observaciones sobre la relacion entre posiciones.
Observacion 3. Sean p y p
posiciones tales que p , p
y p
, p. Entonces,
para cualquier posici on p
tal que p _ p
(resp. p
_ p
), se cumple que p
, p
(resp. p
, p)
Observacion 4. Sean p y p
posiciones tales que p , p
,p , p
, y p
, p. Sean
y
signaturas tales que, para cualquier ()

op
y
)
op
, p _ label()
y p
_ label(
). Entonces,
= .
A continuaci on probamos algunos lemas sobre la funci on interpretAux() que
nos sive como funci on auxiliar para interpret().
Lema 1. Sea T un diagrama UMLMOVA, sea una signatura tal que genSign(T)
, sea E una especicaci on ecuacional y

X una lista de variables, tales
que X = , w una expresi on CollectionLiteralParts de OCLMOVA, tal que
free(w) X, y p una posici on tal que para cualquier p
labels(), p
p.
Supongamos, adem as, que para cualquier (sub)expresi on w
en w de OCLMOVA,
y cualquier posici on p
, tal que p _ p
, se cumple que:
interpret(, E,

X, w
, p
) =
, E
, t
),
donde
1.
es una signatura tal que
y para cualquier (
)
op
,
p
_ label(), y
2. t
es un
(X)-termino.
interpretAux(, E,

X, w, p) =
, E
, t)
donde
3.
y, para cualquier (
)
op
,
p _ label(), y
4. t es un
(X)-termino.
Demostraci on. Recordemos que cualquier expresi on CollectionLiteralPartsCS
es una lista no vaca de expresiones OclExpressionCS separadas por comas. El
lema se prueba por inducci on en la longitud de esta lista. El caso interesante es
el caso base, que consideramos a continuaci on.
A.1. Propiedades de la Funci on interpret() 153
Sea w OclExpressionCS. Entonces, por la Denicion 1,
interpretAux(, E,

X, OclExpressionCS, p) =
interpret(, E,

X, OclExpressionCS, p).
N otese que, por lo supuesto en el lema,
interpret(, E,

X, OclExpressionCS, p) =
, E
, t
),
donde
y t
cumplen (1) y (2). Por tanto, el lema se cumple.

Lema 2. Sea T un diagrama UMLMOVA, una signatura, tal que genSign(T)
, E una -especicaci on ecuacional tal que genRls(T) E,

X es una
lista de variables, tales que X = , w una expresi on CollectionLiteralParts
de OCLMOVA, tal que free(w) X, y p una posici on, tal que para cualquier
p
labels(), p
p. Supongamos, adem as, que para cualquier (sub)expresi on

w
en w de OCLMOVA, y cualquier posici on p
, tal que p _ p
, se cumple que
interpret(, E,

X, w
, p
) =
, E
, t
),
donde
1. E
es una
y (E
E) es una
(

interpretAux(, E,

X, w, p) =
, E
, t),
donde
4. E
es una
y (E
E) es una
(

Demostraci on. Recordemos que cualquier expresi on CollectionLiteralPartsCS
es una lista no vaca de expresiones OclExpressionCS separadas por comas. El
lema se prueba por inducci on sobre la longitud de esta lista, de forma an aloga
al lema 1.
Lema 3. Sea T un diagram UMLMOVA, una signatura tal que genSign(T)
, E una -especicaci on ecuacional tal que genRls(T) E y E no incluye
ecuaciones cuyos smbolos top de funci on en las partes izquierdas sean collect,
forAll, exists, select o reject, seguidos por una posici on. Sea

X una lista de
variables tal que X = y X no contiene variables repetidas Sea w una
expresi on CollectionLiteralParts de OCLMOVA, tal que free(w) X y ninguna
de las variables iteradoras en w est an en X. Sea p una posici on tal que pa-
ra cualquier p
labels(), p
p. Supongamos, adem as, que para cualquier

(sub)expresi on w
en w de OCLMOVA y cualquier posici on p
, tal que p _ p
, se
cumple que
interpret(, E,

X, w
, p
) =
, E
, t
)
donde (E
E) es un conjunto de ecuaciones cuyas partes izquierdas son to-

das instancias diferentes de los siguientes dos patrones, con iterator collect,
forAll, exists, select, reject, y q cualquier secuencia de n umeros positivos sepa-
rados por un punto, y x y xs son distintas y no est an contenidas en X:
1. iterator
q
(x
1
, ..., x
n
, nil)
2. iterator
q
(x
1
, ..., x
n
, col(x, xs)
interpretAux(, E,

X, w, p) =
, E
, t),
donde (E
E) es un conjunto de ecuaciones tales que sus partes izquierdas

son todas instancias diferentes de los patrones (1) y (2).
Demostraci on. Recordemos que cualquier expresi on CollectionLiteralExpCS es
una lista no vaca de expresiones OclExpressionCS separadas por comas. El
lema se prueba por inducci on sobre la longitud de esta lista, de forma an alogal
al lema 1.
Finalmente, probamos las Proposiciones 1, 2, y 3.
Proposici on 1. Sea T un diagrama UMLMOVA, una signatura que cumple
que genSign(T) , E una especicaci on ecuacional,

X una lista de variables
tal que X = , w una expresi on OCLMOVA, tal que free(w) X, y p una
posici on tal que para cualquier p
labels(), p

interpret(, E,

X, w, p) =
, E
, t)
donde
1.
y, para cualquier (
)
op
,
p _ label(), y
2. t es un
(X)-termino.
Demostraci on. Por inducci on estructural sobre w.
VariableExpCS
Sea w simpleNameCS. Por la Denicion 1,
= , y, por las premisas,

asVar(simpleNameCS) X. Por tanto, la proposici on se cumple.
Sea w simpleNameCS. Por la Denicion 1,
= . Recordemos que
simpleNameCS debe ser, en este caso, el nombre de un literal de enumera-
cion de T. Notemos que, por las premisas, genSign(T) , lo que implica,
en particular, que simpleNameCS ()
op
, con arity(simpleNameCS) = 0.
Por tanto, la proposici on se cumple.
Sea w Bag. Por la Denicion 1,
= . Notemos que, por las

premisas, genSign(T) , lo que implica en particular, que nil ()
op
,
con arity(nil) = 0. Por tanto, la proposici on se cumple.
Sea w BagCollectionLiteralPartsCS. Por la Denicion 1,
interpret(, E,

= interpretAux(, E,

N otese que, por hipotesis de inducci on, para cualquier (sub)expresi on w
en CollectionLiteralPartsCS de OCLMOVA, y cualquier posici on p
, tal que
p _ p
, se cumple que:
interpret(, E,

X, w
, p
) =
, E
, t
),
donde
1.
y para cualquier (
)
op
,
p
_ label(), y
2. t
es un
(X)-termino.
Por tanto, podemos aplicar el Lema 1 para probar la proposici on.
IntegerLiteralExpCS
Sea w String. Por la Denicion 1,
= . Notemos que, por las pre-

misas, genSign(T) , lo que implica en particular, que asInt(String)
()
op
, con arity(asInt(String)) = 0. Por tanto, la proposici on se cumple.
StringLiteralExpCS
Sea w String. Por la Denicion 1,
= . Notemos que, por las pre-

misas, genSign(T) , lo que implica en particular, que asStr(String)
()
op
, con arity(asStr(String)) = 0. Por tanto, la proposici on se cumple.
BooleanLiteralExpCS
Sea w true. Por la Denicion 1,
= . Notemos que, por las premisas,

genSign(T) , lo que implica en particular, que true ()
op
, con
arity(true) = 0. Por tanto, la proposici on se cumple.
La prueba es an aloga para false.
IteratorExpCS
Sea w (OclExpressionCS
1
OclExpressionCS
2
)). Por la Denicion 1,
= (collect
p
, [X[ + 1)
1

2
y t = collect
p
(
X, t
1
), donde
1
,
2
, y t
1
se obtienen por recur-
si on. Notemos que, por hipotesis de inducci on,
1
X = ,
2
(X
asVar(simpleName)) = , y, para 1 i 2,
i
, y, para cualquier
(
i
)
op
, p.i _ label(), lo que implica por la Observaci on 4, que
(
1
) (
2
) = , puesto que p.1 , p.2, p.1 , p.2, y p.2 , p.1.
Notemos tambien que collect
p
, ()
op
, puesto que, por las premisas, para
cualquier p
labels(), p
p. Ademas notemos que, para 1 i 2,

collect
p
, (
i
)
op
, puesto que p p.i. Finalmente, notemos que, por
hipotesis de inducci on, t
1
es un
1
(X)-termino. Por tanto, la proposici on
se cumple.
La prueba es an aloga para los otros operadores en la categora Iterato-
rExpCS: es decir, para forAll, exists, select, y reject.
OperationCallExpCS
Sea w not OclExpressionCS
1
. Por la Denicion 1,
=
1
y t =
not(t
1
), donde
1
y t
1
se obtienen por recursi on. Notemos que, por hipote-
sis de inducci on,
1
y, para cualquier (
1
)
op
, p.1 _ label().
Notemos tambien que, por hipotesis de inducci on,
1
X = , Ademas
notemos que, por hipotesis de inducci on, t
1
es un
1
(X)-termino. Final-
mente, notemos que, por las premisas genSign(T) , lo que implica en
particular, que not , con arity(not) = 1. Por tanto, la proposici on se
cumple.
La prueba es an aloga para los siguientes operadores de la categora Ope-
rationCallExpCS: oclType, allInstances, isEmpty, notEmpty, size y
asSet.
1
or OclExpressionCS
2
). Por la Denicion 1,
=
1

2
y t = (t
1
or t
2
), donde, para 1 i 2,
i
y t
i
se obtienen
por recursi on. Notemos que, por hipotesis de inducci on, para 1 i 2,

i
y, para cualquier (
i
)
op
, p.i _ label(), lo que implica
por la Observaci on 4, que (
1
) (
2
) = , puesto que p.1 , p.2,
p.1 , p.2, y p.2 , p.1. Notemos tambien que, por hipotesis de inducci on,
para 1 i 2,
i
X = . Ademas notemos que, por hipotesis de
inducci on, para 1 i 2, t
i
es un
i
(X)-termino. Finalmente, notemos
que, por las premisas genSign(T) , lo que implica en particular, que
or , con arity(or) = 2. Por tanto, la proposici on se cumple.
La prueba es an aloga para los siguientes operadores de la categora de ex-
presiones OperationCallExpCS: and, implies, =, <, , >, , +,
, , oclIsKindOf, oclIsTypeOf, oclAsType, excludes, includes,
excluding, including, excludesAll, includesAll, y union.
AttributeCallExpCS
1
. simpleNameCS). Recordemos que simple-
NameCS debe ser, en este caso, el nombre de un atributo at de T. Por
la Denicion 1,
=
1
y t = simpleNameCS(t
1
), donde
1
y t
1
se ob-
tienen por recursi on. Notemos que, por hipotesis de inducci on,
1
y, para cualquier (
1
)
op
, p.1 _ label(). Notemos tambien
que, por hipotesis de inducci on,
1
X = , Ademas notemos que,
por hipotesis de inducci on, t
1
es un
1
(X)-termino. Finalmente notemos
que, por las premisas, genSign(T) , lo que implica en particular, que
simpleNameCS , con arity(simpleNameCS) = 1. Por tanto, la propo-
sici on se cumple.
1
. simpleNameCS). Recordemos que simple-
NameCS debe ser, en este caso, el nombre de un extremo de asociaci on
rl de T. Por la Denicion 1,
=
1
y t = simpleNameCS(t
1
), donde
1
y t
1
se obtienen por recursi on. Notemos que, por hipotesis de inducci on,

1
y, para cualquier (
1
)
op
, p.1 _ label(). Notemos tam-
bien que, por hipotesis de inducci on,
1
X = , Ademas notemos que,
por hipotesis de inducci on, t
1
es un
1
que, por las premisas, genSign(T) , lo que implica en particular, que
simpleNameCS , con arity(simpleNameCS) = 1. Por tanto, la propo-
sici on se cumple.
IfExpCS
Sea la expresi on w (if OclExpressionCS
1
2
else
OclExpressionCS
3
endif). Por la Denicion 1,
=
1

2

3
y
t = ifThenElse(t
1
, t
2
, t
3
i
y t
i
se obtienen por re-
cursi on. Notemos que, por hipotesis de inducci on, para 1 i 3,
i
y, para cualquier (
i
)
op
, p.i _ label(), lo que implica por la
Observaci on 4, que (
1
) (
2
) = , (
2
) (
3
) = , y
(
1
) (
3
) = . Notemos tambien que, por hipotesis de induc-
cion, para 1 i 3,
i
X = , Ademas notemos que, por hipotesis de
inducci on, para 1 i 3, t
i
es un
i
que, por las premisas genSign(T) , lo que implica en particular, que
ifThenElse , con arity(ifThenElse) = 3. Por tanto, la proposici on se
cumple.
Proposici on 2. Sea T un diagrama UMLMOVA, una signatura que cumple que
genSign(T) , E una -especicaci on ecuacional tal que genRls(T) E,

X
una lista de variables tal que X = , w una expresi on OCLMOVA, tal que
free(w) X, y p una posici on tal que, para cualquier p
labels(), p
p.
interpret(, E,

X, w, p) =
, E
, t)
donde
1. E
es una
y (E
E) es una
(

VariableExpCS
Sea w simpleNameCS. Por la Denicion 1, E
= E. Por tanto, la
proposici on se cumple.
= E. Por tanto, la
Sea w Bag. Por la Denicion 1, E
= E. Por tanto, la proposici on

se cumple.
interpret(, E,

= interpretAux(, E,

N otese que podemos utilizar la hipotesis de inducci on para aplicar el Le-
ma 2 y probar la proposici on.
IntegerLiteralExpCS
Sea w String. Por la Denicion 1, E
= E. Por tanto, la proposici on se

cumple.
StringLiteralExpCS

se cumple.
BooleanLiteralExpCS
Sea w true. Por la Denicion 1, E

cumple.
IteratorExpCS
1
OclExpressionCS
2
= (collect
p
, [X[ + 1)
1

2
) y
E
= genCollectRls(p,

2
) E
1
E
2
.
donde, para 1 i 2,
i
y E
i
se obtienen por recursi on, as como t
2
.
Notemos que, por hipotesis de inducci on, para 1 i 2, E
i
es un
i
-
especicaci on ecuacional, tal que E E
i
y (E
i
E) es una (
i
)-top-
especicaci on ecuacional. Notemos tambien que, por la Proposici on 1,
es una signatura, y t
2
es un
2
(X asVar(simpleName))-termino. En-
tonces, notemos que genCollectRls(p,

2
) es una
((collect
p
, [X[ + 1)-top especicaci on ecuacional. Ademas, notemos que
se da la siguiente igualdad (genCollectRls(p,

2
)
E) = (genCollectRls(p,

2
), puesto que collect
p
,
()
op
, dado que, por las premisas, para cualquier p
labels(), p
p.
En consecuencia,
E
es una
-especicaci on ecuacional;
E E
; y,
(E
E) = (genCollectRls(p,

2
) (E
1
E)
(E
2
E)) is a ((collect
p
, [X[ +1)(
1
) (
2
)) = (
)-
top-especicaci on ecuacional.
La prueba es an aloga para los otros operadores de la categora de expre-
siones IteratorExpCS, es decir, para forAll, exists, select, y reject.
OperationCallExpCS
Sea w (not OclExpressionCS
1
=
1
y E
=
E
1
, donde
1
y E
1
se obtienen por recursi on. Notemos que, por hipotesis
de inducci on, E
1
es una
1
1
y (E
1
E) es una (
1
)-top-especicaci on ecuacional. Por tanto, la
rationCallExpCS: oclType, allInstances, isEmpty, notEmpty, size,
y asSet.
1
or OclExpressionCS
2
= (
1
2
) y E
= (E
1
E
2
i
y E
i
se obtienen
E
i
es una
i
i
y (E
i
E) es una
(
i
)-top-especicaci on ecuacional. En consecuencia,
E
es una
E E
; y
(E
E) = ((E
1
E)(E
2
E)) es una ((
1
)(
2
)) = (
)-
top-especicaci on ecuacional;
rationCallExpCS: and, implies, =, <, , >, , +, , ,
oclIsKindOf, oclIsTypeOf, oclAsType, excludes, includes, exclu-
ding, including, excludesAll, includesAll y union.
AttributeCallExpCS
1
. simpleNameCS). Por la Denicion 1,
1
y E
= E
1
, donde
1
y E
1
se obtienen por recursi on. Notemos que,
por hipotesis de inducci on, E
1
es una
1
-especicaci on ecuacional tal que
E E
1
y (E
1
E) es una (
1
)-top-especicaci on ecuacional. Por
tanto, la proposici on se cumple.
1
1
y E
= E
1
, donde
1
y E
1
por hipotesis de inducci on, E
1
es una
1
-especicaci on ecuacional tal que
E E
1
y (E
1
E) es una (
1
)-top-especicaci on ecuacional. Por
IfExpCS
Sea w (if OclExpressionCS
1
2
else Ocl-
ExpressionCS
3
= (
1

2

3
) y E
=
(E
1
E
2
E
3
i
y E
i
se obtienen por recur-
si on. Notemos que, por hipotesis de inducci on, para 1 i 3, E
i
es una
i
i
y (E
i
E) es una (
i
)-
top-especicaci on ecuacional. En consecuencia,
E
es una
E E
; y
(E
E) = ((E
1
E) (E
2
E)) (E
3
E)) es una ((
1
)
(
2
) (
3
)) = (
)-top-especicaci on ecuacional.
que genSign(T) , y E una -especicaci on ecuacional, tal que genRls(T)
E y E no incluye ecuaciones cuyas smbolos de funci on top en las partes
izquierdas sean collect, forAll, exists, select, o reject, seguidos por una posici on.
Sea tambien

X una lista de variables tal que X = , y X no contiene variables
repetidas. Sea w una expresi on OCLMOVA tal que free(w) X y ninguna de las
variable iteradoras en w est an en X. Sea p una posici on tal que, para cualquier
p
labels(), p

interpret(, E,

X, w, p) =
, E
, t)
donde (E
E) es un conjunto de ecuaciones tales que sus partes izquierdas son

todas diferentes instancias de los siguientes dos patrones:
1. iterator
q
(x
1
, ..., x
n
, nil)
2. iterator
q
(x
1
, ..., x
n
, col(x, xs)
donde iterator collect, forAll, exists, select, reject y q es cualquier secuencia
de n umeros positivos separados por puntos, y x y xs son distintas y no est an
contenidas en la lista X.
VariableExpCS
= E. Por tanto, la
= E. Por tanto, la

se cumple.
interpret(, E,

= interpretAux(, E,

IntegerLiteralExpCS

cumple.
StringLiteralExpCS

se cumple.
BooleanLiteralExpCS

cumple.
IteratorExpCS
1
OclExpressionCS
2
= (collect
p
, [X[ + 1)
1

2
) y
E
= genCollectRls(p,

2
) E
1
E
2
.
donde, para 1 i 2,
i
y E
i
se obtienen por recursi on, as como t
2
.
Notemos que, por hipotesis de inducci on, para 1 i 2, (E
i
E) es un
conjunto de ecuaciones tal que sus partes izquierdas son todas instancias
diferentes de los patrones (1) y (2). Notemos tambien que, por la de-
nicion, el resultado de genCollectRls(p,

2
) es un
conjunto de ecuaciones cuyos unicos elementos son una instancia collect del
patr on (1) y una instancia collect del patr on (2). Entonces, notemos que,
por las Proposiciones 1 y 2, para 1 i 2, (E
i
E) son (
i
)-top espe-
cicaciones ecuacionales y, para cualquier (
i
)
op
, p.i _ label(),
lo que implica por la Observaci on 4, que (
1
) (
2
) = , puesto
que p.1 , p.2, p.1 , p.2, y p.2 , p.1. Finalmente, notemos que, por las
premisas, collect
p
, ()
op
y, para 1 i 2, collect
p
, (
i
)
op
, puesto
que p p.i. Por tanto, la proposici on se cumple.
La prueba es an aloga para los otros operadores de la categora de expre-
siones IteratorExpCS, es decir, para forAll, exists, select, y reject.
OperationCallExpCS
1
=
1
y E
=
E
1
, donde
1
y E
1
se obtienen por recursi on. Notemos que, por hipotesis
de inducci on, (E
1
E) es un conjunto de ecuaciones tal que todas sus
partes izquierdas son diferentes instancias de los patrones (1) y (2). Por
rationCallExpCS: oclType, allInstances, isEmpty, notEmpty, size,
y asSet.
1
or OclExpressionCS
2
= (
1
2
) y E
= (E
1
E
2
i
y E
i
se obtienen
(E
i
E) es un conjunto de ecuaciones tal que sus partes izquierdas son
todas instancias diferentes de los patrones (1) y (2). Entonces, notemos
A.2. Propiedades de la Funci on interpret+() 163
que, por las Proposiciones 1 y 2, para 1 i 2, (E
i
E) son (
i
)-
top especicaciones ecuacionales y, para cualquier (
i
)
op
, p.i _
label(), lo que implica por la Observaci on 4, que (
1
) (
2
) = ,
puesto que p.1 , p.2, p.1 , p.2, y p.2 , p.1. Por tanto, la proposici on se
cumple.
rationCallExpCS: and, implies, =, <, , >, , +, , ,
oclIsKindOf, oclIsTypeOf, oclAsType, excludes, includes, exclu-
ding, including, excludesAll, includesAll y union.
AttributeCallExpCS
1
1
y E
= E
1
, donde
1
y E
1
se obtienen por recursi on. Notemos que, por
hipotesis de inducci on, (E
1
E) es un conjunto de ecuaciones tal que sus
partes izquierdas son todas instancias diferentes de los patrones (1) y (2).
1
1
y E
= E
1
, donde
1
y E
1
por hipotesis de inducci on, (E
1
E) es un conjunto de ecuaciones tal que
todas sus partes izquierdas son instancias diferentes de los patrones (1)
y (2). Por tanto, la proposici on se cumple.
IfExpCS
1
2
else Ocl-
ExpressionCS
3
= (
1

2

3
) y E
=
(E
1
E
2
E
3
i
y E
i
se obtienen por recursi on.
Notemos que, por hipotesis de inducci on, para 1 i 2, (E
i
E) es un
conjunto de ecuaciones tal que sus partes izquierdas son todas instancias
diferentes de los patrones (1) y (2). Entonces, notemos que, por las Pro-
posiciones 1 y 2, para 1 i 3, (E
i
E) son (
i
)-top especicaciones
ecuacionales y, para cualquier (
i
)
op
1
)(
2
) = , (
2
)(
3
) = ,
y (
1
) (
3
) = . Por tanto, la proposici on se cumple.
A.2. Propiedades de la Funcion interpret+()
En esta secci on probamos propiedades sobre la funci on interpret+() que
se usan en la Seccion 2.3.4 para probar la terminaci on de las especicaciones
ecuacionales generadas por esta funci on (y consecuentemente, por la funci on
interpret()). En particular, probamos las Proposiciones 5 y 6. Recordemos que
la nocion de orden de reduccion usada realmente para probar la propiedad de
terminaci on es la de un orden de reduccion rpo, que viene denido como sigue:
Denicion 3. Sea una signatura. Una -precedencia es un orden parcial
estricto sobre , y un -estatus es una funci on que traduce cada a mul
o lex
, para alguna permutaci on on 1, ..., n, donde n = arity(). Ahora, sea

< un precedencia bien fundada sobre y sea un estatus sobre . Tambien,
sean s f(s
1
, . . . , s
n
) y t -terminos. Entonces, s >
rpo
t si y solo si una de las
siguientes clausulas se cumple
s
i
t o s
i
>
rpo
t, para alg un 1 i n. (A.1)
t g(t
1
, . . . , t
m
) y alguna de las siguientes clausulas se cumple:
f > g y s >
rpo
t
i
, para todo 1 i m. (A.2)
f = g, (f) = mul, y s
1
, . . . , s
n
) >
rpo
t
1
, . . . , t
n
). (A.3)
f = g, (f) = lex
, y existe 1 i n, tal que: (A.4)

s
(j)
= t
(j)
, para 1 j < i, y
s
(i)
>
rpo
t
(i)
y
s >
rpo
t
(j)
, para i < j n, (A.5)
donde rpo
es la extensi on a multiconjunto de >

rpo
.
La propiedad interesante de los ordenes de reduccion rpo es que, dada una
precedencia < y un estatus sobre , existe ex actamente un unico orden de
reduccion <
rpo
sobre T
. La siguiente observaci on es sobre el orden de reduccion

inducido <
rpo
a partir de las uniones respectivas de las funciones de precedencia
y estatus. Esta observaci on se usa en la Proposici on 6.
Observacion 5. Para i = 1, 2, sean
i
, E
i
, T
i
, y T
i
repectivamente, una sig-
natura, una
i
-especicaci on ecuacional, una
i
-precedencia, y una
i
-funci on
de estatus. Tambien, sea >
(Pi,Ti)
rpo
el orden de reducci on inducido de T
i
y T
i
.
Supongamos que (
i
, E
i
) es compatible con >
(Pi,Ti)
rpo
y tambien que (
1

2
)
es una signatura, (T
1
T
2
) es una (
1

2
)-precedencia, y (T
1
T
2
) es una
(
1
2
)-funci on de estatus. Entonces, ((
1
2
), (E
1
E
2
)) es compatible con
el orden de reducci on >
((P1P2),(T1T2))
rpo
que inducen (T
1
T
2
) y (T
1
T
2
)).
Demostraci on. Supongamos que l = r es una ecuaci on en E
1
(el otro caso
es completamente an alogo). Puesto que, por las premisas, (T
1
T
2
) es una
(
1
2
)-precedencia, y (T
1
T
2
) es una (
1
2
)-funci on de estatus, entonces,
para cualquier smbolo
1
(y, a fortiori, para cualquier smbolo que ocurra en
l o r), ,
2
o T
2
() = T
1
() y T
2
() = T
1
(). Entonces l >
((P1P2),(T1T2))
rpo
r
se cumple puesto que, por las premisas, l >
(P1,T1)
rpo
r se cumple.
La siguiente observaci on se usa en la Proposici on 6.
Observacion 6. Sea una signatura, T una -precedencia, T una -funci on
de estatus,

X una lista de variables x
1
, . . . , x
n
, x, xs tal que X = , y p una
posici on tal que p , labels(). Ahora, sea T
la precedencia (iterator
p
, max(T+
1)) T) y sea T
la funci on de estatus (iterator

p
, lex) T , donde iterator
collect, forAll, exists, select, reject. Entonces, para cualquier (

X)-termino t,
iterator
p
(x
1
, . . . , x
n
, col(x, xs)) >
(P
,T
)
rpo
t
Demostraci on. Por inducci on estructural sobre t.
Sea t una variable de

X. Entonces, por la Clausula (A.1) de la Denicion 3,
la observaci on se cumple.
Sea t una constante. Entonces, por la Clausula (A.2) de la Denicion 3, la
observaci on se cumple puesto que iterator
p
es una precedencia asignada
en T
que es mayor que la precedencia asignada a cualquier smbolo en .

Sea t un termino f(t
1
, . . . , t
n
). Entonces, por la Clausula (A.2) de la De-
nicion 3, la observaci on se cumple puesto que iterator
p
es una precedencia
asignada en T
que es mauor que la precedencia asignada a cualquier

smbolo de y, por inducci on , para todo 1 i n,
iterator
p
(x
1
, . . . , x
n
, col(x, xs)) >
(P
,T
)
rpo
t
i
A continuaci on, probamos algunos lemas sobre la funci on interpretAux+()
que nos sirve como funci on auxiliar para interpret+(). El Lema 4 se usa en la
Proposici on 5, y el Lema 5 en la Proposici on 6.
Lema 4. Sea T un diagrama UMLMOVA, una signatura, tal que genSign(T)
, E una especicaci on ecuacional, T una -precedencia, T una -funci on
de estatus,

X una lista de variables, tal que X = , w sea una expre-
si on CollectionLiteralParts de OCLMOVA tal que free(w) X, y p una posici on
tal que, para cualquier p
labels(), p
p. Supongamos, adem as, que para

cualquier (sub)expresi on w
, tal que
p _ p
, se cumple que

X, w
, p
) =
, E
, T
, T
, t
),
donde
1. T
es una
y (T
T) es una (
)-
precedencia; y
2. T
es una
-funci on de estatus tal que T T
y (T
T ) es una
(
)-funci on de estatus.

X, w, p) =
, E
, T
, T
, t),
donde
1. T
es una
y (T
T) es una (
)-
precedencia; y
2. T
es una
y (T
T ) es una (
)-
funci on de estatus.
Demostraci on. Recordemos que cualquier expresi on CollectionLiteralExpCS-es
una lista no vaca de expresiones OclExpressionCS que est an separadas por
comas. El lema se prueba por inducci on en la longitud de esta lista, de forma
an aloga al lema 1.
Lema 5. Sea T un diagrama UMLMOVA, una signatura tal que genSign(T)
, E una especicaci on ecuacional, T una -precedencia T una -funci on de
estatus

X una lista de variables tal que X = , w una expresi on Collection-
LiteralParts de OCLMOVA tal que free(w) X, y p una posici on tal que, para
cualquier p
labels(), p
p. Adem as supongamos que (, E) es compatible

con el orden de reducci on <
rpo
inducido por T y T . Por ultimo, supongamos
que, para cualquier expresi on w
, tal
que p _ p
, se cumple que

X, w
, p
) =
, E
, T
, T
, t
)
donde
1. E
es compatible con el orden de reducci on <

rpo
inducido por T
y T
.

X, w, p) =
, E
, T
, T
, t)
donde
1. E

rpo
inducido por T
y T
.
Demostraci on. Recordemos que cualquier expresi on CollectionLiteralExpCS es
una lista no vaca de expresiones OclExpressionCS separadas por comas. El lema
se prueba por inducci on sobre la longitud de esta lista, de forma an analoga al
lema 1.
Ahora probamos las Proposiciones 5 y 6.
Proposici on 5. Sea T un diagrama UMLMOVA, una signatura, que cumple
que genSign(T) , E una especicaci on ecuacional, T una -precedencia, T
una -funci on de estatus,

X una lista de variables, tal que X = , w una
expresi on OCLMOVA tal que free(w) X y p una posici on tal que, para cualquier
p
labels(), p


X, w, p) =
, E
, T
, T
, t)
donde
1. T
es una
y (T
T) es una (
)-
precedencia; y
2. T
es una
y (T
T ) es una (
)-
funci on de estatus.
VariableExpCS
Sea w simpleNameCS. Por la Denicion 2, T
= T y T
= T . Por tanto,
la proposici on se cumple.
Sea w simpleNameCS. Por la Denicion 2, T
= T y T
= T . Por tanto,
la proposici on se cumple.
Sea w Bag. Por la Denicion 2, T
= T y T
= T . Por tanto, la

= interpretAux+(, E, T, T ,

IntegerLiteralExpCS
Sea w String. Por la Denicion 2, T
= T y T
= T . Por tanto, la
StringLiteralExpCS
Sea w String. Por la Denicion 2, T
= T y T
= T . Por tanto, la
BooleanLiteralExpCS
Sea w true. Por la Denicion 2, T
= T y T
= T . Por tanto, la
IteratorExpCS
1
OclExpressionCS
2
T
= (collect
p
, max(T
1
T
2
) + 1) T
1
T
2
y
T
= (collect
p
, lex) T
1
T
2
,
donde, para 1 i 2, T
i
y T
i
por hipotesis de inducci on, para 1 i 2, T
i
es una
i
-precedencia tal
que T T
i
y (T
i
T) es una (
i
)-precedencia. Notemos tambien
que, por hipotesis de inducci on, para 1 i 2, T
i
es una
i
-funcion de
estatus tal que T T
i
y (T
i
T ) es una (
i
Ademas notemos que, por la Proposici on 1, para 1 i 2, para cualquier
(
i
)
op
(
1
) (
2
Finalmente, notemos que, collect
p
, ()
op
, puesto que, por las premisas,
para cualquier p
labels(), p
p, y, para 1 i 2, collect
p
,
(
i
)
op
, puesto que p p.i. Por tanto, la proposici on se cumple.
La prueba es an aloga para los otros operadores de la categora Iterato-
rExpCS, es decir, para forAll, exists, select, y reject.
OperationCallExpCS
1
). Por la Denicion 2, T
= T
1
y T
= T
1
,
donde T
1
y T
1
se obtienen por recursi on. Notemos que, por hipotesis de
inducci on, T
1
es una
1
1
y (T
1
T) es una
(
1
)-precedencia. Notemos tambien que, por hipotesis de inducci on,
T
1
es una
1
-funcion de estatus tal que T T
1
y (T
1
T ) es una (
1
)-
funci on de estatus. Por tanto, la proposici on se cumple.
La prueba es an aloga para los siguientes operadores de OperationCa-
llExpCS: oclType, allInstances, isEmpty, notEmpty, size, y asSet.
1
or OclExpressionCS
2
T
= T
1
T
2
y T
= T
1
T
2
, donde, para 1 i 2, T
i
y T
i
se obtienen por
recursi on. Notemos que, por hipotesis de inducci on, para 1 i 2, T
i
es
una
i
i
y (T
i
T) es una (
i
)-precedencia.
Notemos tambien que, por hipotesis de inducci on, para 1 i 2, T
i
es una
i
i
y (T
i
T ) es una (
i
)-funci on de
estatus. Ademas notemos que, por la Proposici on 1, para 1 i 2, para
cualquier (
i
), p.i _ label(), lo que implica por la Observaci on 4,
que (
1
) (
2
La prueba es an aloga para los siguientes operadores OperationCallExpCS:
y, implies, =, <, , >, , +, , , oclIsKindOf, ocl-
IsTypeOf, oclAsType, excludes, includes, excluding, including, ex-
cludesAll, includesAll y union.
AttributeCallExpCS
1
. simpleNameCS). Por la Denicion 2, T
=
T
1
y T
= T
1
, donde T
1
y T
1
por hipotesis de inducci on, T
1
es una
1
1
y
(T
1
T) es una (
1
)-precedencia. Notemos tambien que, por hipotesis
de inducci on, T
1
es una
1
1
y (T
1
T )
es una (
1
)-funci on de estatus. Por tanto, la proposici on se cumple.
1
. simpleNameCS). Por la Denicion 2, T
=
T
1
y T
= T
1
, donde T
1
y T
1
por hipotesis de inducci on, T
1
es una
1
1
y
(T
1
T) es una (
1
)-precedencia. Notemos tambien que, por hipotesis
de inducci on, T
1
es una
1
1
y (T
1
T )
es una (
1
)-funci on de estatus. Por tanto, la proposici on se cumple.
IfExpCS
1
2
else Ocl-
ExpressionCS
3
endif). Por la Denicion 2, T
= T
1
T
2
T
3
y T
=
T
1
T
2
T
3
, donde, para 1 i 3, T
i
y T
i
se obtienen por recursi on.
Notemos que, por hipotesis de inducci on, para 1 i 3, T
i
es una
i
i
y (T
i
T) es una (
i
)-precedencia.
Notemos tambien que, por hipotesis de inducci on, para 1 i 3, T
i
es
una
i
i
y (T
i
T ) es una (
i
)-funci on
de estatus. Ademas notemos que, por la Proposici on 1, para 1 i 3,
para cualquier (
i
), p.i _ label(), lo que implica por la Ob-
servaci on 4, que (
1
) (
2
) = , (
2
) (
3
) = , y
(
1
) (
3
) = . Por tanto, la proposici on se cumple.
Proposici on 6. Sea T un diagrama UMLMOVA, una signatura que cumple
que genSign(T) , E una especicaci on ecuacional, T una -precedencia,
T una -funci on de estatus

X una lista de variables tal que X = , w
una expresi on de OCLMOVA tal que free(w) X, y p una posici on tal que, para
cualquier p
labels(), p
p. Adem as, supongamos que (, E) es compatible

con el orden de reducci on <
rpo
inducido por T y T . Entonces, se cumple que

X, w, p) =
, E
, T
, T
, t)
donde
1. E

rpo
inducido por T
y T
.
VariableExpCS
= E. Por tanto, la
= E. Por tanto, la

se cumple.

= interpretAux+(, E, T, T ,

IntegerLiteralExpCS

cumple.
StringLiteralExpCS

se cumple.
BooleanLiteralExpCS

cumple.
IteratorExpCS
1
OclExpressionCS
2
= (collect
p
, [X[ + 1)
1

2
),
E
= genCollectRls(p,

2
) E
1
E
2
T
= (collect
p
, max(T
1
T
2
) + 1) T
1
T
2
y
T
= (collect
p
, lex) T
1
T
2
donde, para 1 i 2,
i
, E
i
, T
i
, y T
i
se obtienen por recursi on, as como
t
2
.
Procedemos en dos pasos: primero, probamos que (E
1
E
2
) es compatible
con el orden de reduccion inducido por T
y T
, y, entonces, probamos que

genCollectRls(p,

2
) es tambien compatible con es-
te orden de reduccion.
Paso 1. Notemos que, por la Proposici on 1, para 1 i 2,
i
es una
signatura tal que
i
y, para cualquier (
i
)
op
, p.i _ label(),
lo que implica por la Observaci on 4, que (
1
) (
2
) = , puesto
que p.1 , p.2, p.1 , p.2, y p.2 , p.1. Por tanto, (
1
2
) es una signatura.
Notemos tambien que, por la Proposici on 2, para 1 i 2, E
i
es una
i
-
especicaci on ecuacional. Por tanto, puesto que (
1
2
) es una signatura,
(E
1
E
2
) es una (
1

2
)-especicaci on ecuacional.
Notemos tambien que, por la Proposici on 5, para 1 i 2, T
i
es una
i
i
y (T
i
T) es una (
i
)-precedencia.
Por tanto, puesto que (
1
) (
2
) = , (T
i
T
2
) es una (
1
2
)-
precedencia.
i
es una
i
i
y (T
i
T ) es una (
i
)-funci on
de estatus. Por tanto, puesto que (
1
) (
2
) = , (T
i
T
2
) es
una (
1

2
Finalmente, notemos que, por hipotesis de inducci on, para 1 i 2,
E
i
es compatible con el orden de reduccion <
rpo
inducido por T
i
y T
i
.
Por tanto, por la Observaci on 5, (E
1
E
2
) es compatible con el orden de
reduccion inducido por (T
1
T
2
) y (T
1
T
2
), y, a fortiori, con el orden
de reduccion inducido por T
= ((collect
p
, max(T
1
T
2
) + 1) T
1
T
2
)
y T
= ((collect
p
, lex) T
1
T
2
), puesto que por las premisas, para
cualquier p
labels(), p
p, y, para 1 i 2, collect
p
, (
i
)
op
,
puesto que p p.i y, para cualquier (
i
)
op
, p.i _ label().
Paso 2. Debemos mostrar que l >
(P
,T
)
rpo
r, para cualquier ecuaci on l = r
in genCollectRls(p,

2
). Notemos que:
collect
p
(x
1
, . . . , x
n
, nil) >
(P
,T
)
rpo
nil se cumple por la Clausula (A.1)
de la Denicion 3.
collect
p
(x
1
, . . . , x
n
, col(x, xs)) >
(P
,T
)
rpo
union(t
2
, collect
p
(x
1
, . . . , x
n
,
xs)) se cumple por la Clausula (A.2) de la Denicion 3, puesto que:
collect
p
> union se cumple puesto que union genSign(T)

1

2
, y collect
p
posee una precedencia asignada en T
que es mayor que la precedencia asignada a cualquier smbolo en
1

2
; y
collect
p
(x
1
, . . . , x
n
, col(asVar(simpleName), xs)) >
(P
,T
)
rpo
t
2
se cum-
ple por la Observaci on 6, puesto que, por la Proposici on 1, t
2
es
un
2
-termino, posiblemente con variables contenidas en el con-
junto x
1
, . . . , x
n
, asVar(simpleName).
collect
p
(x
1
, . . . , x
n
, col(x, xs)) >
(P
,T
)
rpo
collect
p
(x
1
, . . . , x
n
, xs)
se cumple por la Clausula (A.3) de la Denicion 3, puesto que
col(x, xs) >
(P
,T
)
rpo
xs se cumple por la Clausula (A.1) de la De-
nicion 3.
Por tanto, genCollectRls(p,

2
) es tambien compa-
tible con el orden de reduccion inducido por T
y T
, y la proposici on se
cumple.
La prueba es an aloga para los otros operadores IteratorExpCS: es decir,
forAll, exists, select, y reject.
OperationCallExpCS
1
=
1
, E
= E
1
,
T
= T
1
, T
= T
1
, donde
1
, E
1
, T
1
y T
1
se obtienen por recursi on. Note-
mos que, por la Proposici on 1,
1
es una signatura; por la Proposici on 2,
E
1
es una
1
-especicaci on ecuacional; y, por la Proposici on 5, T
1
es a
1
-precedencia y T
1
es una
1
-funcion de estatus. Finalmente, notemos
que, por hipotesis de inducci on, E
1
is compatible con el orden de reduccion
<
rpo
inducido por T
1
y T
1
. Por tanto, la proposici on se cumple.
llExpCS: oclType, allInstances, isEmpty, notEmpty, size, y asSet.
1
or OclExpressionCS
2
= (
1

2
), E
= (E
1
E
2
), T
= (T
1
T
2
), y T
= (T
1
T
2
),
donde, para 1 i 2,
i
, E
i
, T
i
, y T
i
se obtienen por recursi on. Notemos
que, por la Proposici on 1, para 1 i 2,
i
es una signatura; tal que

i
y, para cualquier (
i
)
op
1
) (
2
) = , puesto que p.1 , p.2,
p.1 , p.2, y p.2 , p.1. Por tanto, (
1

2
) es una signatura.
i
es una
i
-
especicaci on ecuacional. Por tanto, puesto que (
1
2
) es una signatura,
(E
1
E
2
) es una (
1

2
i
es una
i
i
y (T
i
T) es una (
i
)-precedencia.
1
) (
2
) = , (T
1
T
2
) es una (
1
2
)-
precedencia.
i
es una
i
i
y (T
i
T ) es una (
i
)-funci on
de estatus. Por tanto, puesto que (
1
) (
2
) = , (T
i
T
2
) es
una (
1

2
Finalmente, notemos que, por hipotesis de inducci on, para 1 i 2, E
i
is
compatible con el orden de reduccion <
rpo
inducido por T
i
y T
i
. Por tanto,
por la Observaci on 5, (E
1
E
2
) es compatible con el orden de reduccion
inducido por (T
1
T
2
) y (T
1
T
2
). Por tanto, la proposici on se cumple.
llExpCS: y, implies, =, <, , >, , +, , , oclIsKindOf,
oclIsTypeOf, oclAsType, excludes, includes, excluding, including,
excludesAll, includesAll y union.
AttributeCallExpCS
1
1
, E
= E
1
, T
= T
1
, T
= T
1
, donde
1
, E
1
, T
1
y T
1
se obtienen
por recursi on. Notemos que, por la Proposici on 1,
1
es una signatura;
por la Proposici on 2, E
1
es una
1
-especicaci on ecuacional; y, por la
Proposici on 5, T
1
is a
1
-precedencia y T
1
es una
1
-funcion de estatus.
Finalmente, notemos que, por hipotesis de inducci on, E
1
es compatible con
el orden de reduccion <
rpo
inducido por T
1
y T
1
. Por tanto, la proposici on
se cumple.
1
1
, E
= E
1
, T
= T
1
, T
= T
1
, donde
1
, E
1
, T
1
y T
1
se obtienen
por recursi on. Notemos que, por la Proposici on 1,
1
es una signatura;
por la Proposici on 2, E
1
es una
1
-especicaci on ecuacional; y, por la
Proposici on 5, T
1
es una
1
-precedencia y T
1
es una
1
-funcion de estatus.
Finalmente, notemos que, por hipotesis de inducci on, E
1
es compatible con
el orden de reduccion <
rpo
inducido por T
1
y T
1
. Por tanto, la proposici on
se cumple.
IfExpCS
1
2
else OclExpres-
sionCS
3
= (
1
3
), E
= (E
1
E
2
E
3
), T
= (T
1
T
2
T
3
), y T
= (T
1
T
2
T
3
i
,
E
i
, T
i
, y T
i
se obtienen por recursi on. Notemos que por la Proposici on 1,
para 1 i 3,
i
es una signatura; tal que
i
y, para cualquier
(
i
)
op
(
1
)(
2
) = , (
1
)(
3
) = , y (
2
)(
3
) = .
Por tanto, (
1

2

3
) es una signatura.
i
es una
i
-especicaci on ecuacional. Por tanto, puesto que (
1

2

3
) es una
signatura, (E
1
E
2
E
3
) es una (
1
3
i
es una
i
i
y (T
i
T) es una (
i
)-precedencia.
1
) (
2
) = , (
1
) (
3
) = , y
(
2
) (
3
) = , (T
i
T
2
T
3
) es una (
1
3
)-precedencia.
i
es una
i
i
y (T
i
T ) es una (
i
)-funci on de
estatus. Por tanto, puesto que (
1
)(
2
) = , (
1
)(
3
) =
, y (
2
) (
3
) = , (T
i
T
2
T
3
) es una (
1
3
)-funci on
de estatus.
Finalmente, notemos que, por hipotesis de inducci on, para 1 i 3, E
i
is compatible con el orden de reduccion <
rpo
inducido por T
i
y T
i
. Por
tanto, por la Observaci on 5, (E
1
E
2
E
3
) is compatible con el orden
de reduccion inducido por (T
1
T
2
T
3
) y (T
1
T
2
T
3
). Por tanto, la
A.3. Propiedades de genRls(T)
En esta secci on probamos una propiedad sobre genRls(T) que se usa en la
Seccion 2.3.4 para probar la terminaci on de las especicaciones ecuacionales
generadas por esta funci on (y en consecunecia por la funci on interpret()). En
particular, probamos la Proposici on 7.
Proposici on 7. Sea T un diagrama UMLMOVA. Entonces, el TRS genRls(T) es
compatible con el orden de reducci on <
rpo
inducido por genPrec(T) y genStat(T).
Demostraci on. Simplemente consider andola, podemos ver que la precedencia
genPrec(T) est a bien fundada. Ahora mostramos que para cualquier ecuaci on
l = r en genRls(T), l >
rpo
r se cumple.
equal
Consideremos las ecuaciones que denen equal.
equal(nil,nil) >
rpo
true se cumple por la Clausula (A.1) de la Denicion 3
puesto que nil true se cumple.
equal(nil, col(x, xs)) >
rpo
false se cumple por la Clausula (A.2) de la De-
nicion 3 puesto que nil false se cumple. La prueba del caso simetrico
es an aloga.
equal(col(x, xs),col(y,ys)) >
rpo
and(equal(x,y),equal(xs,ys)) se cumple por
la Clausula (A.2) de la Denicion 3 puesto que equal[3] > y[2], y
rpo
equal(x,y) se cumple por la Clausu-
la (A.4) de la Denicion 3 puesto que equal equal, 1, 2 = 1, 2
y, col(x, xs) >
rpo
x se cumple por la Clausula (A.1) de la Denicion 3;
an alogamente col(y, ys) >
rpo
y se cumple.
rpo
equal(xs,ys) se cumple por la Clausu-
la (A.4) de la Denicion 3 puesto que equal equal, 1, 2 = 1, 2,
col(x, xs) >
rpo
xs se cumple, y col(y, ys) >
rpo
ys tambien se cumple
por la Clausula (A.1) de la Denicion 3.
A.3. Propiedades de genRls(T) 175
excludes
Consideremos la ecuaci on que dene excludes.
excludes(xs, y) >
rpo
not(includes(xs,y)) se cumple por la Clausula (A.2)
puesto que excludes[4] > not[1], y
excludes(xs, y) >
rpo
includes(xs, y) se cumple por la Clausula (A.2)
puesto que excludes[4] > includes[3], excludes(xs, y) >
rpo
xs y exclu-
des(xs, y) >
rpo
y se cumple por la Clausula (A.1) de la Denicion 3.
includes
Consideremos las ecuaciones que denen includes.
includes(nil, y) >
rpo
false se cumple por la Clausula A.1 de la Denicion 3,
puesto que nil false.
includes(col(x, xs), y) >
rpo
ifThenElse(equal(x, y), true, includes(xs, y))
se cumple por la Clausula (A.2) de la Denicion 3 puesto que includes[3] >
ifThenElse[1], y
rpo
equal(x, y) se cumple por la Clausula (A.4)
de la Denicion 3 puesto que includes[3] equal[3], 1, 2 = 2, 1
y, y = y, col(x, xs) >
rpo
x por la Clausula (A.1) de la Denicion 3;
rpo
true se cumple por la Clausula (A.2) de
la Denicion 3 puesto que y true; y
rpo
includes(xs, y) se cumple por la Clausu-
la (A.4) de la Denicion 3 puesto que includes includes, 1, 2 =
2, 1 y col(x, xs) >
rpo
xs.
excluding
Consideremos las ecuaciones que denen excluding.
excluding(col(x, xs), y) >
rpo
ifThenElse(equal(x, y), excluding(xs, y), col(x,
excluding(xs, y))), por la Clausula (A.2) de la Denicion 3 puesto que ex-
cluding[3] > ifThenElse[1] se cumple, y
rpo
equal(x, y) se cumple por la Clausula
(A.4) de la Denicion 3 puesto que excluding[3] equal[3], 1, 2 =
2, 1 y, col(x, xs) >
rpo
x se cumple por la Clausula (A.1) de la
Denicion 3;
rpo
excluding(xs,y); se cumple por la Clau-
sula (A.4) de la Denicion 3 puesto que excluding excluding,
1, 2 = 2, 1 y, col(x, xs) >
rpo
xs y y = y se cumple por la
Clausula (A.1) de la Denicion 3;
rpo
col(x,excluding(xs, y)) se cumple por la
Clausula (A.4) de la Denicion 3 puesto que excluding[3] > col[1] y
rpo
x por la Clausula (A.1) de la Deni-
cion 3, y excluding(col(x, xs), y) >
rpo
excluding(xs, y) se cumplen
por la Clausula (A.4) de la Denicion 3, puesto que excluding ex-
cluding, 1, 2 = 2, 1 y, col(x, xs) >
rpo
xs y y = y se cumplen
including
Consideremos las ecuaciones que denen including.
including(xs,x) >
rpo
col(x,xs) por la Clausula (A.2) de la Denicion 3,
puesto que se cumple que including[3] > col[1], including(xs,x) >
rpo
xs y
including(xs,x) >
rpo
x por la Clausula (A.1) de la Denicion 3.
excludesAll
Consideremos las ecuaciones que denen excludesAll.
excludesAll(xs, col(y,ys)) >
rpo
and(excludes(xs,y),excludesAll(xs,ys)) se
cumple por la Clausula A.2 de la Denicion 3, puesto que excludesAll[4] >
y[2] se cumple, y
excludesAll(xs,col(y, ys)) >
rpo
excludes(xs,y) se cumple por la Clau-
sula A.2 de la Denicion 3 puesto que excludesAll[4] > excludes[4],
1, 2 = 1, 2, y las desigualdades excludesAll(xs,col(y, ys)) >
rpo
xs y tambien excludesAll(xs,col(y, ys)) >
rpo
y se cumplen por la
Clausula A.1 de la Denicion 3, tambien
excludesAll(xs,col(y, ys)) >
rpo
excludesAll(xs,ys) por la Clausula A.4
de la Denicion 3, puesto que excludesAll excludesAll, 1, 2 =
2, 1 y, puesto que xs = xs y col(y,ys) >
rpo
ys se cumple por la
Clausula A.1 de la Denicion 3 como antes.
La prueba para las ecuaciones que denen includesAll es completamente an alo-
ga.
union
Consideremos ahora las ecuaciones que denen union.
union(nil,xs) >
rpo
xs se cumple por la Clausula A.1 de la Denicion 3;
union(x, xs) >
rpo
col(x,xs) se cumple por la Clausula (A.2) de la Deni-
cion 3 puesto que union[2] > col[1], union(x, xs) >
rpo
x y union(x, xs) >
rpo
xs se cumplen por la Clausula (A.1) de la Denicion 3;
union(col(x, xs),ys) >
rpo
col(x,union(xs,ys)) se cumple por la Clausu-
la (A.2) de la Denicion 3 puesto que union[2] > col[1] y
A.3. Propiedades de genRls(T) 177
rpo
x se cumple por la Clausula (A.1) de la
Denicion 3, y
rpo
union(xs,ys) se cumple por la Clausula (A.4)
de la Denicion 3 puesto que union union, ys = ys y col(x,xs) >
rpo
xs por la Clausula (A.1) de la Denicion 3.
isEmpty
Consideremos ahora las ecuaciones que denen isEmpty.
isEmpty(nil) >
rpo
true se cumple por la Clausula (A.1) de la Denicion 3
puesto que nil true y
isEmpty(col(x,xs)) >
rpo
false se cumple por la Clausula (A.1) de la De-
nicion 3 puesto que col(x,xs) >
rpo
false.
La prueba es completamente an aloga para notEmpty y para ifThenElse.
size
Consideremos ahora las ecuaciones que denen size.
size(nil) >
rpo
1 se cumple por la Clausula (A.1) de la Denicion 3 puesto
que nil 1.
size(col(x,xs)) >
rpo
1 + size(xs) se cumple por la Clausula (A.2) de la
Denicion 3 puesto que size[3] > +[2] se cumple, y
size(col(x, xs)) >
rpo
1 se cumple por la Clausula (A.1) de la Deni-
cion 3 puesto que col(x,xs) >
rpo
1; y
size(col(x, xs)) >
rpo
size(xs) se cumple por la Clausula (A.4) de la
Denicion 3, puesto que size size y col(x, xs) >
rpo
xs se cumple
asSet
Consideremos ahora las ecuaciones que denen asSet.
asSet(col(x,xs)) >
rpo
ifThenElse(includes(xs,x),asSet(xs), col(x,asSet(xs)))
se cumple por la Clausula (A.2) de la Denicion 3, puesto que asSet[4] >
ifThenElse[1] y
asSet(col(x,xs)) >
rpo
includes(xs,x) se cumple por la Clausula (A.2)
de la Denicion 3, ya que asSet[4] > includes[3] y que tambien se
cumple que asSet(col(x,xs)) >
rpo
xs y asSet(col(x,xs)) >
rpo
x por la
Clausula (A.1) de la Denicion 3;
asSet(col(x,xs)) >
rpo
asSet(xs) se cumple por la Clausula (A.3) de la
Denicion 3, puesto que asSet asSet y col(x,xs) >
rpo
xs se cumple
por la Clausula A.1 de la Denicion 3;
asSet(col(x,xs)) >
rpo
col(x,asSet(xs)) se cumple por la Clausula (A.2)
de la Denicion 3, puesto que asSet[4] > col[1] y asSet(col(x,xs)) >
rpo
x se cumple por la Clausula (A.1) de la Denicion 3 y se cumple que
asSet(col(x,xs)) >
rpo
asSet(xs) por el caso previo.
at(o)
Consideremos ahora la ecuaci on que dene at.
at(o) >
rpo
v por la Clausula A.1 de la Denicion 3 puesto que o v.
rl(o)
Consideremos ahora la ecuaci on que dene rl.
Tenemos que probar que rl(o) >
rpo
col(o
n
, col(o
n1
, . . . , o
1
, nil)). La prueba
se hace por inducci on en el n umero de objetos ligados a o mediante el rol rl:
si n = 0, por la Clausula (A.1) de la Denicion 3, rl(o) >
rpo
nil puesto
que o nil.
si n = 1, por la Clausula (A.2) de la Denicion 3, rl(o) >
rpo
col(o
1
, nil),
puesto que rl > col, y
rl(o) >
rpo
o
1
y rl(o) >
rpo
nil, por la Clausula (A.1) de la Denicion 3,
puesto que o o
1
y o nil (resp.).
Supongamos que, por hipotesis de inducci on
rl(o) >
rpo
col(o
n1
, col(o
n2
, . . . , o
1
, nil)).
Por La Clausula (A.2) de la Denicion 3, rl(o) >
rpo
col(o
n
, col(o
n1
,
. . ., o
1
, nil)), puesto que rl > col, y rl(o) >
rpo
o
n
por la Clausu-
la (A.1) de la Denicion 3 puesto que o o
n
, y tambien se cumple
que rl(o) >
rpo
col(o
n1
, col(o
n2
, . . . , o
1
, nil)) por hipotesis de induc-
cion.
La prueba para la ecuaci on que dene allInstances es completamente
an aloga.
oclIsKindOf()
Consideremos ahora la ecuaci on que dene oclIsKindOf.
oclIsKindOf(o, c) >
rpo
includes(allInstances(c), o) se cumple por la Clau-
sula (A.2) de la Denicion 3 puesto que oclIsKindOf[4] > includes[3], y
oclIsKindOf(o, c) >
rpo
allInstances(c) por la Clausula (A.2) de la
Denicion 3 puesto que oclIsKindOf[4] > allInstances[2], y tambien
se cumple que oclIsKindOf(o, c) >
rpo
c por la Clausula (A.1) de la
Denicion 3 y tambien, oclIsKindOf(o, c) >
rpo
o.
Apendice B
El Metamodelo de Secu-
reUML+ComponentUML
179
180 Apendice B. El Metamodelo de SecureUML+ComponentUML
B.1. La Sintaxis Abstracta de SecureUML
En esta secci on explicamos la sintaxis abstracta de SecureUML introducida
por el metamodelo de SecureUML mostrado en la Figura B.1. Para introducir
los distintos elementos de modelado seguimos el orden alfabetico.
Action
SecureUML proporciona un lenguaje para especicar polticas de control de
acceso para acciones sobre recursos protegidos. Las acciones pueden ser atomicas
o compuestas.
Asociaciones
isassigned : Permission [1..*] Esta asociaci on determina que permisos per-
mite ejecutar la accion self.
compositeAction : CompositeAction [*] Esta asociaci on determina si la
accion self es parte de una accion compuesta.
resource : Resource [1..*] Esta asociaci on determina los recursos sobre los
que la accion self puede ejecutarse.
Restricciones No hay restricciones adicionales.
Notacion Cada accion referida por un permiso puede ser una accion sobre el
recurso raz o sobre un subrecurso suyo. Cada atributo de la clase de asociaci on
que representa un permiso signica la asignaci on de una accion al permiso. La
accion est a identicada por el nombre y el tipo del atributo. Los estereotipos
delante de estos atributos especican el tipo abstracto de la accion. El tipo del
atributo especica la clase concreta de la accion (por ejemplo, read, update, o
full access) que el permiso est a permitiendo.
Role
+default: Boolean
User
Permission
+default: Boolean
AuthorizationConstraint
+body: String
+language: String
Action
AtomicAction CompositeAction
Resource
RoleHierarchy
superrole
subrole
UserAssignment
hasRole
includes
givesAccess
hasPermission
PermissionAssignment
constraints
ConstraintAssignment
isconstraintby
ActionAssignment
isAssigned accesses
subordinatedActions
ActionHierarchy
compositeAction
ResourceAssignment
action resource
Figura B.1: Metamodelo de SecureUML
B.1. La Sintaxis Abstracta de SecureUML 181
AtomicAction
Las acciones atomicas se corresponden con operaciones reales del sistema
modelado.
Generalizaciones
Action
Restricciones
Las acciones atomicas deben ser asignadas al menos a un permiso y cuando
son asignadas a mas de uno, entonces ninguno de estos puede ser el permiso
por defecto.
context AtomicAction
inv existsAPermission:
self.allAssignedPermission()>notEmpty()
inv overridingDefaultPermission:
self.allAssignedPermission()
>forAll(p1, p2[ p1<>p2 implies not(p1.default))
AuthorizationConstraint
SecureUML proporciona la posibilidad de restringir permisos con restric-
ciones de autorizaci on, expresadas tpicamente mediante formulas OCL. Estas
restricciones restringen los permisos a aquellos en los que los estados del siste-
ma satisfacen las formulas. Las restricciones de autorizaci on reejan propiedades
dinamicas de las polticas de seguridad que deben comprobarse en cada estado
del sistema.
Asociaciones
constraints : Permission [1..*] Esta asociaci on determina que permisos
est an restringidos por self. Un usuario que tenga tales permisos tiene que
satisfacer la restricci on de autorizaci on para poder ejecutar las acciones a
los que los permisos dan acceso.
Atributos
body: String [1] La cadena de texto que especica la restricci on en el
lenguaje denido en el atributo language.
language: String [1] La cadena de texto que especica el lenguaje en el
que se denen las restricciones, en nuestro caso, OCL.
Restricciones
Las restricciones de autorizaci on se escriben en OCL.
context AuthorizationConstraint
inv: self.language = OCL
Notacion Las restricciones de autorizaci on se adjuntan a las clases de asocia-
cion de los permisos como comentarios.
CompositeAction
Las acciones compuestas se usan para agrupar acciones en una jerarqua de
acciones a distintos niveles.
Generalizaciones
Action
Asociaciones
subordinatedAction : Action [1..*] Esta asociaci on determina las acciones
subordinadas de self, es decir, el grupo de acciones que la componen.
Restricciones
El permiso por defecto no puede estar asignado a una accion compuesta.
context CompositeAction
body: allAssignedPermission : Set(Permission) =
self.isAssigned>union(self.compactionPlus().isAssigned)
inv nonDefaultPermission:
self.allAssignedPermission>forAll(p[not(p.default))
Permission
Los permisos especican los roles que pueden realizar las distintas acciones.
Los usuarios adquieren permisos cuando se les asignan los roles apropiados de
acuerdo con sus competencias y responsabilidades en la organizaci on.
Atributos
default : Boolean El permiso por defecto s olo puede estar asociado al
rol por defecto y s olo puede tener asignadas acciones atomicas. Existe
solamente un permiso default.
Asociaciones
giveaccess : Role [1..*] Esta asociaci on determina los roles que tiene el
permiso self.
isconstraintby : AuthorizationConstraint [*] Esta asociaci on determina las
restricciones de autorizaci on que restringen el acceso a las acciones permi-
tidas por self.
accesses : Action [1..*] Esta asociaci on determina las acciones a las que
self da acceso.
Restricciones Las siguientes invariantes garantizan que el modelo contiene
un permiso por defecto con la semantica deseada. En concreto, que las acciones
atomicas est an asignadas al menos a un permiso y, que si tienen asignado mas de
uno, entonces ninguno de ellos puede ser el por defecto; ademas, que el permiso
por defecto es unico, que s olo puede ser dado al rol por defecto y que s olo
puede acceder acciones atomicas; nalmente, que la restricci on de autorizaci on
del permiso por defecto siempre tiene que poder satisfacerse.
context Permission
inv existsADefaultPermission:
Permission.allInstances()>select(p[p.default)>size() = 1
inv defaultPermissionAssignedToDefaultRole:
self.default implies self.givesaccess>forAll(r[r.default)
inv onlyAtomics :
self.default implies self.accesses
>select(a [ a.oclIsTypeOf(CompositeAction))>isEmpty()
inv constrainedByTrue:
self.default implies self.isconstraintby.body = true
Notacion Un permiso, junto con sus relaciones con roles y acciones, se de-
ne mediante un solo elemento de notaci on UML: una clase de asociaci on con
el estereotipo Permission)). La clase de asociaci on conecta un rol con una
entidad (denotada como una clase UML) que es designada como el recurso pro-
tegido raz. Las acciones que tal permiso se reere pueden ser acciones sobre
el recurso raz o sobre subrecursos de este recurso raz. Cada atributo de la
clase de asociaci on representa la asignaci on de una accion al permiso, donde
la accion se identica por su nombre y el tipo del atributo. Los estereotipos
delante de un atributo especican el tipo abstracto de la accion. El estereotipo
entityaction)), por ejemplo, especica que un atributo de un permiso se reere
a una accion sobre una entidad. El nombre del atributo del permiso especica el
nombre del recurso o subrecurso al que se reere el permiso. El tipo del atributo
del permiso especica la clase concreta de accion (por ejemplo, read, update,
or full access) que permite este permiso. Las restricciones de autorizaci on se
adjuntan como comentarios a las clases de asociaci on que representan permisos.
Estilo
El nombre del permiso se escribe centrado.
La primera letra del nombre de un permiso se escribe en may uscula.
Resource
Representa los tipos de elementos del modelo del sistema que pueden estar
protegidos. Los recursos protegidos ofrecen acciones que tpicamente est an jerar-
quizadas. SecureUML deja abierto cu ales son los recursos protegidos y que ac-
ciones ofrecen a los clientes. Estas se especican en lo que se llama un dialecto
del lenguaje y dependen de los elementos del lenguaje de modelado de dise no
subyacente.
Asociaciones
actions : Actions [1..*] Esta asociaci on determina las acciones que pueden
ejecutarse sobre self.
Notacion La clase de asociaci on que denota un permiso conecta un rol con
la entidad que representa el recurso raz protegido del permiso. Las acciones a
las que este permiso da acceso pueden s olo ser acciones sobre el recurso raz o
sobre subrecursos de este recurso raz.
Role
Los roles representan funciones de trabajo dentro de una organizaci on; tpi-
camente existe una jerarqua entre estos roles.
Atributos
default : Boolean El rol por defecto se usa para establecer la poltica de
acceso por defecto en un sistema. Todos los usuarios tienen al menos el
rol por defecto, que es el mas general en la jerarqua de roles. El rol por
defecto es ademas unico dentro de una poltica de seguridad.
Asociaciones
subrole: Role [*] Esta asociaci on determina los subroles inmediatos de self
y que, por tanto, heredan todos sus permisos.
superrole : Role [1..*] Esta asociaci on determina los superroles inmediatos
de self.
hasPermission : Permission [1..*] Esta asociaci on determina los permisos
que tiene el rol self.
includes : User [*] Esta asociaci on determina que usuarios tienen asigna-
dos self como rol.
Restricciones
Default role Los siguientes invariantes garantizan que los modelos de segu-
ridad contienen un rol por defecto con la semantica deseada; en particular
que cualquier usuario posee al menos el rol por defecto.
context Role
inv existsADefaultRole:
Role.allInstances()>select(r[r.default)>size() = 1
inv allRolesInheritFromDefaultRole:
self.superrolePlus()>exists(r[r.default)
context User
Role hierarchy. El siguiente invariante garantiza que no haya ciclos en la
jerarqua de roles.
context Role
inv noCyclesinRoleHierarchy:
self.superrole> forAll(r[r.superrolePlus()>excludes(self))
Notacion Un rol se representa usando la notaci on de una clase UML con el
estereotipo Role)). Una relacion de herencia entre dos roles se denota usando
una relacion de generalizaci on UML. El rol referenciado por la echa de la rela-
cion de generalizaci on es superrol del rol referenciado por la cola de la relacion.
Los roles no tienen atributos ni metodos.
Estilo
Los nombres de rol se escriben centrados.
La primera letra de un nombre de rol se escribe en may uscula.
User
La clase User representa a los usuarios del sistema. Los usuarios y los permi-
sos se asignan a roles para establecer la poltica de control de acceso est atico. En
concreto, para concederles permisos de acceso, a los usuarios se les asignan roles,
de acuerdo con sus competencias y responsabilidades dentro de la organizaci on.
Asociaciones
hasRole : Role [*] Esta asociaci on determina los roles que tiene el usuario.
Restricciones
Cualquier usuario tiene, al menos, el rol por defecto.
context User
B.2. La Sintaxis Abstracta de ComponentUML
En esta secci on explicamos la sintaxis abstracta de ComponentUML intro-
ducida por el metamodelo de ComponentUML que se muestra en la Figura B.2.
ComponentUML es un lenguaje simple para modelar sistemas basados en com-
ponentes. Esencialmente, proporciona un subconjunto de los modelos de clase de
UML: las entidades (Entities) pueden relacionarse mediante asociaciones (As-
sociations) y pueden tener atributos (Attribute) y metodos (Methods). Para
introducir los distintos elementos de modelado seguimos el orden alfabetico.
Attribute
Method
+isQuery: Boolean
AssociationEnd
Entity
Entity
Method EntityAttribute
Entity
AssociationEnd
has
Method
has
Attribute
hasAssociationEnd
Association
association
association
End
*
*
*
1
1
2
1
1
Figura B.2: Metamodelo de ComponentUML
Association
Las asociaciones se usan para especicar relaciones entre entidades. Una
asociaci on se construye desde un elemento Association del modelo y cada enti-
dad que participe en una asociaci on est a conectada a Association mediante un
AssociationEnd.
Asociaciones
associationEnd : AssociationEnd [2] Esta asociaci on determina los extre-
mos de asociaci on que posee self.
B.2. La Sintaxis Abstracta de ComponentUML 187
Semantica Una asociaci on declara que puede haber enlaces entre instancias
de las entidades asociadas.
Notacion Una asociaci on binaria se dibuja mediante una lnea continua que
conecta dos entidades distintas, o una entidad consigo misma (en cuyo caso los
dos extremos de la asociaci on tienen que tener nombres distintos).
AssociationEnd
Los extremos de asociaci on conectan cada entidad que participa en una aso-
ciaci on.
Asociaciones
EntityAssociationEnd: Entity [1] Esta asociaci on determina el tipo nal
del extremo de asociaci on.
association : Association [1] Esta asociaci on determina la asociaci on a la
que self pertenece.
Notacion Una cadena de texto situada cerca del nal de la lnea para mostrar
el nombre del extremo de asociaci on. Otros elementos que pueden aparecer hacia
el extremo de la lnea son las multiplicidades.
Attribute
Representan propiedades estructurales que posee la entidad.
Asociaciones
EntityAttribute: Entity [1] Esta asociaci on determina que entidad posee a
self.
Notacion Un atributo se muestra como una cadena de texto en el segundo
compartimento de una entidad.
Entity
Los elementos de tipo Entity representan tipos objeto de un dominio parti-
cular.
Asociaciones
hasAssociationEnd : AssociationEnd [1..*] Esta asociaci on determina el
extremo de asociaci on que tiene tipo self.
hasAttribute : Attribute [*] Esta asociaci on determina los atributos que
tiene self.
hasMethod : Method [*] Esta asociaci on determina los metodos que tiene
self.
Notacion Una entidad se representa mediante una clase UML con el estereo-
tipo Entity)). En su primer compartimento aparece el nombre de la entidad.
Una entidad posee dos compartimentos adicionales que contienen sus atributos
y metodos.
Estilo
Los nombres de las entidades se escriben centrados.
La primera letra de un nombre de entidad se escribe en may uscula.
Method
Representan las propiedades de comportamiento que posee la entidad.
Atributos
isQuery: Boolean Este atributo determina si el metodo est a libre de efectos
secundarios.
Asociaciones
EntityMethod: Entity [1] Esta asociaci on determina la entidad a la que
self pertenece.
Notacion Un metodo se muestra como una cadena de texto en el tercer com-
partimento de una entidad.
B.3. La Sintaxis Abstracta de SecureUML+ ComponentUML 189
Action Resource
AtomicAction
CompositeAction
EntityFullAccess EntityUpdate
AssociationEndFullAccess
EntityRead
AttributeFullAccess
AtomicRead
AtomicExecute AtomicDelete
AtomicUpdate
AtomicCreate
Attribute
Method
+isQuery: Boolean
AssociationEnd
Entity
action ResourceAssignment
resource
Entity
Method
EntityAttribute
EntityAssociationEnd
hasMethod
has
Attribute
hasAssociationEnd
Figura B.3: Denicion del Dialecto de ComponentUML.
B.3. La Sintaxis Abstracta de SecureUML+
ComponentUML
El metamodelo que se muestra en la Figura B.3 dene el dialecto de Secu-
reUML que proporciona la conexion entre este y ComponentUML.
SecureUML+ComponentUML identica los siguientes elementos de mode-
lado de ComponentUML como recursos protegidos: Entity, Method, Attribute,
y AssociationEnd. Las acciones que ofrecen estos recursos son:
Recursos Acciones
Entidades create (crear), read (leer),
update (modicar), delete (borrar),
full access (acceso completo).
Atributos read, update, full access
Metodos execute (ejecutar)
Estremos de asociaci on read, update, full access
Las acciones que aparecen subrayadas son acciones compuestas.
Restricciones del Dialecto
Asociacion entre Recursos y Acciones. Los siguientes invariantes garan-
tizan que las acciones se reeren al recurso correcto.
context AtomicCreate
inv targetsAnEntity:
self.resource.oclIsTypeOf(Entity)
context AtomicDelete
context AtomicUpdate
inv targets:
or self.resource.oclIsTypeOf(AssociationEnd)
context AtomicRead
inv targets:
or self.resource.oclIsTypeOf(AssociationEnd)
context AtomicExecute
inv targetsAMethod:
self.resource.oclIsTypeOf(Method)
context EntityFullAccess
context EntityRead
context EntityUpdate
inv targetsAnAttribute:
context AssociationEndFullAccess
inv targetsAnAssociationEnd:
self.resource.oclIsTypeOf(AssociationEnd)
Conjunto de Acciones. Las siguientes restricciones aseguran que los recur-
sos tienen el conjunto correcto de acciones denidas sobre ellos.
context Entity
inv areAccessedBy:
self.action>exists(a[a.oclIsTypeOf(EntityFullAccess)) and
self.action>exists(a[a.oclIsTypeOf(EntityUpdate)) and
self.action>exists(a[a.oclIsTypeOf(EntityRead)) and
self.action>exists(a[a.oclIsTypeOf(AtomicCreate)) and
self.action>exists(a[a.oclIsTypeOf(AtomicDelete))
context Attribute
inv areAccessedBy:
self.action>exists(a[ a.oclIsTypeOf(AttributeFullAccess)) and
context Method
B.3. La Sintaxis Abstracta de SecureUML+ ComponentUML 191
inv areAccessedBy:
self.action>exists(a[a.oclIsTypeOf(AtomicExecute))
context Associationend
inv areAccessedBy:
self.action>exists(a[ a.oclIsTypeOf(AssociationEndFullAccess)) and
Jerarqua de Acciones. Las siguientes restricciones aseguran que las accio-
nes compuestas est an formadas por el conjunto correcto de acciones subordina-
das.
context EntityFullAccess
>select(a[a.oclIsTypeOf(EntityUpdate))
>select(a[a.oclIsTypeOf(EntityRead)))
>select(a[a.oclIsTypeOf(AtomicCreate)))
>select(a[a.oclIsTypeOf(AtomicDelete)))
context EntityRead
>select(a[a.oclIsTypeOf(AtomicRead))
>select(me[me.isQuery).action
context EntityUpdate
>select(a[a.oclIsTypeOf(AtomicUpdate)))
>select(me[not(me.isQuery)).action
context AssociationEndFullAccess
B.4. La Transformacion de Sintaxis Concreta a
Abstracta
En esta secci on denimos la transformaci on asm() de modelos de dise no con
seguridad en sintaxis concreta a su correspondiente instancia del metamodelo
en sintaxis abstracta. Con este n, denimos varias funciones auxiliares asm(x)
que indican el resultado de representar en sintaxis abstracta el elemento de
modelado x; el valor de asm(x) depende, l ogicamente, del tipo del elemento
x. En lo que sigue, ppal es el objeto principal generado en cada caso por la
funci on asm(x), cuyo nombre asumiremos denido por convenci on; abusando
de notaci on, asm(x).ppal denotar a el objeto principal generado por la funci on
asm() al representar en sintaxis abstracta el elemento x. Ademas, utilizamos
las funciones efa(), eu(), er(), ac(), ad(), au(), ar(), afa(), du(), dr(), dfa, y
ae() para denotar los objetos generados por la funci on asm() que representan
acciones sobre recursos o subrecursos, y cuyos nombres tambien asumiremos
denidos por convenci on.
Por defecto, la representacion en sintaxis abstracta de un modelo Secure-
UML+ComponentUML generada por la funci on asm() incluye:
Un objeto default:Role, tal que
default:Role.default := true.
Un objeto default:AuthorizationConstraint, tal que
language := OCL y
body := true
Un objeto default:Permission, tal que
default:Permission.default := true;
default:Permission.isConstraintby :=
default:AuthorizationConstraint; y
B.4. La Transformacion de Sintaxis Concreta a Abstracta 193
default:Permission.givesAccess := default:Role.
Ademas, incluye los objetos y enlaces generados por la funci on asm() para
cada elemento presente en el modelo SecureUML+ComponentUML de que se
trate, de acuerdo con las siguientes clausulas:
Entity Para cada entidad e, la funci on asm() llama a la funci on asm(e), que
genera los siguientes objectos:
un objeto ppal de tipo Entity;
un objeto efa(ppal ) de tipo EntityFullAccess;
un objeto eu(ppal ) de tipo EntityUpdate;
un objeto er(ppal ) de tipo EntityRead;
un objeto ac(ppal ) de tipo AtomicCreate; y
un objeto ad(ppal ) de tipo AtomicDelete.
Ademas, asm(e) genera los siguientes enlaces entre objetos:
ppal .action := efa(ppal ),eu(ppal ),er(ppal ), ac(ppal ), ad(ppal );
efa(ppal ).subordinatedAction := eu(ppal ), er(ppal ), ac(ppal ), ad(ppal );
default:Permission.accesses := ac(ppal ),ad(ppal );
Attribute Para cada atributo a de una entidad e, la funci on asm() llama a
la funci on asm(a), que genera los siguientes objetos:
un objeto ppal de tipo Attribute;
un objeto afa(ppal ) de tipo AttributeFullAccess;
un objeto au(ppal ) de tipo AtomicUpdate; y
un objeto ar(ppal ) de tipo AtomicRead.
Ademas, asm(a) genera los siguientes enlaces entre objetos:
ppal .EntityAttribute := asm(e).ppal;
ppal .action := afa(ppal ), au(ppal ), ar(ppal );
afa(ppal ).subordinatedAction := au(ppal ), ar(ppal );
eu(asm(e).ppal).subordinatedAction := au(ppal );
er(asm(e).ppal).subordinatedAction := ar(ppal );
default:Permission.accesses := au(ppal ),ar(ppal );
Method Para cada metodo de consulta m de una entidad e, la funci on asm()
llama a la funci on asm(m), que genera los siguientes objetos:
un objeto ppal de tipo Method, tal que
ppal .isQuery := true;
ppal .EntityMethod := asm(e).ppal;
un objeto ae(ppal ) de tipo AtomicExecute;
Ademas, asm(m) genera los siguientes enlaces entre objetos:
ppal .action := ae(ppal );
default:Permission.accesses := ae(ppal ); y
er(asm(e).ppal).subordinatedAction := ae(ppal )
Por otra parte, para cada metodo no de consulta m de una entidad e, asm(m)
genera los siguientes objetos:
un objeto ppal de tipo Method, tal que
ppal .isQuery := false;
ppal .EntityMethod := asm(e).ppal;
un objeto ae(ppal ) de tipo AtomicExecute;
Ademas, asm(m) genera los siguientes enlaces entre objetos:
ppal .action := ae(ppal );
default:Permission.accesses := ae(ppal ); y
eu(asm(e).ppal).subordinatedAction := ae(ppal )
AssociationEnd Para cada extremo de asociaci on d de una entidad e, la
funci on asm() llama a la funci on asm(d), que genera los siguientes objetos:
un objeto ppal de tipo AssociationEnd;
un objeto dfa(ppal ) de tipo AssociationEndFullAccess;
un objeto au(ppal ) de tipo AtomicUpdate; y
un objeto ar(ppal ) de tipo AtomicRead.
Ademas, asm(d) genera los siguientes enlaces entre objetos:
ppal .EntityAssociationEnd := asm(e).ppal;
ppal .action := dfa(ppal ), au(ppal ), ar(ppal )
dfa(ppal ).subordinatedAction := au(ppal ), ar(ppal );
eu(asm(e).ppal).subordinatedAction := au(ppal );
er(asm(e).ppal).subordinatedAction := ar(ppal ); y
default:Permission.accesses := au(ppal ), ar(ppal );
Role Para cada rol r, la funci on asm() llama a la funci on asm(r), que genera:
un objeto ppal de tipo Role, tal que
ppal .default := false;
ppal .superrole := default:Role
User Para cada usuario u, la funci on asm() llama a la funci on asm(u), que
genera:
un objeto ppal de tipo User, tal que
ppal .hasRole := default:Role.
AuthorizationConstraint Para cada restricci on de autorizaci on ath, la fun-
cion asm() llama a la funci on asm(ath), que genera:
un objeto ppal de tipo AuthorizationConstraint, tal que
language := OCL y
body := ath
Permission Para cada permiso p, la funci on asm() llama a la funci on asm(p),
que genera:
un objeto ppal de tipo Permission, tal que
ppal .default := false;
RoleHierarchy Para cada relacion de herencia entre dos roles r
1
r
2
, asm()
genera el siguiente enlace:
asm(r
2
).ppal.subrole := asm(r
1
).ppal.
UserAssignment Para cada asignaci on de un usuario u a un rol r, asm()
genera el siguiente enlace:
asm(u).ppal.hasRole := asm(r).ppal.
PermissionAssignment Para cada asignaci on de un permiso p a un role r,
asm() genera el siguiente enlace:
asm(r).ppal.hasPermission := asm(p).ppal.
ConstraintAssignment Para cada asignaci on de una restricci on ath a un
permiso p, asm() genera el siguiente enlace:
asm(p).ppal.isConstraintBy := asm(ath).ppal.
EntityFullAccess Permission Para cada entity e, y cada permiso p que
permite entity full access a e, asm() genera el siguiente enlace:
asm(p).ppal.accesses := efa(asm(e).ppal).
Ademas, asm() borra cualquier enlace entre el el objecto default:Permission y los
objectos ac(asm(e).ppal) o ad(asm(e).ppal). Por ultimo, para cada atributo a,
metodo m, y extremo de asociaci on d de e, asm() borra cualquier enlace entre
el objeto default:Permission y los objetos au(asm(a).ppal), ar(asm(a).ppal),
au(asm(d).ppal), ar(asm(d).ppal), o ae(asm(m).ppal)
EntityReadAccess Permission Para cada entity e, y cada permiso p que
permite entity read access a e, asm() genera el siguiente enlace:
asm(p).ppal.accesses := er(asm(e).ppal).
Ademas, para cada atributo a, metodo de consulta m, y extremo de asociaci on
d de e, asm() borra cualquier enlace entre el objeto default:Permission y los
objetos ar(asm(a).ppal), ar(asm(d).ppal), o ae(asm(m).ppal).
EntityUpdateAccess Permission Para cada entidad e, y cada permiso p
que permite entity update access a e, asm() genera el siguiente enlace:
asm(p).ppal.accesses := eu(asm(e).ppal).
Ademas, para cada atributo a, metodo de no consulta m, y extremo de asocia-
cion d de e, asm() borra cualquier enlace entre el objeto default:Permission y
los objetos au(asm(a).ppal), au(asm(d).ppal), o ae(asm(m).ppal);
AtomicCreateAccess Permission Para cada entidad e, y cada permiso p
que permite atomic create access a e, asm() genera el siguiente enlace:
asm(p).ppal.accesses := ac(asm(e).ppal).
Ademas, asm() borra cualquier enlace entre el objeto default:Permission y el
objeto ac(asm(e).ppal);
AtomicDeleteAccess Permission Para cada entidad e, y cada permiso p
que permite atomic delete access a e, asm() genera el siguiente enlace:
asm(p).ppal.accesses := ad(asm(e).ppal).
Ademas, borra cualquier enlace entre el objeto default:Permission y el objeto
ad(asm(e).ppal);
AttributeFullAccess Permission Para cada atributo a, y cada permiso p
que permite attribute full access to a, asm() genera el siguiente enlace:
asm(p).ppal.accesses := afa(asm(a).ppal).
Ademas, asm() borra cualquier enlace entre el objeto default:Permission y los
objetos au(asm(a).ppal) ar(asm(a).ppal).
AttributeAtomicUpdateAccess Permission Para cada atributo a, y cada
permiso p que permite attribute atomic update access to a, asm() genera el
siguiente enlace:
asm(p).ppal.accesses := au(asm(a).ppal).
objeto au(asm(a).ppal);
AttributeAtomicReadAccess Permission Para cada atributo a, y cada
permiso p que permite attribute atomic read access to a, asm() genera el
siguiente enlace:
asm(p).ppal.accesses := ar(asm(a).ppal).
objeto ar(asm(a).ppal).
AssociationEndFullAccess Permission Para cada extremo de asociaci on
d, y cada permiso p que permite association-end full access a d, asm() genera
el siguiente enlace:
asm(p).ppal.accesses := dfa(asm(d).ppal).
Ademas, asm() borra cualquier enlace entre el objeto default:Permission y los
objetos au(asm(d).ppal) ar(asm(d).ppal).
AssociationEndAtomicUpdateAccess Permission Para cada extremo de
asociaci on d, y cada permiso p que permite association-end atomic update ac-
cess a d, asm() genera el siguiente enlace:
asm(p).ppal.accesses := au(asm(d).ppal);
objeto au(asm(d).ppal).
AssociationEndAtomicReadAccess Permission Para cada extremo de a-
sociaci on d, y cada permiso p que permite association-end atomic read access
a d, asm() genera el siguiente enlace:
asm(p).ppal.accesses := ar(asm(d).ppal).
objeto ar(asm(d).ppal).
AtomicExecuteAccess Permission Para cada metodo m, y cada permiso
p que permite atomic execute access to m, asm() genera el siguiente enlace:
asm(p).ppal.accesses := ar(asm(m).ppal).
objeto ae(asm(m).ppal).

Ocl 1

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Ocl 1

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDAD COMPLUTENSE DE MADRID

ANTICA FORMAL EJECUTABLE

est a bajo p, denotado por p p

(X) al conjunto de terminos, inductivamente denidos

(X); esto es, las variables son terminos.

(X); esto es, las

(X) y (t) denota el termino que resulta de sustituir simul-

, para alguna permutacion sobre 1, ..., n, donde

(X) es un orden de reescritura si y solo si

(X), f con aridad(f) = n,

(X) y todas las susti-

(X) es un orden de reescritura bien fundado.

es compatible con un TRS (, R) si r < l

contiene a la signatura genSign(T)

incluye las ecuaciones de genRls(T) mas las

) = false, para cada par de objetos o, o

equal(c,c) = true, para cada clase c en T

) = false, para cada par de clases c, c

oclIsKindOf oclIsKindOf(o, c) = includes(allInstances(c), o), para cada

Usaremos ademas las siguientes funciones auxiliares en la denici on de la

X una lista de variables (x

es una extensi on de que a nade a solamente smbolos que est an etiquetados

labels(), ocurre que p

es una signatura que cumple que

es una extensi on de E que a nade las ecuaciones

a nade a . Usa la nocion de -top especicaci on

X una lista de variables tales que X = , w una expresi on OCLMOVA tal

-especicaci on ecuacional tal que E E

)-top especicaci on ecuacional.

p. Entonces, se cumple que

E) es un conjunto de ecuaciones tal que sus partes izquierdas son

ticos entre las

) devuelta por esta funci on existe una funci on de

tal que el rpo-orden de reduccion

sobre es compatible con el sistema de reescritura de

. Para hacerlo, introducimos una

son, respectivamente, una funci on de precedencia y una funci on

que devuelve interpret +(); y

es compatible con el TRS denido por las ecuaciones en el conjunto E

devuelto por interpret +().

son generadas recursivamente por interpret +() mientras

son como en la Denici on 1.

son como en la Denici on 1.

son como en la Denici on 1.

son como en la Denici on 1, y

son como en la Denici on 1, y

son como en la Denici on 1.

son como en la Denici on 1.

son como en la Denici on 1.

son como en la Denici on 1.

son como en la Denici on 1, y para 1 i 2,

son como en la Denici on 1, y, para 1 i 2,

son como en la Denici on 1, y, para 1 i 2,

son como en la Denici on 1, y, para 1 i 2,

son como en la Denici on 1, y para 1 i 2,

son como en la Denici on 1, y

son como en la Denici on 1, y para 1 i 2,

son como en la Denici on 1, y para 1 i 2, T

son como en la Denici on 1, y para 1 i 2, T

son como en la Denici on 1, y para 1 i 2, T

son como en la Denici on 1, y para 1 i 2, T

son como en la Denici on 1, y para 1 i 2, T

son como en la Denici on 1, y para 1 i 2, T