dsls para la extraccion de modelos en modernizaci´on

DSLs para la extraccion de modelos en modernizacion

Javier Luis Canovas Izquierdo, Oscar Sanchez Ramon,Jesus Sanchez Cuadrado, y Jesus Garcıa Molina

Departamento de Informatica y SistemasUniversidad de Murcia {jlcanovas,osanchez,jesusc,jmolina}@um.es

Resumen. La Modernizacion Dirigida por Modelos ha emergido recientemente comouna nueva area de investigacion dedicada a la automatizacion basada en modelos deprocesos de evolucion de software. En los proximos anos se necesitara un gran esfuerzopara encontrar principios, tecnicas y metodos para esta nueva area y sera crucial laexperiencia adquirida en el desarrollo de casos de estudio reales de modernizacion.En este artıculo presentamos dos DSLs para la extraccion de modelos: Gra2MoLpara la extraccion a partir de codigo fuente conforme a una gramatica y H2MoL parael caso de texto que no esta bien formado, como por ejemplo HTML. El diseno deestos lenguajes es fruto de la experiencia adquirida en un proyecto de migracion deaplicaciones de la plataforma Struts a JSF, en el que se han aplicado las tecnicasbasadas en modelos.

Palabras clave: Modernizacion dirigida por modelos, Gra2MoL, H2MoL, extraccionde modelos

1 Introduccion

Las tecnicas de Desarrollo de Software Dirigido por Modelos (DSDM) no son solamente utilespara la creacion de nuevos sistemas software sino tambien para la modernizacion de sistemasexistentes. De este modo, la Modernizacion de Software Dirigida por Modelos (MSDM) haemergido recientemente como un nuevo paradigma para abordar la automatizacion basada enmodelos de las actividades de evolucion del software. En esta direccion el OMG ha propuestovarios estandares de modernizacion dentro de la iniciativa ADM [1]. En los proximos anosse requerira un gran esfuerzo para encontrar principios, tecnicas y metodos para esta nuevaarea, y la experiencia adquirida en el desarrollo de casos de estudio de modernizacion realessera crucial.

De acuerdo con los objetivos de un proyecto de modernizacion, se pueden distinguir variosescenarios [2], como la migracion de plataformas o la conversion de lenguajes. Ademas, confrecuencia un problema de modernizacion abarca mas de un escenario. Las caracterısticas deun escenario de modernizacion determinan las tareas necesarias para llevar cabo el proyecto.

En este artıculo presentamos un caso de estudio de Modernizacion Dirigida por Modelospara un escenario de migracion de plataformas: la migracion de un sistema web basado enStruts a un sistema Java Server Faces (JSF). Nos referiremos a este caso de estudio comoStruts2JSF. Este proyecto ha servido para experimentar en las tres principales etapas de unproyecto de modernizacion dirigido por modelos: extraccion de los modelos de los artefactosfuente, rediseno del sistema y generacion del nuevo sistema.

Sin embargo, y por cuestiones de espacio, en este artıculo nos centraremos en las aproxi-maciones que hemos ideado para solucionar los retos aparecidos durante la extraccion demodelos, que es la etapa que actualmente requiere de una mayor labor de investigacion. Enconcreto, presentaremos Gra2MoL como lenguaje para extraer modelos a partir de codigoconforme a una gramatica y H2MoL como lenguaje para extraer modelos en base a texto que

Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 2, No. 3, 2008

ISSN 1988–3455 SISTEDES, 2008 1

no esta bien formado, como por ejemplo HTML. En la migracion Struts2JSF utilizaremosGra2MoL para extraer modelo del codigo Java, H2MoL para codigo JSP y el frameworkEMF (Eclipse Modeling Framework) para ficheros XML.

El documento esta organizado de la siguiente manera. En primer lugar se describe elproblema y los metamodelos de las plataformas. A continuacion la seccion 4 presenta las doscontribuciones principales del trabajo: dos lenguajes especıficos del dominio dirigidos a laextraccion de modelos a partir de los ficheros del sistema origen (por ejemplo codigo fuenteJava o JSP). En la seccion 5 se expone el trabajo relacionado y finalmente, se presentan lasconclusiones y el trabajo futuro.

2 Descripcion del problema

Struts [3] es un framework para desarrollar aplicaciones web en Java que aparecio en elano 2000, y que esta basado en la arquitectura Modelo-Vista-Controlador (MVC). Por otraparte, Java Server Faces (JSF) [4] aparecio en el ano 2004, con el objetivo de simplificar eldesarrollo de interfaces web Java. Este framework tambien utiliza una arquitectura MVC yse ha convertido en un estandar de facto.

La migracion Struts2JSF es un ejemplo de escenario de migracion de plataformas. Esteescenario normalmente se combina con un escenario de conversion de lenguajes, aunqueen este caso no se requiere debido a que las dos plataformas estan basadas en el lenguajeJava. En general, un proceso de modernizacion requiere la creacion de metamodelos querepresenten la arquitectura existente y la arquitectura destino. Dicho proceso consta de trespasos principales: extraccion de modelos a partir de los artefactos del sistema existente (in-genierıa inversa), transformacion de los modelos del sistema existente para generar modelosdel sistema destino (rediseno) y generacion de los artefactos del sistema destino (ingenierıadirecta).

El proceso de modernizacion aplicado se muestra en la Figura 1. En primer lugar seextraen tres modelos conforme al metamodelo de la plataforma Struts a partir del codigofuente Struts. Cada modelo Struts se transformara en su correspondiente modelo JSF. Elultimo paso consiste en la generacion de los ficheros fuente de la aplicacion JSF usandotransformaciones modelo-codigo. El codigo fuente con la logica de negocio no requiere ninguntipo de transformacion sino que se migra sin cambios.

Fig. 1. Proceso de modernizacion aplicado en el caso de estudio Struts2JSF

Puede observarse que tanto los artefactos de Struts como los de JSF se organizan en lasmismas tres partes: clases Java, codigo JSP y ficheros de configuracion XML.


ISSN 1988–3455 SISTEDES, 2008 2

3 Metamodelos de las plataformas

Todo proyecto de modernizacion basada en modelos necesita de metamodelos que describanlas plataformas involucradas. En este caso de estudio no estamos interesados en modelarcompletamente las plataformas Struts y JSF, dado que esto implicarıa tratar con demasia-dos elementos y variantes de codificacion. En cambio nos hemos centrado en un conjuntode caracterısticas basicas como validacion de formularios, navegacion entre paginas, manejode beans e internacionalizacion, que es suficiente para el objetivo de este caso de estudio.Ademas, dado que no se ha realizado un analisis semantico, el codigo reconocido se restringea las convenciones de programacion mas utilizadas. A pesar de que no se necesitan meta-modelos de Struts y JSF completos, el diseno es todavıa complejo porque se debe representarel lenguaje Java y la arquitectura MVC.

Para mejorar la modularidad, los metamodelos de Struts y JSF se han organizado entres paquetes, uno por cada una de las partes mencionadas en la seccion anterior: JSP, beansy configuracion. Tanto Struts como JSF, aunque usan librerıas de etiquetas especıficas, seapoyan sobre la tecnologıa JSP. Por otra parte, los beans de Struts y JSF comparten con-ceptos Java comunes y extienden las metaclases definidas en los metamodelos comunes paraespecializarlas. Por ejemplo, es util distinguir especıficamente un metodo Struts validate,es decir, crear una metaclase validateMethod que hereda de la metaclase JavaMethod delmetamodelo Java. Por lo tanto, se han desarrollado dos metamodelos reutilizables para JSPy Java que se comparten por ambos metamodelos, como puede observarse en la Figura 2.Esto ha permitido que los metamodelos sean mas compactos y faciles de mantener ademasde promover su reutilizacion1.

Fig. 2. Organizacion de paquetes de metamodelos.

4 Extraccion de modelos

El primer paso en un proyecto de MSDM consiste en la extraccion de modelos a partir delos artefactos fuente existentes, tales como codigo fuente o ficheros de configuracion XML.Estos modelos son conformes a los metamodelos de la plataforma origen y representan lainformacion del sistema existente que es necesaria para crear el nuevo sistema.

La extraccion de estos modelos requiere establecer un puente entre diferentes espaciostecnologicos, en particular entre la tecnologıa del DSDM (modelware) y las tecnologıas em-pleadas para describir el texto de los ficheros origen, normalmente gramaticas (grammar-ware) y esquemas XML. En un escenario de migracion de plataformas, este puente es uni-direccional y consiste en la creacion de un analizador sintactico que construye los modelosa partir de los artefactos fuente. Sin embargo, un sistema tambien puede estar formado porficheros cuyo contenido no esta bien formado (por ejemplo, HTML), donde las aproximacio-nes anteriores no pueden ser aplicadas.1 Los metamodelos se pueden descargar de http://gts.inf.um.es/age


ISSN 1988–3455 SISTEDES, 2008 3

4.1 Extraccion de modelos a partir de codigo conforme a una gramatica

La mayorıa de los escenarios de modernizacion requieren tratar con codigo fuente cuya es-tructura puede ser expresada por una gramatica. Por lo tanto, es posible utilizar herramien-tas que proporcionen un puente entre los espacios tecnologicos grammarware y modelwarepara llevar a cabo la extraccion de modelos. Se han propuesto varias aproximaciones paraestablecer un puente entre las gramaticas y los modelos. xText [5] y los trabajos de Wimmeret al. [6] y Kunert [7] son los ejemplos mas destacables. Estos trabajos estan basados enla generacion automatica de un metamodelo a partir de la gramatica, y de un analizadorsintactico para la extraccion de modelos.

La utilidad de estas aproximaciones esta restringida por varias limitaciones que surgenen situaciones practicas. Desde nuestra experiencia, hemos identificado cuatro problemasprincipales:

– El bajo nivel de los metamodelos generados frecuentemente obliga a aplicar transforma-ciones modelo a modelo para obtener metamodelos de mas alto nivel como un AST o unmetamodelo KDM [8]. Esta idea aparece reflejada en la Figura 3, en la que se contrastaun metamodelo generado con el metamodelo deseado.

Fig. 3. (a) Metamodelo generado a partir de la gramatica de Java usando xText. (b) Metamodelode alto nivel deseado.

– Los modelos extraıdos se almacenan normalmente en ficheros XMI. En proyectos degran tamano que contienen cientos de ficheros fuente, se puede producir la duplicacionde informacion dado que los artefactos software estan representados en los ficheros fuentey en los modelos. Esto hace que esta aproximacion sea ineficiente en cuanto a tiempo ymemoria.

– Determinada informacion derivada del analisis sintactico tal como nombres de ficheros,lıneas, columnas, etc. es importante en el proceso de modernizacion, principalmente parapermitir la trazabilidad entre el codigo y el modelo. Esta informacion se pierde debidoa que los metamodelos generados no la incluyen, y por lo tanto no se propaga a losmodelos.

– Existe un catalogo considerable de definiciones de gramaticas para generadores de anal-izadores sintacticos como ANTLR [9] o JavaCC [10]. Ademas, los artefactos softwarese programan normalmente con lenguajes de programacion con bastante difusion, comoCOBOL, C, o Java, y crear la gramatica de un lenguaje de programacion desde ceroes una tarea difıcil y que conlleva mucho tiempo. Las aproximaciones de modernizaciondirigida por modelos deberıan permitir la reutilizacion de las definiciones de gramaticaspara algun generador de analizadores sintacticos existentes.


ISSN 1988–3455 SISTEDES, 2008 4

Con estos problemas en mente, hemos definido un DSL para la extraccion de modelosdenominado Gra2MoL [11], cuyas dos caracterısticas mas relevantes son: (i) incorpora unpotente lenguaje de consultas para recorrer el arbol sintactico y recuperar la informaciondel codigo fuente, (ii) la gramatica es utilizada para poder referenciar a los elementos deesta en las consultas al arbol sintactico. Gra2MoL nos permite especificar explıcitamente lasrelaciones entre los elementos de la gramatica origen y los elementos de un metamodelo des-tino, y trata el codigo fuente como un modelo usando la definicion de gramatica subyacentecomo si se tratara de un metamodelo. La Figura 4 ilustra el esquema de Gra2MoL.

Fig. 4. Esquema de Gra2MoL. El codigo fuente PG es conforme a la gramatica G y el modelo MT

es conforme a el metamodelo MMT . T denota al processo de transformacion y MappingGra2M oL

son las correspondencias expresadas con Gra2MoL entre G y MMT .

La entrada de una transformacion Gra2MoL es codigo fuente junto con la definicion de lagramatica a la que conforma y una definicion de transformacion (mapping). En primer lugarel codigo fuente se analiza sintacticamente para construir un arbol sintactico y la definicionde la transformacion trata con dicho arbol, utilizando la gramatica para tipar los nodos.

En los arboles sintacticos, las referencias entre elementos se establecen implıcitamentepor medio de identificadores. Por otra parte, los modelos son grafos donde las referenciasentre elementos son explıcitas. Transformar una referencia basada en identificadores en unareferencia explıcita implica buscar el nodo identificado que puede estar fuera del ambito dela regla que realiza la transformacion. Por tanto, las transformaciones gramatica a modelorealizan un uso intensivo de consultas sobre todo el arbol sintactico para recuperar infor-macion que esta fuera del ambito de la regla actual. En [12] este tipo de transformaciones sedenomina transformaciones global a local. Si se usase la notacion punto para escribir estasconsultas, se necesitarıa una larga cadena de navegacion. Por esta razon hemos desarrolladoun lenguaje de consultas inspirado en Xpath [13] para extraer informacion que esta dispersaa lo largo del codigo fuente y para permitir la navegacion del arbol sintactico sin necesidadde especificar cada paso de navegacion, con lo que se evita especificar largas expresiones denavegacion.

En el caso de estudio Struts2JSF, Gra2MoL nos ha permitido extraer modelos del codigofuente Java del sistema Struts. Para ello hemos implementado una definicion de transfor-macion entre los elementos de la gramatica Java y los elementos del metamodelo StrutsBeans.Por ejemplo, el siguiente codigo muestra una regla que extrae un elemento ValidateMethoddel metamodelo a partir de un elemento methodDeclaration de la gramatica de Java.

rule ’validateMethod’

from methodDeclaration{Identifier.eq("validate")} cbd

to StrutsBeans::ValidateMethod

queries

md : /cbd//#methodDeclaration{Identifier.exists};

t : /md/#type;

fp : /cbd//formalParameters///#formalParameterDecls;

st : /cbd//#blockStatement;

mappings

name = new JavaSimplified::Name;


ISSN 1988–3455 SISTEDES, 2008 5

name.identifier = md.Identifier;

name.strValue = md.Identifier;

parameters = fp;

statements = st;

returnType = t;

end_rule

Una regla Gra2Mol tiene cuatro secciones. La seccion from especifica los sımbolos noterminales de la gramatica origen (en el ejemplo es methodDeclaration y filtra los metodosllamados validate) y declara una variable que sera ligada a un nodo del arbol cuando seaplique la regla (en el ejemplo es cbd). Esta variable puede ser usada en cualquier expresiondentro de la regla. La seccion to especifica la metaclase del elemento del metamodelo destino(en el ejemplo es ValidateMethod). La seccion de consultas (queries) contiene un conjuntode expresiones de consulta que sirven para asignar a variables determinados elementos delcodigo fuente. Finalmente, la seccion mappings contiene un conjunto de bindings para asignarvalores a las propiedades de los elementos del modelo destino en base a las variables definidasen la seccion de consultas. Estos bindings son un tipo especial de asignacion utilizada enlenguajes de transformacion de modelos como RubyTL [14] y ATL [15].

Atendiendo a la parte de las consultas, una consulta se compone de un conjunto deoperadores de consulta. Hay tres tipos de operadores de consulta: /, // y ///. El operador/ devuelve los hijos inmediatos de un nodo y es similar al uso de la notacion punto. Porotra parte, los operadores // y /// permiten la navegacion de todos hijos del nodo (directose indirectos) recuperando todos los nodos de un tipo dado. Estos dos operadores permitenignorar nodos superfluos intermedios, facilitando la definicion de la consulta, dado que seespecifica que tipo de nodos deben ser encontrados pero no como alcanzarlos.

El operador /// difiere ligeramente del operador //. Mientras que el operador /// buscarecursivamente en el arbol sintactico, el operador // solo selecciona aquellos nodos cuya pro-fundidad es menor o igual que la profundidad del primer nodo seleccionado. De este modoel operador /// solo se utiliza para extraer informacion de estructuras gramaticales recursi-vas. Por ejemplo, en la consulta /cbd//formalParameters///#formalParameterDecls dela regla ValidateMethod, una vez que se ha seleccionado un elemento formalParameters,se recupera la lista de parametros del metodo.

Los operadores de consulta pueden incluir expresiones de filtro opcionales y una expresionde tipo ındice tales que solo aquellos nodos que satisfagan dichas expresiones seran selecciona-dos. En el ejemplo anterior, la consulta /cbd//#methodDeclaration{Identifier.exists}define una expresion de filtro de modo que solo se seleccionaran aquellos nodos de tipomethodDeclaration que tiene una hoja del arbol de tipo Identifier.

En cuanto a la extraccion de modelos a partir de ficheros XML, un sistema Struts in-volucra un fichero de configuracion XML que es conforme a un esquema XML. Actualmenteexisten herramientas para construir un puente entre los espacios tecnologicos XML y model-ware, tales como las existentes en el proyectos EMF de la plataforma Eclipse. En este casode estudio hemos utilizado EMF para extraer modelos de los ficheros de configuracion. Estosmodelos, aunque reflejan la estructura del esquema XML, han resultado adecuados dado quela definicion de la transformacion de los ficheros de configuracion es practicamente directa.

4.2 Extraccion de modelos a partir de texto no bien formado

En esta seccion abordaremos el problema de la extraccion de modelos a partir de texto queno es conforme a ningun formalismo (como una gramatica o un esquema XML), por lo queson necesarios reconocedores dedicados. En aplicaciones web el ejemplo prototıpico son laspaginas HTML y las plantillas como JSP o ASP. Los navegadores web tienen reconocedoresdedicados para tratar con las diferentes variantes de HTML. Los lenguajes de plantillas no


ISSN 1988–3455 SISTEDES, 2008 6

consideran el contenido de la plantilla sino que simplemente se encargan de ejecutar el codigoscriptlet anadiendo el resultado a la salida estandar. Por ejemplo, el siguiente fragmento decodigo JSP es una pagina HTML que contiene etiquetas HTML, etiquetas Struts y codigoscriptlet.

<%@ taglib uri="http://jakarta.apache.org/struts/tags-html" prefix="html"%>

<%@ taglib uri="http://jakarta.apache.org/struts/tags-bean" prefix="bean"%>

<html></body>

Data for: <%= session.getAttribute("loggedUser") %>

</html:form action="/showData">

<p>

<bean:message key="user.name"/><html:text property="name"/>

</html:form>

</body></html>

Claramente esto no es un documento valido por dos razones: (i) no se permite codigoscriptlet en un XML y (ii) algunas etiquetas como <p> no estan cerradas. Es importantedestacar que incluso aunque es una mala practica escribir codigo como este, la mayorıa delos sistemas existentes estan construidos con este estilo.

Para tratar con el primer problema hemos creado un pequeno preprocesador basado enel uso de expresiones regulares que sustituye codigo scriptlet por comentarios XML. Pos-teriormente un paso de postprocesamiento extraera el codigo scriptlet de los comentarios.Daremos mas detalles mas adelante. Para el segundo problema no es posible usar una plan-tilla XSLT, un analizador XML, el framework EMF o Gra2MoL porque el codigo HTMLpuede ser inconsistente, es decir, no es un XML valido o no es conforme a la gramaticaHTML. Por esta razon habrıa que crear un analizador dedicado.

Sin embargo, crear este analizar sintactico consume tiempo y es propenso a errores debidoa la variedad de casos que debe manejar. Por tanto hemos definido la siguiente aproximacion.Primero hemos utilizado una de las API existente en Ruby (HTree [16]) para convertir textoHTML en texto XHTML que puede ser procesado por un analizador de XML.

Una vez que hemos sido capaces de hacer que el HTML sea conforme a XML, el siguientepaso es extraer modelos conformes al metamodelo Struts-JSP en base al contenido del XML.En este punto podrıamos utilizar EMF para extraer modelos del XHTML y a partir de ellosaplicar un lenguaje de transformacion de modelos. Sin embargo, los unicos elementos quedeseamos hacer corresponder entre plataformas son las etiquetas especıficas de Struts yJSF, mientras que el resto de las etiquetas HTML se traduciran a una etiqueta generica(GenericHTMLTag). Por lo tanto un mecanismo para establecer correspondencias genericasentre patrones del nombre de la etiqueta HTML aumentarıa la legibilidad, productividad y lafacilidad de mantenimiento que la aplicacion de un lenguaje de transformacion de modelos,donde es necesario escribir reglas con diferentes filtros para tratar cada tipo de etiqueta.

Por esta razon, para abordar el problema de los artefactos XML no bien formados,hemos ideado un lenguaje de transformacion especıfico del dominio denominado H2MoLimplementado como un DSL embebido en Ruby. Este lenguaje nos permite especificar quepartes de la pagina JSP seran ignoradas (que no son conformes a XML) con el fin de realizarla etapa de preprocesamiento. Internamente se utiliza HTree para transformar el codigoHTML en XHTML que posteriormente es procesado con un analizador sintactico XML.Ademas, proporciona construcciones para especificar como transformar etiquetas XML enelementos del metamodelo destino. Es importante destacar que este DSL no esta acopladocon nuestro metamodelo JSP sino que puede ser utilizado con cualquier metamodelo destino.El unico requisito es que el metamodelo destino tenga estructura de arbol.

A continuacion se muestra un fragmento de codigo H2MoL utilizado para establecer lacorrespondencia entre paginas JSP con etiquetas Struts a nuestro metamodelo JSP de JSF.


ISSN 1988–3455 SISTEDES, 2008 7

sub /<%@.+%>/, ’JSP::Directive’, ’directives’

sub /<%.+%>/, ’JSP::ScriptLet’, ’tags’

pre ’html’, ’Struts::View::HTMLTag’, ’tags’

map ’bean:message’, ’Struts::View::MessageTag’, ’tags’

generic ’JSP::GenericHTMLTag’, ’tags’

En su estado actual, este DSL proporciona cuatro tipos de sentencias, que se utilizanpara reconocer nodos XML y realizar correspondencias uno a uno con una metaclase destino.Para cada correspondencia el resultado se almacena en la propiedad especificada en el ultimoparametro de la sentencia (por ejemplo, un elemento GenericHTMLTag se almacena en lapropiedad tags del elemento padre). Los tipos de sentencias son los siguientes:

– sub. Toma una expresion regular con el fin de reconocer un fragmento de texto XML nolegal. Tambien se puede utilizar una metaclase para especificar un elemento del modeloque se creara cuando el texto se reconozca. El motor de ejecucion es el encargado desustituir la porcion de texto con un comentario XML como se ha explicado antes y deestablecer las correspondencias necesarias.

– map. Reconoce cualquier etiqueta XML cuyo prefijo y nombre concuerden con el iden-tificador o expresion regular dados.

– pre. Reconoce cualquier etiqueta XML prefijada por la etiqueta indicada o que concuerdacon la expresion regular dada.

– generic. Cualquier nodo XML que no forme parte de una de las correspondencias ante-riores es tomado por esta sentencia. Es importante destacar que solo es posible definiruna sentencia de este tipo.

En cuanto a la ejecucion de las sentencias, conviene mencionar que una vez que unasentencia se ejecuta con un nodo XML el resto de sentencias no se ejecutan. De hecho, elorden de prioridad de las sentencias es el siguiente: sub, map, pre, generic.

El uso de esta aproximacion aporta varias ventajas sobre la creacion de un inyector y eluso de un lenguaje de transformacion de modelos general [12]:

– La operacion sub nos permite aplicar esta estrategia para JSP, ASP y cualquier otromotor de ejecucion de plantillas de un modo generico.

– La sentencia generic hace posible la realizacion de correspondencias genericas. Ademastratar con prioridades es mas sencillo que escribir filtros en reglas de transformacionpara asegurar una estrategia de aplicacion de reglas apropiada.

– Este DSL se ejecuta directamente sobre el texto HTML sin apoyarse en ficheros XMIintermedios con lo que se obtiene una mejora del rendimiento.

5 Trabajo relacionado

La extraccion de modelos a partir de codigo fuente es un area que todavıa no tiene la madurezdeseada, aunque ya se han presentado varias propuestas interesantes. Entre ellas destacamosel framework MoDisco y las propuestas para conectar las tecnicas propias de las gramaticas(grammarware) con las tecnicas del DSDM (modelware), como son la herramienta xTextincluida en el toolkit openArchitectureWare y los trabajos de Wimmer y Kunert.

MoDisco (Model Discovery) [17] es una aproximacion extensible para ofrecer soporte a laextraccion de modelos de sistemas existentes que ha sido definida como parte del proyectoGMT [18] de Eclipse. Los componentes del framework MoDisco son: un metamodelo basadoen KDM [8], un mecanismo de extension del metamodelo, varias facilidades de manipulacionde modelos, y una metodologıa para disenar extensiones. Actualmente, debido a que estaen desarrollo solo ofrece la infraestructura para manejar y crear modelos. MoDisco define el


ISSN 1988–3455 SISTEDES, 2008 8

concepto de discoverer, que es un componente software capaz de analizar un sistema existente(por ejemplo codigo Java), y extraer un modelo mediante la infraestructura proporcionada.La finalidad de MoDisco no es cubrir todos los aspectos de un proceso de modernizacionsino unicamente ofrecer la infraestructura necesaria para la construccion de discoverers. Deesta forma, Gra2MoL puede ser utilizado para la implementacion de los discoverers.

xText [5] es un lenguaje que pertenece al framework openArchitectureWare [19] y permiteconstruir DSLs textuales en la plataforma Eclipse. En este lenguaje, la sintaxis concretatextual del DSL se especifica por medio de un lenguaje de definicion de gramaticas similara EBNF. A partir de la gramatica especificada se genera automaticamente el metamodelodel DSL, un analizador sintactico para reconocer la sintaxis del DSL y para instanciar elmetamodelo, y un editor especıfico del DSL. Wimmer [6] et. al. han propuesto un frameworkgenerico para conectar el grammarware y el modelware. El funcionamiento de este frameworkse resume en dos etapas. En una primera etapa, se aplican un conjunto basico de reglaspara generar un metamodelo no refinado a partir de una gramatica EBNF tales como lasgeneradas por xText. En la segunda etapa se aplican varias heurısticas para mejorar dichosmetamodelos. De forma similar, en Kunert [7] se opta por anadir anotaciones a la gramaticacon el objetivo de guiar el proceso de generacion. Es importante destacar que no existenherramientas que soporten estas dos ultimas aproximaciones.

Las principales desventajas de xText y los trabajos de Wimmer et. al y Kunert se hancomentado en la seccion 4.1. Gra2MoL carece de estas deficiencias dado que permite creardirectamente modelos que conformen a un metamodelo cualquiera como puede ser KDMo un metamodelo AST. Para ello, se especifica la definicion de una transformacion de unagramatica a un metamodelo. Dado que Gra2MoL ha sido disenado explıcitamente paratrabajar con este tipo de transformaciones, es mas facil escribir estas transformaciones quecuando se utiliza un lenguaje de transformacion de modelos comun. Gra2MoL tambien nospermite acceder a informacion tales como la lınea y columna donde se localiza un nodo enel codigo fuente. Ademas, puesto que Gra2MoL no utiliza un lenguaje especial para definirla gramatica, sino ANTLR [9], se promueve la reutilizacion de gramaticas existentes.

6 Conclusiones y trabajo futuro

En los proximos anos, la realizacion de casos de estudio sera crucial para que la Modern-izacion de Software Dirigida por Modelos madure como disciplina. La experimentacion conlos casos de estudio ayudara a identificar que cuestiones deben ser resueltas, ası como probarlas aproximaciones propuestas.

En este artıculo hemos presentado parte de los resultados de un proyecto de migracionde un sistema Struts a un sistema JSF, en concreto, el trabajo relacionado con la fase deextraccion de modelos. Los retos que hemos identificado relacionadas con esta fase son: (i)necesidad de disenar metamodelos modulares para promover la separacion de conceptos yla reutilizacion y (ii) utilizacion de tecnicas eficientes y efectivas de extraccion de modelosde artefactos fuente.

Hemos presentado una aproximacion para cada uno de estos retos. Los metamodeloshan sido disenados de una forma modular de modo que compartan conceptos comunes,facilitando ası su mantenimiento y reutilizacion. Hemos analizado diversas soluciones parala extraccion de modelos a partir de codigo conforme a una gramatica y hemos justificadoel uso de Gra2MoL frente a otras alternativas como xText. Para la extraccion de codigoconforme a un esquema XML hemos recurrido al framework EMF, y para la extraccion demodelos de texto no bien formado hemos creado un DSL llamado H2MoL con la finalidadde tratar con codigo HTML no bien formado.

En cuanto al trabajo futuro, continuaremos trabajando en Gra2MoL. Actualmente esta-mos estudiando la adecuacion de la estructura de reglas (que actualmente es dirigida por el


ISSN 1988–3455 SISTEDES, 2008 9

origen), ya que la experiencia adquirida en este caso de estudio nos ha inducido a cuestionarla necesidad de una aproximacion dirigida por el destino. Tambien seguiremos mejorandoH2MoL para que sea posible incluir condiciones de filtrado mas complejas.

Finalmente en este caso de estudio hemos trabajado con metamodelos ad-hoc para rep-resentar las plataformas, pero una alternativa para afrontar la fase de metamodelado es eluso de KDM. Sin embargo, debido al reducido numero de casos de estudio practicos conKDM, todavıa no estan claras las ventajas de este. Como lınea de trabajo futuro, planeamosestudiar esta alternativa en profundidad.

Agradecimientos

Este trabajo ha sido parcialmente financiado por los proyectos TIC-INF 06/01-0001 de laConsejerıa de Educacion y Cultura (CARM) y 05645/PI/07 de la Fundacion Seneca. JavierLuis Canovas Izquierdo dispone de una beca FPI de la Fundacion Seneca y Jesus SanchezCuadrado dispone de una beca FPU del Ministerio de Educacion y Ciencia.

Referencias

1. ADM. http://adm.omg.org2. ADM Task Force. Architecture-driven modernization scenarios.

http://adm.omg.org/ADMTF Scenario White Paper(pdf).pdf3. Struts. http://struts.apache.org4. JSR 127 Java Server Faces (JSF) Specification. http://jcp.org/en/jsr/detail?id=1275. Efftinge, Sven. openArchitectureWare 4.1 Xtext language reference. 2006

http://www.eclipse.org/gmt/oaw/doc/4.1/r80 xtextReference.pdf6. Wimmer, Manuel and Kramler, Gerhard. Bridging Grammarware and Modelware. Satellite

Events at the MoDELS 2005 Conference. 2006. 159–1687. Andreas Kunert. Semi-automatic Generation of Metamodels and Models from Grammars and

Programs. Fifth Intl. Workshop on Graph Transformation and Visual Modeling Techniques.2006. Electronic Notes in Theorical Computer Science

8. ADM Task Force. Knowledge Discovery Meta-Model (KDM). 2007http://www.omg.org/spec/KDM/1.0/

9. Parr, Terence. The Definitive ANTLR Reference: Building Domain-Specific Languages. Prag-matic Programmers. 2007

10. Java Compiler Compiler. https://javacc.dev.java.net11. J. Canovas Izquierdo, J. Sanchez Cuadrado and J. Garcıa Molina. Gra2MoL: A domain specific

transformation language for bridging grammarware to modelware in software modernization. 2ndWorkshop on Model-Driven Software Evolution. 12th European Conference on Software Main-tenance and Reengineering. 2008

12. J. van Wijngaarden and E. Visser. Program Transformation Mechanics. A Classification ofMechanisms for Program Transformation with a Survey of Existing Transformation Systems.Technical Report UU-CS-2003-048. Department of Information and Computing Sciences, UtrechtUniversity. 2003

13. Xpath. www.w3.org/TR/xpath14. J. Sanchez Cuadrado and J. Garcıa Molina. A plugin-based language to experiment with model

transformation. 9th International Conference in Model Driven Engineering Languages and Sys-tems. Volume 4199 of Lecture Notes in Computer Science. Springer (2006) 336-350.

15. F. Jouault and I. Kurtev. Transforming Models with ATL. 2005.16. HTree. http://a-k-r.org/htree/17. MoDisco project. http://www.eclipse.org/gmt/modisco18. GMT project. http://www.eclipse.org/gmt/19. Open Architecture Ware. http://www.eclipse.org/gmt/oaw


ISSN 1988–3455 SISTEDES, 2008 10

A Domain Specific Language for the Internet of Things?

Pau Giner, Joan Fons, y Vicente Pelechano

Centro de Investigacion en Metodos de Produccion de SoftwareUniversidad Politecnica de Valencia

Camino de Vera s/n, 46022 Valencia, Spain{pginer,jjfons,pele}@pros.upv.es

Resumen. Information Systems supporting organizational Business Processes usu-ally deal with real-world objects. The information about these physical elements iscommonly provided by human beings, which is far from being efficient. Automaticidentification technologies can improve this linkage. Thanks to RFID, books in alibrary can be borrowed just by picking them up. However, due to technological het-erogenity and the fast-changing requirements of Business Processes, ad-hoc solutionsdifficult system maintainability and evolution. The present work, based on the foun-dations of Model Driven Engineering, introduces modeling primitives to capture therequirements for this physical-virtual connection. These primitives permit to definean abstract specification that is useful to reason about the system and can guide itsdevelopment, or even derive the system automatically. Finally, this paper presentshow these ideas have been applied to the Smart Toolbox application.

1 Introduction

Information Systems are no longer constrained into the Digital Space. Business Processesusually deal with physical objects such as products in a supermarket or baggage pieces inan airport. This supposes a gap between the physical world and the Information System.The Internet of Things vision [6] aims at reducing this gap between physical and virtualworlds. Thanks to Ubiquitous Computing (Ubicomp) technologies, Information Systemscan get closer to the real world [16]. The linkage between physical elements and their digitalcounterparts gets automated, and people can focus on their real world activities, while thesystem is hidden in the background.

Automatic Identification (Auto-ID) technologies enable real-world objects to be takenautomatically in consideration by a software system, thus objects become “smart” as theyare not human-dependent anymore [15]. Traditionally, identification aspects have been com-pletely overlooked in the design of Information Systems as there were few options available toidentify any physical object. Normally the common identification mechanism was to delegatein human skills –such as reading a serial number– to extract the identity of an object andtransfer this by means of conventional interaction devices –mainly keyboards and mice– tothe system. In the Internet of Things, real-world objects become first class citizens. People,places and things can be identified in a myriad of different ways. Radio Frequency Identi-fications (RFID), Smartcards, barcodes, magnetic strips, and contact memory buttons toname a few, are some Auto-ID enabler technologies with a different degree of automation.

The present work faces the integration of digital and physical spaces from a system spec-ification perspective by the use of Domain Specific Languages (DSLs) [8]. The integrationof real-world objects in Information Systems is commonly faced from a technological per-spective. Ad-hoc solutions are developed for a particular technology. This approach hinders? This work has been developed with the support of MEC under the project SESAMO TIN2007-

62894 and cofinanced by FEDER.


ISSN 1988–3455 SISTEDES, 2008 11

the evolution of the system, as identification mechanisms are coupled with a certain tech-nological solution. Thus, benefits provided by DSLs in terms of easy of specification andmaintenance [3], are quite relevant for this kind of applications.

The main contribution of this work is the definition of a DSL to specify the linkagebetween digital and physical worlds in Information Systems. With the proposed DSL, systemdescriptions are kept close to the domain –facilitating system specification– and they aretechnologically independent –improving system evolution–. Developers for the Internet ofThings can use this language to state their requirements in a technology-agnostic fashionand the modeling community has an opportunity to apply their tools and techniques for thedevelopment of this new kind of systems.

The remainder of the paper is structured as follows. In section 2, a precise characterizationis given about the kind of system this work is dealing with. Section 3 introduces the DSLdefined. Section 4 gives some insights about the application of the DSL for the developmentof a case study. Related work is presented in section 5. Finally, section 6 presents conclusionsand further work.

2 Domain Analysis

DSLs describe concisely problems of a certain domain. Thus, domain knowledge is vital forthe definition of a DSL. Prior to the design of the language [12], the analysis of the domainis necessary. In order to do so, the following steps are required [17, 3]: identify the problemdomain of interest, gather all relevant knowledge of this domain, and cluster this knowledgein a handful notions and operations on them. Each of these steps are detailed below for thekind of applications considered in this work. Once domain concepts are clearly defined, aDSL based on these concepts can be designed.

2.1 Domain Identification

The present work deals with Information Systems that integrate real-world elements tosupport Business Processes in an organization. This definition is quite broad but we arefocused on applications where this linkage is highly exploited and identification –speciallyAuto-ID– is relevant. These systems contain several elements suitable to be identified bymeans of potentially different technologies.

In order to illustrate the DSL defined in the present work, we are using examples basedon the Smart Toolbox [10] application. This case study consists in monitoring the tools usedfor aircraft maintenance tasks. During aircraft reparations, the system should prevent toolsfrom being lost and causing potential damage. In order to do so, the content, the locationand the carrier of the toolbox is sensed automatically in real-time. This application improvesthe aircraft Maintenance, Repair, and Overhaul (MRO) process in an unobtrusive manner,so it fits perfectly in the application domain targeted in this work.

2.2 Gathering Relevant Knowledge

Once the domain is identified, we are interested in detecting the properties that are specificto this domain in order to characterize it. For our domain of interest, the core concept isthe identification mechanism. The identification mechanism is in charge of preservingthe real-virtual linkage. In the present section we define the aspects that are particular tothis mechanism in order to better characterize the domain. A conceptual framework for thedescription of the elements involved in the identification process was presented in [7].

Ubicomp systems integrate different services –sensors and actuators– seamlessly in theenvironment. Identification mechanisms can be considered as a specific kind of sensor and


ISSN 1988–3455 SISTEDES, 2008 12

actuator combination –e.g., a printing service combined with a barcode reading one–. How-ever, some properties specific to identification, not present when considering these sensorsand actuators independently, emerge when they are part of an identification system. Theseproperties are described below.

Limited replaceability. The functionality that an identification system provides is well-known [9]. Functions to create or acquire identifiers are common to any identificationtechnology. However, in contrast to common sensors, the replaceability of services in-volved in identification is quite limited. Replacing a barcode reader by an RFID reader,despite its common functionality –capture an identifier and transfer it to the digitalword– is not trivial. Some compensatory measures –such as label all products withRFID tags if it was not done preventively– should be taken for this change to work.

Multiplicity of the real-virtual linkage. The relation between physical elements andtheir virtual counterpart is not always one to one. Physical elements can share thesame identifier –i.e.: products that are labelled indicating their product type– or containmultiple identifiers –i.e.: a human-readable numeric code accompanying a barcode–.

Distributed processes. Systems of this kind usually expand across organizations involv-ing diverse computing resources. Labels are commonly produced by one system and readby many different systems with the potential need to share information among them.To support a whole Business Process, several systems need to be integrated.

2.3 Clustering the Knowledge

Identification mechanisms can be seen from different perspectives. We have defined sev-eral modelling dimensions in order to better structure the domain knowledge and reducedependencies among concepts. These are data dimension, technological dimension and re-sponsibility dimension.

Each dimension represents a different viewpoint of the system. Data dimension stressesthe relevance of information. The Technological dimension perceives the identification mech-anism as a device that bridges digital and physical spaces. Finally, the Responsibility dimen-sion describes the organization of elements for a certain task in a compositional view. Moredetail about these dimensions and the defined primitives is given below.

3 Design of the DSL

Once the domain has been analyzed, we present the design of the DSL. The modellingprimitives that conform the abstract syntax of the DSL are detailed below for each detecteddimension. The Smart Toolbox example has been used to illustrate the proposal. Fig. 1presents the specification of the example using the DSL. However, the concrete syntax usedin examples is not normative. Further research is needed to determine the best concretesyntax –either graphical or textual– in terms of intuitiveness and comprehensibility.

3.1 Data Dimension

The data dimension represents the available information at the Digital Space. Pieces ofinformation are organized in classes and relationships between these classes. The relevantinformation for all the members of a class is expressed by means of attributes. It can bemodelled by means of a class diagram –see Fig. 1–.

In the example, a Toolbox must have a Location and it can be carried by a Mechanic.It can contain several Tools which usually are a subset of the tools that were assigned tothis toolbox. There are different types of tools. A ToolKind represents the tools of the same


ISSN 1988–3455 SISTEDES, 2008 13

Fig. 1. Specification for the example using the DSL

type and it provides information regarding tool lifetime. In this model there is no distinctionbetween information that is pure digital –such as ToolKind– and the information that hassome real-world object associated with it. To manage the complexity in the multiplicity ofthe real-virtual linkage, we consider that even information without a physical counterpartcan be labelled –e.g., tools that are labelled with their toolkind identifier–.

3.2 Technological Dimension

The technological dimension represents the choices that exist to connect the data elementswith the services used for identification. Several primitives are defined to make this re-lationship as flexible as possible. The defined primitives are mediums, codifications andtechnologies. The identity of an element is expressed following a codification at the DigitalSpace. This identity can be represented in the Physical Space in different mediums and sometechnologies are able to handle the movement of information between both spaces.

Mediums The identity of objects can be present in the physical world in different forms.Mediums are physical supports for identifiers. For instance, a sequence of bars on a paperor a radio wave emitted by an RFID tag.

Different mediums can be defined as needed. They can be related in a hierarchy tospecialize them in groups with shared properties as depicted in Figure 1. In the example,numbers on paper is a kind of paper medium. The paper medium requires line of sight to allowthe extraction of the identifier. Two specializations are defined to distinguish an identifierexpressed by means of numbers –readable by humans– from one expressed by means of animage –more likely to be processed by a machine–.


ISSN 1988–3455 SISTEDES, 2008 14

Codifications Codifications represent a family of identifiers. Codifications usually are basedon numbering schemas such as Electronic Product Code (EPC). We define some informationto characterize the Codification primitive:

Supported mediums: this is a set of mediums that are capable to hold a physical repre-sentation of an identifier for the present codification. An EPC code can have a numericrepresentation or it can be represented by means of radio weaves. The indicated medi-ums are possible representations. The final system will only support a subset of thesemediums.

Elements following the codification: indicated classes from the data model need to beidentified by using the present codification. These restrictions usually respond to re-quirements of external organizations. Some companies such as Wal-Mart require theirproviders to use specific codifications for their products and adopting these codificationsis a must to interoperate with their systems. If a class is required to be codified in morethan one codification, all of them are considered.

Data handling services: Codifications rely on services for retrieving the information aboutthe identified elements, generate new identifiers and establish conversions between cod-ifications. For this to work a common data format is assumed. XML or a more specificlanguage such as Physical Markup Language (PML [4]), can be considered.

Codifications represent the different ways in which the information at the Data dimensioncan be expressed, the mediums where this information can be transferred and the servicesthat permit to do so.

Technology Technologies in this context are defined as families of services that can beused for a certain codification in a given medium. In the example –see Fig. 1–, mechanicsare identified on a numbers on paper medium. This means that reading services belonging tothe Text Label technology can be used. This services could be a keyboard for the mechanicto introduce her identification number or an OCR device to read it automatically. Thecodification used to identify a Mechanic could be either EPC or Consecutive Numbering.

Services involved in a technology group can have a different role with respect to theidentification process. Services can act as minters –the ones that generate physical repre-sentations of identifiers– or readers –services in charge of transmitting identifiers from thephysical to the digital world–. A printer can play the role of minter to translate identifiers toa barcode representation. A general video camera can be used as a reader for these barcodesbut not for RFID tags. So there is a need to specify which services can be used for a cer-tain technology. In addition, the multiplicity supported in identification should be indicated.Barcode readers usually read barcodes one-by-one, while RFID antennas can detect severaltags per read.

3.3 Responsibility Dimension

In an environment where objects are aware of other objects, the responsibility of identi-fication cannot be assumed. In the case study, the responsible for determine which toolsare contained in a certain toolbox is the own toolbox. This responsibility, previous to theusage of RFID technology was for the mechanic. These two scenarios –responsibility for toolidentification on (a) mechanic or (b) toolbox– define completely different systems.

Both scenarios are depicted in Figure 2, to illustrate the relevance of this aspect. Inthe scenario (a), mechanics can be equipped with a PDA and they indicate by hand whichtoolbox they are carrying and the tools that are contained in it. In the scenario (b), thetoolbox can be equipped with an RFID antenna to detect labels on tools and mechanics.


ISSN 1988–3455 SISTEDES, 2008 15

Fig. 2. Different possible responsibilities

Evolving the system from one scenario to the other only requires to do the correspondingmodification at modeling level.

Responsibility Dimension presents real-world objects that are identifiable by the systemand a hierarchy of responsibility of its identification. This model includes the relationshipsthat each object is responsible of informing about for a certain task. This should be consistentwith relationships established in the Data Dimension. Identifiable elements can be relatedusing relationships of two kinds: responsibility and delegated responsibility.

Responsibility relationship: The source element should obtain the information aboutthe target element.

Delegated responsibility relationship: The target element is considered an extensionof the source element. This causes that the responsible of obtaining the source elementis also responsible for the target element acquisition. In Figure 2, the dotted line be-tween the toolbox and its tools in scenario (a), means that the Mechanic is in chargeof identifying the tools. So the system should offer the needed mechanisms not only toindicate the detected tools, but also to indicate in which toolbox they are.

For both kinds of relationships it can be specified the medium used to identify an element.In the example, tools corresponding to the content of a toolbox should be detectable bymeans of radio and numbers on paper mediums. Although identification of physical elementsis the common case –marked as sensed in the figure–, alternatively it is also possible to mark arelationship as new or known. Elements marked as known are retrieved from the informationrepository whereas the new elements require the creation of the information at the digitalspace but also the minting of the associated physical element.

Events Identification mechanisms are a kind of sensors that can detect interesting events ofbusiness level –e.g., when the repairing task of the example is completed–. In the example twoevents are defined. LocationChange and ContentMismatch. The first represents the toolboxgoing out of a particular location; the later indicates that the actual content is not theone expected. LocationChange is used to determine that the repair task has been completed,whereas ContentMismatch is useful to detect forgotten tools during the repair task. A globalevent is defined combining both to indicate a mismatch in the content of a toolbox whenthe reparation has finished.

4 Applying the DSL

The presented concepts have been formalized in a DSL by means of metamodeling technolo-gies. A prototype of the Smart Toolbox example has been developed in order to detect howDSL concepts map to a specific implementation solution.


ISSN 1988–3455 SISTEDES, 2008 16

4.1 Formalizing the Concepts in a Metamodel

To represent the concepts introduced in the present work we define a metamodel. In this way,the abstract syntax for the DSL is clearly defined. The metamodel defines what constructscan be used and how they can be combined for the creation of models. Therefore, thelanguage defined is unambiguous at least at syntactic level.

Fig. 3. DSL metamodel and example model conforming to it.

The modeling primitives presented in this work have been formalized using Ecore. Ecore,part of the Eclipse Modeling Framework (EMF), is a language targeted at the definitionof metamodels with precise semantics. The defined metamodel for this work is organizedin different packages –one for each detected dimension plus a core package with generalconcepts such as service or task–. Figure 3 presents an excerpt of the metamodel1, wheresome of the concepts from the technological dimension and relationships among them areshown. Using EMF facilities for the edition of models, a specification for the case studyconforming to the DSL was defined –see right hand side of Fig. 3–.

4.2 Driving the Implementation of the Case Study

We have developed the Smart Toolbox case study example in order to detect how DSL con-cepts can map to a specific implementation architecture. These technological mappings helpto systematize the development process and constitute the first step toward its automation.More detail about the target architecture and the technological mappings is given below.

Target Architecture Considering requirements for this kind of systems in terms of distri-bution and replaceability, the Smart Toolbox application has been implemented following aService Component Architecture2 (SCA). SCA is a vendor, technology and language neutralmodel for implementing Service Oriented Architectures (SOAs).

Different technologies can be used for the implementation of SCA components and bind-ings, and an asynchronous communication model is provided. The configuration of compo-nents and their connection is decoupled from the implementation favouring replaceabilityof components. In addition, SCA components can be distributed in different comput-ing nodes, from different threads in the same machine to different computers. For data1 The complete metamodel can be obtained from http://www.pros.upv.es/labs/projects/auto-id/2 http://www.osoa.org/display/Main/Service+Component+Architecture+Home


ISSN 1988–3455 SISTEDES, 2008 17

interoperability we have used Service Data Objects (SDO). SDO makes it possible to hidethe back-end data source, as it offers homogeneous access for XML, relational or file baseddata sources among others [14].

For our specific domain, we have defined two kind of components, Identification Compo-nents (ICs) and Services –readers and minters–. ICs are in charge of retrieving informationusing the different services or other identification components. Services encapsulate the tech-nologies that allow reading and minting identifiers from/to the physical space.

In order to build onto the defined architecture, in addition to define these components,it should be decided (1) how ICs are connected to services and (2) how ICs are connectedto each other.

Technological Mappings In the present section we illustrate how the different conceptsdefined in the DSL can be mapped to the target architecture. In this way, the productionof the case study prototype is systematized. The knowledge obtained from the definition ofthese mappings is liable to be formalized in transformation rules and automate the devel-opment process for systems of this kind.

Fig. 4. Eclipse toolset used for the development the prototype.

Eclipse tools were used for the development of the case study –see Fig. 4– and ApacheTuscany was the chosen implementation of the SCA and SDO specifications. How DSLconcepts map to the defined architecture for each of the DSL dimensions is detailed below.

Data dimension: Information structure captured in this dimension can be easily expressedas an XML Schema –Fig. 4 shows at the top-right side the Eclipse XSD editor used–.The defined XML Schema is imported by the SDO framework to define the system datatypes to be used in the system.

Technological dimension: In this dimension the required Services are detected –e.g., weneed Fiducial, Text Label and RFID readers–. This components wrap existing technology-specific solutions. The RFID middelware used was Accada [5]. Fiducials were detected


ISSN 1988–3455 SISTEDES, 2008 18

using reacTIVision3 and a wide-angle lens webcam. Text Label is implemented as a webpage that allows the user to introduce an identifier using the keyboard.When wiring these components, replaceability limitations captured in this dimensionare considered. Services can only be connected to an IC if these services are based on atechnology that supports the required mediums and codifications.

Responsibility dimension: From the information captured in this dimension, the re-quired ICs and their wiring are defined. Toolbox, Location, Mechanic and Tools im-plement the IDElement interface –see Fig. 4 at the bottom-left side– to act as an ICimplementation. SCA annotations are used to indicate that (1) the interface can be usedin a distributed environment –it is remotable– (2) the getElement method has not imme-diate response –it is a one-way method–; and (3) it has an associated callback interface–it is a bidirectional interface–. The use of bidirectional interfaces allows asynchronouscommunication. In Fig. 4, code for IdElement and IdElementCallback interfaces is shown.Components accessing an IC should implement the setElement method –to receive thedata– and the updated method –to get notifications of changes–.Component wiring is defined in a XML-based composite specification –see Fig. 4 at thetop-left side–. The hierarchy of responsibility, captured in the Responsibility Dimension,is reproduced when wiring ICs.

5 Related Work

Object tagging applications have been studied for a long time [19]. The need for definingarchitectures that support Auto-ID has lead to the development of frameworks and middle-ware to abstract from the filtering and aggregation tasks needed when tags are processed.Some middleware is specific to RFID [5, 2], but support for Auto-ID in a technology inde-pendent fashion has been also developed [1, 11, 18]. However, although frameworks providedomain-specific primitives, the usage of general purpose languages such as Java to imple-ment their extensions does not enforce the usage of domain-specific concepts, so frameworkusage rules are only enforced by documentation. The usage of models goes one step further,allowing only a well-defined set of conceptual primitives to be present, and then mappingthem into a specific framework.

Physical Markup Language (PML [4]) is a format for the exchange of data capturedby the sensors in an Auto-ID infrastructure. PML concepts are targeted at describing thephysical world, while our approach provides concepts to also describe the linkage with thedigital world and aspects at requirement level. In [13] Munoz presents a method for thedevelopment of pervasive systems based on MDE. However the specific needs regardingidentification are not considered.

6 Conclusions and Further Work

The development of applications for the emerging Internet of Things requires to respondto many challenges at different levels –technological, data, requirements, etc.–. The use ofmodelling techniques can help to integrate all these aspects.

The DSL introduced in this work covers the physical-virtual gap that exist when real-world objects are involved in Information Systems from a modelling perspective. Accordingto the analysis of the application domain, we have detected the aspects that are relevantfor the physical-virtual linkage. We have defined a conceptual framework that captures therelevant concepts in order to constitute a language that describes this linkage. Adescription of the identification aspect of a system can be mapped systematically to a3 http://reactable.iua.upf.edu/?software


ISSN 1988–3455 SISTEDES, 2008 19

target architecture that supports the requirements detected for this kind of applicationsin component replaceability and distribution terms.

In this work, we have established a systematic path from identification requirementsexpressed in a technologically-independent fashion to technological-specific solutions sup-porting these requirements. In order to evaluate the expressivity of the defined DSL, thedevelopment of more case studies in production environments is required. The feedbackof development teams and final users would be really valuable. This feedback could also helpto find a concrete syntax for the primitives defined in the language.

The development of tools to support the process and the integration with existingmodeling solutions in the area would provide a great value to the work. The integrationwith PervML [13] would allow the definition of some aspects –such as service behavior– thatare not related with identification but are needed for the construction of a complete system.

Referencias

1. K. Aberer, M. Hauswirth, and A. Salehi. Middleware support for the “internet of things”. In5th GI/ITG KuVS Fachgesprach, Stuttgart, Germany, 7 2006.

2. C. Bornhovd, T. Lin, S. Haller, and J. Schaper. Integrating automatic data acquisition withbusiness processes experiences with sap’s auto-id infrastructure. In vldb’2004: Proceedings ofthe Thirtieth international conference on Very large data bases, pages 1182–1188. VLDB En-dowment, 2004.

3. A. Deursen and P. Klint. Little languages: little maintenance? Technical report, Amsterdam,The Netherlands, 1997.

4. C. Floerkemeier, D. Anarkat, T. Osinski, and M. Harrison. Pml core specification. White Paper.University of St. Gallen. Auto-ID Center., October 2003. Version 1.0.

5. C. Floerkemeier, C. Roduner, and M. Lampe. Rfid application development with the accadamiddleware platform. IEEE Systems Journal, Special Issue on RFID Technology, Dec. 2007.

6. N. Gershenfeld, R. Krikorian, and D. Cohen. The internet of things. Scientific American,291(4):46–51, 2004.

7. P. Giner, M. Albert, and V. Pelechano. Physical-virtual connection in ubiquitous business pro-cesses. In Proceedings of the 10th International Conference on Enterprise Information Systems,volume 2, pages 266 – 271, Barcelona (Spain), June 2008.

8. J. Gray, J.-P. Tolvanen, S. Kelly, A. Gokhale, S. Neema, and J. Sprinkle. Domain-SpecificModeling (in CRC Handbook of Dynamic System Modeling), chapter 7, page (in publication).CRC Press, 2007.

9. T. Kindberg. Implementing physical hyperlinks using ubiquitous identifier resolution. In WWW’02: Proceedings of the 11th international conference on World Wide Web, pages 191–199, NewYork, NY, USA, 2002. ACM Press.

10. M. Lampe, M. Strassner, and E. Fleisch. A ubiquitous computing environment for aircraftmaintenance. In SAC ’04: Proceedings of the 2004 ACM symposium on Applied computing,pages 1586–1592, New York, NY, USA, 2004. ACM.

11. M. Langheinrich, F. Mattern, K. omer, and H. Vogt. First steps towards an event-based in-frastructure for smart things. Ubiquitous Computing Workshop, PACT 2000. Philadelphia.,October 2000.

12. M. Mernik, J. Heering, and A. M. Sloane. When and how to develop domain-specific languages.ACM Comput. Surv., 37(4):316–344, 2005.

13. J. Munoz and V. Pelechano. Building a software factory for pervasive systems development. InCAiSE, pages 342–356, 2005.

14. L. Resende. Handling heterogeneous data sources in a soa environment with service data objects(sdo). In SIGMOD ’07: Proceedings of the 2007 ACM SIGMOD international conference onManagement of data, pages 895–897, New York, NY, USA, 2007. ACM.

15. K. Romer, T. Schoch, F. Mattern, and T. Dubendorfer. Smart identification frameworks forubiquitous computing applications. Wirel. Netw., 10(6):689–700, 2004.


ISSN 1988–3455 SISTEDES, 2008 20

16. M. Strassner and T. Schoch. Today’s impact of ubiquitous computing on business processes.In F. Mattern and M. Naghshineh, editors, Short Paper Proc. International Conference onPervasive Computing, pages 62–74, Pervasive2002, April 2002.

17. A. van Deursen, P. Klint, and J. Visser. Domain-specific languages: an annotated bibliography.SIGPLAN Not., 35(6):26–36, 2000.

18. J. Vermeulen, R. Thys, K. Luyten, and K. Coninx. Making bits and atoms talk today: Apractical architecture for smart object interaction. In First international workshop on Designand Integration Principles for Smart Objects (DIPSO’2007), Innsbruck (Austria), September2007.

19. R. Want, K. P. Fishkin, A. Gujar, and B. L. Harrison. Bridging physical and virtual worldswith electronic tags. In CHI ’99: Proceedings of the SIGCHI conference on Human factors incomputing systems, pages 370–377, New York, NY, USA, 1999. ACM Press.


ISSN 1988–3455 SISTEDES, 2008 21

Perfiles UML y Desarrollo Dirigido por Modelos: Desafíos y

Soluciones para Utilizar UML como Lenguaje de Modelado

Específico de Dominio

Giovanni Giachetti1, Beatriz Marín1 y Oscar Pastor1

1 Centro de Investigación en Métodos de Producción de Software

Universidad Politécnica de Valencia

Camino de Vera s/n, 46022 Valencia, España {ggiachetti, bmarin, opastor}@pros.upv.es

Resumen. El Desarrollo de Software Dirigido por Modelos (DSDM) es sin lugar a dudas el

esquema de desarrollo que más atención recibe a nivel mundial. Para su correcta aplicación,

las propuestas DSDM requieren un lenguaje de modelado que posea una semántica precisa

dentro del dominio de aplicación. Para obtener este lenguaje de modelado se suele optar por

dos alternativas: (1) crear un nuevo Lenguaje de Modelado Específico de Dominio (LMED),

o (2) extender la semántica de UML mediante un perfil UML. Este trabajo se centra en la

segunda alternativa, ya que la falta de un proceso claro para la definición de perfiles UML, ha

provocado que muchas de las propuestas basadas en esta estrategia tengan errores en su

especificación o no aprovechen las características introducidas en las últimas versiones de

UML. Este trabajo pretende dar apoyo a aquellas propuestas DSDM que decidan utilizar

UML para definir sus modelos, señalando los desafíos que tendrán que superar para obtener

un proceso que les permita construir correctamente perfiles UML. Para cada uno de estos

desafíos se proponen pautas para resolverlos exitosamente. Finalmente, se mostrará como

integrar perfiles UML y LMEDs en una propuesta DSDM para aprovechar los beneficios que

proveen estas alternativas de modelado.

Palabras Clave: DSDM, LMED, Perfil UML, UML.

1 Introducción

Dada la relevancia que tiene hoy en día el Desarrollo de Software Dirigido por Modelos (DSDM),

no es extraño que aparezcan constantemente nuevas propuestas basadas en este esquema de

desarrollo enfocadas a los más diversos dominios de aplicación. En este contexto, el contar con

lenguajes de modelado adecuados es indispensable para la correcta aplicación de las distintas

propuestas DSDM. Por este motivo, muchas propuestas han definido sus propios lenguajes de

modelado que se conocen como Lenguajes de Modelado Específicos de Dominio (LMED). Estos

lenguajes de modelado proveen la precisión semántica necesaria para describir sin ambigüedad los

modelos conceptuales que participarán en los procesos de desarrollo de software. De esta manera,

mediante transformaciones de estos modelos conceptuales se puede obtener el producto de

software final.

La definición de un LMED correcto no es una tarea trivial, ya que deben ser considerados todos

los constructores conceptuales requeridos dentro del dominio de aplicación, indicando cada una de

las propiedades y restricciones que deben tener para evitar inconsistencias o ambigüedades de

modelado. En caso que la definición del LMED no sea correcta, la propuesta DSDM no contará

con el soporte adecuado y no podrá ser aplicada exitosamente. Para obtener un LMED correcto se

suele construir el metamodelo que describe los constructores conceptuales del dominio


ISSN 1988–3455 SISTEDES, 2008 22

(metamodelo del LMED) y luego, a partir de este metamodelo, se construyen las herramientas de

modelado necesarias.

Existe otra alternativa para obtener un lenguaje de modelado que se ajuste a las necesidades de

una propuesta DSDM: extender el Lenguaje de Modelado Unificado (UML) con la semántica

requerida por la propuesta DSDM, debido a que UML no cuenta con la precisión suficiente para

realizar de forma correcta un proceso de transformación de modelos completo. Esta falta de

precisión se puede observar en los puntos de variación semánticos definidos en la Superestructura

de UML [13]. Las extensiones de UML se suelen definir mediante un perfil UML que incorpora la

precisión semántica de un LMED, o en otras palabras, UML se convierte en el LMED.

De estas dos alternativas de modelado, la construcción de un LMED propietario toma cada vez

más relevancia, ya que al describir sólo el conjunto de constructores conceptuales del dominio, su

estructura se ajusta mejor al dominio de aplicación, facilitando su compresión por parte de

expertos del dominio. Otra ventaja de un LMED es que su menor tamaño y complejidad en

relación a UML, facilita la implementación de herramientas que optimicen las tareas de modelado,

desarrollo y mantenimiento de los sistemas de software generados.

Por otra parte, a pesar de los beneficios que presentan los LMED, las propuestas DSDM se ven

motivadas a utilizar perfiles UML para integrar en UML la precisión semántica que requieren,

debido a que UML es el lenguaje más utilizado a nivel mundial para la definición de modelos

asociados al desarrollo de software. Contar con una propuesta DSDM que de soporte a UML

permite llegar a un mayor número de usuarios potenciales, aprovechar la gran variedad de

tecnologías UML existentes, y reducir la curva de aprendizaje [17]. Además, UML puede ser

utilizado como mecanismo para difundir ideas y teorías entre distintas comunidades científicas,

especialmente para aquellas tecnologías que pueden tener una aplicación interdisciplinaria.

Actualmente, la especificación de UML [12][13] definida por OMG (Object Management

Group) [11], incorpora una serie de características para mejorar las posibilidades de extensión de

este lenguaje mediante el uso de perfiles UML. Las nuevas características de los perfiles UML

permiten definir la precisión semántica requerida por la mayoría de las propuestas DSDM

existentes, provocando que en los últimos años la cantidad de perfiles UML se incremente

considerablemente. Sin embargo, a pesar del uso masivo que se hace de los perfiles UML, aún no

existe un proceso estandarizado que indique cómo elaborar correctamente un perfil UML que

integre (en UML) la semántica requerida por una propuesta DSDM. Tal como señala Selic en [16],

la falta de un proceso para la definición de perfiles UML conlleva que no se aprovechen todas las

posibilidades de extensión que éstos proveen y, que en muchos casos, los perfiles UML resultantes

sean técnicamente inválidos al no cumplir con la especificación de OMG. También France et al.

[5] señalan la falta de un mecanismo que indique cómo especificar las extensiones de forma

correcta sobre UML.

Por este motivo, el objetivo de este trabajo es presentar un proceso genérico para aquellas

propuestas DSDM que deseen extender UML mediante un perfil UML, y de esta manera poder

utilizar UML como LMED. Este proceso genérico está basado en la solución de integración con

UML desarrollada para la propuesta OO-Method [15], que es un propuesta DSDM que ha sido

aplicada exitosamente al desarrollo industrial de software por la empresa CARE-Technologies [3].

Este artículo muestra cómo se han definido los distintos pasos que componen el proceso

propuesto, indicando los desafíos encontrados y como han sido resueltos. Además, dado que tanto

UML como LMEDs presentan una serie de ventajas para las propuestas DSDM, uno de los

desafíos propuestos consiste en mostrar cómo es posible integrar estas alternativas de modelado en

un mismo entorno DSDM para aprovechar los beneficios de ambas.

El resto del artículo está organizado de la siguiente manera: después de esta introducción, la

Sección 2 presenta un análisis de distintos trabajos asociados a la construcción de perfiles UML

para propuestas DSDM, identificando los puntos fuertes y débiles de cada propuesta. En la

Sección 3 se utiliza el análisis realizado para construir un proceso genérico que sirva en la

elaboración de un perfil UML correcto, mostrando los desafíos y soluciones planteadas en el

desarrollo del proceso. Finalmente, la Sección 4 presenta las conclusiones y trabajos futuros.


ISSN 1988–3455 SISTEDES, 2008 23

2 Análisis de Propuestas para la Definición de Perfiles UML

Antes de analizar los mecanismos para la definición de perfiles UML, es importante tener claro

que no todas las propuestas DSDM pueden utilizar perfiles UML para integrar en UML sus

necesidades particulares de modelado. La principal restricción radica en que los perfiles UML no

pueden cambiar la semántica original del metamodelo que extienden. En este trabajo el

metamodelo que debe ser extendido es el metamodelo de UML, que estará dado por la

especificación de OMG que ha sido denominada Superestructura de UML [13].

La restricción de los perfiles UML descrita en el párrafo anterior, limita el conjunto de

propuestas DSDM a aquellas cuyos constructores conceptuales pueden ser considerados como un

subconjunto de los constructores de UML. Sin embargo, UML al ser formulado como un lenguaje

de modelado de propósito general, permite que la mayoría de las propuestas DSDM existentes

cumplan con esta restricción.

Analizando la literatura relacionada a los perfiles UML se han encontrado dos caminos para la

definición de perfiles UML. El primer camino consiste en definir de forma manual e intuitiva las

extensiones necesarias, de acuerdo a los criterios y conocimientos con los que cuente el diseñador

del perfil UML. Esta forma intuitiva de definir perfiles UML es compleja, y además, tiene

asociados los riesgos de obtener una implementación incorrecta que no cumpla con la

especificación de UML o de cometer errores propios de una definición manual.

El segundo camino para la elaboración de perfiles UML consiste en un esquema más

estructurado y formal. Este esquema está centrado en el metamodelo que describe los

constructores conceptuales del dominio (que corresponde al metamodelo del LMED). Luego, se

establecen las correspondencias entre este metamodelo y el metamodelo de UML, para finalmente

integrar la semántica descrita en el metamodelo del LMED en UML mediante la elaboración del

perfil UML correspondiente.

Es importante destacar que el metamodelo del LMED representa sólo la sintaxis abstracta del

lenguaje de modelado [8]. Sin embargo, en este documento es utilizado el término semántica para

referirnos a la sintaxis abstracta representada por el metamodelo del DSML y de esta manera ser

consistentes con la especificación de UML y los trabajos relacionados.

En resumen, este segundo camino es más adecuado para elaborar un perfil UML correcto por

las siguientes razones:

• La definición del metamodelo del LMED brinda una definición precisa de la semántica que se debe integrar en UML, permitiendo establecer mecanismos de validación e incluso automatizar

la definición de extensiones.

• Dado que el metamodelo del LMED representa un conjunto menor de constructores que el metamodelo de UML y está más ajustado al dominio de aplicación, su definición es más

sencilla e intuitiva que definir las extensiones directamente sobre el metamodelo de UML.

• Existe bastante documentación y herramientas orientadas a la definición de metamodelos, mientras que la literatura relacionada a la correcta definición de perfiles UML es bastante

escasa y las herramientas UML prácticamente no proveen ayuda para su definición.

• El metamodelo del LMED y la identificación de correspondencias con el metamodelo de UML permiten determinar si la semántica requerida por la propuesta DSDM puede ser integrada en

UML, de acuerdo a las limitaciones que presentan los perfiles UML. Además, en caso que no

sea posible la integración, el metamodelo del LMED puede ser utilizado en la construcción de

herramientas de modelado específicas.

Siguiendo el segundo camino para la elaboración de perfiles UML, uno de los primeros trabajos

en proponer el uso del metamodelo del LMED para la obtención de perfiles UML es el de Fuentes-

Fernández et al. [6]. En este trabajo se proponen algunas guías básicas para la generación del perfil

UML a partir del metamodelo del LMED (que en este trabajo es denominado metamodelo de

dominio). Los puntos fuertes de este trabajo son:


ISSN 1988–3455 SISTEDES, 2008 24

1. Propone el uso de Meta Object Facility (MOF) [10] para la definición del metamodelo del LMED. MOF es el lenguaje estándar de OMG para la definición de metamodelos y se

encuentra alineado con la superestructura de UML. Así, el metamodelo del LMED estará

definido en el mismo lenguaje que el metamodelo de UML, manteniendo consistencia

estructural entre ambos.

2. Propone algunas reglas con las que se pueden inferir las extensiones (estereotipos, valores etiquetados y restricciones) así como las metaclases que deben ser extendidas. Estas reglas

proveen una primera aproximación de cómo automatizar la generación de perfiles UML.

Los puntos débiles del trabajo son:

1. Las reglas propuestas para la construcción del perfil UML son muy básicas y no permiten aprovechar la semántica que ya existe en UML. Por ejemplo, propone incorporar todos los

atributos definidos en el metamodelo del LMED como valores etiquetados. Sin embargo,

muchos de estos atributos pueden tener equivalencia con atributos ya definidos en UML.

2. No se establecen pautas para la correcta definición del metamodelo del LMED que estén orientadas a obtener una correcta integración con el metamodelo de UML.

Selic en [16] presenta una aproximación sistemática para la definición de perfiles UML a partir

del metamodelo del LMED (que denomina modelo de dominio). En este artículo se incluyen una

serie de criterios que se deben considerar al momento de elaborar el metamodelo del LMED para

realizar una correcta integración con el metamodelo de UML, así como una lista de

consideraciones para realizar el mapeo del metamodelo elaborado en un perfil UML. Los puntos

fuertes de este trabajo son:

1. Presenta las nuevas características de los perfiles UML. 2. Presenta guías para la correcta definición del metamodelo del LMED. 3. Propone realizar una identificación de equivalencias entre el metamodelo del LMED y el metamodelo de UML para identificar correctamente los elementos que deben ser extendidos y

las extensiones que deben ser realizadas.

El punto débil del artículo es:

1. Las guías presentadas son demasiado generales y no permiten su automatización.

Si bien los artículos orientados a la correcta definición de perfiles UML son escasos, lo son aún

más los que proponen alternativas de automatización. Entre estos trabajos es posible destacar los

trabajos de Lagarde et al. [9] y el de Wimmer et al. [18]. El primero de estos trabajos propone

realizar una identificación de equivalencias entre las clases del metamodelo del LMED y el

metamodelo de UML mediante la definición de un esqueleto inicial del perfil UML. Luego,

mediante la identificación de patrones, este esqueleto es refinado de manera automática para

obtener el perfil UML final. Los puntos fuertes de este trabajo son:

1. Propone un conjunto de reglas para la generación automática del perfil UML. 2. Propone la definición de un mapeo de equivalencias entre las clases de los metamodelos. 3. Propone la identificación de patrones para generar las extensiones necesarias utilizando como referencia la información de mapeo.

Los puntos débiles son:

1. Para realizar el mapeo se define un esqueleto inicial del perfil UML, por lo que el diseñador del LMED requiere tener conocimientos de perfiles UML.

2. Los patrones definidos están centrados principalmente en el manejo de asociaciones entre clases, dejando de considerar muchas otras situaciones de modelado, por lo que no es posible

realizar una generación completa del perfil UML.

El trabajo de Wimmer et al. [18] propone un esquema semiautomático para la integración entre

LMEDs y UML. En esta propuesta se incorpora un lenguaje específico para la definición de

equivalencias (mapeo) entre los metamodelos. Los puntos fuertes de este trabajo son:

1. Establece la definición de un mapeo entre los distintos elementos de los metamodelos (clases, atributos, asociaciones, etc.), lo que permite una mejor inferencia de las extensiones necesarias.


ISSN 1988–3455 SISTEDES, 2008 25

2. Establece pautas para definir las reglas de transformación para obtener el perfil UML y como pueden ser implementadas mediante un lenguaje de transformación de modelos.

El punto débil de esta propuesta es:

1. Sólo permite equivalencias M:1 entre ambos metamodelos, es decir, un elemento del metamodelo del LMED puede estar asociado sólo con un elemento del metamodelo de UML.

Esta es una limitación importante para poder aplicar este trabajo en propuestas DSDM reales,

donde las equivalencias ente metamodelos pueden ser 1:M, e incluso M:M.

El trabajo de Giachetti et al. [7], indica como redefinir el metamodelo del LMED para obtener

un correcto mapeo con el metamodelo de UML. Los puntos fuertes de este trabajo son:

1. Propone la redefinición del metamodelo del LMED en un nuevo metamodelo que permita una correcta integración con el metamodelo de UML.

2. Propone una serie de reglas que deben ser satisfechas para que el metamodelo de un LMED pueda ser integrado completamente en UML.

3. Propone un esquema sistemático para redefinir el metamodelo del LMED y obtener un metamodelo que cumpla con las reglas de integración.

4. Propone un mecanismo sencillo para establecer las equivalencias entre metamodelos. Los puntos débiles son:

1. No presenta reglas de transformación para obtener el perfil UML final. 2. Redefinir el metamodelo del LMED implica un esfuerzo adicional para obtener el perfil UML.

Finalmente, destacaremos el trabajo de Abouzahra et al. [1], que propone una solución para el

intercambio entre modelos definidos con perfiles UML y modelos definidos con LMEDs. Para el

intercambio de modelos usa un mapeo entre la definición del perfil UML (que denomina

metamodelo del perfil) y el metamodelo del LMED. Los puntos fuertes de este trabajo son:

1. Permite aprovechar los beneficios de los LMEDs y los perfiles UML. 2. Es compatible con las propuestas antes señaladas, ya que hace uso del metamodelo del LMED. 3. Ofrece una herramienta de código abierto para realizar el intercambio. Los puntos débiles son:

1. La propuesta está centrada en una herramienta específica, dificultando su generalización. 2. El mapeo entre el perfil UML y el metamodelo del LMED se debe realizar de forma manual.

3 Proceso para la Generación de Perfiles UML: Desafíos y Soluciones

En esta sección, se consideran los puntos fuertes de cada propuesta analizada en la sección 2 para

elaborar un proceso genérico que pueda ser utilizado en la construcción de un perfil UML que

integre en UML toda la expresividad semántica requerida por una propuesta DSDM. En la

definición de este proceso nos encontramos con el siguiente desafío:

Primer desafío: Establecer el punto de partida.

Al analizar los trabajos que proponen alternativas para la correcta definición de perfiles UML,

parece claro que el mejor punto de partida será definir el metamodelo del LMED, siendo éste el

primer paso del proceso para construir perfiles UML. El metamodelo LMED debe ser definido sin

considerar aspectos del perfil UML o del metamodelo de UML para obtener una correcta

representación del dominio y evitar cualquier tipo de restricción semántica. Este metamodelo debe

tener los siguientes elementos:

• El conjunto de constructores conceptuales definidos como clases del metamodelo (metaclases).

• El conjunto válido de relaciones que existen entre los constructores conceptuales.

• El conjunto de restricciones que controlan como pueden ser combinados los diferentes constructores conceptuales para definir modelos válidos.

• La notación asociada a los constructores conceptuales, cuando corresponda.

• El significado de los constructores conceptuales.


ISSN 1988–3455 SISTEDES, 2008 26

Para la elaboración del metamodelo se utilizará la especificación MOF [10] de OMG. El uso de

MOF permitirá que el metamodelo del LMED sea elaborado con el mismo lenguaje que el

metamodelo de UML. De esta manera, se evitan inconsistencias en la notación y el significado de

los constructores utilizados en ambos metamodelos y se facilita la identificación de equivalencias.

Sin embargo, tal como se ha señalado previamente, MOF sólo permite describir la sintaxis

abstracta del LMED y por lo tanto, no permite especificar la notación y el significado de los

constructores conceptuales. Esta información deberá ser documentada de forma separada para que

sirva de apoyo a la especificación y compresión del metamodelo del DSML.

La especificación de MOF está dividida en dos conjuntos. El primer conjunto corresponde a la

especificación MOF completa o CMOF (por complete MOF en inglés). El segundo conjunto

corresponde sólo a los constructores esenciales para la definición de metamodelos denominado

MOF esencial o EMOF (por essential MOF en inglés).

Al analizar la última especificación de UML [12] es posible observar que las capacidades de

extensión soportadas por los perfiles UML son muy cercanas a las capacidades de metamodelado

soportadas por EMOF. En cambio, muchas de las características de CMOF no son soportadas por

los perfiles UML, como por ejemplo, las asociaciones n-arias o la redefinición de propiedades.

Una breve explicación de la similitud que hay entre EMOF y los perfiles UML, es que en

EMOF el elemento principal para la construcción de metamodelos está dado por la metaclase

Class, mientras que en los perfiles UML el elemento principal para la definición de extensiones es

el estereotipo, que es definido como una especialización de la metaclase Class.

Con estas consideraciones, podríamos resumir que el primer paso del proceso para construir el

perfil UML será la definición del metamodelo del LMED utilizando EMOF.

Una vez definido el metamodelo del LMED, será necesario identificar las equivalencias entre

este metamodelo y el metamodelo de UML, encontrando los siguientes desafíos:

Segundo desafío: Resolver diferencias estructurales entre ambos metamodelos que pueden ir en

contra de la correcta identificación de equivalencias.

Tercer desafío: Definir equivalencias que permitan la correcta identificación de las extensiones

necesarias, sin tener que incorporar detalles relacionados con la definición de perfiles UML.

En relación al segundo desafío, los trabajos presentados en [16] y en [18] mencionan que las

diferencias estructurales entre los metamodelos impiden una correcta integración de la semántica

del LMED en UML, provocando pérdida de expresividad semántica en el perfil UML resultante

(en relación al LMED original). La propuesta presentada en [7] permite resolver estas diferencias

estructurales mediante la redefinición del metamodelo del LMED, obteniendo un nuevo

metamodelo equivalente sin conflictos estructurales con el metamodelo de UML.

De esta manera, el segundo paso del proceso será redefinir el metamodelo del LMED para

eliminar las diferencias estructurales entre los metamodelos, permitiendo una correcta

identificación de equivalencias utilizando la propuesta definida en [7].

Luego, el tercer paso será definir un mapeo que indique las equivalencias entre el metamodelo

del LMED o el metamodelo resultante de la redefinición (según corresponda) y el metamodelo de

UML. Para realizar este mapeo se pueden utilizar las soluciones propuestas en [7] y [18]. Ambas

propuestas resuelven el tercer desafío, ya que la definición de las equivalencias se realiza a nivel

de metamodelos sin necesidad de tener conocimientos de cómo definir perfiles UML.

De acuerdo a la propuesta definida en [7], un mapeo correcto debe considerar lo siguiente:

• Los elementos del metamodelo del LMED que participan en el mapeo son: clases, asociaciones, atributos, enumeraciones y tipos de datos. No es necesario que todos los elementos del

metamodelo del LMED estén mapeados, ya que pueden existir elementos sin equivalencias con

el metamodelo de UML.

• Todas las clases del metamodelo del LMED deben ser mapeadas a clases del metamodelo de UML. Esto es debido a la restricción de los perfiles UML, ya que estos pueden ser aplicados

correctamente solo cuando el LMED es un subconjunto de los constructores de UML.

Una vez identificadas las equivalencias (mapeo) entre los metamodelos, será necesario

determinar las extensiones que deben ser realizadas en el metamodelo de UML para integrar la


ISSN 1988–3455 SISTEDES, 2008 27

semántica del LMED. Una vez completado los primeros pasos del proceso (Pasos 1, 2 y 3), se

tendrá: (1) un metamodelo MOF que permite una correcta integración con el metamodelo de UML

y (2) el mapeo de equivalencias entre ambos metamodelos. Por lo tanto el siguiente desafío es:

Cuarto desafío: Identificar automáticamente las extensiones que deben ser definidas sobre el

metamodelo de UML.

La identificación automática de las extensiones evitará que existan inconsistencias semánticas

entre el perfil UML resultante y el LMED original, ya que en un LMED de gran tamaño la

identificación manual de extensiones puede provocar que algunas de las extensiones no sean

correctamente identificadas o simplemente no se lleguen a identificar.

Para identificar las extensiones necesarias se propone el siguiente mecanismo: utilizar el mapeo

de equivalencias para identificar diferencias entre elementos equivalentes e identificar los

elementos del metamodelo del LMED que no son equivalentes con el metamodelo de UML. De

esta manera, las diferencias encontradas entre los elementos equivalentes y los elementos no

equivalentes serán las extensiones que deberán ser incorporadas en el metamodelo de UML. Para

entender mejor esta idea, analicemos el ejemplo presentado en la Figura 1.

UMLClase1

atr1 [0..1]

atr2 [2..*]

Clase1

atr1

atr2 [2..2]

atr3

<<metaclass>>

UMLClase1

Diferencia de la cardinalidad mínima:

Clase1.atr1 = 1UMLClase1.atr1 = 0

Diferencia de la cardinalidad máxima:

Clase1.atr2 = 2UMLClase1.atr2 = *

self.atr2->size < 3

self.atr1->size > 0

Superestructura UMLMetamodelo LMED

Perfil UML

atr3

<<stereotype>>

Clase1

Figura 1. Ejemplo genérico de identificación automática de extensiones

En la Figura 1 se presenta un ejemplo genérico de una clase llamada Clase1 definida en el

metamodelo del LMED que es equivalente a la clase UMLClase1 del metamodelo de UML

(Superestructura UML). Los atributos atr1 y atr2 son equivalentes en ambas clases, sin embargo,

sus cardinalidades son diferentes. Por este motivo, se deben definir dos extensiones sobre la clase

UMLClase1. Mediante estas extensiones, la semántica de los atributos de la clase UMLClase1 se

ajusta a la semántica de los atributos equivalentes del LMED. Además, es posible observar que el

atributo atr3 de la clase Clase1 no tiene equivalencia en el metamodelo de UML. Por esta razón,

este atributo es agregado como un nuevo atributo en el metamodelo de UML mediante un valor

etiquetado definido en el estereotipo Clase1.

La forma en que se define el perfil UML correcto a partir de las extensiones identificadas no es

relevante en este punto, sin embargo, en el ejemplo se ha incorporado la definición del perfil UML

equivalente para entender mejor cómo la identificación de diferencias permite determinar las

extensiones que deben realizarse sobre el metamodelo de UML. De esta manera, el cuarto paso del

proceso para la elaboración del perfil UML corresponde a la identificación automática de las

extensiones que deben ser definidas en el metamodelo de UML. Para realizar esta identificación se

debe considerar:

• La identificación de nuevos elementos: Estos son los elementos del metamodelo del LMED que no son equivalentes con el metamodelo de UML.

• La identificación de las diferencias en el tipo de dato o cardinalidad de las propiedades (atributos y asociaciones) equivalentes.

Una vez identificadas las extensiones que deben ser definidas en el metamodelo de UML, sólo

queda la definición del perfil UML que implementa dichas extensiones. Si bien, para realizar este

paso sí es necesario tener conocimientos de perfiles UML, la ventaja de separarlo en un paso

independiente es que el diseñador del LMED no necesita tener conocimientos de perfiles UML,


ISSN 1988–3455 SISTEDES, 2008 28

permitiendo la construcción del perfil UML final por parte de un especialista en perfiles UML o

incluso de forma automática. Esto último corresponde al quinto desafío identificado:

Quinto desafío: Generar automáticamente el perfil UML a partir del metamodelo del LMED, el

conjunto de equivalencias definidas, y las extensiones identificadas.

Mediante la automatización de este paso, se reduce considerablemente el esfuerzo de mantener

un perfil UML asociado a propuestas DSDM, que están constantemente desarrollando mejoras que

modifican la semántica de sus constructores conceptuales y que cada vez requerirán modificar el

perfil UML para adaptarse a estos cambios. En [7] se indica claramente el impacto de estos

cambios y cómo un mecanismo automático de generación reduce considerablemente el esfuerzo de

mantener la consistencia semántica entre los perfiles UML y las propuestas DSDM.

Para realizar la generación automática, se pueden definir un conjunto de reglas de

transformación, las que pueden ser implementadas mediante lenguajes de transformación de

modelos como ATL [4], tal como se propone en [18]. Para la correcta definición e

implementación de estas reglas se propone separarlas de acuerdo a los constructores conceptuales

del metamodelo el LMED (clases, atributos, asociaciones, etc.). Esta separación facilitará la

correcta identificación de las reglas necesarias para una generación correcta y completa del perfil

UML, además de facilitar la detección de errores o la incorporación de mejoras en las reglas de

transformación implementadas. Algunos aspectos que deben ser considerados en la correcta

definición de las reglas de transformación son:

• Los tipos de datos que no son completamente equivalentes con los tipos de datos primitivos definidos en UML, es decir, que no tienen las mismas propiedades o presentan diferencias entre

propiedades equivalentes, deben ser tratados igual que los tipos de datos no equivalentes. Esta

consideración se debe a que los tipos de datos en UML son especializaciones de la metaclase

Classifier y no de la metaclase Class, y los estereotipos sólo pueden extender elementos de tipo

Class, por lo que no se pueden definir estereotipos sobre los tipos de datos de UML para ajustar

su semántica a los tipos de datos equivalentes del metamodelo del LMED.

• Utilizar las características de los perfiles UML de acuerdo a la especificación actual de UML [12]. Por ejemplo, la especificación actual de UML permite establecer asociaciones a nivel de

estereotipos, por lo que las asociaciones no equivalentes pueden ser incorporadas directamente

en el perfil UML generado. Otras características interesantes pueden ser revisadas en [16].

• El nombre del estereotipo y el nombre de la clase extendida no deben ser iguales. En caso contrario, habría problemas para identificar correctamente si una clase se encuentra extendida

por un estereotipo, dado que los estereotipos son un tipo particular de clases (especialización de

Class) y se identifican por su nombre. Por ejemplo, no se podría determinar si sobre la clase

Property se ha aplicado el estereotipo Property.

• Determinar cómo tratar aquellas propiedades equivalentes del metamodelo del LMED que tengan diferencias de cardinalidad o de tipo que no puedan ser resueltas mediante restricciones.

Para esta situación, se propone como solución la definición de un nuevo valor etiquetado que

reemplace la propiedad de UML. En este caso, las herramientas de desarrollo (por ejemplo un

compilador de modelos) deberán considerar esta propiedad y no la propiedad original de UML.

Con este último paso ya es posible contar con un proceso que genere correctamente un perfil

UML asociado para una propuesta DSDM. Sin embargo, hemos querido incorporar un desafío

adicional:

Sexto desafío: Permitir el intercambio de modelos entre herramientas basadas en un LMED

propietario y herramientas UML basadas en el perfil UML generado.

La solución a este último desafío está en las equivalencias definidas entre el metamodelo del

LMED y el metamodelo de UML, y las reglas de transformación para obtener el perfil UML

completo. Con esta información es posible conocer exactamente las equivalencias (mapeo) que

existen entre el perfil UML y el metamodelo del LMED. Esta información puede ser utilizada en

una herramienta como la presentada en [1], que mediante la información de mapeo entre el perfil

UML y el metamodelo del LMED permite transformar modelos construidos con el perfil UML en

modelos basados en el LMED, y viceversa. Si las reglas de transformación para la generación del


ISSN 1988–3455 SISTEDES, 2008 29

perfil UML son automatizadas, esta información de mapeo también se puede generar

automáticamente durante la generación del perfil UML. Finalmente, el proceso completo queda

representado en la Figura 2.

Paso 2:

Redefinición del metamodelo

Metamodelo

Mapeo entre el perfil UML y el metamodelo LMED

Perfil UML

Modelo UML

Paso 1:

Definir metamodelo EMOF del LMED

Opcional, este paso se

realiza solo si la

redefinición es requerida

Metamodelo LMED

Metamodelo LMED

Paso 3:

Mapeo de las

equivalencias entre metamodelos

Paso 4:

Identificación de extensiones

Metamodelo

+ Mapeo

Paso 5:

Generación del perfil UML

Metamodelo

+

Mapeo

+

Extensiones

Modelo LMEDHerramientas de

modelado propietarias

Herramienta de

intercambio

Herramienta de

modelado UML

Figura 2. Proceso genérico para la construcción de un perfil UML asociado a una propuesta DSDM

En la Figura 2, se puede observar que el segundo paso es opcional dependiendo si el

metamodelo del LMED requiere ser redefinido para permitir una correcta integración con el

metamodelo de UML. Además, los pasos 4 y 5 están destacados para indicar que estos pueden ser

automatizados. Esta figura también muestra el proceso utilizado en la integración de herramientas

basadas en LMED, mediante una herramienta de intercambio que realiza la conversión entre

modelos. Esta herramienta de intercambio recibe como entrada la información de mapeo obtenida

durante el paso 5, y en caso que sea necesario realizar el paso 2, también se debe incorporar el

mapeo entre el metamodelo redefinido y el metamodelo original del LMED.

4 Conclusiones

En este trabajo se propone un proceso genérico para construir perfiles UML destinados a apoyar

las necesidades de modelado de propuestas DSDM. Contar con este proceso permitirá que los

perfiles UML resultantes sean correctos, cumplan con los estándares dictados por OMG y que

además puedan ser validados, ya sea de forma automática o por terceros.

En particular, los pasos en los que se ha separado el proceso propuesto permitirán realizar

validaciones a distintos niveles de la construcción del perfil UML:

• Validación de la correcta semántica del LMED, mediante el metamodelo que describe sus constructores conceptuales (metamodelo del LMED).

• Validación de la definición del perfil UML, mediante la validación de las reglas para la identificación de extensiones y las reglas de transformación para obtener el perfil UML final.

La estructura definida para el proceso permite que éste pueda ser utilizado como referencia para

otros mecanismos de extensión o de intercambio entre metamodelos. Por ejemplo, el metamodelo

de UML puede ser reemplazado por el metamodelo de otro LMED, o se pueden cambiar las reglas

de transformación para definir las extensiones identificadas automáticamente en otro mecanismo

de extensión distinto a un perfil UML. En el trabajo de Bruck et al. [2] se puede encontrar más

información acerca de otras técnicas para extender UML.

El proceso propuesto permite que el perfil UML resultante tenga la misma expresividad

semántica que el LMED original, estableciendo además cómo se puede automatizar la generación

de los perfiles UML para evitar la introducción de errores propios de una definición manual, y

facilitar la adaptación del perfil UML a los cambios de las propuestas DSDM.

En este trabajo, además de indicar cómo generar un perfil UML correcto se muestra cómo se

puede utilizar la información obtenida durante la aplicación del proceso propuesto para permitir la

integración con tecnologías basadas en el metamodelo del LMED; como por ejemplo,


ISSN 1988–3455 SISTEDES, 2008 30

compiladores de modelo o herramientas de modelado propietarias (que incorporen características

para mejorar las posibilidades de modelado dentro del dominio de aplicación). De esta manera, es

posible obtener un perfil UML adecuado y al mismo tiempo aprovechar los beneficios que proveen

las herramientas basadas en LMEDs sin incurrir en esfuerzos adicionales.

El trabajo futuro contempla la implementación de esta propuesta en una herramienta que

automatice el proceso de generación de perfiles UML. La construcción de esta herramienta está

basada en la propuesta DSDM OO-Method [14], que cuenta con un LMED propietario y con una

implementación industrial [15] formada por una suite de herramientas de modelado y un

compilador de modelos para la generación automática de aplicaciones.

Agradecimientos

Este trabajo ha sido desarrollado con el soporte del Ministerio de Educación y Ciencia bajo el

proyecto SESAMO TIN2007-62894 y cofinanciado por FEDER.

Referencias

1. Abouzahra, A., Bézivin, J., Fabro, M.D.D., Jouault, F.: A Practical Approach to Bridging Domain Specific

Languages with UML profiles. In: Proceedings of Best Practices for Model Driven Software Development

(OOPSLA’05) (2005)

2. Bruck, J., Hussey, K.: Customizing UML: Which Technique is Right for You? IBM (2007)

3. CARE-Technologies: Web site, http://www.care-t.com/

4. Eclipse: ATL Project, http://www.eclipse.org/m2m/atl/

5. France, R.B., Ghosh, S., Dinh-Trong, T., Solberg, A.: Model-driven development using uml 2.0: Promises

and pitfalls. In: IEEE Computer, vol. 39 nº 2, 59–66 (2006)

6. Fuentes-Fernández, L., Vallecillo, A.: An Introduction to UML Profiles. In: The European Journal for the

Informatics Professional (UPGRADE), vol. 5 nº 2, 5–13 (2004)

7. Giachetti, G., Valverde, F., Pastor, O.: Improving Automatic UML2 Profile Generation for MDA

Industrial Development. In: Proceedings of 4th International Workshop on Foundations and Practices of

UML (FP-UML) – ER Workshop. LNCS, pp. 113–122. Springer (2008)

8. Harel, D., Rumpe, B.: Meaningful Modeling: What's the Semantics of "Semantics"? In: IEEE Computer,

vol. 37 nº 10, 64-72 (2004)

9. Lagarde, F., Espinoza, H., Terrier, F., Gérard, S.: Improving UML Profile Design Practices by Leveraging

Conceptual Domain Models. In: Proceedings of 22th IEEE/ACM International Conference on Automated

Software Engineering (ASE), pp. 445–448 (2007)

10. OMG: MOF 2.0 Core Specification

11. OMG: Object Management Group Web site, http://www.omg.org/

12. OMG: UML 2.1.2 Infrastructure Specification

13. OMG: UML 2.1.2 Superstructure Specification

14. Pastor, O., Gómez, J., Insfrán, E., Pelechano, V.: The OO-Method Approach for Information Systems

Modelling: From Object-Oriented Conceptual Modeling to Automated Programming. In: Information

Systems. Elsevier Science, vol. 26 nº 7, 507–534 (2001)

15. Pastor, O., Molina, J.C.: Model-Driven Architecture in Practice: A Software Production Environment

Based on Conceptual Modeling. Springer (2007)

16. Selic, B.: A Systematic Approach to Domain-Specific Language Design Using UML. In: Proceedings of

10th IEEE International Symposium on Object and Component-Oriented Real-Time Distributed

Computing (ISORC), pp. 2–9 (2007)

17. Staron, M., Wohlin, C.: An Industrial Case Study on the Choice Between Language Customization

Mechanisms. In: Proceedings of Product-Focused Software Process Improvement (PROFES). LNCS, pp.

177-191. Springer (2006)

18. Wimmer, M., Schauerhuber, A., Strommer, M., Schwinger, W., Kappel, G.: A Semi-automatic Approach

for Bridging DSLs with UML. In: Proceedings of 7th OOPSLA Workshop on Domain-Specific Modeling

(DSM), pp. 97–104 (2007)


ISSN 1988–3455 SISTEDES, 2008 31

Patrones de optimización de rendimiento para

transformaciones de modelos

Jesús Sánchez Cuadrado1, Frédéric Jouault2, Jesús García Molina1, y Jean Bézivin2

1 Universidad de Murcia{jesusc, jmolina}@um.es

2 Université de Nantes{jean.bezivin, frederic.jouault}@univ-nantes.fr

Resumen. Las transformaciones de modelos son un elemento esencial del desarrollode software dirigido por modelos (DSDM). Conseguir un rendimiento adecuado de lasmismas es un requisito fundamental para que la disciplina madure.En este trabajo se presentan cinco patrones de optimización que identi�can posiblescuellos de botella y explican como abordarlos. Asímismo se presenta un frameworkgeneral para la creación de benchmarks para transformaciones, que ha sido usadopara identi�car estos patrones.

Palabras clave: Transformación de modelos, Rendimiento, Benchmarks.

1 Introducción

Las transformaciones de modelos son una pieza clave del desarrollo de software dirigido pormodelos (DSDM) y en los últimos años han aparecido un buen número de lenguajes detransformación. A medida que la disciplina ha madurado, se han escrito transformacionespara resolver problemas cada vez más complejos y continuamente crece el número de desar-rolladores que de�nen transformaciones. Así, el DSDM se aplica actualmente en contextoscomo el desarrollo basado en DSL, la modernización basada en modelos o el megamodel-ing [2]. Además, en algunos de estos contextos el tamaño de los modelos que se manejan esmuy grande, incluso por encima del millón de elementos.

Este contexto requiere que los desarrolladores de transformaciones y de motores paralenguajes de transformación deban considerar cuestiones de rendimiento para conseguirtiempos de ejecución que permitan el uso de los sistemas software que incorporan trans-formaciones de modelos. Para evaluar cuándo el rendimiento es apropiado una estrategia esla de�nición de una serie de benchmarks, como se propone en [8]. Estos benchmarks serviríanpara comparar datos experimentales sobre el tiempo de ejecución de una misma de�niciónde transformación escrita de diferentes formas. Por ejemplo, podrían variar característicascomo la estrategia para encontrar la solución, el lenguaje utilizado o el tamaño del modelo deentrada. La técnica del benchmarking ya ha sido aplicada en otras áreas de la informática,como es el caso de las bases de datos [4] o sistemas expertos.

En el caso de las transformaciones de modelos, la información extraída de la ejecuciónde los benchmarks podría servir para (a) comparar y mejorar diferentes lenguajes de trans-formación y sus implementaciones, y (b) identi�car una serie de patrones y buenas prácticasrelativas a la optimización del código de las de�niciones de transformación.

Este artículo presenta una doble contribución relacionada con los benchmarks de transfor-maciones de modelos: un framework para la especi�cación de benchmarks y varios patronesde optimización de rendimiento. El framework está siendo utilizado actualmente para de�nirun conjunto de benchmarks para la comparación de lenguajes de transformación, y como re-sultado de este trabajo se han identi�cado algunos patrones de optimización. En este trabajo


ISSN 1988–3455 SISTEDES, 2008 32

se describen cinco de los patrones identi�cados. Para cada patrón se dará su motivación, unejemplo concreto en el que aparece, así cómo una discusión sobre las diferentes alternativaspara su implementación. Puesto que estos patrones han sido identi�cados a partir de losdatos experimentales obtenidos a través de una librería de benchmarks, se mostrarán datoscomparativos de cada alternativa de implementación.

El artículo se estructura como sigue: en la siguiente sección se presenta nuestro frameworkpara benchmarks, en la Sección 3 se presentan los patrones identi�cados a partir de los datosexperimentales. En la Seccion 4 se discute sobre el balance entre legibilidad y e�ciencia, y�nalmente en la Sección 5 se dan las conclusiones.

2 Framework para benchmarks

Para facilitar la especi�cación, ejecución y presentación de los resultados de benchmarks detransformaciones de modelos se ha creado un framework cuya arquitectura se muestra en laFigura 1. El framework está destinado a medir el rendimiento de uno o varios lenguajes detransformación con respecto a una o más características.

Los benchmarks se organizan siguiendo una estructura de directorios, donde toda la in-formación relativa a cada benchmark se almacena en un directorio. Se ha de�nido un DSLpara especi�car la información necesaria para ejecutar benchmarks. Estas especi�cacionesson interpretadas para lanzar la ejecución de los benchmarks. Cada uno de ellos es ejecutadon veces, y el valor medio del tiempo de ejecución es calculado. Opcionalmente se puedendescartar los m primeros tiempos para evitar sesgos. El resultado de la ejecución de losbenchmarks es almacenado en un modelo (no se muestra su metamodelo por razones deespacio), que puede ser luego transformado en una representación adecuada para su visual-ización y para la comparación de las medidas.

Nosotros hemos de�nido una transformación que toma un modelo de medidas de rendimientoy crea una tabla comparativa, con cuatro dimensiones: modelo de entrada, transformación,lenguaje e implementación. A partir de esta tabla se genera una página HTML y un �cheroCSV para su exportación en una hoja de cálculo. Las grá�cas comparativas de este artículohan sido calculadas mediante una hoja de cálculo utilizando los resultados en formato CSV.

Fig. 1. Arquitectura del framework para benchmarks.

Como se puede observar en el metamodelo de la Figura 2, una especi�cación del DSL parala ejecución de benchmark consta de dos partes: la de�nición del benchmark y un conjuntode suites de tests del benchmark. La de�nición del benchmark especi�ca un conjunto demetamodelos origen y destino, un conjunto de transformaciones a aplicar y un conjunto demodelos de entrada. Cada de�nición de benchmark debe ir acompañada de una o más suitesformadas por un conjunto de benchmark cases. Cada benchmark case �ja los valores de losparámetros para una ejecución concreta: transformación a ejecutar, modelos de entrada,implementación del lenguaje y opcionalmente tamaño de la memoria montón.


ISSN 1988–3455 SISTEDES, 2008 33

Fig. 2. Metamodelo de la sintaxis abtracta del lenguaje para describir benchmarks.

A continuación se muestra un ejemplo de especi�cación del DSL destinada a ejecutarun benchmark para comparar la e�ciencia de las colecciones. La de�nición del benchmarkincluye dos transformaciones que tienen el mismo metamodelo de entrada y salida, Tree, yun solo modelo de entrada. Se ha de�nido una única suite con dos benchmark case, uno porcada transformación, que se ejecutan para los dos modelos y para la misma máquina virtualde ATL [5], EMFVM. En concreto, la suite compara las colecciones Set y Sequence.

benchmark_definition 'collections' do

metamodel 'Tree' => 'Tree.ecore'

in_model 'IN : Tree' => :parameter

out_model 'OUT : Tree' => 'target.xmi'

input_model_size 'IN' do

model 16000 => 'model_16000.xmi'

model 32000 => 'model_32000.xmi'

end

transformation do

version 'seq_include_atl', :language => :atl, :specification => 'sequence_include.atl'

version 'set_include_atl', :language => :atl, :specification => 'set_include.atl'

end

test_suite 'default' do

execute 'seq_include_atl' do

vm :emfvm

input_model 'IN', :all

end

execute 'set_include_atl' do

vm :emfvm

input_model 'IN', :all

end

end

end

El DSL ha sido diseñado pensando en la �exibilidad. La separación entre de�nición delbenchmark y las suites con respecto a los benchmarks case evita de una forma muy sencillaescribir una y otra vez la información sobre las transformaciones a ejecutar. Como se muestraen el ejemplo, es posible expresar diferentes combinaciones de parámetros de la ejecución deun benchmark, tal como los modelo de entrada para los que se ejecutará la transformación


ISSN 1988–3455 SISTEDES, 2008 34

(por ejemplo, para comparar el rendimiento según el tamaño del modelo o su estructura) oqué implementación del lenguaje se usará (para comparar implementaciones).

Hasta el momento se han de�nido benchmarks que se clasi�can en dos categorías: mi-crobenchmarks que miden aspectos concretos de un lenguaje o de las transformaciones yexamples que corresponden a optimizaciones en ejemplos reales de transformaciones. Elbenchmark del fragmento anterior de especi�cación del DSL sería un ejemplo de microbench-mark. Una transformación UML a Java donde se consideran casos complejos tales como laherencia múltiple es un example.

3 Patrones de rendimiento

En esta sección se describen una serie de patrones para mejorar el rendimiento de las trans-formaciones. Estos patrones están justi�cados por los datos experimentales obtenidos de laejecución de los correspondientes benchmarks3 con el framework de la sección anterior. Lamayor parte de estos patrones están relacionados con consultas y navegación sobre modelos,ya que es donde suelen aparecer los cuellos de botella.

A partir de un benchmark example (esto es, un caso real) se identi�can uno o más cuellosde botella para la transformación y se solucionan. Después se crea un microbenchmark porcada cuello de botella, a partir del cual probablemente se identi�cará un patrón, de maneraque se aisla el problema en particular. Los datos experimentales que se mostrarán para cadapatrón corresponden a microbenchmarks.

Los patrones siguientes se ilustrarán para el lenguaje ATL4, pero las conclusiones obtenidasson generales para cualquier lenguaje basado en reglas, como QVT[6] o RubyTL[7], puestoque en todos ellos la navegación se hace utilizando un lenguaje de consultas basado en iter-adores y notación punto. Por tanto, estos patrones de optimización son patrones de código[3] en cuanto a que son recomendaciones sobre uso de los lenguajes de transformación, eneste caso ilustradas con ATL.

3.1 Evaluación de expresiones booleanas en corto-circuito

Una operación típica de las transformaciones de modelos es el recorrido del modelo origenmediante una consulta con OCL (o un lenguaje similar). Normalmente tales consultas impli-can expresiones booleanas. Cuando las consultas son complejas y los modelos de entrada songrandes, el orden en que las condiciones son evaluadas puede in�uir considerablemente enel rendimiento, ya que si el el lenguaje de transformación soporta evaluación de expresionesbooleanas en corto-circuito [1] es posible escribir la expresión de modo que sólo se evalúenlas condiciones necesarias para determinar el valor de la expresión.

Datos experimentales. La Figura 3(a) muestra el resultado de ejecutar una transfor-mación con una única regla que se aplica según una expresión booleana �or�, de la formacondicionSimple or condicionCompleja. Se comprueba el efecto de utilizar evaluaciónen corto-circuito o no.

La condición simple es una operación cuyo tiempo es constante y no depende del númerode elementos de entrada, mientras que la consulta compleja depende del tamaño del modelode entrada.

3 Se ha utilizado una máquina con las siguientes características: Intel Pentium Centrino 1.5Ghz,1GB de memory RAM. Java version 1.6.0 sobre Linux kernel 2.6.15

4 Se ha utilizado la versión 2006 y la máquina virtual EMFVM sobre Eclipse 3.4


ISSN 1988–3455 SISTEDES, 2008 35

(a) (b)

Fig. 3. (a) Expresiones booleanas con y sin evaluación en corto-circuito. (b) Diferentes formas theobtener una referencia inversa.

Recomendaciones. Como es bien conocido, hay dos estrategias para mejorar el rendimientode una consulta con expresiones de este tipo, dependiendo de si la expresión booleana es�and� o �or�.

� And, La condición más restrictiva (y rápida de evaluar) debe colocarse la primera, esdecir, aquella condición con más probabilidad de devolver un valor �falso� rápidamente.Así, las condiciones que tardan más en evaluarse se ejecutarán en menos ocasiones.

� Or. La condición menos restrictiva (y rápida de evaluar) debe colocarse la primera, esdecir, aquella condición con más probabilidad de devolver un valor �verdad� rápidamente.De esta forma el resto de condiciones más lentas no tienen por qué ser evaluadas cuandoel resultado de la expresión es �verdad�.

Si el lenguaje de transformación no soporta evaluación en cortocircuito, como es el casode OCL estándar (tal y como está implementado en ATL), cualquier expresión puede serreescrita siguiendo las reglas de la tabla siguiente para conseguir el mismo efecto.

Con cortocircuito Sin cortocircuitoAND query1() and query2() if query1() then query2() else false

OR query1() or query2() if query1() then true else query2()

3.2 Navegación por la referencia inversa

Dada una instancia que referencia a otra, cuando se escribe una transformación de modelosa menudo surge la necesidad de disponer de la referencia inversa. Por ejemplo, al manejarárboles puede resultar necesario determinar cuál es el nodo padre de un nodo.

Si en el metamodelo se ha de�nido una referencia inversa a una referencia dada, lanavegación en los dos sentidos se realiza de manera e�ciente. Pero en muchas ocasiones noexiste tal referencia inversa, de manera que la operación de navegación en sentido inversopuede ser costosa ya que implica recorrer todos los posibles elementos destino de la referenciainversa hasta encontrar el indicado.

Un caso particular de este patrón se da cuando la referencia es contenedora (por ejemplo,cuando en un metamodelo Ecore la propiedad container = true). En este caso es posiblepara un lenguaje de transformación explotar la relación única de contención entre un ele-mento y su padre (esto es, todo elemento está contenido en uno o ningún elemento) paraofrecer una operación que obtenga de manera genérica el elemento padre. Por ejemplo, enATL esta operación se llama refImmediateComposite().


ISSN 1988–3455 SISTEDES, 2008 36

Datos experimentales. El microbenchmark para probar este patrón básicamente consisteen una consulta que debe devolver el paquete en el que está contenida una clase (se asumeun metamodelo similar al de UML pero sin la referencia para navegar hacia el paquetecontenedor).

Se de�nen cuatro modos de realizar esta consulta:

� Utilizando un algoritmo iterativo como el siguiente.

helper context ClassD!Class def : parent : ClassD!Package =

ClassD!Package.allInstancesFrom('IN')->any(p |

p.classifiers->includes(self) );

� Utilizando la operación refImmediateComposite().� Precalculando al inicio de la transformación, de una sola vez, una tabla hash (asociativa)

que contiene los pares elemento - contenedor..� Igual que el anterior pero utilizando una operación �mutable� para añadir elementos a

la tabla hash.

Los resultados obtenidos se muestran en la Figura 3(b), donde se han considerado tresmodelos de clases con diferente número de paquetes y clases (paquetes × clases). Eviden-temente la opción con refImmediateComposite es la más e�ciente. Sin embargo, utilizaruna tabla hash es una alternativa casi equivalente, pero sólo si disponemos de operacionesmutables (o si el motor de transformación es capaz de evitar la copia). El algoritmo itera-tivo demuestra ser ine�ciente. También es interesante destacar que la forma del modelo deentrada puede tener impacto: el algoritmo iterativo mostrado antes depende fuertemente decómo esté organizado el modelo, mientras que esta dependencia es mucho menor en el casode precalcular una tabla (o utilizar refImmediateComposite).

Recomendaciones. Si se tiene que navegar a través de una referencia que es inversa aotra referencia contenedora, y no se dispone de ella, se debería comprobar que el lenguaje detransformación utilizado ofrece una operación genérica tal como refImmediateComposite. Sino existe la referencia inversa y además no es contenedora, se debería precalcular utilizandouna tabla hash que permita operaciones mutables.

3.3 Uso de colecciones

Los lenguajes de transformación suelen ofrecer distintos tipos de colecciones, y cada tipoofrece mejor rendimiento para cierto tipo de operaciones. Elegir el tipo adecuado para cadacircunstancia puede mejorar el rendimiento de una transformación considerablemente.

Por razones de espacio en esta sección solo se compararán la implementación de lasoperaciones OCL including (que añade un elemento a una colección) e includes (quecomprueba si existe un elemento), para los tipos de colecciones Sequence, Set y OrderedSet,pero los resultados obtenidos son aplicables a otras operaciones, por ejemplo union. De igualforma, se han creado benchmarks similares para comparar operaciones, como any o exists.

Datos experimentales. El microbenchmark para la operación including consiste en iteraruna lista de n elementos y en cada paso añadir el elemento actual a otra lista. El tiempo deejecución para diferentes tamaños de entrada y para los tres tipos de colecciones se muestraen la Figura 4(a).

El microbenchmark para la operación includes consiste en localizar un elemento que estáposicionado en la mitad de una lista de n elementos. La búsqueda se repite 2000 veces. Eltiempo de ejecución para diferentes tamaños de entrada y para los tres tipos de coleccionesse muestra en la Figura 4(b).


ISSN 1988–3455 SISTEDES, 2008 37

(a) (b)

Fig. 4. (a) Comparativa de la operación including. (b) Comparativa de la operación includes

Como se puede observar, including es mucho más e�ciente para secuencias que para con-juntos. Esto es razonable ya que las inserciones se hacen por la cola y no hay que comprobarduplicados. El coste de includes es mayor para secuencias. Sin embargo, debe tenerse encuenta que el coste convertir una colección en un conjunto (con asSet) es grande y puedeno merecer la pena si las operaciones de consulta no son frecuentes.

Recomendaciones. A la hora de utilizar colecciones se debería elegir el tipo concretosegún las operaciones más frecuentes que se vayan a utilizar. En particular, a no ser que seanecesario asegurar que no haya duplicados en una colección (o que la propia lógica de latransformación no pueda asegurarlo), se debería utilizar el tipo secuencia, en caso contrarioutilizar un conjunto.

En el caso de la consulta includes, se debería utilizar un conjunto ya que el contrato deesta operación en conjuntos asegura más e�ciencia en caso de que la implementación cambie.

3.4 Uso de iteradores

La forma en se especi�can las consultas, normalmente en OCL, tiene un impacto en eltiempo de ejecución de una transformación. Al ser OCL un lenguaje que promueve un estilofuncional, cuando se escriben consultas es frecuente no tener en cuenta la e�ciencia de lasexpresiones, sino que se escriben soluciones legibles, fáciles o inmediatas.

Por ejemplo, es frecuente encontrar código OCL en el que para obtener el primer elementoque cumpla una condición se utiliza la consulta (a). Sin embargo, la consulta (b) es muchomás e�ciente puesto que la iteración termina tan pronto como se cumple la condición.

(a) lista->select(e | condicion)->first()

(b) lista->any(e | condicion)

Datos experimentales. En este caso se ha de�nido un microbenchmark que maneja unalista en la que la condición de búsqueda es satisfecha por todos los elementos que se encuen-tran a partir de la mitad de la lista. Eso signi�ca que la opción (a) obtendrá una lista conn/2 elementos. La Figura 5(a) muestra el tiempo de ejecución para este caso y para la opción(b) que utiliza any para evitar iterar más de lo necesario. Sin embargo, la ejecución de losbenchmarks mostró que para ATL el tiempo de ejecución era similar en ambos casos (en la�gura se solapan los tiempos). La razón es que la implementación actual de any no terminala ejecución tan pronto se encuentra un elemento, sino que es equivalent a �select()->�rst�.


ISSN 1988–3455 SISTEDES, 2008 38

Por tanto, se creo una versión optimizada de any que sí termina la iteración tan prontocomo es posible, es decir, cuando encuentra el elemento que satisface la condición. Comomuestra la grá�ca esta nueva versión tiene un rendimiento superior.

(a) (b)

Fig. 5. (a) Buscar el primer elemento que satisfaga una condición. (b) Resultado de factorizar códigocomún de búsqueda.

Recomendaciones. Se debería evitar el uso de select cuando no sea necesario recorrer todauna colección. En cambio se debería utilizar any, exists, includes, etc. para obtener el valordeseado sin iterar sobre toda la colección.

En ocasiones es preferible sacri�car la legibilidad de una consulta en aras de la e�cienciautilizando la operación iterate para disponer de más �exibilidad. Un ejemplo de esto esel siguiente (no se muestran datos experimentales por razones de espacio). El código (a)cuenta el número de elementos que cumplen una condición utilizando una lista intermediapara almacenar tales elementos. El código (b) hace lo mismo pero evita crear una nuevalista.

(a) thisModule.allNodes->select(e | condicion)->size();

(b) thisModule.allNodes->iterate(e; acc : Integer = 0|

if condicion then acc + 1 else acc endif);

Es razonable que la opción (b) sea más e�ciente a medida que el número de elementos acontar crezca, ya que simplemente incrementa un entero en cada iteración, en vez de creary enlazar una celda para la lista intermedia.

3.5 Identi�car expresiones constantes

Un aspecto intrínseco a las transformaciones de modelos, utilizando lenguajes basados enreglas, es que las reglas se ejecutan al menos una vez por cada patrón origen encontrado(esto es, por cada elemento del modelo de entrada que es una instancia de la metaclaseorigen). Esto signi�ca que las expresiones que aparezcan dentro de una regla se puedenejecutar más de una vez. Cuando estas expresiones dependen completamente del elementoorigen de la regla, entonces es inevitable ejecutarlas siempre. En cambio, aquellas partes dela expresión que son independientes de variables ligadas a la regla pueden ser factorizadas enuna �constante� para ser ejecutadas sólo una vez. Actualmente los motores de transformaciónno soportan este tipo de optimización, por lo que hay que realizarla a mano.

Como ejemplo, considérese la siguiente regla de transformación, donde la condición parasu aplicación es que el clasi�cador �sea apuntado� por otro elemento que determina si es


ISSN 1988–3455 SISTEDES, 2008 39

dibujable o no (Drawable). Puesto que el �ltro se comprueba para cada clasi�cador, todoslos elementos de tipo Drawable son recorridos en cada intento de aplicación de la regla.

rule Classifier2Node {

from source : ClassD!Classifier (

DrawModel!Drawable.allInstances()->exists(e | e.element = source)

)

to Graphic!GraphNode ...

}

Una opción más e�ciente es calcular en una constante todos los elementos que son dibu-jables, de manera que la transformación queda de la siguiente forma.

helper def : drawableElements : Set(ClassD!Classifier) =

ClassD!Drawable.allInstances()->collect(e | e.element);

rule Classifier2Node {

from source : ClassD!Classifier (

thisModule.drawableElements->includes(source)

) ...

}

Datos experimentales. La regla anterior se ha ejecutado para varios modelos de entrada(se asume el mismo número de elementos Classifier y Drawable). En la Figura 5(b) semuestran los resultados para los siguientes casos: (1) sin factorizar el código en una constantey utilizando la versión original de exists, (2) igual que el anterior pero utilizando unaversión optimizada de exists que termina la iteración tan pronto encuentra el elemento, y(3) utilizando la estrategia de precalcular en una constante.

Puede observarse que la estrategia (3) tiene un coste casi constante (complejidad algo-ritmica O(n + m)), mientras que (1) tiene un coste de O(n · m), donde n es el número deelementos de tipo Classifier y m es el número de elementos de tipo Drawable.

Recomendaciones. Tanto en el �ltro y en el cuerpo de las reglas como en los helpers,es posible identi�car expresiones que no dependen de variables de la regla ya que suelenutilizar una operación como allInstances() (o similarmente obtienen todos los elementosa partir de un elemento raíz). En tal caso es posible utilizar una constante para precalcularinformación y almacenarla en un conjunto o en una tabla.

Por otra parte, cabe la pena destacar que el uso de let, u otra instrucción similar, paracrear variables locales es otra práctica recomendable para factorizar expresiones a nivel local.

4 Legibilidad vs. e�ciencia

En general, cuando el código es escrito para mejorar el rendimiento su legibilidad tiende aempeorar. El uso de los patrones anteriores no es una excepción, y en muchos casos provocaque el código no sea claro. Por ejemplo, el siguiente método recursivo que comprueba si unaclase es superclase de otra es legible, pero resulta ine�ciente si el lenguaje de transformaciónusado no maneja bien la recursividad.

helper context ClassM!Class def : isSuperClass(c : ClassM!Class) : Boolean =

if self.superclasses->includes(c) then

true

else

self.superclasses->exists(p | p.isSuperClass(c))

endif;


ISSN 1988–3455 SISTEDES, 2008 40

Escribir una versión e�ciente implica utilizar un mapa para precalcular todas las super-clases con un algoritmo complejo.

Al igual que en el caso de un programa, una transformación debe escribirse procurandoque resulte lo más legible posible para facilitar el mantenimiento, de modo que un balanceadecuado entre legibilidad y rendimiento es fundamental. El reto es identi�car los cuellos debotella que afectan a la e�ciencia. El uso de �pro�lers� permite conocer con exactitud cuálesson las operaciones más costosas. Por otra parte, un framework tal como el que se proponeen la Seccion 2 puede ser útil para comparar diferentes versiones de la misma transformacióny elegir la más adecuada.


En este trabajo se ha presentado un framework para la ejecución de benchmarks y el estudiodel rendimiento de las transformaciones de modelos. A partir de los datos obtenidos con eluso del framework se han identi�cado una serie de patrones de optimización relacionadoscon transformaciones de modelos. En este trabajo se han presentado cinco de ellos.

La ejecución de los benchmarks además ha servido para mostrar algunas de�ciencias en laimplementación del lenguaje de transformación ATL. Así, este framework también resultaútil para probar que las implementaciones de los lenguajes son efectivamente e�cientes ypara su posible comparación.

Como trabajo futuro se pretende crear un plugin para Eclipse que permita, a través depuntos de extensión, añadir nuevos lenguajes de transformación sin necesidad de modi�carel framework. Por último, se seguirán realizando más pruebas de rendimiento de cara aidenti�car una conjunto completo de patrones de rendimiento para transformaciones.

Agradecimientos

Este trabajo ha sido parcialmente �nanciado por los proyectos TIC-INF 06/01-0001 de laConsejería de Educación y Cultura (CARM) y 05645/PI/07 de la Fundación Séneca.

Referencias

1. A. V. Aho and J. D. Ullman. Principles of Compiler Design (Addison-Wesley series in computerscience and information processing). Addison-Wesley, 1977.

2. M. Barbero, F. Jouault, and J. Bézivin. Model driven management of complex systems: Imple-menting the macroscope's vision. In ECBS, pages 277�286. IEEE Computer Society, 2008.

3. K. Beck. Implementation Patterns. Addison-Wesley Professional, 2006.4. M. J. Carey, D. J. DeWitt, and J. F. Naughton. The 007 benchmark. In SIGMOD '93: Proceedings

of the 1993 ACM SIGMOD international conference on Management of data, pages 12�21, NewYork, NY, USA, 1993. ACM.

5. F. Jouault and I. Kurtev. Transforming Models with ATL. In MoDELS 2005: Proceedings ofthe Model Transformations in Practice Workshop, Oct 2005.

6. OMG. MOF 2.0 Query/Views/Transformations. Technical Report ptc/05-11-01, Nov 2005.Available at http://www.omg.org/docs/ptc/05-11-01.pdf.

7. J. Sánchez, J. García, and M. Menarguez. RubyTL: A Practical, Extensible TransformationLanguage. In 2nd European Conference on Model Driven Architecture, volume 4066, pages 158�172. Lecture Notes in Computer Science, June 2006.

8. G. Varro, A. Schurr, and D. Varro. Benchmarking for graph transformation. In VLHCC '05:Proceedings of the 2005 IEEE Symposium on Visual Languages and Human-Centric Computing,pages 79�88, Washington, DC, USA, 2005. IEEE Computer Society.


ISSN 1988–3455 SISTEDES, 2008 41

Providing an open Virtual-Machine-based QVTimplementation

Adolfo Sanchez-Barbudo1, E. Victor Sanchez1, Vıctor Roldan1,Antonio Estevez1, y Jose Luis Roda2

1 Open Canarias, S.L., C/. Elıas Ramos Gonzalez, 4 - Oficina 30438001 Santa Cruz de Tenerife, Spain

{adolfosbh,vsanchez,vroldan,aestevez}@opencanarias.com2 Universidad de La Laguna, La Laguna, Spain

[email protected]

Abstract. Now that OMG’s MOF 2.0 QVT specification has finally reached officialstatus it will be interesting to witness how much impulse it will represent to theevolution of the Model-Driven Engineering field. The Eclipse platform is developingits own open QVT solutions, but they are not ready yet for industrial production.This paper discusses an Eclipse-based QVT open implementation that Open Canariashas been developing for several years. The distinctive trait of this implementation isthat at its core lies a Virtual-Machine model transformation technology, driven bya language named Atomic Transformation Code (ATC). We will explain this QVTsolution and the whole process QVT model transformation instances follow until theycan be executed, which will reflect how this virtual-machine approach influences itsoverall architecture.

Keywords: Model Transformations, QVT, Virtual Machine, ATC.

1 Introduction

The Object Management GroupTM(OMGTM) defines itself as “an international, open mem-bership, not-for-profit computer industry standards consortium”. This organization peri-odically releases public open specifications, many of which become standards that containrecognized best practices that help in driving the industry towards achieving milestones andconfronting further challenges. Modeling and Model-Driven Software Development (MDSD)are covered by several OMG specifications gathered together under the Model-Driven Ar-chitecture (MDA) umbrella.

Similarly, Eclipse “is an open source community, whose projects are focused on buildingan open development platform comprised of extensible frameworks, tools and runtimes forbuilding, deploying and managing software across the lifecycle”. Eclipse focuses on providingopen-source implementation solutions related with the most common problems software andsoftware development faces today.

Many OMG specifications and Eclipse implementations overlap in their scope and goals.There are even Eclipse projects created with the sole purpose of providing an implementationfor a particular OMG specification, such as SBVR, UML2, or OCL. Examples of alignmentbetween both organizations are Eclipse’s M2M (Model To Model) and M2T (Model To Text)projects, which include components dedicated to supporting OMG’s related specifications,which are the MOF Query/View/Transformation (QVT) [10] and MOF Models to Text[11]. For instance, of the three languages the QVT specification comprises, a project to givesupport to the procedural Operational Mappings, which is led by Borland, has been underdevelopment as an Eclipse project since at least as early as 2006.


ISSN 1988–3455 SISTEDES, 2008 42

But the QVT specification has not reached official 1.0 status until recently [10]. The wholeprocess has taken about six whole years, and there are still some unpolished details thatneed further revision. Anyways it is now when QVT has to demonstrate its full potential intobecoming a true industrial standard, or else be relegated to becoming a referential notationmuch in the sense as UML has traditionally been used for documentation and the sharingof ideas, as discussed in [15]. The quality of the available QVT implementations will highlydetermine the success of QVT in the upcoming years.

Back in 2005 Open Canarias S.L. started a model transformation project whose primarygoal was to comply with MDA, therefore the QVT specification was targeted. A preliminarywork on this topic was published in [12]. The fundamental trait of this solution is that it isbuilt upon a Virtual-Machine technology, driven by its own byte-code model transformationlanguage named Atomic Transformation Code (ATC).

In this paper we will discuss our QVT implementation project in terms of the differentsteps involved in the process that ultimately leads to execution of the source QVT modeltransformations, applied over a set of models, via this virtual machine. We will cover severalof the difficulties encountered throughout its development. Some alternatives to differentaspects of this work will also be addressed.

The paper is structured as follows. Section 2 makes a brief overview of the QVT specifi-cation, Section 6 details the chosen technology upon which the QVT model transformationengine is based, Section 4 reviews the architecture of the presented QVT implementationsolution in terms of the three stages it comprises. Related work follows in Section 5 andSection 7 finishes with the conclusions.

2 QVT

The OMG’s MOF Query/View/Transformation (QVT) specifies three different, complemen-tary, statically-typed languages to describe model transformations in the scope of the MDAframework. Two of them enjoy a declarative nature, and the third one is imperative. Thespecification is structured around the architecture depicted in Figure 1. It includes a sectionexplaining a mechanism that enables the opportunity of using black-box invocations.

Fig. 1. QVT layered architecture.

QVT Core (QVTc) is a small declarative language based on pattern matching over aset of variables and evaluating conditions over those variables against a set of models. Thelanguage uses a model-based trace mechanism to record what ocurred during a transforma-tion execution. The trace metamodel must be explicitly provided in the definition of modeltransformations, thus it neither depends on the QVTc language nor is implicitly inferredfrom the contents of such transformations.

The Relations (QVTr) language allows us to specify a set of relationships between MOFmodels. It supports complex object pattern maching. Additionally, trace instances are im-


ISSN 1988–3455 SISTEDES, 2008 43

plicitly created and maintained, which saves the user from having to explicitly manage traceinformation. Although QVTr and QVTc are meant to be semantically equivalent, QVTr isdefined at a higher level of abstraction, so it is more user-friendly. The specification definesa relToCore model transformation to translate among both languages’ abstract represen-tations. This layered relationship is reflected in the QVT architecture shown in Figure 1.

The QVT specification supports a third language named Operational Mappings (QVTo).This imperative language is similar to a traditional procedural programming language, but italso carries a complement of constructs designed to handle (create, modify, etc.) MOF modelextents. Like the other two declarative languages, QVTo is heavily based on the declarative(Essential) Object Constraint Language (OCL) [16], which is extended by QVTo’s own side-effect imperative expressions provided by the ImperativeOCL component.

3 Atomic Transformation Code (ATC) Overview

ATC [8] is an imperative, structured, low-level dynamically-typed model transformationlanguage3 whose instances are defined as models. ATC’s instruction set basically comprisesthe semantics of a general-purpose programming language enriched with a complement ofindivisible, combinable primitives (called atoms) carefully designed to provide model trans-formation functionality at a low abstraction level. Among these, we find AtcGetFeature toquery the value of a model element’s feature, or AtcCreateElement to instantiate a desiredtype defined in a metamodel. Many of these instructions are explained in [8].

Implementation of constructs specific to model transformations are based on the APIof the Eclipse’s metamodeling infrastructure, Eclipse Modeling Framework. The languagesupports some rough automated extensibility mechanism. They are not as powerful as puredynamic polymorfism, but this is not an issue, since ATC model transformations will beusually obtained upon compilation/translation from higher-level notations.

As a tiny example consider the following QVTo code snippet:

query inout Property::privatizeAttribute() {visibility := VisibilityKind::private;

}

Fig. 2. QVTo model example and its ATC translatedd version.

3 ATC-related technology, including the QVT execution project explained here is or will eventuallybe made available at: http://www.modelset.es/atc/atcdownload.html


ISSN 1988–3455 SISTEDES, 2008 44

Where the updated visibility is accessed as a property of the implicit self variable, whichcorresponds to the contextual parameter upon which this query is called.

For instance: aProperty.privatizeAttribute().The equivalent model given in terms of the QVTo abstract syntax and an ATC model

obtained via translation are shown in Figure 2. As can be seen, ATC needs two sequentialinstructions for the assignment instead of the single one required by QVTo. Nevertheless,the represented semantics on either side of this figure carry a rather similar amount ofinformation. Other, bigger examples, may better reflect the verbosity of ATC.

4 QVT Implementation Architecture

QVT is a rather complex specification, full of subtle details that make it very difficultto understand and thus implement. We will explain our particular adopted approach thatprovides a functional, executable implementation of the QVT specification.

The process involved has been partitioned into a sequence of stages. First, textual modeltransformations are parsed to obtain their equivalent abstract representation, which canbe seen as a model. Once a QVT model is obtained, it can serve as input in a modeltransformation that converts it into a semantically equivalent version given in terms of thebyte-code ATC language, since ATC instances are models themselves. The final step is toexecute this ATC model transformation upon real models via its virtual-machine engine. Amore thorough explanation of each stage follows.

4.1 QVT Text Files to QVT Models

OMG’s QVT specification defines a textual concrete syntax for each of its languages alongwith their abstract syntax description. The first step towards execution is to link bothrepresentations, therefore obtaining an abstract syntax model representation of the textuallywritten source transformation. This stage consists of parsing the original text in order toproduce a model in a user-friendly development environment.

The two main topics involved in its development are a parser capable of generating aQVT output model from QVT textual input, and an editor to assist in the programming ofQVT model transformations in textual notation (syntax highlighting, context assist, errormarking, . . . ).

These two subtasks have been implemented by Open Canarias for the QVTo language.The GMT-UMLX project provides similar editors for the two other languages, QVTr andQVTc. All the three editors follow a similar alignment with the MDT-OCL project, whichincludes grammar extension of the LALR Parser Generator (LPG) and variable environmentsharing.

Since QVT is defined as an extension of two other OMG specifications, EMOF (EssentialMOF) and Essential OCL, extending the Eclipse Modeling Framework, EMF (as a legitimateEssential MOF implementation) and MDT-OCL was required. Additionally, GMT-UMLXprovides a useful infrastructure to easily integrate the developed parser into a multi-pageeditor which offers several views and notations of the same source transformation integratedin a single window. By attaching our QVTo editor to this infrastructure we enjoyed thereuse of many features which helped the QVTo editor become a more solid and productiveenvironment than it would have been.

The mechanisms that drive parsing QVT input textual files to generate QVT outputmodels are based on the same principles MDT-OCL uses to parse OCL textual expressions,and are summarized here:


ISSN 1988–3455 SISTEDES, 2008 45

– Defining an Ecore-Based Metamodel for the QVT language (which has been contributedto the GMT-UMLX project). This QVT metamodel extends the Ecore and the Ecore-bound MDT-OCL metamodels.

– Defining a CST Metamodel for the QVT language, which extends (and hence, reuses)the MDT-OCL CST metamodel. It comprises the definition of CST nodes for QVT,ImperativeOCL, and some Ecore concepts complementary to those related with OCL.

– Defining grammars which cover the whole QVT languages. This implies extending theMDT-OCL EssentialOCL grammar and involves the specification of production rules forsome QVT-specific concepts, including ImperativeOCL.

– Defining a CST-building infrastructure for creating CST nodes. It uses and extendsMDT-OCL’s own infrastructure.

– Defining the AST-building infrastructure for creating AST nodes, which also uses andextends MDT-OCL’s.

– Defining the validation actions to validate the generated models, which actually extendthe MDT-OCL’s own validation actions.

– Defining a Standard Library for QVTo (the only QVT language that provides its own)as an extension of the MDT-OCL Standard Library. This library, as stated in the spec-ification, and as is usual for any programming language’s standard library, has beendefined in terms of its language. Consequently, in this case it is represented as a modelthat conforms to the QVTo metamodel.

This stage poses certain technological challenges. For instance, the MDT-OCL project’sdesign did not originally account for language extensions. QVT is not the only languagethat builds upon OCL. The same does, for instance, the M2T language. Enhancements tothe MDT-OCL project’s language extensibility are being successfully contributed.

A previously attempted alternative to supporting QVTo via ATC consisted of elicitingATC models directly from QVTo text parsing in a monolithic Java approach. A workingprototype was produced very quickly, but was soon discarded in favour of the more flexible,model-aligned, approach explained in this work. The main problems with such an alternativewere that it was difficult to keep QVTo textual parsing and ATC generation mixed togetherin a single module. The task of increasing language support incrementally was not alwaysfound as smooth as desirable.

Instead, separation of concerns in this case not only keeps efforts in each stage focused,independently of each other, but also opens the opportunity of independent reuse per stage.That is, QVT editors for the three languages can be integrated in other projects or tools.Likewise, the QVT to ATC translation infrastructure can be used by tools that produceAST models from QVT textual parsing in order for them to achieve true QVT modeltransformation execution, or to enjoy an additional alternative execution path.

4.2 QVT Models to ATC Models

Once a QVT model has been output from the compilation of its respective QVT input filevia the editor-parser process, the next step would be to make it executable in our virtualengine. To that end, such a QVT model must be translated into an equivalent ATC model,as illustrated in Figure 3 for QVTo.

The first alternative to this approach that comes to mind would be to develop a trans-formation engine capable of interpreting and executing QVT models. However, the use of anintermediate layer, a Virtual-Machine model transformation engine, implies beneficial gainsin terms of flexibility, diversity of languages supported and the exploiting of optimizationopportunities.

Reflective Model-Driven Engineering [4] is a powerful instrument in the evolution of theMDE field. Once model transformation instances take the shape of models, they can be


ISSN 1988–3455 SISTEDES, 2008 46

Fig. 3. QVTo model translation schema. VTE stands for Virtual Transformation Engine, and isthe engine that executes ATC models. The same process is applied for the QVTc language.

treated as any other ordinary model, and thus be subject to a process similar to the MDA’sPIM-PSM evolution approach. This can be seen as a model transformation developmentprocess [14]. Since both source and target artifacts on the stage explained in this section aremodels, a model transformation to automatically produce the target from the source is anadequate choice. We call this kind of model transformations translation transformations.

In translating QVTo models into ATC, we could mistakenly assume at first that we face aconversion similar to horizontal, domain mapping transformations, where domain elementsfrom either language are often bound by a nearly one-to-one relationship between eachother. This would usually be described via declarative constructs to promote bidirectionality.Instead, a gap in the level of abstraction is encountered, where the one-to-one relationshipis unusual. Bridging this gap requires a vertical approach. In this case, bidirectionality,although desirable, is not a primary concern here.

Translation transformations into ATC have been developed for both QVTc and QVTo,currently called QVTc2ATC and QVTo2ATC, respectively. Since execution was required,they had to be developed in a language for which a proven model transformation engineexisted and was reliable. We have used a notation close to ATC but of a higher level ofabstraction for productivity reasons. Other working language alternatives should be equallyvalid for this purpose.

Both model transformations have been designed around a common core structure thattakes charge of translating MOF constructs (model parameters, operation parameters, andbasic transformation structuring), and also OCL expressions. The latter includes the OCLStandard Library, which defines a respectable quantity of operations on basic types forwhich code that installs their semantics on translated ATC models must be developed.Additionally, QVTo defines a Standard Library on its own, and QVTc2ATC must accountfor two different execution modes: checking and enforcement.

ATC-based execution support for QVTr models is pending. QVTc being a lower-levelversion of QVTr, a model transformation named relToCore is defined in the QVT specifica-tion to translate QVTr models into QVTc models, a process analogous to the more generalVirtual-Machine concept applied in this work.

The problem with this relToCore transformation is that it is not written in terms ofthe QVTc language, which would have allowed us to translate it into ATC via QVTc2ATCInstead, it is written in QVTr, which means we have to find a suitable QVTr model transfor-


ISSN 1988–3455 SISTEDES, 2008 47

mation engine, such as, perhaps, MOMENT-QVT [13], that must be capable of producingthe QVTc equivalent version of relToCore via the same relToCore transformation.

But such models cannot exist as long as the relToCore is not well defined. The speci-fication states that in QVTr “only first order sets are allowed, i.e., Elements cannot havetype set of sets”, but unfortunately, the transformation makes use of these collections ofcollections constructs at some point. While waiting for the specification to fix this issue, aQVTr2ATC model transformation capable of translating QVTr models directly into seman-tically equivalent ATC counterparts may be worth trying.

This stage has led to improvements on the ATC language in terms of scalability. Importsbetween transformation components have been installed and blind virtual invocations havebeen incorporated to the language.

4.3 QVT Execution

Now we already know how a translated ATC model transformation is obtained. It is seman-tically equivalent to the parsed textual QVT transformation. The third final step consistsof executing this ATC model upon concrete models. The Virtual Transformation Engine(VTE) will take charge of properly and orderly executing the ATC model’s semantics.

Fig. 4. VTE-bound model transformation launcher UI snapshot.

Therefore, this execution stage consists essentially of providing means to locate the inputand output models that are involved in the transformation execution. We have developed ageneric transformation launcher, which comes with a user interface (depicted in Figure 4)in which such models can be entered in a user-friendly mode. It has been designed as ageneric launcher, to which any model transformation engine, even different versions of thesame engine, can be bound. A binding for VTE is provided.

Other automated alternatives are worth considering, such as defining a model transfor-mation chain that might represent part of a Software Product Line, in which models to betransformed are always the same, thus their locations, along with that of the transformationto be executed, do not change. Automating the sequential execution of several transforma-tions may be useful when user interaction is minimized or not required at all.

The complete QVT execution process comprising the three stages explained throughoutthis work is summarized in Figure 5.


ISSN 1988–3455 SISTEDES, 2008 48

Fig. 5. QVT Execution.

5 Related Work

Other available Eclipse-based QVT implementations exist, such as ikv++’s medini QVT[1], a powerful QVTr model transformation engine, or the aforementioned MOMENT-QVT[13]. The SmartQVT model transformation engine [2] covers the QVTo language and ismaintained by some of the people in charge of the QVT specification. In the scope of Eclipse’sM2M project, there are two separate project initiatives to bring support to QVTr andQVTc (by Obeo) and QVTo (by Borland). Concerning QVTo, collaboration between OpenCanarias and Borland currently involves exchanging ideas and sharing test cases. Borlandhas announced that it will refactor its QVTo solution so it becomes capable of generatingQVTo conforming models out from parsed text.

Eclipse has its own official byte-code model transformation language, the ATL-VirtualMachine, toward which several languages are being compiled, including QVT [9], with anapproach that shares many commonalities with ours. Not surprisingly, the group behind thisapproach is working to extend compatibility to other languages, just like the ATC technologyis (see [7], [3]). The importance of these achievements is that work on either infrastructuremay be easily made interoperable with the other by simply providing a translation trans-formation that bridges between both low-level model transformation languages.

The main difference with the ATL-VM is that it incorporates OCL in its core to specifymodel queries and constraints. OCL being declarative, it is independently translated intothe imperative ATC code in our case.

6 QVT Engine Implementation Infrastructure

In this section, we will describe the technology used at the core of our solution. Its mostdistinctive aspect is the use of an intermediate, byte-code model transformation languagenamed Atomic Transformation Code which was originally developed precisely to supportexecution of the QVT specification. Several projects are picked up and combined in anintegral solution capable of executing model transformations specified in the QVT textualconcrete syntax. Eclipse [6] has been selected as our target platform to implement thesolution. Reasons behind this election are unsurprising:


ISSN 1988–3455 SISTEDES, 2008 49

– Eclipse is a powerful open-source platform whose evolution and adoption rate have beengrowing at a very fast pace, and whose flexibility, extensibility, ease of use, etc. make itan ubiquitous platform.

– Eclipse provides a lot of modeling-related functionality which includes EMF [5], as asound metamodeling infrastructure, or the MDT-OCL project, as an implementation ofthe OCL language.

There are several open-source projects we base our QVT execution project on. A list ofrelated Eclipse and non-Eclipse projects we have used to tackle our solution follows:

– MDT-OCL: The official OCL implementation in Eclipse. OCL is a key piece in any QVTimplementation solution, since the three QVT languages rely upon the OCL specificationfor their definition. Our solution has been aligned with the infrastructure developed forthe MDT-OCL project where appropriate.

– UMLX [17]: Another official Eclipse project, currently under the Generative ModelingTechnologies (GMT) section. UMLX provides a lot of common functionality related tothe edition of QVT files. Editors for writing QVTc and QVTr model transformationsare being provided in the context of this project.

– LPG: The LALR(k) Parser Generator is a non-Eclipse project hosted in Sourceforgethat is used by the MDT-OCL project to parse OCL expressions. It provides grammarextensibility mechanisms, an ideal feature for QVT languages.

– Atomic Transformation Code (ATC) [8]: An open, non-official, Eclipse-based project thatconsists of a byte-code model transformation language and its related virtual-machineengine. ATC has been built on top of Eclipse and the EMF project. This is the projectthat actually performs the execution of QVT model transformations and the one whichconfers the Virtual-Machine quality to the whole solution.

7 Conclusions

In this paper a Virtual-Machine-based QVT engine implementation has been described interms of design and technology integration. The solution is subdivided into three main parts.These are firstly source QVT text editing-parsing to obtain equivalent abstract syntax trees,which are represented as models. Secondly, model transformations to automatically translatethem into the byte-code language named ATC that drives the model transformation VirtualMachine. Finally, these semantically equivalent ATC models can be executed, the user beinghidden from the inner details by the UI.

Work is currently very advanced, medium-sized model transformations can usually besmoothly programmed and executed. However, there are still some unfinished areas, such asboth the OCL Standard Library, which concerns the three QVT languages, and the QVToStandard Library. Fortunately there are not currently any technological barriers to achievefull support on that matter. Also, translation support for sophisticated modular componentreuse such as QVTo’s mapping operations inheriting each other, or even refining QVTrRelations, is still unsupported.

Ideally, translation transformations should be writable in terms of a higher-level languagethan the byte-code, such as QVTo, for maintenance or even evolution purposes. For instance,we can write the QVTo2ATC in the same QVTo notation, and then use its model representa-tion obtained via the editor-parser as source for the executable version of QVTo2ATC modeltransformation written in ATC, to generate an identical or similar version as an output. Thesemantical equivalence between the output artifact and the handwritten QVTo2ATC ver-sion could serve as a powerful test case to assert correctness of the procedure and to furtherenhance and extend the transformation itself.


ISSN 1988–3455 SISTEDES, 2008 50

Acknownledgements

Paper co-funded by the MEC (PTR1995-0928-OP), the Plan Nacional de InvestigacionCientıfica, Desarrollo e Innovacion Tecnologica of the Ministerio de Industria, Turismo yComercio (FIT-340000-2007-162) and the Gobierno de Canarias (IDT-TF-07/013).

Thank you Orlando Avila, Veronica Bollati, Christian Damus, Nuria Tejera and Dr.Edward Willink for your invaluable insight and contributions to this whole project.

References

1. ikv++ homepage. http://www.ikv.de.2. SmartQVT, a MOF 2.0 Operational Language Model Transformation Implementation.

http://smartqvt.elibel.tm.fr/.3. O. Avila-Garcıa, A. E. Garcıa, E. V. S. Rebull, and J. L. R. Garcıa. Using software product lines

to manage model families in model-driven engineering. In SAC 2007: Proceedings of the 2007ACM Symposium on Applied Computing, track on Model Transformation, pages 1006–1011.ACM Press, Mar 2007.

4. J. Bezivin, N. Farcet, J.-M. Jezequel, B. Langlois, and D. Pollet. Reflective Model Driven Engi-neering. In Int. Conf. on UML, pages 175–189, 2003. Available at http:/www.lina.sciences.univ-nantes.fr/Publications/2003/BFJLP03.

5. F. Budinsky, D. Steinberg, E. Merks, R. Ellersick, and T. J. Grose. Eclipse Modeling Framework(EMF). Addison Wesley, Aug 2003.

6. D. Carlson. Eclipse Distilled. Addison Wesley, 2005.7. J. S. Cuadrado, E. V. Sanchez, J. G. Molina, and A. Estevez. RubyTL a ATC: un caso real de

transformacion de transformaciones. In DSDM’07: Proceedings del IV Taller Sobre Desarrollode Software Dirigido por Modelos, MDA y Aplicationes, Sep 2007.

8. A. Estevez, J. Padron, E. V. Sanchez, and J. L. Roda. ATC: A low-level model transformationlanguage. In MDEIS 2006: Proceedings of the 2nd International Workshop on Model DrivenEnterprise Information Systems, May 2006.

9. F. Jouault and I. Kurtev. On the architectural alignment of ATL and QVT. In 1st track onMT - SAC 2006: Proceedings of the Symposium on Applied Computing. ACM Press, Apr 2006.

10. OMG. MOF 2.0 Query/View/Transformation specification. Formal Specification formal/2008-04-03, OMG, Apr 2008. http://www.omg.org/docs/formal/08-04-03.pdf.

11. OMG. MOF Model to Text Transformation Language. Technical Report formal/2008-01-16,OMG, Jan 2008. http://www.omg.org/docs/formal/08-01-16.pdf.

12. J. Padron, J. D. Garcıa, E. V. Sanchez, and A. Estevez. Implementacion de un motor detransformaciones con soporte MOF 2.0 QVT. In DSDM’05: Proceedings of the II Taller sobreDesarrollo de Software Dirigido por Modelos. MDA y Aplicaciones, Sep 2005. Available athttp://www.dsic.upv.es/workshops/dsdm05/files/07-Padron.pdf.

13. P. Queralt, L. Hoyos, A. Boronat, J. A. Carsı, and I. Ramos. Un motor de transformacion demodelos con soporte para el lenguaje QVT Relations. In DSDM’06: Proceedings of the III Tallersobre Desarrollo de Software Dirigido por Modelos, MDA y Aplicaciones, Oct 2006. Availableat http://www.dsic.upv.es/workshops/dsdm06/files/dsdm06-14-Queralt.pdf.

14. E. V. S. Rebull, O. Avila-Garcıa, J. L. R. Garcıa, and A. E. Garcıa. Applying a model-driven approach to model transformation development. In MDEIS’2007: Proceedings of the IIIInternational Workshop on Model-Driven Enterprise Information Systems, Jun 2007.

15. E. V. Sanchez, V. Roldan, A. Estevez, and J. L. Roda. Making a case for supporting a byte-code model transformation approach. In Symposium on Eclipse Open Source Software andOMG Open Specifications, Jun 2008.

16. J. B. Warmer and A. G. Kleppe. The Object Constraint Language: Precise Modeling With UML.Addison Wesley, 1998.

17. E. D. Willink. On re-use of OCL for QVT model-checking editors. Technical report,Eclipse UMLX Project, Jun 2007. Available at http://www.eclipse.org/gmt/umlx/doc/MDD-TIF07/MDD-TIF07-QVTEditors.pdf.


ISSN 1988–3455 SISTEDES, 2008 51

Metamodel Syntactic Sheets: un enfoque para la

generación de sintaxis concretas textuales

Javier Espinazo-Pagán, Marcos Menárguez, Jesús Garcia-Molina

University of Murcia, Spain{jespinazo, marcos, molina}@um.es

http://gts.inf.um.es

Abstract. El proceso de desarrollo de los Lenguajes Especí�cos delDominio (DSL) puede afrontarse desde diversos espacios tecnológicostales como XML, el Grammarware o la Ingeniería Dirigida por Modelos(MDE). En el caso de usar MDE, la de�nición de una sintaxis concretapara un DSL textual suele requerir la creación de un puente entre esteespacio tecnológico y el Grammarware. Recientemente han sido propues-tas diversas soluciones para este problema en las cuales el acoplamientoexistente entre las sintaxis concreta y abstracta provoca una duplicaciónde información durante el proceso de desarrollo de DSLs. Por otra parte,en dichos enfoques la reusabilidad de sintaxis concretas no ha sido con-siderada.En este artículo presentamos el enfoque MSS (Metamodel SyntacticSheets) para la de�nición de sintaxis concretas textuales. MSS ha sidoideado para promover la reutilización de sintaxis concretas textuales ypara evitar la duplicación de información. En MSS los metamodelos sonanotados con propiedades sintácticas. Un mecanismo de propagación re-duce el número de anotaciones necesarias, así como el acoplamiento entrelas sintaxis concreta y abstracta. Las sintaxis concretas textuales puedenser reutilizadas anotando sintácticamente el lenguaje de metamodelado,lo cual hace posible la compartición de dialectos sintácticos (convencionestextuales) entre diferentes DSLs.

1 Introducción

El proceso de desarrollo de los Lenguajes Especí�cos del Dominio (DSL) puedeabordarse desde diversos espacios tecnológicos como XML, el Grammarware ola Ingeniería Dirigida por Modelos (MDE). Las técnicas y herramientas de MDEproporcionan claras ventajas para el proceso de desarrollo tales como la de�niciónde modelos del dominio, gracias a la expresividad de los lenguajes de metamod-elado, o la obtención de procesos de desarrollo automáticos. Sin embargo, losDSL textuales dependen de gramáticas para especi�car sus sintaxis concretas,por lo que es necesario tender un puente entre los espacios tecnológicos de MDEy Grammarware.

Como se menciona en [1], existe una signi�cativa redundancia entre la gramáticade la sintaxis concreta textual y el metamodelo de la sintaxis abstracta. Esto


ISSN 1988–3455 SISTEDES, 2008 52

es debido al acoplamiento entre ambos y es un problema común a todos los en-foques existentes para de�nir puentes entre Grammarware y MDE ([1], [2], [3],[4], [5]). Estos enfoques tampoco han prestado atención a la reusabilidad de sin-taxis concretas, por lo que son necesarias nuevas propuestas orientadas a evitarla duplicación de la información y a promover la reutilización en el proceso dedesarrollo de DSLs.

Un ejemplo de la necesidad de reutilización de sintaxis concretas son las fa-milias de DSLs textuales, cuyos miembros son lenguajes que comparten conven-ciones sintácticas, por lo que tienen sintaxis concretas similares. En este artículointroducimos el término dialecto sintáctico para referirnos a dichas convenciones.La aplicación de dialectos sintáticos suele involucrar la repetición de construc-ciones sintácticas a lo largo de la especi�cación de la sintaxis concreta, lo cualincrementa los costes de desarrollo y mantenimiento. En este sentido, las técnicasde reutilización podrían hacer más e�ciente la de�nición de dialectos sintácticos.

MSS (Metamodel Syntactic Sheets) es un enfoque para la especi�cación desintaxis concretas textuales de DSLs que persigue tres objetivos principales:evitar la redundancia de información entre metamodelos y sintaxis concretas,facilitar la reutilización de sintaxis concretas y soportar la de�nición de dialec-tos sintácticos. En MSS, una de�nición de sintaxis concreta textual consiste dehojas sintácticas que contienen un conjunto de propiedades sintácticas que seaplican a los elementos del metamodelo. Un mecanismo de propagación difundelas propiedades sintácticas a través de las relaciones existentes entre los concep-tos de metamodelado, tales como la herencia entre metaclases. La reutilizacióny la creación de familias de DSLs se consiguen gracias a este mecanismo depropagación y a la posibilidad de anotar el propio lenguaje de metamodelado.

Este artículo se organiza como sigue: primero se introduce en la Sección 2la de�nición de patrones sintácticos como base del enfoque MSS. En la Sección3 se describe el DSL utilizado para de�nir las sintaxis concretas textuales. Enla Sección 4 se explica el mecanismo de propagación que permite la creación defamilias de DSLs y la Sección 5 ofrece las conclusiones.

2 Patrones sintácticos

En este artículo presentamos un enfoque para la de�nición de sintaxis concretastextuales a través de la anotación de metamodelos con información sintáctica,que esta sección introduciremos utilizando un sencillo DSL de ejemplo. En laFigura 1 se muestra el metamodelo de dicho DSL, llamado DataForm, cuyopropósito es de�nir formularios de datos consistentes en grupos de campos dedatos.

Este lenguaje de ejemplo presenta una estructura sintáctica anidada, una car-acterística común en los DSLs textuales. El siguiente texto muestra un ejemplode instancia de DataForm.


ISSN 1988–3455 SISTEDES, 2008 53

N a m e d E l e m e n t

n a m e : S t r i n g

F o r m

d a t a : S t r i n g

t i t l e : S t r i n g

G r o u p

F i e l d

r e q u i r e d : B o o l e a n

l a b e l : S t r i n g

T e x t

m a x L e n g t h : I n t e g e r

P a s s w o r d

D a t e

f o r m a t : S t r i n g

g r o u p s f i e l d s

Fig. 1. Sintaxis abstracta del DSL DataForm

Form "BasicUser" {

data: "User";

title: "User Registration";

groups: [

Group "Personal Data" {

fields: [

Text "name" {

required: true;

maxLength: 256;

} ,

Date "birthDate" {

required: false;

label: "Birth Date";

format: "mm/dd/yyyy";

}

]

}

]

}

Más abajo se muestra un extracto de la gramática del DSL DataForm. Para mayorclaridad, los nombres de los símbolos no terminales se de�nen de acuerdo a los ele-mentos del metamodelo; por ejemplo, metaclass-form se re�ere a la declaración de unametaclase Form y feature_form_data se corresponde con la de�nición de la propiedaddata en la metaclase Form.

metaclass_form := 'Form' ID '{' feature_form_data ';'

feature_form_title ';' feature_form_groups '}' ;


ISSN 1988–3455 SISTEDES, 2008 54

feature_form_data := 'data' ':' STRING ;

feature_form_title := 'title' ':' STRING ;

feature_form_group := 'groups' ':'

( '[' ']' | '[' metaclass_group (',' metaclass_group)* ']' );

metaclass_group := 'Group' ID '{' feature_group_fields '}'

feature_group_fields := 'fields' ':'

( '[' ']' | '[' metaclass_field (',' metaclass_field)* ']' );

metaclass_field := ( metaclass_text | metaclass_date

| metaclass_password) ;

...

Nótese que el metamodelo y la estructura sintáctica anidada de la notación estable-cen la forma de las reglas de producción. Estas reglas podrían ser clasi�cadas de acuerdoa tres tipos de construcciones que se dan en el lenguaje: la cabecera y las construc-ciones de propiedad y agregación, que conforman el cuerpo. Las reglas de producciónque pertenecen a una misma categoría tienen la misma estructura. Por ejemplo, lasproducciones feature_form_data y feature_form_title especi�can construcciones depropiedad y di�eren únicamente en el primer símbolo terminal, `data' y `title', respecti-vamente; y las producciones feature_form_groups y feature_group_�elds especi�canasociaciones de agregación y tienen también la misma estructura.

Por lo tanto, cada tipo de construcción sintáctica puede considerarse un patrónsintáctico o plantilla que puede ser parametrizada con símbolos terminales. Esta ideade patrón sintáctico gramatical ha in�uído en la de�nición del enfoque MSS. Usaremosel término propiedad sintáctica para referirnos a los parámetros de los patrones, y eltérmino anotación sintáctica para la asignación de un valor a una propiedad. Algunosejemplos de propiedades sintácticas podrían ser los delimitadores de inicio y �n delcuerpo (llaves en el ejemplo), las palabras clave usadas para identi�car los conceptos,el orden de las características (construcciones de propiedad y de agregación) dentro delcuerpo, los elementos que separan las características entre sí, las características que sedeclaran en la cabecera, etc. Los patrones sintácticos pueden ser aplicados a elementostanto a nivel M2 como a nivel M3 de la arquitectura de cuatro niveles del paradigmade modelado, siendo los aplicados a éstos últimos los más generales, ya que puedenaplicarse a varios DSLs.

Obviamente, los patrones generales son más interesantes ya que la anotación depropiedades sintácticas a nivel del lenguaje de metamodelado permite la reutilizaciónde sintaxis concretas textuales. En este sentido, MSS incorpora un mecanismo de propa-gación que se encarga de propagar las anotaciones sintácticas a través de las relacionesentre los elementos del metamodelo y entre un metamodelo y su meta-metamodelo.De esta forma, MSS evita la redundancia de información entre los metamodelos y lassintaxis concretas y hace posible compartir dialectos sintácticos entre DSLs. La Sección4 explica en detalle el mecanismo de propagación de anotaciones sintácticas.


ISSN 1988–3455 SISTEDES, 2008 55

3 Metamodel Syntactic Sheets

Esta sección describe el DSL propuesto para la anotación de metamodelos con propiedadessintácticas, al que también nos referimos como MSS (Metamodel Syntactic Sheet). Elmetamodelo que representa la sintaxis abstracta de MSS se muestra en la Figura 2. MSSproporciona los conceptos de syntactic sheet (hoja sintáctica) y de syntactic rule (reglasintáctica) para organizar la anotación de propiedades sintácticas para un metamodelo.Una hoja sintáctica consiste en un conjunto de reglas sintácticas que expresan una omás propiedades sintácticas a aplicar a un elemento concreto de un metamodelo (tar-get). Una regla tiene un selector que identi�ca el elemento objetivo (es decir, metaclaseo característica) y un cuerpo que contiene una lista de anotaciones sintácticas.

S y n t a c t i c S h e e t

m e t a m o d e l U R I

R u l e

t a r g e t

r u l e s

0 . . *

F e a t u r e R u l e

C l a s s R u l e

A n n o t a t i o n

p r o p e r t y

v a l u e

a n n o t a t i o n s

0 . . *

Fig. 2. Sintaxis abstacta del DSL de MSS

A continuación se muestra una hoja sintáctica para el metamodelo DataForm de laFigura 1. Las palabras clave class y feature se usan para distinguir entre los dos tiposde regla.

metamodel "http://gts.inf.um.es/data-form/";

class NamedElement priority: 1 {

main-feature: "name" ;

metaclass-identifier: "auto";

}

class Group {

value-separator: "->";

}

class Field {

metaclass-identifier: "auto-uppercase";

prefix-features: "required";

header-features: "label";

}

feature Form.groups {

feature-identifier: "";

value-separator: "";


ISSN 1988–3455 SISTEDES, 2008 56

}

Precediendo al conjunto de reglas de la hoja encontramos una sentencia que de�nela URI de referencia del metamodelo a anotar sintácticamente. El propósito de lasreglas declaradas en el ejemplo se describe a continuación.

La primera regla se aplica sobre la metaclase abstracta NamedElement, y expresados propiedades: i) el valor del atributo name de�nido en la metaclase debe ser usadopara identi�car los conceptos del DSL y ii) la de�nición de un concepto del DSL empiezacon el nombre de la metaclase. Esta regla se aplica a la metaclase que es el ancestrode todas las metaclases del DSL, por lo que el mecanismo de propagación distribuirálas dos anotaciones sintácticas a través de la relación de herencia. Finalmente, se leasigna a la regla un valor de prioridad para resolver posibles colisiones de anotacionessintácticas. En la Sección 4 se discute la técnica usada para resolver las colisiones comoparte del mecanismo de propagación.

La segunda regla se aplica a la metaclase Group. Esta regla de�ne la cadena �- >�como el separador entre los nombres y valores de las características de la metaclase. Lametaclase Group sólo tiene una característica (�elds), pero esta regla podría aplicarse anuevas características, ya que se apoya en la relación de contención entre las metaclasesy las características para propagar las anotaciones sintácticas.

La tercera regla se aplica a la metaclase Field. Expresa tres propiedades: i) ladeclaración de campos de datos usa el nombre de la metaclase en mayúsculas, ii) lacaracterística required pre�ja la declaración y iii) la característica label está incluídaen la cabecera de la declaración del concepto.

La última regla se aplica a la característica groups perteneciente a la metaclaseForm. Esta regla contiene dos propiedades que denotan que deben omitirse el nombrede la característica y el separador.

Como hemos indicado anteriormente, MSS permite la de�nición de dialectos sintác-ticos mediante la anotación del lenguaje de metamodelado con propiedades sintácticasque son compartidas por diversos DSLs. Esto se consigue mediante la propagación delas anotaciones sintácticas desde el meta-metamodelo hacia los metamodelos. Las con-venciones sintácticas establecidas para una familia de DSLs se expresan en una hojasintáctica de�nida para el lenguaje de metamodelado. La hoja sintáctica que se mues-tra a continuación es un ejemplo de un dialecto sintáctico de�nido para el lenguaje demetamodelado Ecore. La primera regla de�ne las propiedades sintácticas comunes atodas las metaclases ya que el elemento objetivo es EClass, mientras que la segundase aplica a la metaclase EStructuralFeature y tiene anotaciones sintácticas para laspropiedades estructurales de las metaclases, es decir, atributos y asociaciones.

metamodel "http://www.eclipse.org/emf/2002/Ecore";

class EClass {

metaclass-identifier: "auto-lowercase" ;

feature-identifier: "auto" ;

value-separator: ":" ;

content-begin-delimiter: "{" ;

content-end-delimiter: "}" ;

content-separator: ";" ;

true-boolean-pattern: "is-*" ;

false-boolean-pattern: "not-*" ;

}


ISSN 1988–3455 SISTEDES, 2008 57

class EStructuralFeature {

multivalued-begin-delimiter: "[" ;

multivalued-end-delimiter: "]" ;

multivalued-separator: "," ;

}

La de�nición de una sintaxis concreta textual requiere de una o más hojas sintác-ticas: aunque es su�ciente con la hoja sintáctica para el metamodelo puede usarse otrahoja para el lenguaje de metamodelado. La hoja del lenguaje de metamodelado podríaincluso ser su�ciente si el DSL no tuviera una notación especí�ca; en tal caso no exis-tiría acoplamiento entre la sintaxis concreta textual y el metamodelo. En esta secciónhemos introducido dos hojas sintácticas para ilustrar las ventajas de la reutilización deun dialecto sintáctico y la opción de ajustar las propiedades sintácticas para elementosespecí�cos del metamodelo.

4 Propagación de anotaciones sintácticas

En esta sección se describe el mecanismo que se encarga de la propagación de lasanotaciones de propiedades sintácticas a través de los elementos del metamodelo. Estemecanismo se ilustra con la propagación de las anotaciones de las dos hojas sintácticasintroducidas en la sección anterior.

En una hoja las reglas sintácticas se usan para de�nir los valores asignados a laspropiedades de un elemento objetivo, si bien una regla no necesita proporcionar el valorpara cada propiedad, ya que las anotaciones pueden ser obtenidas mediante propa-gación, a través de las relaciones existentes entre los conceptos de metamodelado. Enconcreto, se utilizan tres relaciones: i) la relación de herencia entre metaclases, ii) larelación de contención entre una característica y la metaclase que la contiene y iii) larelación de instancia entre un elemento del metamodelo y su metaclase en el meta-metamodelo (por ejemplo, Form es una instancia de la metaclase Ecore EClass).

En el proceso de propagación las metaclases pueden obtener sus anotaciones sin-tácticas de sus padres, así como las características pueden obtener sus anotaciones dela metaclase a la que pertenecen. Esto reduce notablemente el número de anotacionessintácticas a incluir en la hoja sintáctica del metamodelo. Por ejemplo, la anotaciónde metaclases abstractas, tales como NamedElement en la Figura 1, nos permite com-partir la de�nición de propiedades sintácticas a lo largo de varios elementos de unmetamodelo. Por otro lado, la anotación sintáctica del meta-metamodelo proporcionael mayor nivel de reutilización de sintaxis concretas textuales ya que las anotacionesde propiedades sintácticas pueden compartirse entre varios DSLs.

Dado un elemento de un metamodelo, la propagación de las anotaciones sintácticaspuede causar colisiones cuando hay varias anotaciones aplicables. Este problema seresuelve parcialmente priorizando las tres relaciones usadas para la propagación. Lasrelaciones de herencia y de contención entre metaclase y característica no pueden seraplicadas al mismo elemento (clase o característica) al mismo tiempo por lo que sóloes necesario de�nir la prioridad de la relación de instancia frente a las relaciones deherencia y de contención. Hemos decidido priorizar la herencia y la contención sobrela instancia, ya que las anotaciones sintácticas de�nidas en el metamodelo son másespecí�cas que las anotaciones de�nidas en el lenguaje de metamodelado.

Por otro lado, como las metaclases pueden tener más de un padre, pueden apare-cer colisiones en la propagación basada en herencia. Puede observarse que en la hoja


ISSN 1988–3455 SISTEDES, 2008 58

sintáctica de metamodelo de la Sección 4 se ha asignado un valor de prioridad a las an-otaciones de la metaclase NamedElement. Este valor se usa en caso de colisión debidaa herencia, por lo que la resolución de las colisiones depende de la correcta asignaciónde prioridades que haga el usuario.

El mecanismo de propagación funciona de la siguiente manera: primero se comprue-ban las anotaciones de propiedades sintácticas de cada metaclase. Después se solicitanlas anotaciones no declaradas a las metaclases padres. Si una propiedad puede serobtenida de varias metaclases padres se comprueban las prioridades de cada una. Lasanotaciones no resueltas por la herencia pueden ser obtenidas a partir de la meta-metaclase (EClass en el lenguaje Ecore) a través de la relación de instancia. Una vezque la propagación ha sido aplicada a las metaclases del metamodelo, el proceso de con-tinúa con las características de las metaclases. Después, la propagación usa la relaciónde contención en lugar de la relación de herencia. La relación de instancia se usa parapropagar anotaciones desde las meta-metaclases que representan atributos (EAttributeen Ecore) y asociaciones (EReference en Ecore).

G r o u p . f i e l d s

v a l u e - s e p a r a t o r : " - > " f ea tu re - i den t i f i e r : "au to " m u l t i v a l u e d - s e p a r a t o r : " , " m u l t i v a l u e d - e n d - d e l i m i t e r : " ] " m u l t i v a l u e d - b e g i n - d e l i m i t e r : " [ "

G r o u p

v a l u e - s e p a r a t o r : " - > " m e t a c l a s s - i d e n t i f i e r : " a u t o " m a i n - f e a t u r e : " n a m e " f ea tu re - i den t i f i e r : "au to " con ten t - beg in -de l im i t e r : " { " c o n t e n t - e n d - d e l i m i t e r : " } " c o n t e n t - f e a t u r e s - s e p a r a t o r : " ; " t r u e - b o o l e a n - p a t t e r n : " i s - " f a l s e - b o o l e a n - p a t t e r n : " n o t - "

E C l a s s

m e t a c l a s s - i d e n t i f i e r : " a u t o - l o w e r c a s e " v a l u e - s e p a r a t o r : " : " f a l s e - b o o l e a n - p a t t e r n : " n o t - " t r u e - b o o l e a n - p a t t e r n : " i s - " c o n t e n t - f e a t u r e s - s e p a r a t o r : " ; " c o n t e n t - e n d - d e l i m i t e r : " } " con ten t - beg in -de l im i t e r : " { " f ea tu re - i den t i f i e r : "au to "

N a m e d E l e m e n t

m a i n - f e a t u r e : " n a m e " m e t a c l a s s - i d e n t i f i e r : " a u t o "

P r o p a g a c i ó np o r l a R e l a c i ó nd e C o n t e n c i ó n

P r o p a g a c i ó np o r l a R e l a c i ó n

d e H e r e n c i a


d e I n s t a n c i a

E R e f e r e n c e

m u l t i v a l u e d - b e g i n - d e l i m i t e r : " [ " m u l t i v a l u e d - e n d - d e l i m i t e r : " ] " m u l t i v a l u e d - s e p a r a t o r : " , "


d e I n s t a n c i a

L e n g u a j e E c o r e

M e t a m o d e l o D a t a F o r m

E S t r u c t u r a l F e a t u r e

m u l t i v a l u e d - s e p a r a t o r : " , " m u l t i v a l u e d - e n d - d e l i m i t e r : " ] " m u l t i v a l u e d - b e g i n - d e l i m i t e r : " [ "


d e H e r e n c i a

Fig. 3. Propagación de las anotaciones sintácticas para la metaclase Group y su carac-terística fields


ISSN 1988–3455 SISTEDES, 2008 59

Ahora vamos a ilustrar el mecanismo de propagación analizando las anotacionesaplicadas a la metaclase Group y a su característica �elds del metamodelo DataForm.Las anotaciones sintácticas han sido declaradas en las hojas sintácticas presentadas enla Sección 4. La Figura 3 muestra todas las propagaciones que se aplican, las cuales seexplican a continuación.

En la hoja sintáctica del metamodelo, la metaclase Group está anotada con unaregla que tiene un solo valor de propiedad, por lo que el resto de las anotaciones sintác-ticas deben ser obtenidas mediante propagación (las propiedades sintácticas requeridaspara las metaclases se presentaron en la Sección 3). En un primer momento la relaciónde herencia proporcionaría dos anotaciones de la metaclase NamedElement. Las anota-ciones restantes deben ser obtenidas a través de la relación de instancia. Por lo tanto,se propagan seis anotaciones desde la metaclase EClass de Ecore. Nótese que existe unacolisión para la propiedad metaclass-identi�er, pero que la herencia prevalece sobre larelación de instancia como se indicó anteriormente.

La caracteristica �elds de Groups no ha sido anotada en la hoja sintáctica del meta-modelo, por lo que es necesario que obtenga las anotaciones para todas sus propiedades.Inicialmente las anotaciones se extraen de la metaclase Group que contiene la carac-terística, pero sólo se obtienen dos anotaciones. Por lo tanto, las propiedades restantesse obtienen a partir del lenguaje de metamodelado, siendo �elds es una instancia dela metaclase EReference de Ecore, que no ha sido anotada en la hoja sintáctica paraEcore, pero hereda las anotaciones sintácticas de EStructuralFeature.


En este artículo hemos presentado el enfoque MSS para la de�nición de sintaxis concre-tas textuales. Comparado con los enfoques existentes, MSS se caracteriza por dos con-ceptos principales: propiedades sintácticas y propagación de anotaciones de propiedadessintácticas. MSS ofrece las llamadas hojas sintácticas como una forma cómoda de or-ganizar en reglas las anotaciones sintácticas para los elementos del metamodelo.

La propagación de anotaciones sintácticas facilita dos formas de reutilización desintaxis concretas textuales: i) reutilización de anotaciones dentro de un mismo meta-modelo y ii) reutilización de dialectos sintácticos de�nidos mediante la anotación dellenguaje de metamodelado. Las principales contribuciones del enfoque MSS serían:

� Introducción de técnicas de reutilización para el desarrollo de sintaxis concretastextuales.

� Creación de dialectos sintácticos.

� Reducción de la duplicación de información gracias a la reducción del acoplamientoentre las sintaxis concreta y abstracta.

MSS ha sido aplicado para prototipar DSLs en diversos proyectos de investigación.También ha sido utilizado para proporcionar sintaxis concretas textuales a DSLs exis-tentes como el lenguaje de transformación de modelos RubyTL. Actualmente se estánconsiderando nuevos patrones sintácticos y propiedades para mejorar la expresividad delas sintaxis concretas y MSS está siendo integrado en un framework para el desarrollode DSLs.


ISSN 1988–3455 SISTEDES, 2008 60

Agradecimientos

Este trabajo ha sido parcialmente subvencionado por la Fundación Séneca, beca 05645/PI/07,y por el Gobierno de la Región de Murcia (España), beca TIC-INF 06/01-0001.

References

1. Frédéric Jouault, Jean Bézivin, and Ivan Kurtev. TCS: a DSL for the Speci�cationof Textual Concrete Syntaxes in Model Engineering. In Stan Jarzabek, Douglas C.Schmidt, and Todd L. Veldhuizen, editors, GPCE, pages 249�254. ACM, 2006.

2. OpenArchitectureWare. http://www.openarchitectureware.org.3. Manuel Wimmer and Gerhard Kramler. Bridging Grammarware and Modelware.

In MoDELS 2005 Conference Satellite Events, volume 3824, pages 159�168. LectureNotes in Computer Science, 2005.

4. Andreas Kunert. Semi-automatic Generation of Metamodels and Models fromGrammars and Programs. In Fith Intl Workshop on Graph Transformation and

Visual Modeling Techinques. Electronic Notes in Theorical Computer Science, 2006.5. Tony Clark, Paul Sammut, and James Willans. Applied Metamodelling, A Founda-

tion for Language Driven Development, Second Edition. Xactium, 2008.


ISSN 1988–3455 SISTEDES, 2008 61

Verificación de la ejecutabilidad de operaciones definidas con Action Semantics

Elena Planas1, Jordi Cabot1 y Cristina Gómez2

1Estudis d'Informàtica, Multimèdia i Telecomunicació, Universitat Oberta de Catalunya {eplanash | jcabot}@uoc.edu

2 Dept. de Llenguatges i Sistemes Informàtics, Universitat Politècnica de Catalunya [email protected]

Resumen. MDD y MDA requieren definir el modelo de comportamiento del sistema software con un nivel de detalle suficiente para permitir su implementación automática. Con este fin, la especificación UML incorporó el lenguaje Action Semantics (AS) para especificar de forma precisa el comportamiento de un sistema software. Una vez complementadas con estructuras de control de flujo, las acciones de AS permiten especificar de manera completa el efecto de las operaciones definidas en un diagrama de clases. Lamentablemente, las propuestas actuales dedicadas a la verificación de la calidad de los esquemas de comportamiento no son suficientemente potentes como para garantizar la corrección de las especificaciones basadas en AS. El objetivo de este artículo es complementar estos trabajos con la propuesta de una nueva técnica para la verificación de la ejecutabilidad de este tipo de especificaciones. En concreto, la técnica que se propone está basada en el análisis estático de las dependencias entre las acciones que definen el comportamiento de la operación.

1 Introducción

Uno de los grandes retos de la ingeniería del software es obtener, automáticamente, la implementación completa de un sistema software a partir de un modelo inicial descrito en un alto nivel de abstracción. Éste es también el objetivo de dos aproximaciones actuales, el Desarrollo Dirigido por Modelos (Model-Driven Development, MDD) y la Arquitectura Dirigida por Modelos (Model-Driven Architecture, MDA).

Con el fin de alcanzar este objetivo, la mayoría de propuestas siguen una estrategia pragmática, intentando reducir la expresividad del lenguaje UML a un subconjunto ejecutable [17]. La propia OMG está avanzando en la definición de un estándar para un “UML ejectuable” [20].

Un elemento clave de este tipo de métodos [17] [21] es el uso de Action Semantics (AS) para especificar el comportamiento de las operaciones definidas en el diagrama de clases. Las acciones son las unidades fundamentales para especificar el comportamiento de una operación, como por ejemplo la creación de nuevos objetos, la creación de nuevos enlaces entre objetos, la destrucción de objetos existentes o la modificación del valor de los atributos de un objeto, entre otros. Estas acciones se pueden coordinar con bloques condicionales y estructuras iterativas para definir de manera completa el efecto de una operación.

Dada la importancia de AS en la definición del comportamiento de un sistema software, es evidente que la corrección de este tipo de especificaciones tiene un efecto directo sobre la calidad de la implementación final del sistema. A modo de simple ejemplo, consideremos el diagrama de clases de la Fig. 1.1 y la operación añadirPersona. Esta operación no se puede ejecutar nunca con éxito, ya que cada vez que intentemos ejecutarla, llegaremos a un estado del sistema que violará la restricción de cardinalidad mínima ‘1’del rol departamento de la asociación TrabajaEn, dado que los nuevos objetos de tipo persona no estarán enlazados con ningún departamento. Si este error no se detecta (y corrige) antes de continuar con la fase de generación de código, la implementación resultante será totalmente infructuosa.


ISSN 1988–3455 SISTEDES, 2008 62

context Persona::añadirPersona(n:String, e:String){ p: p Persona; p:=createObject(Persona); addStructuralFeature(p,nombre,n); addStructuralFeature(p,email,e); }

Fig. 1.1. Ejemplo de diagrama de clases con una operación definida con AS.

En este sentido, el objetivo de este artículo es proporcionar una técnica para verificar la ejecutabilidad de las especificaciones basadas en AS en tiempo de diseño. Nuestra técnica no requiere ningún tipo de animación/simulación del modelo UML original y, por lo tanto, no sufre el problema de explosión de estados, típico de las técnicas de model checking (MC) [4].

A grandes rasgos, dada una operación op, nuestra técnica determina su ejecutabilidad mediante dos etapas : (1) analiza el flujo de la operación y determina todos sus caminos de ejecución y (2) comprueba la ejecutabilidad de cada camino de ejecución c mediante un análisis estático de las dependencias entre las acciones modificadoras (acciones que cambian el estado del sistema) de c, teniendo en cuenta las restricciones estructurales del modelo. Cuando c no es ejecutable, el diseñador recibe como feedback la información necesaria para reparar c.

La estructura de este artículo es la siguiente: la sección 2 describe los conceptos básicos del lenguaje AS. La sección 3 explica como determinar los diferentes caminos de ejecución de una operación. La ejecutabilidad de estos caminos se describe en la sección 4. La sección 5 revisa los trabajos relacionados y, finalmente, en la sección 6 se presenta las conclusiones y el trabajo futuro.

2 Action Semantics en UML

En UML, el comportamiento de una operación se puede definir mediante el uso de actividades (Activity), donde cada actividad está formada por un conjunto de nodos (ActivityNode) que describen sus diversas etapas . Un nodo puede consistir en una acción básica (Action), o bien en un nodo estructurado (StructuredActivityNode), utilizado para coordinar acciones básicas en secuencias de acciones (SequenceNode), bloques condicionales (ConditionalNode) o bloques iterativos (LoopNode) de tipo do-while o while-do (ver Fig. 2.1).

StructuredActivityNode

BehavioralFeature ExecutableNode

ConditionalNode SequenceNode

StateMachine

ActivityNode

LoopNode

Operation

Behavior

Activity Action

*

0..1

+method

*+specification0..1

+node*

+activity

0..1

Fig. 2.1. Fragmento del metamodelo UML 2.0.

Para los propósitos de éste artículo, consideramos únicamente un subconjunto de las acciones estándares (Action) definidas en el metamodelo de UML1:

1. createObject(cl:Classifier):InstanceSpecification: Crea y retorna un nuevo objeto que es instancia de la clase cl. La acción no tiene ningún otro efecto.

2. destroyObject(o:InstanceSpecification): Destruye el objeto o, que es instancia de una clase. Asumimos que la acción no destruye los posibles enlaces en los que el objeto participa.

3. addStructuralFeature(o:InstanceSpecification,at:StructuralFeature,v:ValueSpecification): Asigna el valor v a l atributo at del objeto o. Consideramos que los atributos multi-valuados se expresan como asociaciones binarias entre la clase y el tipo del atributo.

4. createLink(as:Classifier,p1:InstanceSpecification,p2:InstanceSpecification): Crea un nuevo enlace de la asociación binaria 2 as entre los objetos p1 y p2.

1 UML 2.0 únicamente proporciona una sintaxis abstracta para estas acciones [19]. Nuestra sintaxis concreta

se basa en las metaclasses del metamodelo. Para los nodos estructurados, utilizamos la sintaxis ASL definida en [17].

nombre: String

Persona nombre: String email: String

TrabajaEn 1 * Departmento


ISSN 1988–3455 SISTEDES, 2008 63

5. destroyLink(as:Classifier,p 1:InstanceSpecification,p 2:InstanceSpecification): Destruye el enlace de la asociación binaria as entre los objetos p1 y p2.

6. reclassifyObject(o:InstanceSpecification,nuevasCl:Classifier[0..*],antiguasCl:Classifier[0..*]): Añade el objeto o como instancia de las clases del conjunto nuevasCl y lo elimina de las clases del conjunto antiguasCl .

A modo de ejemplo, hemos definido tres operaciones: finDeRevision, enviarArticulo y despedir (Fig. 2.3) que complementan el diagrama de clases de la Fig. 2.2, que tiene como objetivo representar parte de un sistema de gestión de un congreso. La primera operación (finDeRevision) reclasifica un artículo como rechazado o aceptado dependiendo del parámetro evaluacion. La segunda operación (enviarArtículo) crea un nuevo artículo en revisión y lo enlaza con sus autores. La última operación (despedir) elimina el enlace TrabajaEn entre una persona y su departamento.

Fig. 2.2. Extracto del diagrama de clases de un sistema de gestión de congresos.

context Articulo::enviarArticulo(tit:String, autores:Persona[1..*]) { i: Integer := 1; a := createObject(EnRevision); addStructuralFeature(a,titulo,tit); while i <= autores->size() do createLink(EsAutorDe,a,autores[i]); i := i+1; endwhile }

context Articulo::finDeRevision(com:String, d:Date, evaluacion:String) { if self.oclIsTypeOf(EnRevision) then if evaluacion = ’rechazar’ then reclassifyObject(self,Rechazado,∅); addStructuralFeature(self,comentarios,com); else reclassifyObject(self,Aceptado,∅); addStructuralFeature(self,fechaAcept,d); endif endif }

context Persona::despedir() { destroyLink(TrabajaEn,self,self.departmento); }

Fig. 2.3. Especificación de las operaciones finDeRevision, enviarArticulo y despedir.

3 Cálculo de los caminos de ejecución

La verificación de la ejecutabilidad de una operación se basa en el análisis de todos sus posibles caminos de ejecución. Un camino de ejecución es una secuencia de acciones que se puede seguir durante la ejecución de la operación. Las operaciones triviales (sin bloques condicionales ni bucles) tienen un solo camino de ejecución.

Para calcular los caminos de ejecución, proponemos representar la operación mediante un grafo MBCFG (Model-Based Control Flow Graph), es decir, un grafo de control de flujo basado en la información del modelo. Los MBCFG se han utilizado para expresar diagramas de secuencia UML [9]. En éste artículo, adaptamos esta idea para expresar el flujo de las operaciones basadas en AS.

Para simplificar, cuando creamos el MBCFG asumimos que la operación está definida como una secuencia de nodos (SequenceNode) que contiene un conjunto ordenado de nodos ejecutables (ExecutableNode) que definen el efecto de la operación. Cada nodo ejecutable puede ser una de las posibles acciones definidas en el apartado anterior (otros tipos de acciones se ignoran durante el análisis), un nodo condicional, un bucle o una nueva secuencia de nodos (ver Fig. 2.1). También utilizamos dos nodos especiales: el nodo inicial, que representa la primera instrucción de la operación, y el nodo final, que representa la última. Estos dos nodos no cambian el efecto de la operación, pero ayudan a simplificar la presentación de nuestro MBCFG.

2 Las asociaciones N-arias se pueden expresar fácilmente en términos de asociaciones binarias [16].

P e r s o n a nombre : Str ing emai l : String

Articulo

t i tulo: S t r i n g

R e c h a z a d o

comen ta r i os: Str ing

Aceptado f e c h a Acept : da te

D e p a r t m e n t o

nombre: Str ing

E n R e v i s i o n

E s A u t o r D e

a u t o r 1..** TrabajaEn 1 *

{d is jo in t ,complete}


ISSN 1988–3455 SISTEDES, 2008 64

El digrafo MBCFGop= (Vop, Aop) correspondiente a una operación op se obtiene siguiendo las reglas que se describen a continuación:

- Cada nodo ejecutable de op es un vértice en Vop. - Un arco desde un vértice v1 hasta otro vértice v2 se crea en Aop si v1 precede

inmediatamente v2 en la secuencia ordenada de nodos. - Un vértice v que representa un nodo condicional n, se enlaza con los vértices v1…vn , que

representan el primer nodo ejecutable de cada cláusula (por ejemplo, la cláusula then, la cláusula else, etc.) de n. El último vértice de cada cláusula se enlaza con el vértice vnext , que es el nodo ejecutable que sigue inmediatamente a n. Si n no incluye la cláusula else, se añade un arco entre v y vnext en Aop.

- Un vértice v que representa un bucle n, se enlaza con el vértice que representa el primer nodo ejecutable del cuerpo de n y con el vértice vnext, que es el nodo ejecutable que sigue inmediatamente a n. El último vértice del cuerpo del bucle se enlaza con v (para representar el comportamiento iterativo).

Operación enviarArticulo:

Operación finDeRevision:

Operación despedir:

Fig. 3.1. MBCFG de las operaciones de ejemplo finDeRevision, enviarArticulo y despedir.

La Fig. 3.1 muestra los MBCFG de las operaciones de nuestro ejemplo. Los nodos inicial y final se representan con círculos. Las condiciones de test de los nodos condicionales y de los bucles no se muestran dado que no son parte de nuestro análisis 3.

Dado un grafo MBCFGop G, el conjunto de caminos de ejecución de op se define como cop=caminos(MBCFGop) donde caminos(G) devuelve el conjunto de todos los caminos de G que empiezan en el vértice inicial (el vértice que corresponde con el nodo inicial), acaban en el vértice final y no incluyen arcos repetidos (éstos caminos se conocen como trails [2]).

Cada camino de ejecución de cop se representa formalmente como una secuencia ordenada de nodos definidos mediante tuplas <numero,accion>, donde numero indica el número de veces que la acción accion se ejecuta en ese nodo en particular. Los vértices que representan otros tipos de nodos ejecutables (bloques condicionales o bucles) se descartan.

El elemento numero de la tupla sólo es relevante para acciones que forman parte de un bucle. Para el resto de acciones, el valor del elemento numero siempre es ‘1’. El numero de una acción ac que se encuentra dentro de un bucle se calcula del siguiente modo: (1) A cada bucle while-do del grafo se le asigna una variable diferente de tipo entero (N,…,Z), que representa el número de veces que el bucle puede ser ejecutado. A los bucles do-while se les asigna el valor 1+N,…,1+Z para expresar que el cuerpo del bucle se ejecuta al menos una vez. (2) El numero de ac es igual al producto de las variables de todos los bucles que encontramos en el camino de ejecución entre ac y el vértice inicial. Es decir, ac se ejecutará N veces si ac se encuentra en un bucle de primer nivel, N*M veces si forma parte de un bucle anidado, y así sucesivamente.

3 La detección de caminos no ejecutables debido a condiciones de test insatisfactibles (ya sea de condicionales o bucles) cae fuera del ámbito de éste trabajo. Éste problema se puede reducir a un problema de satisfactibilidad a tratar con las actuales herramientas de verificación UML/OCL.

destroyLink

(TrabajaEn,self,self.department o)

a:=createObject (EnRevision)

addStructuralFeature (a,titulo,tit)

while createLink (EsAutorDe,a,autores[i])

addStructuralFeature (self,comentarios,com)

addStructuralFeature (self,fechaAccept,d)

reclassifyObject (self,Rechazado,∅)

if

if

reclassifyObject (self,Aceptado,∅)


ISSN 1988–3455 SISTEDES, 2008 65

La Fig. 3.2 muestra los caminos de ejecución de los grafos de la Fig. 3.1. Operación finDeRevision: c1 = { } c2 = {<1,reclassifyObject(self,Rechazado,∅)>, <1,addStructuralFeature(self,comentarios,com)>} c3 = {<1,reclassifyObject(self,Aceptado,∅)>, <1,addStructuralFeature(self,fechaAcept,d)>}

Operación enviarArticulo: c1 = {<1,a:=createObject(EnRevision)>, <1,addStructuralFeature(a,titulo,tit)>} c2 = {<1,a:=createObject(EnRevision)>, <1,addStructuralFeature(a,titulo,tit)>,<N,createLink(EsAutorDe,a,autores[i])>}

Operación despedir: c = {<1,destroyLink(TrabajaEn,self,self.departmento)>}

Fig 3.2. Caminos de ejecución de las operaciones de ejemplo finDeRevision, enviarArticulo y despedir.

4 Ejecutabilidad

Decimos que una operación es débilmente ejecutable si existe la posibilidad que el usuario pueda ejecutarla con éxito, es decir, si existe al menos un estado inicial del sistema s (y un conjunto de argumentos para los parámetros de la operación) a partir del cual, una vez aplicadas las acciones modificadoras incluidas en la operación, se obtenga un nuevo estado s’ que satisfaga todas las restricciones de integridad del modelo. Nuestro análisis no tiene en consideración el valor de los parámetros de las acciones, por este motivo definimos la propiedad de ejecutabilidad como ejecutabilidad débil , dado que no requerimos que todas las ejecuciones de la operación tengan éxito (eso puede depender de los valores concretos por los proporcionados por el usuario en tiempo de ejecución), sólo aseguramos que como mínimo se puede ejecutar alguna vez.

A modo de ejemplo, consideremos de nuevo las operaciones definidas en el ejemplo de la Fig. 2.2 y 2.3. Claramente, la operación despedir no es ejecutable debido a que cada vez que eliminamos un enlace entre una persona p y un departamento d alcanzamos un estado de error, dado que p queda sin relación con ningún departamento, una situación prohibida por la restricción de cardinalidad mínima ‘1’ de la relación TrabajaEn. Como veremos más adelante, cuando se despide una persona p de un departamento d es necesario asignar un nuevo departamento d’ a p o bien destruir p en el mismo flujo de ejecución de la operación. Por otro lado, enviarArticulo sí que es ejecutable, ya que es posible encontrar un estado (por ej. un estado con diversos autores dados de alta en el sistema) donde el nuevo artículo se puede enviar con éxito.

La ejecutabilidad débil de una operación se define en términos de la ejecutabilidad débil de sus caminos de ejecución: una operación es débilmente ejecutable si al menos uno de sus caminos de ejecución es débilmente ejecutable. La ejecutabilidad de un camino depende del conjunto de acciones incluidas en dicho camino. La idea básica es que algunas acciones requieren la presencia de otras acciones en el mismo camino de ejecución con el fin de dejar el sistema en un estado consistente al final de la ejecución. Por consiguiente, para ser ejecutable, un camino c debe satisfacer todas las dependencias para cada acción ac de c. Las dependencias para una acción se determinan en función de la información del diagrama de clases y del tipo de modificación que ejecuta la acción. Siguiendo con el ejemplo anterior, la operación despedir no es ejecutable debido a que su único camino de ejecución (Fig. 3.2) no es ejecutable, ya que la acción destroyLink(TrabajaEn,p,d) debe ir seguida de un destroyObject(p) o bien de un createLink(TrabajaEn,p,d’) para evitar violar la restricción de cardinalidad. El camino no incluye ninguna de éstas acciones, por la cual cosa, no es ejecutable.

A continuación presentamos el algoritmo para determinar la ejecutabilidad débil de un camino de ejecución (parámetro de entrada c) en el contexto de un diagrama de clases (parámetro de entrada dc). Para los caminos no ejecutables, el algoritmo es capaz de devolver una posible secuencia de acciones (parámetro de salida accionesReq) que se deben incluir en el camino para que sea ejecutable4.

4 Extender el camino con ésta secuencia es una condición necesaria pero no suficiente para garantizar la su

ejecutabilidad. Las acciones de la secuencia pueden tener, a su vez, dependencias adicionales que deben considerarse. Esto puede detectarse re-aplicando el algoritmo sobre el camino de ejecución extendido.


ISSN 1988–3455 SISTEDES, 2008 66

function ejecutabilidad (in: c: Sequence (<numero:Integer, accion:Action>),

in: <Set(Class),Set(StructuralFeature),Set(Association),Set(GeneralizationSet), Set(Constraint)> out: accionesReq:Set (<numero:Integer, accion:Action >)): Boolean {

dependencias: Set(<numero:Integer, accion:Action>);

node: <numero:Integer, disponibilidad:Integer, accion:Action>; cAux: Sequence(<numero:Integer, disponibilidad:Integer, accion:Action>); cAux := iniCaminoAux(c); for each nodo ∈ cAux do dependencias := obtenerDependencias(nodo,dc); accionesReq := accionesReq U mapear(dependencias,cAux); endfor return (accionesReq = Ø); }

A grandes rasgos, el algoritmo itera a través de las acciones del camino. Para cada acción del camino de entrada, se calculan sus dependencias (función obtenerDependencias). A continuación, la función mapear intenta mapear cada dependencia sobre el resto de acciones del camino. Las dependencias que no se satisfacen completamente se añaden al conjunto accionesReq y se devuelven como feedback al usuario (para que éste pueda añadirlas a la operación y, de esta forma, corregirla). La función iniCaminoAux simplemente crea una copia de c en cAux y añade el atributo auxiliar disponibilidad a cada nodo. Inicialmente éste atributo toma el valor numero y, posteriormente, es actualizado por la función mapear.

A continuación, se explica con más detalle el cálculo de dependencias y el proceso de mapeo, y se muestra la aplicación del algoritmo sobre las operaciones de nuestro ejemplo.

4.1 Cálculo de Dependencias

Una dependencia entre una acción ac1 (antecedente) y otra acción ac2 (consecuente) expresa que la acción ac2 se debe incluir en todos los caminos de ejecución donde aparece ac1, con el fin de evitar violar las restricciones del diagrama de clases. Puede suceder que ac1 dependa de diversas acciones (composición AND) o que tengamos diversas alternativas para mantener la consistencia del sistema después de la ejecución de ac1 (composición OR: cuando alguna de las posibles dependencias aparece en el camino, la dependencia se satisface). Las dependencias entre acciones dependen del tipo de acción y de las restricciones de integridad del diagrama de clases.

La Tabla 4.1 proporciona las reglas para calcular las dependencias requeridas (segunda columna) para cada tipo de acción (primera columna). Estas reglas son una adaptación de las definidas en [3]. Por ejemplo, consideremos la acción p:=createObject(Persona) en el contexto de la Fig. 2.2. Según la tabla, la ejecución de esta acción requiere la creación de un enlace entre la persona y un departamento (createLink(TrabajaEn,p,d)) y la asignación de valor a los atributos nombre (addStructuralFeature(p,nombre,n)) y email (addStructuralFeature(p,email,e)).

La tercera columna de la tabla determina, para cada dependencia, si dos o más acciones dependientes pueden mapear (es decir, pueden compartir) la misma acción del camino. Por ejemplo, la acción createLink puede requerir una acción destroyLink , createObject o reclassifyObject en el mismo camino de ejecución. La primera dependencia no es compartible, debido a que cada createLink necesita un destroyLink diferente para mantener el sistema en un estado consistente. En cambio, si lo es la dependencia createObject ya que diversos createLink pueden modificar un mismo objeto para satisfacer una multiplicidad mínima en una asociación.

Dada la Tabla 4.1, la función obtenerDependencias(nodo): (1) calcula el conjunto de dependencias dep para la acción nodo.accion como se indica en la tabla 4.1, (2) multiplica el valor numero de cada dependencia por el valor de nodo.numero (el número de dependencias de una


ISSN 1988–3455 SISTEDES, 2008 67

acción es proporcional al número de acciones de este tipo en el camino) y (3) devuelve el conjunto dep.

Tabla 4.1. Dependencias de las acciones modificadoras. Min(ci,as) y max(ci,as) denotan la multiplicidad mínima y máxima de la clase ci en la asociación as.

Acción Acciones Requeridas Compartible? addStructuralFeature(o,at,v) para cada atributo at no derivado y obligatorio de c o de alguna superclase de c. No

o=createObject(c) AND <min(c,as),createLink(as,o,o2)> para cada asociación as no derivada donde c o una superclasse de c tiene una participación obligatoria.

No

destroyObject(o:c)

<min(c,as),destroyLink(as,o,o2)> para cada asociación as no derivada donde c o una superclase de c tiene una participación obligatoria.

No

destroyLink(as,o1,o3) (si min(c2,as) <> max(c2,as)) No OR createObject(o1) Si

createLink(as,o1:c1,o2:c2) (donde min(c1,as) = max(c1,as)) que se repetirá en el otro extremo

OR reclassifyObject(o1,c1,Ø) Si

createLink(as,o1,o3) (si min(c2,as) <> max(c2,as)) No OR destroyObject(o1) Si

destroyLink(as,o1:c1,o2:c2) (donde min(c1,as) = max(c1,as)que se repetirá en el otro extremo OR reclassifyObject(o1,Ø,c1) Si

addStructuralFeature(o,at,v) - - addStructuralFeature(o,at,v)para cada atributo at no derivado y obligatorio de cada clase c ∈ nc

No

AND <min(c,as),createLink(as,o,o3)> para cada c ∈ nc y para cada asociación as no derivada donde c tiene una particpación obligatoria.

No

AND reclassifyObject(o,Ø,{cc’}) para cada cc’ tal que ∃cc ∈ nc y cc’ ∉ oc y cc ? cc’ y cc y cc’ son subclases de una misma generalización disjoint y complete y o era instancia de cc’

Si

AND <min(c,as),destroyLink(as,o,o3)> para cada clase c de oc y para cada asociación as no derivada donde c tiene una participación obligatoria.

No

reclassifyObject(o,nc,oc)

AND reclassifyObject(o,{cc’},Ø) para cada cc’ tal que cc’ ∉ nc y ∃cc ∈ oc y cc ? cc’ y cc y cc’ son subclases de una misma generalización disjoint y complete y o era instancia de cc’

Si

4.2 Determinación de las Acciones Requeridas

Para cada dependencia d devuelta por la función obtenerDependencias5, la función mapear comprueba, en primer lugar, si d se puede satisfacer por alguna de las acciones del camino y, si no, añade d al conjunto de acciones requeridas que será devuelto como feedback al diseñador para que complemente la definición de la operación como requisito necesario para que sea ejecutable.

Una dependencia d mapea correctamente con un nodo n del mismo camino de ejecución si se cumplen las siguientes condiciones: (1) las acciones d.accion y n.accion son del mismo tipo, (2) los elementos del modelo modificados por las acciones coinciden (por ejemplo, las dos acciones crean un nuevo enlace de la asociación as), (3) todos los parámetros ligados de d.accion

5 Como hemos visto antes, obtenerDependencias puede devolver más de un conjunto de dependencias

alternativas (todas ellas suficientes para llegar a un estado consistente). En estos casos, la función de mapeo debe comprobar si al menos una de las alternativas mapea correctamente en el camino. Por razones de simplicidad, esta situación no se describe en esta sección.


ISSN 1988–3455 SISTEDES, 2008 68

concuerdan con los parámetros de n.accion y (4) n.numero=d.numero6 (para las dependencias compartibles) o n.disponibilidad=d.numero (para las dependencias no compartibles). En éste último caso, el valor del atributo disponibilidad del nodo se decrementa de acuerdo con el número de acciones “consumidas”: n.disponibilidad:=n.disponibilidad-d.numero.

4.3 Aplicación del algoritmo

A continuación se muestra la ejecución de la función ejecutabilidad para dos de las operaciones especificadas en la sección 2. Las variables libres se muestran en cursiva.

Tabla 4.3.1. Verificación de la ejecutabilidad débil del segundo camino de ejecución de la operación enviarArticulo.

Operación: enviarArticulo Entrada : c2 = { <1,a:=createObject(EnRevision)>, <1,addStructuralFeature(a,titulo,tit)>, <N,createLink(EsAutorDe,(a,autores[i])> }

cAux = { <1,1,a:=createObject(EnRevision)>, <1,1,addStructuralFeature(a,titulo,tit)>, <N,N,createLink(EsAutorDe,a,autores[i])> }

Iteración 1: nodo = <1,1,a:=createObject(EnRevision)> dependencias = { <1,addStructuralFeature(a,titulo,v)>, <1,createLink(EsAutorDe,a,o2)> } accionesReq = { } cAux = { <1,1,a:=createObject(EnRevision)>, <1,0,addStructuralFeature(a ,titulo,tit)>, <N,N-1,createLink(EsAutorDe,a,autores[i])> } Iteración 2: nodo = <1,0,addStructuralFeature(a,titulo,tit)> dependencias = { } accionesReq = { } cAux = { <1,1,a:=createObject(EnRevision)>, <1,0,addStructuralFeature(a ,titulo,tit)>, <N,N-1,createLink(EsAutorDe,a,autores[i])> } Iteración 3: nodo = <N,N-1,createLink(EsAutorDe,a,autores[i])> dependencias = { } accionesReq = { } cAux = { <1,1,a:=createObject(EnRevision)>, <1,0,addStructuralFeature(a ,titulo,tit)>, <N,N-1,createLink(EsAutorDe,a,autores[i])> } Salida : accionesReq = { } ejecutabilidad = true

Este camino de ejecución es ejecutable (todas las acciones requeridas se encuentran en el camino inicial) y, por consiguiente, podemos concluir que la operación enviarArticulo es débilmente ejecutable.

Tabla 4.3.2. Verificación de la ejecutabilidad débil de la operación despedir . Operación: despedir Entrada : c = { <1,destroyLink(TrabajaEn,self,self.departmento)> }

cAux = { <1,1,destroyLink(TrabajaEn,self,self.departmento)> }

Iteración 1: nodo = <1,1,destroyLink(TrabajaEn,self,self.departmento)> dependencias = { <1,createLink(TrabajaEn,self,o2)> OR <1,destroyObject(self)> } accionesReq = { <1,createLink(TrabajaEn,self,o2)> OR <1,destroyObject(self)> } cAux = { <1,1,destroyLink(TrabajaEn,self,self.departmento)> }

Salida : accionesReq = { <1,createLink(TrabajaEn,self,o2)> OR <1,destroyObject(self)> } ejecutabilidad = false

Este camino de ejecución no es ejecutable (y, por lo tanto, la operación despedir no es

ejecutable), ya que la eliminación del enlace viola la restricción de cardinalidad ‘1’ de la asociación TrabajaEn. Como indica el parámetro de salida accionesReq, añadir un enlace entre la persona y un nuevo departamento (createLink(TrabajaEn,self,d’)) o destruir la persona (destroyObject(self)) es necesario para garantizar la ejecutabilidad del camino.

6 Ésta comparación puede incluir variables abstractas (por ejemplo, cuando n es parte de un bucle). En estos

casos, la acción d.accion mapea correctamente si existe una posible instanciación de las variables abstractas que satisface la desigualdad de comparación.


ISSN 1988–3455 SISTEDES, 2008 69

5 Trabajos relacionados

Existe un amplio conjunto de propuestas de investigación dedicadas a la verificación de las especificaciones de comportamiento en UML, la mayoría de las cuales se centran en las máquinas de estado [15], [14], [18], los diagramas de secuencia [1] y la resolución de patologías en diagramas de secuencia [11], diagramas de actividad [8] o en la consistencia entre diversos diagramas [13], [5], [10], [24], [22], [23] y [6], entre muchos otros trabajos.

Sin embargo, la mayoría de los métodos anteriores verifican propiedades muy básicas y/o restringen la expresividad de los modelos UML. De hecho, la mayoría de los métodos anteriores no aceptan la especificación de AS para definir el comportamiento de las operaciones , que es precisamente el objetivo de nuestra técnica.

Otra gran diferencia de nuestra técnica es el formalismo utilizado para realizar la verificación. Para comprobar la ejecutabilidad de una operación (o, en general, cualquier propiedad que pueda expresarse con una fórmula de lógica temporal - LTL [7]) los enfoques anteriores se basan en la utilización de técnicas de model checking (MC) [12]. A grandes rasgos, las técnicas de MC generan y analizan todos los posibles estados de ejecución de una operación (considerando todos los valores posibles para los parámetros) y evalúan si cumplen una cierta propiedad. A pesar de disponer de numerosas optimizaciones, los métodos de verificación basados en MC sufren el problema de explosión de estados. Para contrarrestar este problema, las técnicas de MC trabajan sobre un dominio de valores acotado (con lo que en general no es posible explorar todas las ejecuciones posibles). Esto implica que los resultados proporcionados por estos métodos no son concluyentes, es decir, la ausencia de una solución no se puede utilizar como una prueba: una operación clasificada como no débilmente ejecutable todavía puede tener una correcta ejecución fuera del espacio de búsqueda considerado durante la verificación. Como hemos comentado, nuestro análisis es estático y, por tanto, no requiere animación, por lo cual, es más eficiente y completo.

Existe también una diferencia en el tipo de información proporcionada al diseñador cuando una propiedad no se satisface. Las propuestas basadas en MC son capaces de proporcionar un contra-ejemplo, es decir, un conjunto de valores para los parámetros que no cumple una determinada propiedad. Nuestra técnica proporciona una información más valiosa, es decir, indica cómo modificar la especificación de la operación con el fin de reparar la inconsistencia detectada.

Creemos que nuestra técnica podría ser utilizada para realizar un primer análisis de corrección básica (sin considerar los valores de los parámetros) con el fin de garantizar un mínimo nivel de calidad de las operaciones. Posteriormente, los diseñadores podrían proceder a un análisis más detallado adaptando la técnica de MC a la verificación de las operaciones especificadas en AS.

6 Conclusiones y Trabajo Futuro

Hemos presentado una técnica eficiente para verificar la ejecutabilidad de operaciones definidas imperativamente mediante el formalismo de AS, uno de los elementos clave en el contexto del MDD y los métodos de UML ejecutable.

Nuestra técnica se basa en un análisis estático de las dependencias entre las acciones incluidas en la especificación de una operación, y no requiere ningún tipo de animación del modelo durante el proceso. Además proporciona información al diseñador acerca de cómo reparar las operaciones no ejecutables. Creemos que éstas características hacen que nuestra técnica sea especialmente apropiada para ser integrada en las actuales herramientas MDD, como parte de la verificación por defecto que se aplica para ayudar al diseñador a mejorar la calidad de sus modelos.

Como trabajo futuro, planeamos extender el conjunto de acciones tratadas, aplicar ésta técnica a otros tipos de especificaciones de comportamiento UML e implementar un prototipo que permita automatizar todo el proceso. Por otra parte, nos gustaría proporcionar una traducción automática entre AS y el lenguaje de alguna herramienta popular de MC (por ejemplo, PROMELA [12]) a fin


ISSN 1988–3455 SISTEDES, 2008 70

de que, tras una primera verificación con nuestra técnica, los diseñadores puedan hacer un análisis más fino (aunque parcial) mediante técnicas de MC.

Referencias

1. Baker, P., Bristow, P., Jervis, C., King, D., Thomson, R., Mitchell, B., Burton, S.: Detecting and Resolving Semantic Pathologies in UML Sequence Diagrams. European Soft. Eng. Conf - Foundations of Soft. Eng., 50-59 (2005)

2. Bollobas, B.: Modern graph theory. Springer (2002) 3. Cabot, J., Gómez, C.: Deriving Operation Contracts from UML Class Diagrams. Int. Conf. on Model

Driven Engineering Languages and Systems, LNCS, 4735, 196-210, (2007) 4. Clarke, E. M., Grumberg, O., Jha, S., Lu, Y., Veith, H: Progress on the State Explosion Problem in Model

Checking. In informatics - 10 Years Back. 10 Years Ahead. R. Wilhelm, Ed. Springer-Verlag, 176-194 (2001)

5. Gallardo, M.M., Merino, P., Pimentel, E.: Debugging UML Designs with Model Checking. Journal of Object Technology, 1(2), 101-117 (2002)

6. Egyed, A.: Instant Consistency Checking for the UML. Int. Conf. on Soft. Eng., 381-390 (2006) 7. Emerson, E. A.: Temporal and Modal Logic. Handbook of Theoretical Computer Science, 8, 995-1072

(1990) 8. Eshuis, R.: Symbolic Model Checking of UML Activity Diagrams. ACM Transactions on Soft. Eng. and

Methodology, 15, 1-38 (2006) 9. Garousi, V., Briand, L., Labiche, Y.: Control Flow Analysis of UML 2.0 Sequence Diagrams. European

Conf. on Model Driven Architecture-Foundations and Applications, LNCS, 3748, 160-174 (2005) 10. Graw, G., Herrmann, P.: Transformation and Verification of Executable UML Models. Electronic Notes

in Theoretical Computer Science, 101, 3-24 (2004) 11. Grosu, R., Smolka, S. A.: Safety-Liveness Semantics for UML 2.0 Sequence Diagrams. Int. Conf. on

Application of Concurrency to System Design, 6-14 (2005) 12 Holzmann, G. J.: The spin model checker: Primer and reference manual. Addison-Wesley Professional

(2004) 13. Knapp, A., Wuttke, J.: Model Checking of UML 2.0 Interactions. Workshop on Critical Systems

Development using Modelling Languages, LNCS, 4364, 42-51 (2006) 14. Latella, D., Majzik, I., Massink, M.: Automatic Verification of a Behavioural Subset of UML Statechart

Diagrams using the SPIN Model-Checker. Formal Aspects of Computing, 11(6), 637-664 (1999) 15. Lilius, J., Paltor, I. P.: Formalising UML State Machines for Model Checking. Int. Conf. on the Unified

Modeling Language, LNCS, 1723, 430–445 (1999) 16. McAllister, A. J., Sharpe, D.: An Approach for Decomposing N-Ary Data Relationships. Software-

Practice & Experience, 28(1), 125-154 (1998) 17. Mellor Stephen J., Balcer Marc J.: Executable UML: A foundation for model-driven architecture.

Addison-Wesley (2002) 18. Ober, I., Graf, S., Ober, I.: Validating Timed UML Models by Simulation and Verification. Int. Journal

on Software Tools for Technology Transfer, 8(2), 128-145 (2006) 19. Object Management Group (OMG): UML 2.0 Superstructure Specification. OMG Adopted Specification

(ptc/07-11-02) (2007) 20. Object Manage ment Group (OMG): Semantics of a Foundational Subset for Executable UML Models

RFP (ad/2005-04-02) (2005) 21. Pastor, O., Gómez, J., Insfran E., Pelechano V. : The OO-Method Approach for Information Systems

Modeling: From Object-Oriented Conceptual Modeling to Automated Programming. Inf Syst, 26 507-534 (2001)

22. Rasch, H., Wehrheim, H.: Checking Consistency in UML Diagrams: Classes and State Machines. Formal Methods for Open Object-Based Distributed Systems, LNCS, 2884, 229-243 (2003)

23. Van Der Straeten, R., Mens, T., Simmonds, J., Jonckers, V.: Using Description Logic to Maintain Consistency between UML Models. Int. Conf. on the Unified Modeling Language, LNCS, 2863, 326–340 (2003)

24. Xie, F., Levin, V., Browne, J. C.: Model Checking for an Executable Subset of UML. Int. Conf. on Automated Soft. Eng, 333-336 (2001)


ISSN 1988–3455 SISTEDES, 2008 71

Uso de Modelos de Anotación para automatizar el Desarrollo

Dirigido por Modelos de Bases de Datos Objeto-Relacionales

Juan M. Vara, Verónica A. Bollati, Belén Vela, Esperanza Marcos

Grupo de Investigación Kybele

Universidad Rey Juan Carlos

Madrid (Spain) {juanmanuel.vara, veronica.bollati, belen.vela,

esperanza.marcos}@urjc.es

Resumen

Las transformaciones de modelos son la pieza clave a la hora de automatizar cualquier

propuesta de desarrollo software dirigido por modelos. Sin embargo, la definición de una

transformación de forma genérica (válida para cualquier escenario) puede no resultar

siempre lo más conveniente. Si la distancia entre el metamodelo origen y el metamodelo

destino es demasiado grande, se necesitan decisiones de diseño que guíen o dirijan la

transformación para obtener modelos lo más precisos posibles. De otro modo, habría

opciones que nunca se contemplarían a la hora de generar modelos terminales conforme al

metamodelo destino. En este trabajo se muestra cómo se ha solventado este problema a la

hora de implementar nuestra propuesta para el desarrollo dirigido por modelos de Bases de

Datos Objeto-Relacionales. La técnica utilizada se basa en el uso de modelos de weaving

como modelos de anotación para recoger decisiones de diseño y puede ser fácilmente

extendida a otros dominios y contextos.

Palabras Claves: Desarrollo de Software Dirigido por Modelos, Bases de Datos Objeto-

Relacionales, Transformaciones de Modelos, Modelos de Anotación, Modelos de Weaving

1 Introducción

Las Bases de Datos (BD) Relacionales presentan algunas limitaciones cuando se usan para dotar

de persistencia a los datos de algunos de los sistemas actuales. Las constantes mejoras del

hardware han dado lugar a aplicaciones cada vez más sofisticadas, caracterizadas por incluir

objetos y relaciones complejas entre ellos. Representar cada uno de estos objetos y sus

relaciones en el modelo relacional obliga a descomponer el objeto en varias tuplas. Así, cuando

queremos recuperar un objeto es necesario realizar un número considerable de joins, de manera

que si los objetos que se desea recuperar son demasiado complejos, el rendimiento se reduce

considerablemente [3]. Para resolver algunas de estas carencias surgió una nueva generación de

BD: las BD Orientadas a Objetos (OO), que incluyen a las BD Objeto-Relacionales (OR) [18].

Esta tecnología, basada en estándares [9], permite almacenar y recuperar datos complejos, ya

que ofrece soporte para la definición de nuevos tipos de datos y el mantenimiento de sus

relaciones, datos multimedia, herencia, etc.

Pero las mejoras tecnológicas no bastan para aprovechar las nuevas capacidades, son

necesarias metodologías que orienten a los diseñadores de BDOR en la tarea de desarrollo, tal

como se ha hecho tradicionalmente con las BD Relacionales [5]. En esta línea se presentó una

aproximación dirigida por modelos para el desarrollo de BDOR en [19]. El proceso propuesto

parte de un Modelo Independiente de Plataforma (Platform Independent Model, PIM)


ISSN 1988–3455 SISTEDES, 2008 72

representado mediante un diagrama de clases UML. Tomando éste como entrada, una

transformación modelo a modelo (M2M) genera el Modelo Específico de Plataforma (Platform

Specific Model, PSM), que representa el esquema de la BDOR. Finalmente, una nueva

transformación, ésta de modelo a texto (M2T), devuelve el script SQL que implementa el

esquema de la BDOR modelada.

A la hora de dar soporte en forma de herramienta a este proceso de desarrollo aparece un

problema recurrente: para pasar del PIM al PSM se necesitan algunas decisiones de diseño. Por

ejemplo: dado que el modelo OR de Oracle proporciona dos tipos de datos colección (Varray y

Nested Table), existen dos formas de mapear las propiedades multivaluadas de una clase del

modelo conceptual al esquema de la BDOR.

Sin embargo, de acuerdo a los principios del DSDM [17] el proceso de desarrollo debe

presentar el mayor grado de automatización posible - de hecho lo deseable sería que, una vez

elaborado el modelo de partida (PIM), el proceso fuese completamente automático. Así pues,

para poder completar la transformación, se optó inicialmente por utilizar un valor por defecto

para estas decisiones de diseño (p.e. todas las propiedades multivaluadas se mapean como

columnas de tipo Varray). No obstante, esta aproximación en la que se usa una transformación

única resulta mejorable. Para ello se necesita una transformación que tenga en cuenta cierta

información adicional o decisiones de diseño. En otras palabras, una transformación

parametrizable. Las transformaciones generícas y las transformaciones no-uniformes fueron los

primeros trabajos en esta línea [8, 21] y evidencian la necesidad de disponer de transformaciones

M2M parametrizables. En nuestra opinión, todos los artefactos que se manejan en el marco del

DSDM han de ser modelos. Por lo tanto, la información adicional, decisiones de diseño o

parámetros que controlarán la ejecución de la transformación, también deberían estar recogidos

en un modelo.

En este trabajo se muestra la implementación de nuestra propuesta para el desarrollo de

BDOR, haciendo especial hincapié en el uso de modelos de weaving [2] para recoger el conjunto

de decisiones de diseño que deben guiar la ejecución de la transformación M2M. Así, se puede

ejecutar la transformación para el caso general, o definir un modelo de weaving que sirve para

anotar el modelo origen y por tanto parametrizar la transformación. De este modo, dado un

único modelo origen, se pueden obtener distintos modelos destino sin más que modificar el

modelo de weaving definido, es decir, el valor de los parámetros.

El resto del trabajo se estructura de la siguiente forma: la sección 2 introduce los conceptos

de modelos de weaving y anotación, mientras que la sección 3 resume la propuesta para el

desarrollo de BDOR, centrándose en el uso de modelos de weaving. La sección 4 utiliza un caso

de estudio para mostrar la aplicación de la propuesta y finalmente la sección 5 resume las

principales conclusiones y plantea las líneas abiertas.

2 Conceptos Previos

Antes de presentar la automatización de nuestra propuesta para el desarrollo de BDOR, se

introducen algunos conceptos teóricos que facilitarán su entendimiento.

2.1 Modelos de Weaving

Un modelo de weaving es un tipo especial de modelo pensado para definir y representar las

relaciones entre los elementos de uno o varios modelos [2].


ISSN 1988–3455 SISTEDES, 2008 73

La Fig. 1 representa esta idea: Mw es un modelo de weaving que captura las relaciones entre

los elementos de los modelos Ma y Mb (woven models). Cada elemento de Mw define una

relación entre un conjunto de elementos de Ma y un conjunto de elementos de Mb. Por ejemplo

el elemento r2 de MW define una relación entre a2 y a3 de Ma y b1 de Mb.

En este trabajo se ha utilizado la herramienta ATLAS Model Weaver (AMW) para la

definición y gestión de modelos (y metamodelos) de weaving [7]. AMW proporciona un

metamodelo de weaving base (Core Weaving Metamodel) [6] que contiene un conjunto de clases

abstractas para representar información sobre las relaciones entre los elementos de dos modelos.

La forma típica de proceder es extender dichas clases, definiendo nuevos metamodelos para

dominios concretos.

a1

a3a2

Ma

a1

a3a2

Ma

b1

b2

Mb

b1

b2

Mb

a1

a3

a2

b1

r1

r2 b2

Weaving ModelMw

a1

a3

a2

b1

r1

r2 b2

Weaving ModelMw

Fig. 1. Vista general de un modelo de weaving

2.2 Modelos de Anotación

Los modelos pueden ser anotados o decorados para proporcionar información que no es definida

por el metamodelo. Por ejemplo, anotaciones sobre meta-información usada para el pre-

procesamiento, testeo, manejo de registros, versionado o parametrización [6].

La idea de usar modelos de anotación en el contexto de las transformaciones de modelos es

la siguiente: una transformación se compone de un conjunto de reglas. Dichas reglas codifican

las relaciones entre los elementos de los metamodelos origen y destino. Es decir, la

transformación se define a nivel de metamodelo. Por tanto, podemos usarla para generar un

modelo conforme al metamodelo destino, tomando como entrada cualquier modelo conforme al

metamodelo origen. Sin embargo, este comportamiento puede resultar demasiado genérico.

Podríamos modificarlo teniendo en cuenta algunas consideraciones adicionales en el momento

de ejecutar la transformación. Estas consideraciones pueden tomar la forma de anotaciones y

podemos recogerlas en un modelo de anotación.

Por ejemplo, suponga que se dispone de un metamodelo origen, un metamodelo destino, un

modelo terminal conforme al primero y la correspondiente transformación, que toma como

entrada el modelo origen, y opcionalmente un modelo de anotación. Entonces, para cada modelo

de anotación diferente que se utilice para ejecutar la transformación, se obtendrá un modelo

destino diferente sin cambiar el modelo origen. Esta es la aproximación que se ha seguido en

este trabajo.

3 Desarrollo automático de BDOR en el marco de MIDAS

La propuesta para el desarrollo de BDOR presentada en [19] está enmarcada en MIDAS [11],

una metodología dirigida por modelos para el desarrollo de Sistemas de Información (SI).

La propuesta se centra en el aspecto de contenido, cuyos modelos se muestran en la Fig. 2(a)

y se corresponden con el concepto tradicional de Bases de Datos (BD) en los niveles PIM y

PSM. A nivel PIM se define el modelo conceptual de datos representado a través de un diagrama


ISSN 1988–3455 SISTEDES, 2008 74

de clases UML. A nivel PSM se definen dos modelos: el modelo OR y el modelo de esquemas

XML, dependiendo de la tecnología utilizada para implementar la BD.

En cuanto a las soluciones técnicas utilizadas para soportar este proceso de desarrollo se ha

optado por utilizar ATL [10] para las transformaciones M2M y MOFScript [15] para las

transformaciones M2T. Además, se ha desarrollado un editor gráfico basado en GMF para el

modelado de esquemas de BDOR.

Como muestra la Fig. 2, este trabajo se centra en el paso del modelo conceptual de datos

(PIM) al modelo que representa el esquema de la BDOR (PSM). Como primer paso, en [19] se

realizó un estudio preliminar de las reglas de transformación. El resultado fue un conjunto de

reglas formalizadas usando gramáticas de grafos.

El siguiente paso era automatizar las reglas de transformación usando ATL. Mientras se

codificaban las reglas se comprobó que en la mayor parte de las ocasiones era necesaria

información extra para generar el modelo de salida. Esta información puede entenderse como

una manera de parametrizar la transformación. La primera opción era extender el metamodelo

para que soportara el modelado de esa información extra, y así incluirla en el modelo origen. No

obstante, esto implicaba contaminar el metamodelo con conceptos no relevantes para el dominio

que representa. Por tanto, se necesitaba una manera diferente de recoger esta información extra

que está relacionada con el modelo de entrada, pero no incluida en el mismo. Dado que esta

información extra o parámetros deberían estar disponibles en el momento de ejecutarse la

transformación y teniendo en cuenta el contexto (DSDM), se concluyó que la mejor opción era

utilizar otro modelo para recoger dicha información.

Así, se optó por utilizar el metamodelo de anotación que extiende el metamodelo de weaving

base mencionado en la sección anterior [6]. De este modo, los modelos terminales conformes al

metamodelo sirven como modelos de anotación en el momento de ejecutar la transformación. La

Fig. 2(b) describe gráficamente el proceso completo:

PIM

PS

MConceptual

Data Model

OR

Model

XML

Model

WO

RK

IN

G

CO

DE

ATL

MOFScript CREATE OR REPLACE TYPE Jefe_Proyecto AS

(Codigo_Id

NUM BER,

Nombre

VARCHAR2(30),

Telefono

NUM BER,

Dirige

REF Proyecto);

SQL

CONTENT

UML2 ORDB MetamodelAMW Core Weaving Metamodel

Conceptual Model ORDB Model

AnnotationMetamodel

Annotation Modelfor ORDB

SOURCE TARGET

SOURCE

UML2modeloOR.atl

Extends

c2 c2c2

Fig. 2. a) Dimensión del contenido en MIDAS y

b) Uso de modelos de weaving para el DDM de BDOR

Para cada ejecución de la transformación ATL, es decir, para cada modelo origen, se define

un modelo de weaving conforme al metamodelo de anotación. Dicho modelo contiene un

conjunto de anotaciones que representa la información necesaria para ejecutar la transformación,

esto es, los parámetros usados por algunas de las reglas ATL cuando son ejecutadas. Por tanto,

el modelo destino se genera a partir del modelo origen y el modelo de weaving. De este modo,

dado un modelo conceptual de datos (PIM), se pueden obtener diferentes esquemas de BDOR

(PSM) dependiendo del modelo de weaving (modelo de anotación) utilizado.


ISSN 1988–3455 SISTEDES, 2008 75

3.1 Metamodelos utilizados para pasar del Modelo Conceptual al Modelo de la BDOR

Tal y como muestra la Fig. 2(b), se utilizan tres metamodelos diferentes para el paso de modelos

conceptuales a modelos de BDOR: el metamodelo de UML2, el metamodelo para el modelado

de BDOR y el metamodelo de anotación que, como se ha dicho anteriormente, es una extensión

del metamodelo de weaving base. Dado que el metamodelo de UML es de sobra conocido, nos

limitaremos a introducir brevemente los otros dos.

Conviene realizar una aclaración previa: el primer paso hacia la definición de una

aproximación dirigida por modelos para el desarrollo de BDOR fue definir sendos perfiles UML

para el modelado de BDOR [12] (uno para el estándar y otro para el producto, Oracle 10g [16]).

No obstante, en el momento de implementar la propuesta existía una segunda aproximación para

la definición de lenguajes de modelado: la definición de nuevos lenguajes basados en MOF

(Domain Specific Languages, DSLs [13]).

Esta segunda aproximación ha gozado de gran aceptación gracias a las facilidades

proporcionadas por el EMP y otros frameworks para el trabajo con DSLs, como el Generic

Modeling Environment (GME) o las DSL Tools [4]. De hecho, metodologías contrastadas, que

inicialmente se basaban en el uso de perfiles UML y herramientas ad-hoc, como WebML y su

herramienta WebRatio [1], están siendo actualizadas y/o redefinidas para utilizar lenguajes

basados en MOF e integrarse en los frameworks mencionados. En teoría, la apuesta por

lenguajes basados en MOF resulta en una pérdida de interoperabilidad, pues obliga a desarrollar

nuevas transformaciones de modelos cuando se quiere cambiar el DSL utilizado para modelar el

SI. En la práctica, el mismo problema subyace cuando se usan perfiles UML, pues a día de hoy

la interoperabilidad prometida por XMI sigue sin materializarse por completo.

Por todo ello, teniendo en cuenta la tecnología existente, parecía más acertado definir dos

nuevos metamodelos basados en MOF para expresar los conceptos relacionados con el

modelado de BDOR, uno para el estándar y otro para el producto Oracle 10g. En este trabajo

sólo nos referiremos al del producto, que es el que a día de hoy se ha utilizado para implementar

la transformación del modelo conceptual al esquema de la BDOR.

Metamodelo para el modelado de BDOR. La Fig. 2 muestra el metamodelo para el producto

Oracle10g. El diagrama sólo representa aquellos conceptos relacionados con la OO del

modelo OR, es decir, los artefactos correspondientes al modelo relacional no se incluyen.

-Name : string

Model Restriction

-Name : String

Table

«fk»Foreign Key

«pk»Primary Key

«unique»Unique

«not null»Not Null

Datatype

-Name : String

«nt»Nested Table Type

-Name : String

Basic Data Type

-Name : String

«ref»Reference Type

-Name : String

«udt»Structured Type

-

«persistent»Typed Table

-Name : String-NumElements : Integer

«array»Varray

-Name : String

Stored Nested Table

-Name : String-size : Integer

Attribute

-Name : String

«method»Method

Primitive Type

-unidad : Char

LOB Type

1..1

0..*

1..1

0..*

1..1

0..*

0..* 1..1 0..*1 0..*1..1

1..1

1..1

1..1

0..*

0..*

1..*

0..*

0..1

overrides

supertype

0..* 1..1

0..*

1..1

1..*

0..1

0..*0..*

0..*

1..*

Fig. 3. Metamodelo para el modelado de BDOR en Oracle 10g


ISSN 1988–3455 SISTEDES, 2008 76

Los nuevos tipos incluyen tipos colección (Varray y Nested Table), tipos referencia (REF) y

tipos estructurados o definidos por el usuario (UDT). Un tipo estructurado puede contener

atributos y métodos y, finalmente, una tabla tipada está basada en un tipo estructurado. (para

más detalles véase [12]).

Metamodelo de Anotación. La Fig. 4 muestra el metamodelo de anotación utilizado junto al

metamodelo de weaving base [6]. Un modelo de anotación (AnnotationModel) incluye una

referencia al modelo anotado (AnnotatedModel) y varias anotaciones (objetos annotation). Cada

anotación se refiere a un elemento del modelo anotado (AnnotatedModelElement) y contiene una

lista de propiedades (property). Finalmente, cada propiedad tiene un identificador (key) y un

valor (value). Es decir, cada anotación no es más que un par clave-valor.

WModel

WModelRef

WLink

WLinkEnd

-name : String-description : String

WElement

-ownedElement 1

-model

1..*

ref : StringWRef

WElementRef

modelRef

*

child

parent

end

1-* link

element

AnnotationModelAnnotatedModel contents

*

AnnotationreferencedModel

1

AnnotatedModelElementannotatedModelElement

0..1

1

1 1

KeyValue

Property

*

properties 1

Core Weaving MetamodelownedElementRef

1 - *

wovenModel

Fig. 4. Metamodelo de Anotación

3.2 Del modelo conceptual al esquema de la BD: decisiones de diseño

Una vez presentados los metamodelos, se resumen las principales decisiones de diseño que se

pueden tomar a la hora de pasar del modelo conceptual al modelo que representa el esquema de

la BDOR:

Atributos Multivaluados: se mapean al esquema de la BDOR incluyendo un atributo o

columna de tipo colección en el tipo de datos que mapea la clase. Dado que Oracle soporta

dos tipos de datos colección, el diseñador puede elegir cuál prefiere para cada atributo: usar

una Nested Table (NT) o un Varray. Por defecto, la transformación ATL utilizará el tipo NT,

pero el diseñador puede modificar este comportamiento añadiendo una anotación al atributo.

Esto es, incluyendo un objeto annotation (key = DataType, value = Varray) en el modelo de

weaving, que apunte al atributo del modelo conceptual.

Extremos de asociaciones de cardinalidad N: sea una asociación A ↔ B de cardinalidad

N:M y sean T_A y T_B los tipos de datos que mapean las clases A y B al esquema de la

BDOR. Para mapear los dos extremos de la asociación se añade una columna de tipo

colección en T_A y otra en T_B. La primera será de referencias a T_B y la segunda de

referencias a T_A. Se puede elegir un tipo colección diferente para cada uno de los extremos

de la asociación sin más que añadir una anotación similar a la que se describía en el punto

anterior.

Tamaño de tipos colección: el tipo NT es de tamaño indefinido (se pueden agregar elementos

dinámicamente), pero el tipo Varray es de tamaño predefinido. Por defecto, todos los objetos


ISSN 1988–3455 SISTEDES, 2008 77

de tipo Varray que se incluyan en el modelo de la BDOR serán de tamaño 1000. No obstante,

si el diseñador optó por usar un Varray para mapear un atributo multivaluado o el extremo de

una asociación de cardinalidad N, puede añadir una anotación (key = Size, value = X) para

especificar que el tamaño del Varray es X.

Jerarquías: finalmente, hay dos formas de mapear jerarquías de clases del modelo conceptual

al esquema de la BDOR: incluir un único tipo de datos que recoja los atributos de la clase

padre y todos los de las clases hijas y utilizarlo para definir una única tabla tipada; o incluir un

tipo de dato y una tabla tipada por cada clase de la jerarquía (comportamiento por defecto).

Para utilizar la primera opción hay que añadir una anotación (key = Hierarchy, value = Table)

a la clase raíz de la jerarquía.

4 Caso de Estudio

Esta sección utiliza un caso de estudio para mostrar el uso de modelos de weaving en el proceso

propuesto para el desarrollo de BDOR. La BD del caso de estudio está diseñada para almacenar

la información relacionada con la gestión de los proyectos de un despacho de arquitectura. A

continuación se mostrará cómo el uso de anotaciones a modo de decisiones de diseño controla la

forma en que las reglas de transformación ATL generan ciertas partes del modelo de la BDOR a

partir del modelo conceptual de datos.

Nótese que, una vez definido el modelo conceptual, el resto del proceso es automático. De

hecho, se podría prescindir del modelo de weaving que sirve para anotar el modelo conceptual,

ya que las reglas ATL se han codificado de manera que, en ausencia de anotaciones, presenten

un comportamiento por defecto. No obstante, de cara a mejorar el proceso de desarrollo

propuesto, se ha utilizado GMF para construir un editor gráfico para modelos de BDOR. De esta

forma el diseñador puede refinar y/o modificar el modelo que representa el esquema de la

BDOR antes de lanzar la generación de código

4.1 Modelo Conceptual

La Fig. 5 muestra el modelo conceptual para el caso de estudio.

Fig. 5. Modelo conceptual de datos para el caso de estudio


ISSN 1988–3455 SISTEDES, 2008 78

Cada proyecto tiene un jefe de proyecto y está compuesto por un conjunto de planos. Cada

plano contiene varias figuras y cada figura puede ser o no un polígono, en cuyo caso estaría

compuesto de líneas

La figura es una captura de pantalla de UML2, una implementación basada en EMF del

metamodelo de UML para Eclipse. En general UML2 es la herramienta utilizada como editor

gráfico siempre que es preciso definir un diagrama de clases en el marco de MIDAS.

4.2 Modelo de Anotación

La Fig. 6 muestra el modelo de weaving utilizado como modelo de anotación para el caso de

estudio. Nótese cómo se ha añadido una anotación referente a la propiedad multivaluada

Architects de la clase Plan. La anotación incluye dos propiedades: una para indicar que se desea

usar un tipo Varray para mapear el atributo (key = DataType, value = Varray) y otra para indicar

el tamaño del Varray (key = Size, value = 100).

Fig. 6. Vista parcial del modelo de weaving para el caso de estudio.

4.3 Uso de anotaciones para parametrizar la transformación

La siguiente sección muestra brevemente cómo se procesan las anotaciones en el código ATL

que implementa la transformación parametrizada. A modo de ejemplo, se mostrará cómo se

utiliza la información que proporciona el modelo de anotación para dirigir el mapeo de atributos

multivaluados.

Para ello se codifican una serie de funciones auxiliares o helpers y se definen dos

reglas: una para mapear el atributo con un tipo Varray y otra para hacerlo con un tipo NT.

rule PropertyMultivalued2NTAttribute {from

p :UML!Property (not p.isDerived and p.isMultivalued() and p.refImmediateComposite().oclIsTypeOf(UML!Class)and p.mapTo() ='NT')

toa : modeloOR!Attribute ( … … ),st : modeloOR!StoredNestedTable (… …))

}

rule PropertyMultivalued2VArrayAttribute {from

p :UML!Property (not p.isDerived and p.isMultivalued()and p.refImmediateComposite().oclIsTypeOf(UML!Class) and p.mapTo() ='VARRAY')

toa : modeloOR!Attribute ( … )

}

Fig. 7. Parte de las reglas para la transformación de atributos o propiedades multivaluadas


ISSN 1988–3455 SISTEDES, 2008 79

La Fig. 7 muestra la declaración de estas reglas. La condición de guarda de ambas reglas

comprueba cuál ha sido la decisión del diseñador mediante una llamada al helper mapTo

El código de esta función se muestra a continuación. La función invoca a su vez a otras dos

funciones: getLink(), que recorre el modelo de weaving para devolver el objeto Annotation

asociado a la propiedad, y getAnnotationValue(), que recupera el valor de la propiedad

DataType incluida en la anotación.

-- It says whether the ‘self’ multivalued property should be mapped to an NT or a VARRAY attributehelper context UML!Property def: mapTo() : String =

if self.getLink().oclIsUndefined() then 'NT'

elseif self.getLink().getAnnotationValue('DataType') = 'NT' then

'NT'else

'VARRAY'endif

endif;

Fig. 8. Función o Helper mapTo()

5 Conclusiones y Trabajos Futuros

En [19] se completó la definición de una propuesta para el desarrollo dirigido por modelos de

BDOR. Sólo restaba automatizarla para aprovechar las ventajas de aplicar los principios del

DSDM al desarrollo de BDOR. Para ello se ha definido un nuevo metamodelo para el modelado

de BDOR a partir del perfil UML presentado en [12], se han codificado las transformaciones

M2M y M2T definidas como parte del proceso propuesto y se ha construido un editor gráfico

para modelos de BDOR.

Este trabajo se ha centrado en una de estas tareas: la transformación del modelo conceptual

de datos al modelo de la BDOR. Aunque inicialmente se codificó una transformación estándar,

una vez que se comenzó a validar la transformación usándola en diferentes casos de estudio, se

detectó un problema recurrente: si se querían contemplar todas las opciones posibles para

generar el esquema de la BDOR, era necesario contemplar ciertas decisiones de diseño a la hora

de ejecutar la transformación.

Este trabajo ha mostrado cómo se solventó este problema utilizando modelos de weaving a

modo de modelos de anotación. De esta manera se dispone de transformaciones M2M

parametrizables, sin perder el carácter genérico de las transformaciones y sin contaminar el

modelo origen con información que no es propia del dominio que representa. Además, el uso de

modelos como contenedores para las anotaciones permite mantener un repositorio de

información con las decisiones de diseño que han guiado el proceso de desarrollo.

Esta aproximación aumenta la precisión de los modelos utilizados en las distintas etapas del

desarrollo, y por tanto, del código generado a partir de ellos. La técnica utilizada es fácilmente

generalizable y aplicable a otros dominios o contextos y podría considerarse sencilla o compleja

en función del punto de vista. En nuestra opinión resulta una solución muy potente dados los

beneficios que aporta: la posibilidad de introducir decisiones de diseño, sin disminuir el grado de

automatización del proceso de desarrollo, hacen realidad muchas de las promesas del DSDM.

De cara al futuro este trabajo plantea varias líneas: por un lado, se planea soportar tareas de

ingeniería inversa a partir de esquemas de BDOR. Para ello, se están estudiando algunas

posibilidades que permitirían, no sólo generar el código SQL a partir de un modelo, sino

también parsear un script SQL para obtener el modelo correspondiente. Por otro lado, ya se está

trabajando para utilizar esta técnica en el resto de transformaciones M2M de M2DAT (MIDAS


ISSN 1988–3455 SISTEDES, 2008 80

MDA Tool), la herramienta que da soporte a la metodología MIDAS [20]. En ese sentido, este

trabajo ha servido como una primera toma de contacto y ha proporcionado un conjunto de

lecciones aprendidas sobre el uso de modelos de weaving como modelos de anotación que

resultarán muy útiles para desarrollos futuros.

Agradecimientos

Este trabajo se ha realizado en el marco del proyecto GOLD, financiado por el Ministerio

Español de Educación y Ciencia (TIN2005-00010/) y el proyecto M-DOS (URJC-CM-2007-

CET-1607) cofinanciado por la Universidad Rey Juan Carlos y la Comunidad de Madrid.

Referencias 1. Acerbis, R., Bongio, A., Brambilla, M. y Butti, S., WebRatio 5: An Eclipse-Based CASE Tool for

Engineering Web Applications, in Web Engineering, 2007, 501-505.

2. Bernstein, P A. Applying Model Management to Classical Meta Data Problems. First Biennial

Conference on Innovative Data Systems Research, Asilomar, CA, USA. 2003.

3. Bertino, E. y Marcos, E. Object Oriented Database Systems. In: Advanced Databases: Technology

and Design, O. Díaz y M. Piattini (Eds.). Artech House, 2000

4. Bézivin, J. Some Lessons Learnt in the Building of a Model Engineering Platform. 4th Workshop in

Software Model Engineering (WISME), Montego Bay, Jamaica (2005)

5. Chen, P.P. The Entity-Relationship Model – Toward a Unified View of Data. ACM Transactions on

Database Systems, Vol. 1, No. 1. March 1976, pp. 9-36, 1976.

6. Didonet Del Fabro, M.: Metadata management using model weaving and model transformation. Ph.D.

Tesis Universidad de Nantes (2007).

7. Didonet Del Fabro, M., Bézivin, J. y Valduriez P. Weaving Models with the Eclipse AMW plugin.

Eclipse Modeling Symposium, Eclipse Summit Europe, Esslingen, Alemania. 2006.

8. Gerber, A., Lawley, M., Raymond, K., Steel, J., Wood, A.: Transformation: The Missing Link of

MDA. International conference on Graph Transformation (2002) 90-105.

9. ISO / IEC 9075 Standard, Information Technology – Database Languages – SQL:2003, International

Organization for Standardization, 2003.

10. Jouault, F. y Kurtev, I. Transforming Models with ATL. En: Proc. of the Model Transformations in

Practice Workshop. MoDELS Conference, Jamaica. 2005.

11. Marcos, E. Vela, B., Cáceres, P. y Cavero, J.M. MIDAS/DB: a Methodological Framework for Web

Database Design. DASWIS 2001. Yokohama (Japan), Noviembre, 2001. LNCS 2465, Springer-

Verlag, pp. 227-238, Septiembre, 2002.

12. Marcos, E., Vela, B. y Cavero, J.M. Extending UML for Object-Relational Database Design. Fourth

Int. Conference on the Unified Modeling Language, UML 2001. Toronto (Canada), LNCS 2185,

Springer-Verlag, pp. 225-239. Octubre, 2001.

13. Marjan, M., Jan, H. y Anthony, M.S.: When and how to develop domain-specific languages. ACM

Comput. Surv. 37 (2005) pp. 316-344.

14. Microsoft SQL Server. http://www.microsoft.org/sql/.

15. Oldevik, J., Neple, T., Grønmo, R., Aagedal, J. y Berre, A.-J.: Toward Standardised Model to Text

Transformations. Model-driven Architecture – Foundations and Applications, pp. 239-253, 2005.

16. Oracle Corporation. Oracle Database 10g. Release 2 (10.2). In: www.oracle.com.

17. Selic, B. The pragmatics of Model-Driven development, IEEE Software, Vol. 20, 5, Sept.-Oct. 2003.

18. Stonebraker, M. y Brown, P., Object-Relational DBMSs. Tracking the Next Great Wave. Morgan

Kauffman, 1999.

19. Vara, J.M., Vela, B., Cavero, J.M., Marcos, E.: Model transformation for object-relational database

development. SAC '07: Proceedings of the 2007 ACM symposium on Applied computing, pp.1012-

1019, 2007.

20. Vara, J.M., De Castro, V. y Marcos, E. WSDL automatic generation from UML models in a MDA

framework In International Journal of Web Services Practices. Volume 1 – Issue 1 & 2. Noviembre

2005, pp.1 – 12. 2005.

21. Varró, D., Pataricza, A.: Generic and Meta-Transformations for Model Transformation Engineering.

UML 2004. 7th International Conference, Vol. 3273. Springer (2004) 290-304.


ISSN 1988–3455 SISTEDES, 2008 81

http://www.microsoft.org/sql/

http://www.oracle.com/

Una Aproximacion MDA para Modelar Transacciones

de Negocio a Nivel CIM

Jose Bocanegra1, Joaquın Pena2, y Antonio Ruiz-Cortes2

1 Facultad de Ingenierıa, Universidad de la AmazoniaFlorencia-Colombia

[email protected] Departamento de Lenguajes y Sistemas Informaticos, Universidad de Sevilla

Sevilla-Espana{joaquinp, aruiz}@us.es

Resumen. Con la globalizacion de los mercados, las transacciones de negocio estanadquiriendo una importancia significativa porque permiten tener una vision abstractade las interacciones que tienen lugar entre las distintas organizaciones que colaboranpara el cumplimiento de sus objetivos de negocio. Esto ha permitido el desarrollo denumerosos trabajos de investigacion que tratan de modelar de una u otra forma lastransacciones de negocio. No obstante, ninguno de estos trabajos toma como referenciamodelos a nivel CIM que esten enfocados a observar la interaccion entre empresasdesde el punto de vista de los gestores de las mismas.Por otra parte, M. Papazoglou propone un modelo que aglutina toda la informacionrelevante para este tipo de interacciones llamado Business Transaction Model (BTM )cuyas caracterısticas lo hacen ser optimo para el nivel CIM. Sin embargo, el autorno propone una notacion grafica de este modelo. Ademas, el modelo no presenta larigurosidad necesaria para una implementacion basada en MDA/MDD.En este artıculo proponemos un metamodelo adaptado a MDA/MDD y una notacionbasada en Colaboraciones UML2 con pequenas extensiones para la instanciacion delmodelo BTM y desarrollamos una transformacion MDD que permite mapear algunascaracterısticas de BTM a procesos de negocio usando notacion BPMN y viceversa.

Palabras clave: Transacciones de Negocio, MDD, Servicios Web.

1. Introduccion

El panorama economico actual hace que las empresas tengan que ser altamente compe-titivas y necesiten implantar y actualizar continuamente sus procesos de produccion. Estecontexto obliga a las empresas a hacer un uso extensivo de la tecnologıa de la informacionpara poder soportar sus propios procesos de negocio y agilizar las complejas interaccionesque se dan con sus socios comerciales. M. Papazoglou ha denominado a estas interaccionescomo transacciones de negocio [5] definiendolas como sigue:

Una transaccion de negocio es una interaccion entre multiples participantes, que buscan

cumplir un objetivo de negocio. Las transacciones se extienden por largos perıodos de tiempo

y finalizan cuando se cumplen con exito las condiciones convenidas.Las transacciones de negocio, ademas de modelar la interaccion entre dos o mas negocios,

tambien muestran informacion de alto nivel orientada a los gestores empresariales. Esto haceque presenten informacion complementaria a la que se suele usar en los modelos CIM enareas de investigacion como los procesos de negocio o la interaccion entre empresas graciasa Servicios Web compuestos.

Concretamente, en [5], M. Papazoglou propone un modelo llamado Business Transaction

Model (nos referiremos a el como BTM ). En BTM, el autor, ademas del proceso de negocio,


ISSN 1988–3455 SISTEDES, 2008 82

incluye cinco elementos adicionales para dotar de mas expresividad al modelo CIM: (i) laspartes y los roles, (ii) las restricciones e invariantes, (iii) los documentos, (iv) funcionesde negocio predefinidas y (v) un conjunto de atributos y relaciones. Una explicacion masdetallada de esta propuesta puede verse en la Seccion 2.

Con el fin de aclarar las diferencias entre los modelos CIM mas extendidos y el propuestopor Papazoglou vamos a presentar un ejemplo tıpico de una transaccion de negocio. En laFigura 1 puede verse el flujo de informacion y bienes que se origina entre una agencia de viajesy una aerolınea cuando un viajero decide adquirir un plan turıstico. La figura esta elaboradausando la notacion BPMN (Business Process Modeling Notation).

Fig. 1. Proceso de negocio en BPMN

Como podemos ver en la Figura 1, en este tipo de modelo es posible visualizar las acti-vidades, el orden en el cual se realizan y los actores que participan. Por ejemplo, podemosver que el rol Viajero realiza la actividad Buscar Viaje para despues pasarle el control alrol Agencia de Viajes. En un proceso de negocio tambien podemos observar los documentosintercambiados y los mensajes que se originan. Por ejemplo, el Viajero suministra la infor-macion del itinerario a la Agencia de Viajes. Sin embargo, los elementos fundamentales parauna transaccion de negocio definidos por Papazoglou, como son las restricciones legales, lascondiciones economicas o los perfiles de los roles que llevan a cabo cada parte en la transac-cion no son tenidos en cuenta. En la Tabla 1 podemos ver un ejemplo de una transaccionde negocio que complementa el proceso de negocio de este mismo ejemplo. De este modo,podemos observar la restriccion que limita al rol Aerolınea, en este caso, que sea de bajocosto. Ası mismo podemos observar las operaciones de negocio que debe estar en capacidadde proveer el rol Agencia de Viajes : buscar plan y entregar plan.

Elemento Descripcion

Transaccion de negocio Proveer un plan de viaje

Roles Aerolınea, Viajero y Agencia de Viajes

Restricciones Solo se contrata con aerolıneas de bajo costo

Documentos Itinerario de viaje, billetes

Operaciones de negocio: rol Agencia de Viajes Buscar plan y entregar planTabla 1. Ejemplo textual de una transaccion de negocio basada en el modelo BTM

Aunque el modelo BTM avanza el estado del arte mejorando los modelos usados a nivelCIM, el autor no entra en detalle en varios aspectos importantes: (i) no propone una notaciongrafica para la instanciacion del metamodelo, (ii) no muestra la correlacion que existe entrelos procesos de negocio (tenidos en cuenta en el metamodelo) y los modelos de transaccion,


ISSN 1988–3455 SISTEDES, 2008 83

(iii) el metamodelo presenta algunas deficiencias al no haber sido probado en un entornode implementacion, y (iv) no define transformaciones MDA/MDD del modelo CIM a otrosmodelos PIM o PSM, sino que sugiere, sin entrar en detalle, algunas posibles correlacionescon estandares WS-*. Con respecto al resto de propuestas estudiadas para el modelado anivel CIM de este tipo de transacciones, estas solo han centrado sus esfuerzos en modelarunicamente los procesos de negocio, dejando de lado informacion importante que debe estarrepresentada en un modelo de transacciones, p.e. [3], [9], [1].

Estos problemas, nos motivan a complementar la propuesta de Papazoglou para modelosCIM y su correlacion con el proceso de implementacion haciendo uso de una aproximacionMDD. Por tal razon, en este artıculo presentamos las siguientes aportaciones:

Proporcionamos un metamodelo adaptado a MDA/MDD y una notacion basada enColaboraciones UML2 con pequenas extensiones para la instanciacion del modelo BTM

(Seccion 3). En esta seccion y a raız del descubrimiento de algunas deficiencias en elmetamodelo de BTM, hemos realizado algunas mejoras/adaptaciones del mismo.Desarrollamos una transformacion MDD que permite mapear algunas caracterısticasestaticas de un modelo BTM basado en colaboraciones UML2 a procesos de negociousando notacion BPMN y viceversa. Esto nos permite mantener ambas vistas de unatransaccion coherentes entre sı (Seccion 4).Para la validacion tanto del modelado como de la transformacion hemos desarrolladoun prototipo que presentamos en la Seccion 5, usando los lenguajes de transformacionATL, MoF script y la herramienta Eclipse GMF.

2. Trabajo relacionado

En esta seccion hacemos un analisis de las propuestas que han tratado el tema de mo-delado de transacciones de negocio. El resumen de este analisis puede verse en la Tabla2.

Caracterıstica ElementoPropuestas

[5] [3] [9] [1] Nuestra propuesta

Partes y roles√ ∼ - -

√

Restricciones e invariantes√

- - -√

Objetos√

- ∼ -√

Modelo CIM Funciones de negocio√

- ∼ -√

Procesos de negocio√ √ ∼ √ √

Atributos√

- - -√

Notacion grafica - - - -√

Transformaciones Modelo estatico a dinamico - - - -√

Tabla 2. Comparativa de propuestas

2.1. Modelos CIM para transacciones de negocio

Como referencia para determinar cual es la informacion que debe estar disponible enun modelo CIM para una transaccion de negocio, hemos tomado la propuesta que hace M.Papazoglou en [5]. La Figura 2, representa el metamodelo UML de la propuesta, donde cadapaquete hace referencia a un bloque:


ISSN 1988–3455 SISTEDES, 2008 84

La parte o partes que interactuan en la transaccion y los roles que juegan cada una(Paquete 1). Ej: Aerolınea, Viajero y Agencia de Viajes.Restricciones e invariantes que se pueden resumir como reglas y condicionantes que seaceptan de comun acuerdo entre las partes (Paquete 2). Ej: la parte que juegue el rolAerolınea debe ser exclusivamente de bajo costo.Los documentos usados en la transaccion (Paquete 3). Ej: el itinerario de viaje suminis-trado por el Viajero.Un conjunto de funciones de negocio predefinidas. Una funcion de negocio es una des-cripcion de principios de negocio claramente definidos (Paquete 4). Ej: una funcionpredefinida para ordenar un billete aereo.Los procesos que se ejecutan en la interaccion (Paquete 5).Las funciones de negocio y un conjunto de atributos y relaciones (Paquete 6). Ej: buscarplan, entregar plan.

Fig. 2. Metamodelo BTM representado mediante notacion UML

No obstante, y a pesar de ser una de las aproximaciones mas completas, el autor no propo-ne una notacion grafica para la instanciacion del modelo. Esta situacion genera dificultadespara el procesamiento automatico del mismo. Adicionalmente, existen otras deficiencias quedeben ser subsanadas, entre ellas el hecho de que en el metamodelo no se establecen losatributos de las clases, por ejemplo, para determinar la informacion asociada a un rol y laexistencia de relaciones duplicadas entre dos clases, por ejemplo, entre la clase Business-

Transaction y la clase Party. Por tal razon se hace necesaria una extension de este modelocon el fin de dar soporte para la aplicacion de tecnicas MDA.

Otras propuestas, como la presentada en [9], ademas del proceso de negocio cubre as-pectos como los servicios y la informacion. Desafortunadamente, los modelos propuestosestan ubicados a nivel PIM, es decir, orientados mas hacia la construccion del software quehacia los directivos de las organizaciones. Como podemos observar en la Tabla 2, las demaspropuestas estudiadas solo se limitan a modelar el proceso de negocio.


ISSN 1988–3455 SISTEDES, 2008 85

2.2. Transformaciones

La propuesta de Papazoglou solo se limita a mencionar un conjunto de estandares WS-*que pueden dar soporte para la ejecucion de la transaccion. Desafortunadamente no existendetalles sobre el mapeo entre el modelo y los estandares.

En [3], Lopez et al. proponen una division de la transaccion de negocio en diferentesniveles: CIM, PIM y PSM. En esta propuesta ya se menciona el tema de MDD, y de comoeste puede ayudar en el proceso de transformacion entre niveles. La propuesta plantea unconjunto de transformaciones MDD ası: de PIM a PSM, de PIM a PIM y de PSM a PSM. Elmodelo de datos mapea a un modelo OR/XML schema. El modelo de navegacion se mapea aun modelo XML/HTML. Los modelos de casos de uso de la transaccion se mapean a modelosWSDL/BPEL. Desafortunadamente, esta propuesta no proporciona transformaciones entreel modelo CIM y PIM, ni transformaciones entre los modelos PSM y texto.

En [1], Ibrahim et al. proponen tres niveles de division de la transaccion: organizacional,de negocios y tecnico. Aunque la propuesta no menciona elementos de MDD, podemosasumir que los tres niveles de la transaccion pueden ser considerados como los tres nivelespropuestos por MDD: organizacional a nivel de CIM, de negocios a nivel PIM y tecnico anivel PSM.

Sin embargo, como se observa en la tabla, no hemos encontrado ninguna propuesta queproponga transformaciones CIM2CIM para mantener la correlacion entre una vista dinami-ca, por ejemplo BPMN, y una vista estatica, por ejemplo Casos de Uso o colaboracionesUML, como es nuestro caso.

Esto nos permite afirmar que la transformacion propuesta supone un avance respecto delestado del arte actual.

3. Propuesta de Modelado para BTM

Como se menciono en la seccion anterior, hemos tomado como referencia para el mode-lado de transacciones de negocio la propuesta de Papazoglou. Aunque el autor no sugiereuna notacion grafica para instanciar el modelo, optamos por usar modelos de colaboracionUML2. Esta decision esta motivada porque en el campo de los agentes software, que orga-nizan los agentes imitando las organizaciones de personas, uno de los elementos utilizadospara modelar organizaciones de agentes y sus interacciones son las colaboraciones [6]. Encontraposicion, otras notaciones como las basadas en casos de uso no permiten especificarla informacion necesaria sin realizar cuantiosas extensiones, lo que motiva de nuevo el usode colaboraciones como modelos base para la extension.

3.1. Extensiones/modificaciones realizadas al modelo BTM y lascolaboraciones UML2

Notese que la inclusion de la notacion nos ha motivado a realizar algunas modificacionesal metamodelo original [6]. Estas modificaciones han requerido:

Incluir una clase denominada Organization. Esto permite agrupar los roles/actores pororganizaciones y de esta forma, al momento de hacer el mapping a BPMN poder te-ner una Pool por cada organizacion. Ademas, complementa BTM proporcionando unainformacion que es relevante para los modelos CIM.Incluir dos tipos de Business Objects (In y Out) para detallar si un artefacto es de en-trada o salida. Esto permite establecer el orden de ejecucion de las actividades. Como seobserva, complementamos BTM anadiendo informacion de que productos / documentos/ servicios son necesarios para una transaccion y que productos / documentos / serviciosson producidos


ISSN 1988–3455 SISTEDES, 2008 86

Con relacion a las colaboraciones UML, hemos realizado un conjunto de transformacionesbasadas en trabajos anteriores de uno de los autores [6,7,8]. Las extensiones propuestas sonlas siguientes:

Dividir los ıconos de colaboracion en tres compartimientos para incluir la siguiente in-formacion: (i) el tipo de colaboracion (transaccion o actividad), (ii) el nombre de latransaccion o de la actividad, y (iii) los documentos manejados, tanto de entrada comode salida.Dividir los CollaborationsRoles en tres compartimientos para incluir la siguiente infor-macion: (i) el nombre del rol, (ii) los documentos manejados, y (iii) las funciones denegocio o capacidades que ofrece el role en la transaccion.

3.2. Notacion para modelos estaticos de BTM

La siguiente es la notacion que hemos usado para la instanciacion de modelo:

Una transaccion de negocio (BusinessTransaction) se representa mediante una colabo-racion UML2 que presenta una notacion grafica en forma de elipse punteada dividida entres compartimientos. En el primer compartimiento ubicamos el nombre de la transac-cion, en el segundo una descripcion, y en el tercero, los documentos asociados a esatransaccion.Los roles (Role) son representados usando CollaborationsRoles de UML2. En los Colla-

borationsRoles incluimos la siguiente informacion: (i) el nombre del rol, (ii) los docu-mentos/productos manejados de entrada y salida y (iii) las operaciones ejecutadas.Las restricciones de negocio (BusinessConstraints) son representadas mediante una ex-presion dentro de corchetes y ubicada en una nota textual unida con el ıcono de colabo-racion.Los objetos de negocio (BusinessObjects) se representan mediante compartimientos tantoen los roles como en la transaccion de negocio. Tambien adjuntamos un modelo de clasesa la colaboracion que representa las relaciones entre los objetos de negocio involucradosen la transaccion. Esto nos permite representar las primitivas de negocio referenciales(dependencias entre objetos) como dependencias UML y las descriptivas (posibles valorespara un objeto de negocio) como posibles valores de un enumerado UML.Las operaciones de negocio (BusinessOperations) son representadas como metodos enlos roles.Las funciones de negocio (BusinessFunctions), es decir, transacciones de negocio pordefecto, son representadas mediante un modelo de colaboracion parametrizado.Las actividades (Activity) son representadas mediante los ıconos de colaboracion en loscuales se descompone una colaboracion de mayor nivel de abstraccion.Las primitivas de negocio (BusinessPrimitive) estan divididas en dos tipos: por unaparte, las primitivas de tipo referencial (Referential) se representan como dependenciasUML entre clases; por otra parte, las primitivas de tipo descriptivas (Descriptive) serepresentan mediante enums de UML.

La Figura 3 representa una transaccion de negocio usando la notacion propuesta. Elobjetivo de la transaccion es Proveer un plan de viaje de acuerdo a las exigencias del Viajero.Esta transaccion de negocio esta regida por una restriccion, la cual establece que la lıneaaerea que suministre el servicio de transporte debe ser exclusivamente de bajo costo.

En la transaccion participan tres roles: la Aerolınea, el Viajero y la Agencia de Viajes.Como puede observarse, las partes (Party) no se representan en el modelo, porque esto solopodrıa hacerse cuando se defina quien va a jugar cada uno de los roles. Por ejemplo, la partedenominada Vueling puede jugar el rol Aerolınea.


ISSN 1988–3455 SISTEDES, 2008 87

Las funciones de negocio (BusinessFunctions) son transacciones de negocio predefinidaspara ordenes, pagos, transporte y entrega. UML2 proporciona modelos para parametrizarlas colaboraciones. Aunque por razones de espacio no podemos mostrar estos modelos, sonlos que proponemos usar para definir transacciones parametrizadas que despues pueden serinstanciadas para concretarse, por ejemplo, en una orden donde lo solicitado es un viaje.

Fig. 3. Notacion: modelo estatico

3.3. Notacion para modelos dinamicos de BTM

La Figura 4 representa la correlacion entre el metamodelo de BTM y los procesos denegocio usando notacion BPMN. La correlacion utilizada es la siguiente:

La transaccion en conjunto es representada por un proceso de negocio.Las organizaciones que agrupan a los roles son representadas mediante Pools.Los roles de cada organizacion son representados mediante Lanes.Las actividades en BTM son representadas como actividades en BPMNLos objetos de negocio son representados como DataObjects

4. Transformaciones de modelos estaticos de transacciones de

negocio a BPMN

Como hemos expuesto anteriormente, BTM propone la utilizacion de procesos para de-tallar las transacciones. Dado que entre los modelos de transaccion y los de procesos existe


ISSN 1988–3455 SISTEDES, 2008 88

Fig. 4. Notacion: modelo dinamico

la correlacion expuesta anteriormente, hemos desarrollado dos transformaciones ATL quepermiten obtener parte de una colaboracion UML partiendo de un BPMN, y viceversa.

Para el ejemplo utilizado, tenemos una transaccion de negocio que genera un proceso denegocio. Los roles Aerolınea, Viajero y Agencia de Viajes se trasforman en tres Lanes conel mismo nombre. A su vez, las tres actividades de BTM (buscar viaje, evaluar preferenciasy suministrar tiquete) son transformadas a tres actividades BPMN.

El modelo BPMN obtenido luego de la transformacion, no es un modelo completo, solouna estructura inicial. En algunos casos, es posible obtener el orden de ejecucion de lasactividades teniendo en cuenta los objetos de negocio intercambiados.

5. Implementacion

Mediante una infraestructura tecnologica hemos desarrollado un prototipo inicial quevalide la viabilidad de obtener un prototipo ejecutable usando los modelos propuestos anivel CIM.

Para conseguir esto, en primer lugar se desarrollo la infraestructura necesaria para darsoporte a los modelos y transformaciones. Para el modelo estatico de la transaccion desa-rrollamos un editor de modelos usando la herramienta Eclipse GMF. Para el modelado delos procesos de negocio hemos utilizado un plugin de Eclipse que permite la elaboracion demodelos BPMN. Finalmente, y haciendo uso del lenguaje de transformacion ATL, desarro-llamos dos transformaciones para obtener un modelo BPMN a partir de un modelo BTM yviceversa.

La Figura 5 detalla el modelo BTM obtenido a partir del editor desarrollado, y el aspectodel proceso de negocio una vez aplicada la transformacion.

Adicionalmente, se han desarrollado un conjunto de pruebas para la transformacion delmodelo propuesto a infraestructuras de servicios web, por ejemplo, a WSDL, asumiendo quecada uno de los roles tendra un unico servicio web que lo represente. Teniendo esto en cuenta,hemos supuesto que existiran varios servicios web que probablemente seran compuestos paraofrecer la interfaz del servicio que representa a cada uno de los roles. Ası pues, las operacionesde negocio que debe ejecutar cada rol se han transformado en metodos concretos del servicio


ISSN 1988–3455 SISTEDES, 2008 89

Fig. 5. Aspecto del editor de modelos y la transformacion obtenida

web y los documentos de entrada y salida de los roles, representados mediante agregacionesde tipos de datos XSD, han sido mapeados como parametros de metodos setter y getter.

La orquestacion del proceso de negocio debe hacerse a mano, dado que el directivo queproporciona el modelo a nivel CIM no se preocupa por esos detalles.

Como trabajo futuro, deseamos tomar como referencia las propuestas [3] y [1] para di-vidir la transaccion en varios niveles: CIM, PIM, PSM y codigo y de esta forma generartransformaciones automaticas o semiautomaticas entre cada uno de los niveles.

6. Conclusiones

En este trabajo hemos proporcionado un metamodelo adaptado a MDA/MDD, una no-tacion basada en Colaboraciones UML2 y un conjunto de extensiones para la instanciacionde un modelo de transacciones de negocio (BTM ). De igual forma hemos desarrollado unatransformacion MDD que permite mapear algunas caracterısticas de un modelo BTM ba-sado en colaboraciones UML2 a procesos de negocio usando notacion BPMN y viceversalo que permite mantener ambas vistas de una transaccion coherentes entre sı. Finalmente,y con el objetivo de realizar la validacion tanto del modelado como de la transformacionhemos desarrollado un prototipo usando los lenguajes de transformacion ATL, MoF scripty la herramienta Eclipse GMF.

Los resultados obtenidos, nos permiten afirmar que informacion que otros autores utilizana nivel PIM, como son las interfaces de los servicios web, pueden ser obtenidas, en parte,de modelos CIM, como el propuesto, que haya sido realizado por expertos del negocio novinculados a las tecnologıas de la informacion, como por ejemplo los integrantes de undepartamento de ventas de las organizaciones implicadas.


ISSN 1988–3455 SISTEDES, 2008 90

Reconocimientos

Este trabajo ha sido financiado parcialmente por la Universidad de la Amazonia y laFundacion Carolina mediante una beca otorgada a Jose Bocanegra, y mediante el proyectoCICYT Web-Factories (TIN2006-00472) de la Comision Europea (FEDER) y el GobiernoEspanol y el proyecto ISABEL (TIC-2533) del gobierno Andaluz.

Referencias

1. Ibrahim, I., Schwinger, W., Weippl, E., Altmann, J., Winiwarter, W.: Agent Solutions forE-business Transactions, Database and Expert Systems Applications, Proceedings. 12th Inter-national Workshop on Volume , Issue , Page(s):84 - 87. (2001)

2. Lee, H.: The Triple-A supply chain. Harvard Business Review, 82(10):102-112. (2004)3. Lopez, G., De Castro, V., Marcos, E.: Implementation of Business Process Requiring User

Interaction. OTM Workshops, LNCS 4277, pp. 107-115. (2006)4. Papazoglou, M., Traverso, P., Dustdar, S., Leymann, F.: Service-Oriented Computing Research

Roadmap. Technical report/vision paper on Service oriented computing European Union Infor-mation Society Technologies (IST), Directorate D - Software Technologies (ST). (2006).

5. Papazoglou, M., Kratz, B.: A Business-Aware Web Services Transaction Model. In: ICSOC.(2006)

6. Pena, J.: On improving the modelling of complex acquitance organisations of agents: A methodfragment for the analysis phase. Ph.D thesis, Departamento de Lenguajes y Sistemas Informati-cos. Universidad de Sevilla. (2005)

7. Pena, J; Dominguez-Machuca, J. A.; Gonzalez-Zamora, M. M. A Roadmap For Future Re-search On The Specification Of Business Services In Supply Chain Management: The QuestFor Synergy Between Software Engineering And Service Operations Management Fields Manu-facturing Fundamentals: Necessity And Sufficiency (Proceedings of 3rd World Conference OnPom, Pom Tokyo 2008)

8. Pena, J; Dominguez-Machuca, J. A.; Gonzalez-Zamora, M. M. Towards Specifying InstrumentalBusiness Services In Supply Chain: A Preliminary Proposal. Actas Del XVII Congreso NacionalDe Acede, Spain, 2007.

9. Zinnikus, I., Benguria, G., Elvesæter B., Fischer, K., Vayssiere, J.: A Model Driven Approachto Agent-Based Service-Oriented Architectures. K. Fischer et al. (Eds.): MATES 2006, LNAI4196, pp. 110-122. (2006)


ISSN 1988–3455 SISTEDES, 2008 91

A Roadmap Toward Model-Driven Feature Refactoring

Salvador Trujillo, Karmele Intxausti, Xabier Mendialdua

IKERLAN Research Centre Mondragon, Spain

{strujillo, kintxausti, xmendialdua}@ikerlan.es

Abstract. Feature refactoring is the process of decomposing a system's code into a set of modules, called features, that are a means for communicating commonalities and variabilities to stakeholders. As features encapsulate functionality, different compositions of features yield a family of different systems. Previous work describes how feature decomposition is done manually at source code level, it being a time consuming task. This work describes an alternative approach whereby refactoring begins at a higher level of abstraction (i.e., abstracting refactoring from code). We drew our inspiration from ideas for model harvesting and show how they can be applied to feature refactoring. This paper introduces the approach we took whereby a gas boiler system controller was manually feature refactored into a software product line. After this experience, we outline a model- driven approach for simplifying such refactorings in the future. Ultimately, this work envisages a broader perspective where feature refactoring and model-driven development techniques are used together to yield a software product line.

1 Introduction

A number of benefits promote software product lines to be applied to an industrial setting. It has been shown the cost reductions, time-to-market drops, quality improvements and productivity gains that can be achieved [5].

Our case study is not an exception. It is an industrial software embedded system in which the previously mentioned product line benefits were likewise pursued. However, the initial motivation to start this work was not to create a product-line itself, but to manage the increasing amount and diversity of functionality that our system demands. A well known trend is that variability is steadily shifting from hardware to software in embedded systems. The point is not only that software embraces increasing functionality, but that functionality itself is increasingly complex. Hence, software product lines offer a promising approach to manage the variability of the software.

The search of techniques for dealing with system variability led us to the creation of a software product line for our industrial software intensive system. Nonetheless, the contribution of our work rests not only on the benefits we gained by following a product line approach, but on the alternative approach we followed to create the product line out of an existing system.

Feature refactoring is the process of decomposing a system's code into a set of features [10] (a.k.a. extractive approach [4]). Earlier work described how feature code decomposition was done manually at source code level [14]. This was a cumbersome, error prone and time consuming task. This work introduces an approach in which decomposition begins at a higher level of abstraction.


ISSN 1988–3455 SISTEDES, 2008 92

We identified certain patterns of variability in the code, which we eventually abstracted in terms of models. Overall, we leveraged ideas from model harvesting, and prospectively describe their application to feature refactoring [12].

This paper outlines a model-based approach for simplifying such refactorings in the future. This work envisages a broader perspective where feature refactoring and model-driven development techniques are used together to yield a software product line. We describe a roadmap of challenges to promote the research on this field and welcome others in facing it.

This paper describes the approach for our industrial system to become a software product line. We present a case study of feature refactoring a substantial software intensive system, in which a number of qualitative and quantitative benefits, related to lines of code reduction and complexity decline, are reported. The approach permits us to manage the increasing amount and diversity of functionality that our family of systems demands. However, this manual feature refactoring is a cumbersome and time-consuming task. Hence, the roadmap we introduce in order to simplify such refactorings in the future. We begin describing our feature refactoring.

2 Feature Refactoring

Feature Refactoring is the inverse of feature composition. Instead of starting with a base system Base and features F1 and F2, and composing them to build system Product = F2●F1●Base, feature refactoring starts with Product and refactors Product into features F1, F2, Base. Feature refactoring involves the process of decomposing a system into a set of features, each encapsulating system functionality. Decomposition enables different compositions of features yield different systems.

2.1 Case Study

Our case study is a gas boiler appliance to provide heating and hot water. Note that this system is currently in use, controlling the gas boilers that customers operate. It is a software intensive system consisting of a number of hardware devices (e.g., water pump, gas safety valve, thermostat, sensors, user interfaces, combustion system, etc.), and a software controller managing a microprocessor, which operates the entire system.

The functionality of the system involves startup and shutdown, safety activities regarding gas flow, device communications, device user interfaces, service level management (e.g., hot water and/or home heating), assorted device regulations depending on source energy used, and others. Overall, it embraces the operation and communication of all hardware devices that form the entire system. Our work focuses on the control software.

2.2 Analyzing Target System

We began our work by first attempting to understand the code of the system at hand. Instead of studying all the stable versions of our software, the domain experts advised us to concentrate our analysis on a few major versions of the system. We chose the five most significant (in terms of modifications) baseline versions, aided by domain experts.


ISSN 1988–3455 SISTEDES, 2008 93

Hence, a detailed inspection of the source code and the documentation of each version was carried out. The documentation makes it easier to grasp specific details, even though this does not mean that the code was understood at first.

Actually, our reading of the code was neither literal, nor complete, i.e., very rarely did we understand all the parts of a function [13]. Instead we scanned through the code identifying repetitive patterns, understanding them, and putting them together to get a bigger picture. In perspective, the occurrence of repetitive patterns planted the seed for recognizing the importance of modeldriven development.

Codification Details. The system was implemented using ANSI C programming language. The amount of code in each system version was relatively small (totaling 10 KLOC), consisting of a number of source files. Each source file realizes the functionality of a module, which typically controls a hardware device (e.g., one module controls the water pump, another manages the safety valve and so on). This structure was common to all the 5 versions selected.

A first inspection revealed codification details, which would have an impact during the refactoring later on. The code was in plain C, where no object oriented concepts were considered. The code was at low level, meaning that bitwise operations perform common operations (e.g., activate a hardware device). Another detail was the way parameters were passed to improve performance, which undermined code understanding.

Different Versions. The versions selected were similar, as they differed slightly around 5% in values such as lines of code, statements, and comments. We carried out a study of the evolution among selected system versions by comparing them successively. Our aim was to detect which parts differed from system to system. The specific goal was to examine whether those parts accomplished any functionality that could eventually be refactored.

Although our initial intention in analyzing version evolution was to find different functionality, our work did not reveal significant functionality added from version to version (of the original individual systems). Instead, we encountered code changes related mostly to maintenance. This added code was insignificant either in terms of functionality or in terms of lines of code.

The conclusion is that we were really looking for system variants of a product line, but still found five system versions, whose differences are not related to new functionality. More to the point, we concluded in our case that no family of variants can be created from the difference among the versions. Hence, we decided to concentrate our efforts on a single version to study whether inner variability appears.

Targeting a Single System. We then looked into whether a single version can be feature refactored into product variants. To this end, we decided to pick a version out of those versions initially selected. Such versions share comparable values in terms of lines of code and quality measures with small differences. We decided to select the most recent version (called CAL_205) because it has (i) the lowest value in terms of lines of code and statements, (ii) the best value in terms of quality measures, and (iii) being the most recent presumably has less defects than earlier versions.

2.3 Identifying Features

Our intention was to obtain a family of product variants out of the individual selected version by feature refactoring it. Starting from the code of the selected version, the idea was to identify those features that form the constituent parts in terms of functionality, to detect which code parts


ISSN 1988–3455 SISTEDES, 2008 94

realized them, and then to refactor them by decomposing the code. We began by identifying features within the selected version.

A feature is a means for communicating commonalities and variabilities to stakeholders. Features are used to distinguish products within a Software Product Line (SPL). Although the definition of feature is not new [6], there are different notions of it [3].

Feature refactoring aims to identify those features that realize a system. Hence, determining the features is a major task towards creating a product line. CAL_205 is the baseline system for a product line of variants. We wanted to feature refactor CAL_205 into a CORE kernel with common functionality and optional features with further functionality. By doing so, we created a product line of CAL_205, which we called GaBoPL (the Gas Boiler Product Line). We relied on domain expert guidance to define the features of GaBoPL:

• BoilerType: defines the general type of the boiler, options follow: ANA (analog), this boiler type operates analogical devices such as sensors; ATM (atmospheric), the combustion is done by burning air from the premises where the boiler is located; DIG (digital), this type involves digital sensors and how they are operated; and BIT (bithermic), this boiler type uses separate circuits for heating and domestic hot water.

• Power: sets the power capacity of the combustion (24KW or 30KW).

• EnergySource: determines the source of energy, options follow: PRO (propane), this type of gas is used; BUT (butane), another type of gas; and SOL (solar), the burning process is aided by solar collectors, which pre-heat the water.

• Test: are carried out to evaluate microprocessor operation, options follow: MAN (manufacturing), this testing process is completed just after micro manufacturing; and BUR (burn-in), this testing process is carried out during operation to check memory failures.

• Interface: selects desired command board, options follow: SIM (basic), this interface simply uses push buttons and LED indicators; ADV (advance), this uses a Liquid Crystal Display (LCD) interface; and SAT, activates a mode which enables an operator to diagnose the boiler whenever a failure appears.

From this feature set of GaBoPL, we can synthesize different GaBo product variants.

2.4 Detecting Feature Code

Starting from this feature name identification, the goal is to recognize which code part implements each feature, and then decompose them. By decomposing, we mean pulling those parts that realize each feature apart the common code, with the entire process known as feature refactoring.

Incremental Refactoring. The process to detect and decompose variable code was largely incremental. We followed an incremental extractive approach whereby each individual feature was decomposed from the original system sequentially [4]. This means that all the code realizing a feature are decomposed at the same time, i.e. features dictate order.

We first refactored BoilerType related features such as ANA, ATM, BIT and DIG. It required two people/day to complete this task, with a domain and product-line individual working together a full day, using our reports to browse code and pulling apart those blocks that realized each feature.


ISSN 1988–3455 SISTEDES, 2008 95

Afterward, another two people/day was spent on refactoring features related to the Interface, namely SIM, ADV and SAT Diagnostics. Upon completion, half a day was dedicated to pulling the SOL feature apart. Lastly, another day's effort was required to decouple the Test features.

Overall, we refactored into features around 25% of the original code. This portion of code forms the variable part of the system, whereas the remaining code forms the common part of the product line code.

Code Blocks. While feature identification refers to an abstraction level, feature code decomposition refers to those parts that actually realize and implement a feature abstraction. We designate them as code blocks. It is not necessary to emphasize that this code block recognition is far from trivial. Some time is needed to isolate small code blocks. In doing so, we detected some repetitive code patterns that helped us to accelerate this process. Again, this vindicates the importance of model-driven development.

Figure 1: Code Patterns

Certain guidelines were followed for locating feature code such as variables that are related to specific functionality. Hence, we proceeded to locate them within the code (e.g., to look for such variables within the source), and then analyzed the neighborhood of those locations in detail. This idea is inspired from Program Slicing, which starts with the observation that there are times when only a portion of a program's behavior is of interest [18].

Repetitive Occurrences of Code. We initially used simple tools to report string occurrences and easily navigate around them within the code. These reports accelerated our systematic search of feature code and helped us to feature refactor it.

This search typically led to further searches where a variable code containing a certain string (e.g., A) was connected with another variable code (e.g., B). So, using the same reports we scanned the source code to search for those parts that appeared frequently. In our case, we found several repetitive occurrences of code, that preclude the apparition of a sort of code patterns.

Initially, we were looking for feature code to be located, but were not aiming particularly at identifying types of occurrences. However, after a few iterations we soon realized that variable code share similar types, which we introduce next. Figure 1 shows excerpts of code with some real examples found in our case study.


ISSN 1988–3455 SISTEDES, 2008 96

• A) Define-based: we found many refactorizable #define-s directives. In our case, they defined values used later within the code. Note that many of these #define-s are related to features identified before. For instance, when BoilerType is ATM, this means that “#define ATMOSPHERIC 0x33” appears. This also occurs for other features. This typical example is shown in Lines 10-11 of Figure 1.

• B) Global-variable-based: another type appeared when the name of a given global variable contained a name reminiscent of the functionality of a feature. An example of this is shown in Lines 20-22 (time_burn_in is related to BUR feature).

• C) Conditional: conditional statements govern frequently whether or not large chunks of code are executed. Our case is not an exception. In particular, the if statement is repeatedly used in the original system to decide which code parts are executed depending on certain system variables, which we deem related to a specific functionality. Lines 30-38 show an example with the BoilerType feature described earlier.

• D) Expression: note that expressions within if conditions contain values defined in a #define directive. A few times, the expressions within an if statement needed to be refactored. This occurs when different values defined with #define are used together. Lines 40-42 show an example. Note that this type is tougher to refactor because modifying such expressions requires typically understanding them beforehand. This task is rather difficult as expressions become frequently fairly complex.

• E) Sentence: plain statements are also refactored when they are suspected to involve the code realizing a feature. Recognizing this code is rather difficult, even more without expert assistance. The documentation provides some support in this task. Nonetheless, a very few blocks belong to this group. Lines 50-51 outline an example in Figure 1.

Classifying Code Occurrences. The detection of the variable code provided us with a valuable classification for them. We scanned all the code in order to count the occurrences of each type. The BOILER and PUMP modules each account for around 20% of the occurrences, whereas the FLAME and MEMORY modules do not vary. The most used is Conditional, which appears in 54% of the blocks. Note that 84% of the code belongs to either the Define-based or Conditional group, whereas the others are used on a rather low scale. This classification of code blocks would lead us subsequently to foresee the need of a refactoring model.

Patterns. As the numbers showed previously the combination of Define- based and Conditional is by far the most common in our case. This combination of if and #define can be regarded as a primitive form of handling variability where a generic code is somehow configured. (Although this mechanism resembles conditional compilation achieved by #ifdef, it is somewhat different.) This provided us with an initial and valuable form of structural pattern, which eventually enabled us to recognize their repetition, and ultimately guide us to fully consider the importance of model-driven development.

2.5 Resulting Product Line

The result of feature refactoring is a software product line, making it possible to manufacture a family of system variants with different variability.


ISSN 1988–3455 SISTEDES, 2008 97

Feature Implementation. A set of code blocks realizes the functionality of different features. We used BigLever GEARS1 tool to implement the variability in the form of variation points (i.e., define the logic to link features with code blocks in order to enable product generation later on).

Generating Product Variants. Once features are pulled apart from the code, and relationships between features and code are defined, it is a simple matter to define, synthesize, and build different variants of GaBoPL. For example, a version GaBo14 that contains the features ATMOSPHERIC for BoilerType, GAS for EnergySource, MANUFACTURING for Test, and ADVANCE for Interface, together with the common part denoted as CORE, is specified and built by composing features: GaBo14 = features (CORE,ATM,GAS,MAN,ADV). Over fifty are theoretically possible, whereas eight are commercial products.

Benefits. We shifted from the original product-centric system to a product line, giving product-line advantages such as the reduced effort to create new variants, and the reduced effort to add new features [5]. Reported benefits on product lines range from reduced variant cost to reduced time-to-market [5, 17]. In our case, we could report a number of quantitative benefits mostly related to complexity (max reduction of 50%) and memory requirements (max reduction of 25%).

The most significant point to emphasize is that a customized system variant can be created based on specific feature requirements. This is achieved with critical involvement of domain experts.

Drawbacks. In our experience, feature refactoring requires remarkable effort to build our product line out of the original system. In general, we believe that feature refactoring demands extraordinary effort. Hence, support is required to facilitate it.

As said previously, this work involves repetitive, cumbersome and timeconsuming tasks. This encompasses inspection of source code by hand. The use of model-driven development techniques is envisaged as a way of reducing the effort needed in the feature refactoring.

3 Perspective & Roadmap

We have described so far how the original gas boiler individual system was refactored into a product line that yields a family of systems. This section puts our work into a greater perspective, and describes an scenario in which feature refactoring is assisted by model-driven development. A roadmap of challenges is presented to attain this.

3.1 Perspective

This case study was done with some assistance from experts and reports, but it is still a rather manual process. Our experience has shown that tool support could certainly help to accelerate the detection of code blocks.

Automating feature refactoring alone seems a big challenge in product line engineering. The question is whether any mechanism could facilitate what is still a manual process. Based on our

1 http://www.biglever.com


ISSN 1988–3455 SISTEDES, 2008 98

experience feature refactoring our legacy system, this section outlines a model-driven approach to feature refactoring.

The envision is to bridge the gap between feature refactoring and modeldriven development. We put first of all our roadmap into a greater perspective.

3.1.1 Related work

Architecture Driven Modernization. Model Driven Development (MDD) is an emerging paradigm for software construction that uses models to specify systems, and model transformations to synthesize executables [2]. Model Driven Architecture (MDA) is a specific realization of MDD [11], proposed by the Object Management Group (OMG).

Architecture Driven Modernization (ADM2) is the name of the initiative of the OMG related to extending the modeling approach to the existing (or legacy) software systems, which has been one of the biggest obstacles for the modeling adoption.

The aim of ADM is to harvest models out of code [12]. This model harvesting enables MDD techniques to be used later on. N.B.: these techniques are intended for individual systems, but not for product lines.

Feature Oriented Model Driven Development (FOMDD) combines two paradigms for the creation of SPL starting from scratch: Feature Oriented Programming (FOP) for the product line and Model-Driven Development (MDD) for the modeling [15]. This is not the situation in many cases where a legacy system already exists.

Feature Oriented Refactoring is a paradigm to refactor such existing system into a product-line [14], whereas ADM (a.k.a., model harvesting [12], reverse engineering to model driven, etc) is a paradigm to refactor an existing individual system into a modeling approach.

The challenge is how to combine both together (in the same way as FOMDD did with FOP and MDD) to yield FOMDD refactoring, where our case study yields preliminary ideas. Our approach to create our product line prospectively combines ideas from feature refactoring with ideas from model harvesting. We believe that much more work is needed to crystallize these ideas. A roadmap in that direction is introduced next.

3.2 Roadmap

A roadmap is introduced based on the perspective gained in our case study and building on the related work. We contextualize first the challenges encountered in our work, we then introduce an envisaged scenario, and finally present the roadmap to reach them.

2 Note that ADM is the inverse of MDA acronym. http://adm.omg.org/


ISSN 1988–3455 SISTEDES, 2008 99

Figure 2: A model for Feature Refactoring

3.2.1 Challenges

A Model for Feature Refactoring. It is our intention to introduce a model describing feature refactoring. This idea arose at some point during our work when we realized that the model was already apparent in our head, but not properly formalized as a model. Hence, we attempted to specify those ideas into a model abstraction.

This work started by understanding the artifacts of the original system, and identifying afterward which features comprised the product line. Although the decomposition process was partially supported by tools, it was essentially a manual process. We recognized certain patterns in the code (e.g., #define-if) that eventually facilitated our feature refactoring process. Our aim was to model those patterns and how the occurrences of patterns guide the decomposition of artifacts among features.

We aim to introduce the general mechanisms needed for this model to be applicable to other cases. The motivation is to represent in a model the relationship between features and the code realizing them. The challenge is to define a general model where all these concepts are defined together. Figure 2 portrays our ideas into a preliminary model.

In general, a model for feature refactoring consists of (i) Features of the target product line to be created (e.g. a feature model), (ii) Units of the original system in the form of Package (e.g. set of files), Artifact (e.g. files of the system such as source code, model, etc) or Part (e.g. modularization parts such as methods or procedures) that are to be decomposed (e.g. files of a target system), and (iii) how they inter-relate, i.e. the relationships between features and decomposed code [16].

When the granularity of the refactoring is fine (i.e. pieces of code smaller than Part that realize a specific Feature), the relationships can be represented by means of Blocks. These Blocks conform to a pattern that should be defined elsewhere (i.e., the Blocks represent an instance matching a pattern). Although this work feature refactored source code artifacts, it would be also possible to refactor other representations, such as models, makefiles, and documentation. This general refactoring model needs to be populated for each feature refactoring case [16].


ISSN 1988–3455 SISTEDES, 2008 100

Harvesting a Model. Populating the model outlined before with Feature and system-related (Package, Artifact, Part) information seems trivial. However, introducing their relationships in the form of Unit is far from trivial. A challenge is how to automatically populate the entire model, including relationships.

We introduced some patterns based on our experience. For instance, if a #define-if pair can be recognized by tool support, the model instance could be populated with candidate code Units. However, each case demands a different set of patterns (e.g. #ifdef instead of #define-if [9]).

The general goal is to select or define a set of particular patterns for each case to be feature refactored and then populate the model instance with Units. Thus, starting from pattern definitions, it would be possible to create tools in order to search candidate Units that match such patterns. These Units eventually bind to a feature.

This harvesting of the refactoring model would facilitate the feature refactoring of code, abstracting it from scanning code to checking candidate Units.

A Model Driven Approach for Feature Refactoring. This work seeks new ways to code decomposition using abstractions where a model-driven approach was preliminarily outlined to aid in this process. It consists of tasks to automatically populate a refactoring model, identifying candidate feature code, and then decompose those selected code into a specific variability realization technique.

Our product line is created using a specific approach to represent variability. Hence, when we located code, we represented them in the form of BigLever GEARS blocks. It would be possible now to automate the realization of variability by creating a mapping between the refactoring model (see Figure 2) and the implementation of the refactoring in such tools.

Additionally, this modeling approach may foster the definition of new mappings for handling new approaches. For instance, a mapping between the refactoring model and other variability implementation might be possible (e.g., AHEAD Tool Suite [1]). Capitalizing on the models introduced before would make this easier.

This separation of the refactoring model from the refactoring realization leads us to the idea of a mapping to automatically color code following ideas by Kästner [8]. This would make it possible to see the already decomposed code together, while using different mappings to decompose code. The ultimate goal behind these mappings is to apply Model Driven Development ideas to its fully extent in the context of feature refactoring [2].

Figure 3: Envisaged Scenario


ISSN 1988–3455 SISTEDES, 2008 101

3.2.2 Scenario

The challenges introduced before form the constituent parts of a broader scenario. The scenario we envisage would exploit the synergies between feature refactoring and model-driven development. Our intention is to describe such scenario, the motivation is to welcome others in the grand challenge of modeldriven feature refactoring of legacy systems.

Figure 3 shows the envisage scenario. Rectangles correspond to models and arrows correspond to model transformations (model-to-model, model-to-source, source-to-model). As they are numbered, we describe them in order.

1. Parsing: this involves parsing into an AST model the source code of the legacy system. This is already faced by ADM and tools such as CIDE [7, 8].

2. Coloring: this involves coloring the AST model parsed previously. The idea is to bind colors to features and then assign colors to blocks of code. This is also provided by CIDE [7, 8].

3. CM (CIDE Model): The CIDE coloring tool has an implicit model to represent the information that relates features, colors, and blocks of code. A specific model representation, CM, is required in terms of MDD to make explicit such representation. Doing so, it would enable to use modeling tools (e.g. define metamodel, define model transformations, etc).

4. Fill RM (Refactoring Model) from CM: the aim is to define a model to represent the refactoring more abstract and more general than CIDE. Filling refers to a model transformation from a CM model to a RM model. The intention is to do so with available MDD tooling.

5. Refactoring Model (RM): the aim is to formalize a general refactoring model to represent the refactoring (similar to the outlined in Figure 2). Additionally, this model is intended to be more abstract than CM to encompass other inputs than CM (e.g. from other inputs than CIDE). This model might represent the code introducing granularity of refactoring (i.e., which are the different grains of the feature refactored code) [16].

6. Transform from RM to RRM (Refactoring Realization Model): the aim is to define a model transformation from a RM to a RRM. This transformation would enable to introduce realization details into the general refactoring model. These realization details refer to the real implementation of the variability. Again, the intention is to define the model transformation using available tools.

7. Refactoring Realization Model (RRM): define a model to represent the realization of the variability. This model would contain implementation details, but would be intermediate since it is not yet bound to a specific variability approach (e.g. GEARS, AHEAD [1], etc).

8. Transform from RRM to GRM (GEARS Realization Model): define a model transformation to obtain a specific variability implementation model from a RRM. This transformation would introduce GEARS specific details and syntax for achieving variability (e.g. code blocks, GEARS feature logic, definition of features, etc).

9. Transform from RRM to ARM (AHEAD Realization Model): similarly, this transformation would introduce AHEAD specific details and syntax for achieving


ISSN 1988–3455 SISTEDES, 2008 102

variability (e.g. refinements of code, AHEAD layers to distribute features, equations for the definition of features, etc).

10. GRM (GEARS Realization Model): this model would define the GEARS specific realization of variability. As sketched previously, these details refer in general to the way variability is represented through code blocks, the way features are defined in GEARS, and the logic to dictate how features are inter-related.

11. ARM (AHEAD Realization Model): similarly, this model would define the AHEAD specific realization of variability. As mentioned previously, these details refer to the way features are distributed in layers, the way variability is represented through code by means of refinements, the way features are defined, etc [1].

3.2.3 Roadmap

Although the most of the envisaged scenario described in Figure 3 is yet unexplored, there are specific parts such as the Refactoring Model and its granularity that are being explored currently [16].

A roadmap is described to realize the envisaged scenario. It subdivides in two parts:

• Bridging CIDE to the Refactoring Model: the first corresponds to the connection between the existing coloring tool and the refactoring model. It encompasses steps 3-4-5 of Figure 3. This would initially connect CIDE with the refactoring model, as a first step to connect with other remaining models. For instance, this would enable CIDE in the future to feature refactor product lines in more implementations than those offered nowadays (e.g. GEARS in addition to AHEAD).

• Bridging the Refactoring Model to the Refactoring Realization (implementation): the second corresponds to the connection between the (abstract) refactoring model and the implementation. It encompasses steps 5 to 11 of Figure 3. So far, this is achieved by hand, i.e. we describe the feature refactoring in an abstract way, but additionally need to transpose the variability at code level. If the scenario described before is accomplished, it would be possible to automate the feature refactoring once the model is represented using Model-Driven Development techniques.

4 Conclusions

This paper has presented our experience from a case study on feature refactoring a legacy embedded system. We believe our work is a valuable case study on industrial feature based system refactoring, where some specific benefits were accomplished.

This feature refactoring has been accomplished by hand. This exposes the need for the feature refactoring automation. We target at such automation proposing an envisaged scenario that benefits on ideas from the model-driven development community.

We envision a future in which the full potential of model-driven development can be exploited to feature refactor a legacy system into a software product line. The goal of this paper is to describe a roadmap, which ultimately may promote research on the field of model-driven feature refactoring.


ISSN 1988–3455 SISTEDES, 2008 103

References

[1] D. Batory, J.Neal Sarvela, and A. Rauschmayer. Scaling Step-Wise Refinement. IEEE Transactions on Software Engineering (TSE), 30(6):355-371, June 2004.

[2] S. Beydeda, M. Book, and V. Gruhn, editors. Model-Driven Software De velopment. Springer, 2005.

[3] A. Classen, P. Heymans, and P.Y. Schobbens. What's in a Feature: A Requirements Engineering Perspective. In 11th International Conference on Fundamental Approaches to Software Engineering (FASE 2008), Budapest, Hungary, to appear, pages 262-277, 2008.

[4] P. Clements and C. Krueger. Point/Counterpoint: Being Proactive Pays Off/Eliminating the Adoption Barrier. IEEE Software, 19(4):28-31, July/August 2002.

[5] P. Clements and L.M. Northrop. Software Product Lines - Practices and Patterns. Addison-Wesley, 2001.

[6] K. C. Kang and et al. Feature Oriented Domain Analysis Feasability Study. Technical Report CMU/SEI-90-TR-21, Software Engineering Institute, November 1990.

[7] C. Kästner, S. Apel, and D. Batory. A Case Study Implementing Features using AspectJ. In 11th International Software Product Lines Conference (SPLC 2007), Kyoto, Japan, September 2007.

[8] C. Kästner, S. Apel, and M. Kuhlemann. Granularity in Software Product Lines. In 30th International Conference on Software Engineering (ICSE 2008), Leipzig, Germany, May, 2008.

[9] R. Kolb, D. Muthig, T. Patzke, and K. Yamauchi. A Case Study in Refactoring a Legacy Component for Reuse in a Product Line. In 21st IEEE International Conference on Software Maintenance (ICSM), 2005.

[10] J. Liu, D. Batory, and C. Lengauer. Feature Oriented Refactoring of Legacy Applications. In 28th International Conference on Software Engineering (ICSE 2006), Shanghai, China, May, 2006.

[11] OMG. MDA Guide version 1.0.1. OMG document 2003-06-01, 2003.

[12] T. Reus, H. Geers, and A. van Deursen. Harvesting Software Systems for MDA-Based Reengineering. In ECMDA-FA, pages 213-225, 2006.

[13] E. Soloway, R. Lampert, S. Letovsky, D. Littman, and J. Pinto. Designing Documentation to Compensate for Delocalized Plans. Commun. ACM, 31(11):1259-1267, 1988.

[14] S. Trujillo, D. Batory, and O. Díaz. Feature Refactoring a Multi- Representation Program into a Product Line. In 5th International Con- ference on Generative Programming and Component Engineering (GPCE 2006), Portland, OR, USA, Oct, 2006.

[15] S. Trujillo, D. Batory, and O. Díaz. Feature Oriented Model Driven Development: A Case Study for Portlets. In 29th International Conference on Software Engineering (ICSE 2007), Minneapolis, MN, USA, May, 2007.

[16] S. Trujillo, X. Mendialdua, and V. Azkarraga. Staged Feature Refactoring: A Case Study of Embedded Systems. In Draft, 2008.

[17] F. van der Linden, K. Schmidt, and Eelco Rommes, editors. Software Product Lines in Action. Springer, 2007.

[18] M. Weiser. Program Slicing. 10(4):352-357, July 1984.


ISSN 1988–3455 SISTEDES, 2008 104

Feature Patterns and Product Line Model Transformations

Miguel A. Laguna, Bruno González-Baixauli

Department of Computer Science, University of Valladolid, Campus M. Delibes, 47011 Valladolid, Spain

{mlaguna, bbaixauli}@infor.uva.es

Abstract: Feature models are the basic instrument to analyze and configure the variability and commonality of a software product line. But feature models embody various different variability facets (structural, behavioral, non-functional, etc.). Features, used as core model, must be completed with other techniques (i.e. goals or UML models) to fulfill these variability aspects. This approach allows us to proceed in several steps, using the appropriate paradigms in each phase. The global picture is a sequence of model transformations from goal/requirements to features and from both to the architecture. In this context, this article aims to identify patterns in the feature models and their relation with the corresponding architectural counterparts (class and use case diagrams). The work is completed with the definition and implementation of meta-model based transformations between these models. The existence of a feature pattern catalog and the associated transformations make the automated creation of models and traceability links possible, enhancing the productivity of the development process of product lines.

Keywords: feature models, software product line, model transformation

1 Introduction

The development of software product lines (PL) faces many technical and organizational trends, in spite of its success in the reuse field [2, 5]. On the requirement level, one of the key activities is the specification of the variability and commonality of the PL. The design of a solution for these requirements constitutes the PL domain architecture. Later, the concrete product architecture must be derived for each variant in the family. In this process the functional and non-functional customer requirements are used for choosing among alternative features and, indirectly, via traceability paths, the architecture of the product [2].

Feature Oriented Domain Analysis (FODA) [18] proposed features as the basis for analyzing and representing commonality and variability of applications in a domain. A feature represents a system characteristic realized by a software component. There are four types of features in feature modeling: Mandatory, Optional, Alternative, and Or groups of features. However, although its effectiveness has been proven in many projects, these models are more oriented to the solution than to requirements. On the other hand, non-functional requirements (NFR) and platform specific aspects must be taken into account and other models can express these aspects better (we use UML models and goal oriented techniques). Consequently, the use of the feature diagrams as a monolithic tool over-simplifies and limits the potential of the technique.

The origin of the problem is that FODA feature models try to cover different variability facets simultaneously: they represent structural, behavioral, non-functional, and platform variability. We consider that other well known techniques, different from feature diagrams (such as goal and UML models) are better at expressing different aspects of variability, while the feature model can be the central piece of the puzzle that connects the rest of the models. Taking into account the different categories of features, we have proposed to analyze them separately [20]:

• Goal models (essentially hard goal) represent the intention of the PL, i.e. the high level objectives the family of applications must solve. The soft-goals represent the non-


ISSN 1988–3455 SISTEDES, 2008 105

functional characteristics. These can be used with the hard-goals contribution information to configure the optimal solution for a concrete application in the PL [11].

• Feature models represent the functional variability. They connect the goals with the UML models. Two main categories of features are included: structural and behavioral (services and operations) features.

• UML models organize the architecture specification, including structural and behavioral system requirements of the PLs, connected with the feature model.

The aim was to analyze the product line requirements using the appropriate model for each

different variability aspect. The development of a PL can be seen as a sequence of model transformations from goals/soft-goals to features and from both to the initial architecture (a set of UML models), tracing the relationships between these models.

We have manually developed some case studies of PLs using this approach1. However, the productivity (and the complexity in non-trivial product lines) requires the construction and derivation of the different models to be automated. As the main strength of the Model Driven Engineering (MDE) paradigm is the manipulation of models, we propose to use this approach to define these transformations. This approach requires the establishment of precise rules, using meta-modeling and transformation tools. To establish these rules, the recurring patterns in the feature models must be discovered and correlated to UML structures. In this context, the next Section identifies the basic patterns that can be found in feature models. The result is a catalog of feature patterns and their corresponding structural and behavioral UML models. Section 3 shows the application of the MDE approach automating these transformations, using meta-modeling and QVT [26]. Section 4 presents related work and Section 5 concludes the paper and proposes additional work.

2 Feature Patterns

In a product line development process, after the goals and feature models are established, several structural and behavioral UML models must be built (hopefully using a catalog of commonly used derivations from feature to UML models). A revision of the literature has shown it to be naive to try to make a simple and univocal transformation from feature models to UML diagrams. Therefore, we have adopted a pragmatic and multi-view approach as stated in the introduction: separating the different categories of features and analyzing them with different techniques. In this section, we use a selection of examples extracted from a large case study described in [23], using feature models, class models and activity diagrams. It is an electronic commerce product line (manually developed) and includes a great number of optional features and, as a consequence, a large number of potentially derived products. The feature tool used is the fmp eclipse plug-in developed in Waterloo University [1] and an adapted version of a conventional CASE tool.

We differentiate two kinds of transformations: the structural information of the feature models is mapped to class diagrams and the behavioral features are connected with use case diagrams.

Consider the simplest situation. An AND feature construction that represents structural information can be directly transformed into classes and attributes (Figure 1). In our approach, based on [9], the features are typed. The type can be a simple type or the default FEATURE type itself. The key aspect is that the leaves of the tree can be features with information about simple types and in these cases a simple typed feature is mapped into an attribute of a parent class.

If the leaf is not an atomic feature (or is simply an intermediate node in the tree) a little more complicated solution is required. The mapping consists of creating a class that represents the feature (more details will be added during the later refinement of the structural model). The mandatory and optional features imply a 1..1 or 0..1 composition relationship respectively. Figure

1 available at http://www.giro.infor.uva.es as student term projects


ISSN 1988–3455 SISTEDES, 2008 106

1 includes some examples of both circumstances: CreditCardInfo is a class that represents optional information in the class model; LoginCredentials represents compulsory information.

This enables the identification of several simple patterns in feature models: • The presence of a mandatory feature of FEATURE type originates a class that is associated

(with a 1..1 multiplicity) with another class that represents the parent feature. • The presence of an optional feature of FEATURE type originates a class that is associated

(with a 0..1 multiplicity) with another class that represents the parent feature. • The presence of a mandatory feature of a simple type (INTEGER, STRING, DATE…, i.e.

any type different from default FEATURE type) originates an attribute in a class that represents the parent feature. The presence of an optional feature defined by a simple type originates an optional attribute (represented by the UML attribute multiplicity information) in the class that represents the parent feature.

Summing up, the structure of classes/attributes connected by a 1..1 or 0..1 multiplicity association or composition relationship reflects the original structure of the features.

The common architectural equivalence of a set of grouped features (alternative and OR groups) is based on generalization. In fact, a combination of composition and generalization relationships is needed to differentiate alternative from OR patterns. Both variants have a common part in the corresponding class diagram structure: a composition relationship indicates whether the selection of one or several sub-features is compulsory (minimum multiplicity equal to or greater than one) or optional (minimum multiplicity equal to zero). The composition maximum multiplicity differentiates the OR relation (maximum multiplicity greater than one) from the pure alternative relation (maximum multiplicity exactly equal to one).

Figure 2 shows examples of both variants. The CheckOut feature always has a CheckOutType, but this must be (in a concrete application) a Registered CheckOut or, alternatively, a Guest CheckOut. The two variants cannot be implemented simultaneously in a concrete application. This is reflected in the composition relationship shown in the same Figure: only one instance of type CheckOutType can be connected to a CheckOut instance. However, the variant of the PaymentTypes feature implies that more than one feature can be selected (but one of these must always be the CreditCard payment type). The multiplicity 1..3 of the composition relationship states this possibility. Finally, the PaymentGateways group of features are optional and compatible (the multiplicity 0..2 clarifies the possibilities).

These patterns conform to the literature. However, we can appreciate that some basic information is lost. For example, it is necessary to show that the payment type DebitCard or ElectronicCheque can be used in some applications or not, but each application in the PL must have the CreditCard PaymentType. This is not shown in Figure 2, and this representation must be modified to clarify these differences.

RegistrationInfo

Login (String)

CreditCardInfo

LoginCredentials

ShippingAdress (String)

CardNumber (String)

Password (String)

CardName (String)

0..1

0..1

1..1

0..1

BillingAdress (String)

ExpiryDate(Date)

SecurityInfo (String)

0..1

RegistrationInfo

+ShippingAdress: String[0..1]+BillingAdress: String[0..1]

LoginCredentials

+login: String+password: String

1

CreditCardInfo

+CardName: String+CardNumber: String+ExpiryDate: Date+SecurityInfo: String[0..1]

0..1

Fig. 1 Structural feature model fragment and the corresponding UML model equivalent


ISSN 1988–3455 SISTEDES, 2008 107

CheckOut

Registered

ShippingOptions

CheckOutType

TaxationOptions

PaymentGateways

CreditCard

0..1

1..1

0..1

ElectronicCheque

FraudDetection

PaymentTypes

1..1 PaymentOptions

DebitCard

1..3

1..1

Guest

CustomPGVerisign

0..2

CheckOut

ShippingOptions

0..1

TaxationOptions

1

PaymentOptions

1PaymentTypes

1..3

CreditCard

DebitCard

ElectronicCheque

PaymentGateways0..2

FraudDetection0..1

CheckOutType

Registered Guest

1

Verisign

CustomPG

Fig. 2 Structural feature model fragment with examples of alternative and OR feature constructions and the corresponding literature based architectural solution

In a previous work we proposed to separate the representation of variability of the PL completely from the variability of the concrete applications [21], using the UML package merge mechanism to add details to the models in an incremental way. The <<merge>> relationship indicates that the contents of two packages are combined. It is used when elements in different packages have the same name and represent the same concept, which is extended incrementally in each separate package. Selecting the desired packages, it is possible to obtain a tailored definition from all the possible ones. Although the examples in UML focus on class diagrams, the mechanism can be extended to any UML model, in particular use cases and sequence diagrams.

This mechanism provides a clear traceability between feature and UML models. Each optional feature is described by an optional package of the PL that will be selected or not, in function of the concrete configuration of features. The process consists of establishing, for each UML model, a base package that embodies the common part of the PL. Then, associated to each optional feature, a new package is built, so that all the necessary changes in the model remain located. This package is connected through the <<merge>> relationship with its base package in the exact point of the package hierarchy. The direction of the relationship expresses the dependence between packages: the base or merged package can always be included in a specific product, the receiving package is an extension of the base package and can only be included if the base package is also selected. This is exactly the way the expert decides which features are included or not during the configuration process, and must be directly reflected in the configuration of packages. A modified version of the feature patterns is imaginable, combining the literature based structures with the package merge mechanism.

The representation of the PL structural model we use is shown in Table 1, which presents some examples of the package based version of the feature patterns equivalences with structural models. This second version is preferable, as it removes any ambiguity about the multiplicity semantics and is directly translatable to code.

The example 5 is clarifying: All the applications in the PL have the possibility of Credit Card payment but some of them have two or three additional possibilities of payment. This doesn’t presume which type of payment (or combination) will be selected by the final user in each system execution. The semantics of cardinality in feature models is different from the multiplicity semantics in class diagrams and is actually related to the package organization of the PL architecture. A collateral benefit is that the traceability between features and packages is registered automatically.


ISSN 1988–3455 SISTEDES, 2008 108

A similar argumentation can be used if we want to find the behavioral equivalences of feature

patterns. We base the UML behavioral model on use case diagrams (obviously combined with the package merge mechanism) with intensive use of include and extend relationships. Mandatory behavior is modeled with included use cases and optional behavior with extension use cases. But

Table 1 Examples of basic structural features and their transformation to package combination of class diagrams Feature Pattern Class Structure (package merge variant)

(1)

Login (String)

LoginCredentials

Password (String)

LoginCredentials

+login: String+password: String

RegistrationInfo

ShippingAdress (String)

0..1

BillingAdress (String)0..1

(2)

PRegistrationInfo

PBillingAdress

PShippingAdress

<<merge>>

<<merge>>RegistrationInfo

RegistrationInfo

+ShippingAdress: String

RegistrationInfo

+BillingAdress: String

CheckOut

ShippingOptions

TaxationOptions

1..1

0..1

PaymentOptions

1..1

(3)

PCheckOut

CheckOutPaymentOptions 1

TaxationOptions1

PShippingOptions<<merge>>CheckOut

ShippingOptions

1

PaymentGateways

CustomPGVerisign

0..2

(4)

PPaymentGateways

PaymentOptions

PaymentGateways

1

PVerisignPaymentGateways

Verisign

<<merge>>

PCustomPG

<<merge>>

PaymentGateways

CustomPG

PCheckOut

PaymentOptions<<merge>>

CreditCardElectronicCheque

PaymentTypes

DebitCard

PurchaseOrder

1..4

(5)

PCheckOutPaymentOptions PaymentTypes1..*

CreditCard

PPurchaseOrderPElectronicCheque

PDebitCard

<<merge>>

<<merge>>

<<merge>>

PurchaseOrder

PaymentTypes PaymentTypes

ElectronicCheque

PaymentTypes

DebitCard


ISSN 1988–3455 SISTEDES, 2008 109

optional behavior has, as in structural models, two meanings. Using the same example, the details of payment steps can be different in an implemented application in the PL because it is possible to pay by cheque or credit card (and then we use the extend relationship). However, any application always requires the credit card payments but not the cheque possibility (this second behavior is in an extension use case inside an optional package). This approach leads us to Table 2, basic examples of patterns (optional/mandatory and include/extend combinations). The name of use cases can be modified as a part of the transformation (using a convention as “manage X”) but this is not relevant as the internal structure of each package is only a fist cut that must be manually refined (in contrast, the package structure must be preserved).

3 Transformations of feature patterns

The complexity of the models forces us to automate the transformations in order to successfully adopt the product line paradigm. As the method we have chosen is based on the meta-model mapping approach [8], our work consists of defining a set of transformations between the feature patterns and the architectural UML constructions (both defined in terms of the corresponding meta-model), based on the informal finding of the previous section.

Table 2 Basic behavioral features and their transformation to package combination of UML use case diagramsFeature Pattern Use Case diagrams (package merge variant)

CheckOut

ShippingOptions

TaxationOptions

1..1

0..1

PaymentOptions

1..1

(1)

PCheckOut

CheckOut

Actor

PShipping

ShippingOptionsCheckOut

<<include>>

<<merge>>

TaxationOptions

<<include>>

PaymentOptions<<include>>

CreditCardElectronicCheque

PaymentTypes

DebitCard

PurchaseOrder

1..4

(2)

PCheckOut

PaymentOptions

CreditCard

PaymentTypes<<include>>

<<extend>>

PElectronicCheque

PDebitCard

PPurchaseOrder

<<merge>>

<<merge>>

<<merge>> PaymentOptions

PaymentOptionsPaymentOptions

PurchaseOrder

<<extend>>

DebitCard

<<extend>>

ElectronicCheque

<<extend>>


ISSN 1988–3455 SISTEDES, 2008 110

The way to define a transformation is to identify an element (or more exactly a combination of connected elements that satisfy certain constraints) of the feature model and give the two equivalences in terms of the UML meta-model. As the election of the meta-model greatly influences the transformation process, we evaluated several possibilities specified in the literature. The meta-model proposed by Czarnecki et al. in [9] has finally been selected because of the simplicity of the transformations. In this approach, the distinctive property of the relationships is the cardinality. In a previous work [21], we defined and implemented the structure of packages that represent the architectural vision of the PL, facilitating the traceability of the models. The transformation is now completed, filling the packages with classes, attributes, and relationships (and in parallel, use cases and extend/include relationships).

The transformation from feature into structural models (Table 1) implies: a) Transform the Feature model into a UML model. b) Transform each RootFeature into a root Package, which includes a class with the same

name as the feature. c) Transform each mandatory FeatureGroup (i.e., with minimum cardinality greater than

zero, as in example 5 of Table 1) into a super-class of the set of classes generated by its owned GroupedFeature instances and generate an association with the class generated from the owner Feature.

d) Transform each optional FeatureGroup (i.e., with minimum cardinality equal to zero, as in example 4) into a package merged with the package associated with the parent feature. Then, inside this package, create a super-class of the set of classes generated by its owned GroupedFeature instances and an association with a duplicate of the class generated from the owner Feature.

e) Transform each mandatory GroupedFeature into a class that specializes the class generated by the owner FeatureGroup (CreditCard in example 5).

f) Transform each optional GroupedFeature into a package merged with the package associated with the parent feature. Then, inside the new package, create a class that specializes a duplicate of the class generated by the owner FeatureGroup (DebitCard in example 5)

g) Transform each mandatory SolitaryFeature typed as FEATURE into a class and associate it with the class generated from the owner feature (TaxationOp in example 3).

h) Transform each mandatory SolitaryFeature (all the subtypes except FEATURE) into a typed attribute and assign this attribute to the class generated from the owner feature (Login in example 1).

i) Transform each optional SolitaryFeature (all the subtypes) into a package merged with the package associated with the parent feature. Then:

a. Inside the new package, transform the SolitaryFeature typed as FEATURE into a class and, additionally, associate this class with a duplicate of the class generated from the owner feature with (ShippingOptions in example 3).

b. Inside the new package, transform the SolitaryFeature with type other than FEATURE into an attribute and assign this attribute to a duplicate of the class generated from the owner feature (ShippingAdresss in example 2).

The strategy is based on the three subtypes of Feature. The root of every tree in a feature model

(RootFeature) is transformed into a base package (and an initial class, which will generally be discarded) and a recursive transformation of SolitaryFeatures and FeatureGroups linked to every feature is carried out. The presence of a group implies a class associated to the parent feature that is specialized in several subtypes (one per alternative feature). Previously, a new merging package is created if the feature is optional. A similar set of transformations has been defined in parallel from feature patterns to use case diagrams. The complete definition of both sets of transformations, using QVT [26], can be found in [22]. The package content must be revised and completed, but the package structure itself can be used afterwards to automatically derive the


ISSN 1988–3455 SISTEDES, 2008 111

product model by selecting the desired features. This possibility compensates for the overcharge of complexity that the traceability management and the extensive use of packages in the architectural models entails.

Concerning the implementation details of the transformations, a partial implementation, using XML style sheets, was given in [21]. We used a combination of available tools, based on the Eclipse platform (fmp plug-in [11]) and Microsoft proprietary tools. The connection between them is achieved using intermediate XML files that can be automatically generated. The C# language and the Microsoft .NET platform have been selected because of the direct support of the package merge mechanism by means of partial classes. In [21] these experiences are described. The developed product line domains include Web and mobile based families of applications.

Work in progress includes the development, with the Microsoft DSL tools, of a specific domain language, functionally equivalent to the fmp eclipse plug-in, to integrate all the steps of the process, from goals analysis to application package configuration inside the Microsoft Visual Studio platform.

4 Related Work

Schobbens et al. [27] have reviewed the different variants of feature diagrams, clarifying the differences and establishing generic formal semantics. The influence of non-functional requirements preferences in variant selection has been faced by several methods. The original FODA proposal uses the feature models to represent all the types of variability, functional and non-functional [18]. Jarzabek et al. address the non-functional requirements and feature relationships in the PL context [15]. They extend FODA with concepts of goal-oriented analysis. The proposed framework allows developers to record design rationale in the form of interdependencies between variant features and soft-goals, with both models at the same level. Finally Yu et al. present a model-driven extension to their Early Requirements Engineering tool (OpenOME) in [31] that generates an initial feature model from stakeholder goals.

Also, the work devoted to relating feature constructions and architectural designs is abundant. Recent proposals express variability with UML models by modifying or annotating these models. Structural, functional or dynamic models have been used. Some authors have proposed explicitly representing the functional variation points by adding annotations or changing the essence of the use case diagrams. For example, Von der Maßen et al. [30] propose using new relationships ("option" and "alternative") and the consequent extension of the UML meta-model. John and Muthig [16] suggest the application of use case templates to represent the variability in PLs, using stereotypes. Concerning structural models, either the mechanisms of UML are used directly (through the specialization relationship, the association multiplicity, etc.), as in the case of Jacobson [14]; or the models are explicitly annotated using stereotypes. The work of Gomaa [10] is an example of this approach, since it uses the stereotypes <<kernel>>, <<optional>> and <<variant>> (corresponding to obligatory, optional, and variant classes). Similarly, Clauß proposes a set of stereotypes to express the variability in architecture models [4].

In the Czarnecki meta-model approach [9], the features are typed (including FEATURE type as default type and String, Integer, etc.). Additionally, we use other elemental types such as Date, Time, Money, directly translatable to conventional programming languages.

The mapping between requirements and design has always been considered complex for several reasons (flexibility and adaptability of the PL, technology options, availability of resources, etc.) [28]. The classical works of Kang and Lee [17, 18, 23], Czarnecky [7], Griss et al. [12], or Bosh [2] among others, have enabled the identification of a set of feature patterns that can potentially populate the intended catalog. Sochos et al. provide an analysis of the PL methods and propose strengthening the mapping between requirements and architecture by modifying the feature models [28]. The disadvantage is the introduction of implementation characteristics in the requirements models. Bragança et al. [3] propose the reverse transformation, obtaining features from use case


ISSN 1988–3455 SISTEDES, 2008 112

models. Their solution requires the UML meta-model extension and the use of annotations. Another solution, proposed by Czarnecki [6], consists of annotating the UML models with presence conditions, so that each optional feature is reflected in one or, more realistically, several parts of a diagram (which may be a class, an association, an attribute, etc. or a combination of elements). Although the class diagrams are the most used, the technique can be applied to any UML model, in particular the sequence or activity diagrams. Some tools are provided, such as an Eclipse plug-in for the definition and configuration of the feature model and an auxiliary tool to show the presence condition in UML models. We think that our package approach is a better solution as it uses conventional UML CASE tools.

5 Conclusions and future work

In this article, the possibilities provided by the combination of different modeling paradigms to represent and configure variability in a product line are discussed. The main contribution is the identification of patterns in feature models and their mapping into the corresponding architectural structures. The organization of the product line in packages that represent the common and optional parts is taken into account as an integral part of the transformations.

The feature patterns catalog enables the automated creation of traceability links between the product line feature and the architectural models. A set of transformations based on QVT are defined to obtain the UML behavioral and structural models, including the package structures. Work in progress includes the development of a specific domain language (based on the feature meta-model) that will connect all the phases of the process, from goal analysis to the application package configuration in the same tool, using these traceability links.

As future work, an advanced vision is based more strictly on the MDE paradigm, automating most of the phases of product line development. Firstly, the set of UML structural and behavior models are obtained using the feature pattern transformations (manual completion of these models will always be required). Then, the goal based configuration process yields a subset of packages that will be merged into a (platform independent) combined model using existing MDE tools. The resulting PIM will be used as input to code generator tools. These tools are precisely intended to generate the platform specific models and the final code. We are evaluating some of the best known tools in order to assess the practical possibilities of the product line and MDE paradigms alliance.

Acknowledgements

This work has been supported by the Junta de Castilla y León (project VA018A07).

References

1. Antkiewicz, M., Czarnecki, K.: Feature modeling plugin for Eclipse. In OOPSLA’04 Eclipse technology exchange workshop (2004)

2. Bosch, J.: “Design & Use of Software Architectures. Adopting and Evolving a Product-Line Approach”. Addison-Wesley (2000)

3. Bragança, A., Machado, R. J.: "Automating Mappings between Use Case Diagrams and Feature Models for Software Product Lines", Proceedings of SPLC 2007, pp 3-12, Kyoto, Japan, IEEE CS Press (2007)

4. Clauß, M.: Generic modeling using Uml extensions for variability. In Workshop on Domain Specific Visual Languages at OOPSLA 2001 (2001)

5. Clements, P. C., Northrop, L.: “Software product lines: Practices and Patterns”. SEI Series in Software Engineering, Addison-Wesley (2001)


ISSN 1988–3455 SISTEDES, 2008 113

6. Czarnecki, K., Antkiewicz, M.: Mapping features to models: a template approach based on superimposed variants, In proceedings of GPCE’05, LNCS 3676, Springer, pp. 422-437 (2005)

7. Czarnecki, K., Eisenecker, U. W.: “Generative Programming: Methods, Tools, and Applications”, Addison-Wesley (2000)

8. Czarnecki, K., Helsen. S.: “Classification of Model Transformation Approaches”. OOPSLA’03 Workshop on Generative Techniques in the Context of Model-Driven Architecture (2003)

9. Czarnecki, K., Helsen, S., Eisenecker, U.: Staged Configuration Through Specialization and Multi-Level Configuration of Feature Models. Software Process Improvement and Practice, 10(2), pp. 143 – 169 (2005)

10. Gomaa. H.: Object Oriented Analysis and Modeling for Families of Systems with UML. InW. B. Frakes, editor, IEEE International Conference for Software Rreuse (ICSR6), pages 89–99, (2000)

11. González-Baixauli, B., Leite J.C.S.P., Mylopoulos, J. “Visual Variability Analysis with Goal Models”. Proc. of the RE’2004. Kyoto, Japan. IEEE Computer Society, 2004. pp: 198-207 (2004)

12. Griss, M.L., Favaro, J., d'Alessandro, M., "Integrating feature modeling with the RSEB", Proceedings of the Fifth International Conference on Software Reuse, p.76-85. (1998)

13. Halmans, G., and Pohl, K., “Communicating the Variability of a Software-Product Family to Customers”. Journal of Software and Systems Modeling 2, 1, 15—36 (2003)

14. Jacobson I., Griss M. and Jonsson P. “Software Reuse. Architecture, Process and Organization for Business Success”. ACM Press. Addison Wesley Longman. (1997)

15. Jarzabek, S.; Yang, B.; Yoeun, S., "Addressing quality attributes in domain analysis for product lines," Software, IEE Proceedings - , vol.153, no.2, pp. 61-73, (2006)

16. John, I., Muthig, D.: Tailoring Use Cases for product line Modeling. Proceedings of the International Workshop on Requirements Engineering for product lines 2002 (REPL’02). Technical Report: ALR-2002-033, AVAYA labs, (2002)

17. Kang, K. C., Kim, S., Lee, J. y Kim, K. “FORM: A Feature-Oriented Reuse Method with Domain-Specific Reference Architectures”. Annals of Software Engineering, 5:143-168 (1998)

18. Kang, K. C., Cohen, S., Hess, J., Nowak, W., Peterson, S.: “Feature-Oriented Domain Analysis (FODA) Feasibility Study”. Technical Report, CMU/SEI-90-TR-21, Software Engineering Institute (Carnegie Mellon), Pittsburgh, PA 15213 (1990)

19. Kazman, R., Klein, M., Clements, P.: ‘ATAM: method for architecture evaluation’, Technical Report CMU/SEI-2000-TR-004,Software Engineering Institute, Carnegie Mellon University,Pittsburgh, PA, USA (2000)

20. Laguna, M.A., González-Baixauli, B.: Product Line Requirements: Multi-Paradigm Variability Models. Proceedings of the 11th Workshop on Requirements Engineering WER 2008, Barcelona, Spain (2008)

21. Laguna, M.A., González-Baixauli, B., Marqués, J.M.: Seamless Development of Software Product Lines: Feature Models to UML Traceability. Sixth International Conference on Generative Programming and Component Engineering (GPCE 07). Salzburg, Austria (2007)

22. Laguna, M.A., González-Baixauli, B., Marqués, J.M.: Feature Patterns and Multi-Paradigm Variability Models, GIRO Technical Report 2008/01, University of Valladolid (2008). Available at http://www.giro.infor.uva.es/Publications/

23. Lau, S.: “Domain Analysis of E-Commerce Systems Using Feature-Based Model Templates”, MASc Thesis, ECE Department, University of Waterloo, Canada, 2006.

24. Lee, K., Kang, K. C., Chae, W., Choi, B. W.: “Feature-Based Approach to Object-Oriented Engineering of Applications for Reuse”. Software: Practice and Experience, 30(9):1025-1046. 2000.

25. Object Management Group: “MDA Guide Version 1.0” (2003) 26. Object Management Group and QVT-Merge Group: “Revised submission for MOF 2.0

Query/View/Transformation version 2.0” Object Management Group doc. ad/2005-03-02 (2005) 27. Schobbens, P., Heymans, P., Trigaux, J., and Bontemps, Y. Generic semantics of feature diagrams.

Comput. Netw. 51, 2, 456-479 (2007) 28. Sochos, P., Philippow, I., Riebish, M.: Feature-oriented development of software product lines: mapping

feature models to the architecture. Springer, LNCS 3263, pp. 138-152 (2004) 29. van Deursen, A., Klint P.: “Domain-Specific Language Design Requires Feature Descriptions”. Journal

of Computing and Information Technology 10(1):1-17 (2002) 30. von der Massen, T., Lichter, H.: “RequiLine: A Requirements Engineering Tool for Software product

lines”. In Software Product-Family Engineering, PFE 2003, Siena, Italy, LNCS 3014 pp 168-180 (2003) 31. Yu, Y., Lapouchnian, A., Liaskos, S., Mylopoulos, J., Leite., J.C.S.P.: From goals to high-variability

software design, pp. 1-16, In: 17th International Symposium on Methodologies for Intelligent Systems (ISMIS'08) (2008)


ISSN 1988–3455 SISTEDES, 2008 114

http://www.giro.infor.uva.es/Publications/�

dsls para la extraccion de modelos en modernizaci´on

Documents