DSLs para la extracción de modelos en modernización

Transcripción

1 DSLs para la extracción de modelos en modernización Javier Luis Cánovas Izquierdo, Óscar Sánchez Ramón, Jesús Sánchez Cuadrado, y Jesús García Molina Departamento de Informática y Sistemas Universidad de Murcia {jlcanovas,osanchez,jesusc,jmolina}@um.es Resumen. La Modernización Dirigida por Modelos ha emergido recientemente como una nueva área de investigación dedicada a la automatización basada en modelos de procesos de evolución de software. En los próximos años se necesitará un gran esfuerzo para encontrar principios, técnicas y métodos para esta nueva área y será crucial la experiencia adquirida en el desarrollo de casos de estudio reales de modernización. En este artículo presentamos dos DSLs para la extracción de modelos: Gra2MoL para la extracción a partir de código fuente conforme a una gramática y H2MoL para el caso de texto que no está bien formado, como por ejemplo HTML. El diseño de estos lenguajes es fruto de la experiencia adquirida en un proyecto de migración de aplicaciones de la plataforma Struts a JSF, en el que se han aplicado las técnicas basadas en modelos. Palabras clave: Modernización dirigida por modelos, Gra2MoL, H2MoL, extracción de modelos 1 Introducción Las técnicas de Desarrollo de Software Dirigido por Modelos (DSDM) no son solamente útiles para la creación de nuevos sistemas software sino también para la modernización de sistemas existentes. De este modo, la Modernización de Software Dirigida por Modelos (MSDM) ha emergido recientemente como un nuevo paradigma para abordar la automatización basada en modelos de las actividades de evolución del software. En esta dirección el OMG ha propuesto varios estándares de modernización dentro de la iniciativa ADM [1]. En los próximos años se requerirá un gran esfuerzo para encontrar principios, técnicas y métodos para esta nueva área, y la experiencia adquirida en el desarrollo de casos de estudio de modernización reales será crucial. De acuerdo con los objetivos de un proyecto de modernización, se pueden distinguir varios escenarios [2], como la migración de plataformas o la conversión de lenguajes. Además, con frecuencia un problema de modernización abarca más de un escenario. Las características de un escenario de modernización determinan las tareas necesarias para llevar cabo el proyecto. En este artículo presentamos un caso de estudio de Modernización Dirigida por Modelos para un escenario de migración de plataformas: la migración de un sistema web basado en Struts a un sistema Java Server Faces (JSF). Nos referiremos a este caso de estudio como Struts2JSF. Este proyecto ha servido para experimentar en las tres principales etapas de un proyecto de modernización dirigido por modelos: extracción de los modelos de los artefactos fuente, rediseño del sistema y generación del nuevo sistema. Sin embargo, y por cuestiones de espacio, en este artículo nos centraremos en las aproximaciones que hemos ideado para solucionar los retos aparecidos durante la extracción de modelos, que es la etapa que actualmente requiere de una mayor labor de investigación. En concreto, presentaremos Gra2MoL como lenguaje para extraer modelos a partir de código conforme a una gramática y H2MoL como lenguaje para extraer modelos en base a texto que ISSN SISTEDES,

2 no está bien formado, como por ejemplo HTML. En la migración Struts2JSF utilizaremos Gra2MoL para extraer modelo del código Java, H2MoL para código JSP y el framework EMF (Eclipse Modeling Framework) para ficheros XML. El documento está organizado de la siguiente manera. En primer lugar se describe el problema y los metamodelos de las plataformas. A continuación la sección 4 presenta las dos contribuciones principales del trabajo: dos lenguajes específicos del dominio dirigidos a la extracción de modelos a partir de los ficheros del sistema origen (por ejemplo código fuente Java o JSP). En la sección 5 se expone el trabajo relacionado y finalmente, se presentan las conclusiones y el trabajo futuro. 2 Descripción del problema Struts [3] es un framework para desarrollar aplicaciones web en Java que apareció en el año 2000, y que esta basado en la arquitectura Modelo-Vista-Controlador (MVC). Por otra parte, Java Server Faces (JSF) [4] apareció en el año 2004, con el objetivo de simplificar el desarrollo de interfaces web Java. Este framework también utiliza una arquitectura MVC y se ha convertido en un estándar de facto. La migración Struts2JSF es un ejemplo de escenario de migración de plataformas. Este escenario normalmente se combina con un escenario de conversión de lenguajes, aunque en este caso no se requiere debido a que las dos plataformas están basadas en el lenguaje Java. En general, un proceso de modernización requiere la creación de metamodelos que representen la arquitectura existente y la arquitectura destino. Dicho proceso consta de tres pasos principales: extracción de modelos a partir de los artefactos del sistema existente (ingeniería inversa), transformación de los modelos del sistema existente para generar modelos del sistema destino (rediseño) y generación de los artefactos del sistema destino (ingeniería directa). El proceso de modernización aplicado se muestra en la Figura 1. En primer lugar se extraen tres modelos conforme al metamodelo de la plataforma Struts a partir del código fuente Struts. Cada modelo Struts se transformará en su correspondiente modelo JSF. El último paso consiste en la generación de los ficheros fuente de la aplicación JSF usando transformaciones modelo-código. El código fuente con la lógica de negocio no requiere ningún tipo de transformación sino que se migra sin cambios. Fig. 1. Proceso de modernización aplicado en el caso de estudio Struts2JSF Puede observarse que tanto los artefactos de Struts como los de JSF se organizan en las mismas tres partes: clases Java, código JSP y ficheros de configuración XML. ISSN SISTEDES,

3 3 Metamodelos de las plataformas Todo proyecto de modernización basada en modelos necesita de metamodelos que describan las plataformas involucradas. En este caso de estudio no estamos interesados en modelar completamente las plataformas Struts y JSF, dado que esto implicaría tratar con demasiados elementos y variantes de codificación. En cambio nos hemos centrado en un conjunto de características básicas como validación de formularios, navegación entre páginas, manejo de beans e internacionalización, que es suficiente para el objetivo de este caso de estudio. Además, dado que no se ha realizado un análisis semántico, el código reconocido se restringe a las convenciones de programación más utilizadas. A pesar de que no se necesitan metamodelos de Struts y JSF completos, el diseño es todavía complejo porque se debe representar el lenguaje Java y la arquitectura MVC. Para mejorar la modularidad, los metamodelos de Struts y JSF se han organizado en tres paquetes, uno por cada una de las partes mencionadas en la sección anterior: JSP, beans y configuración. Tanto Struts como JSF, aunque usan librerías de etiquetas específicas, se apoyan sobre la tecnología JSP. Por otra parte, los beans de Struts y JSF comparten conceptos Java comunes y extienden las metaclases definidas en los metamodelos comunes para especializarlas. Por ejemplo, es útil distinguir específicamente un método Struts validate, es decir, crear una metaclase validatemethod que hereda de la metaclase JavaMethod del metamodelo Java. Por lo tanto, se han desarrollado dos metamodelos reutilizables para JSP y Java que se comparten por ambos metamodelos, como puede observarse en la Figura 2. Esto ha permitido que los metamodelos sean más compactos y fáciles de mantener además de promover su reutilización 1. Fig. 2. Organización de paquetes de metamodelos. 4 Extracción de modelos El primer paso en un proyecto de MSDM consiste en la extracción de modelos a partir de los artefactos fuente existentes, tales como código fuente o ficheros de configuración XML. Estos modelos son conformes a los metamodelos de la plataforma origen y representan la información del sistema existente que es necesaria para crear el nuevo sistema. La extracción de estos modelos requiere establecer un puente entre diferentes espacios tecnológicos, en particular entre la tecnología del DSDM (modelware) y las tecnologías empleadas para describir el texto de los ficheros origen, normalmente gramáticas (grammarware) y esquemas XML. En un escenario de migración de plataformas, este puente es unidireccional y consiste en la creación de un analizador sintáctico que construye los modelos a partir de los artefactos fuente. Sin embargo, un sistema también puede estar formado por ficheros cuyo contenido no está bien formado (por ejemplo, HTML), donde las aproximaciones anteriores no pueden ser aplicadas. 1 Los metamodelos se pueden descargar de ISSN SISTEDES,

4 4.1 Extracción de modelos a partir de código conforme a una gramática La mayoría de los escenarios de modernización requieren tratar con código fuente cuya estructura puede ser expresada por una gramática. Por lo tanto, es posible utilizar herramientas que proporcionen un puente entre los espacios tecnológicos grammarware y modelware para llevar a cabo la extracción de modelos. Se han propuesto varias aproximaciones para establecer un puente entre las gramáticas y los modelos. xtext [5] y los trabajos de Wimmer et al. [6] y Kunert [7] son los ejemplos más destacables. Estos trabajos están basados en la generación automática de un metamodelo a partir de la gramática, y de un analizador sintáctico para la extracción de modelos. La utilidad de estas aproximaciones está restringida por varias limitaciones que surgen en situaciones prácticas. Desde nuestra experiencia, hemos identificado cuatro problemas principales: El bajo nivel de los metamodelos generados frecuentemente obliga a aplicar transformaciones modelo a modelo para obtener metamodelos de más alto nivel como un AST o un metamodelo KDM [8]. Esta idea aparece reflejada en la Figura 3, en la que se contrasta un metamodelo generado con el metamodelo deseado. Fig. 3. (a) Metamodelo generado a partir de la gramática de Java usando xtext. (b) Metamodelo de alto nivel deseado. Los modelos extraídos se almacenan normalmente en ficheros XMI. En proyectos de gran tamaño que contienen cientos de ficheros fuente, se puede producir la duplicación de información dado que los artefactos software están representados en los ficheros fuente y en los modelos. Esto hace que esta aproximación sea ineficiente en cuanto a tiempo y memoria. Determinada información derivada del análisis sintáctico tal como nombres de ficheros, líneas, columnas, etc. es importante en el proceso de modernización, principalmente para permitir la trazabilidad entre el código y el modelo. Esta información se pierde debido a que los metamodelos generados no la incluyen, y por lo tanto no se propaga a los modelos. Existe un catálogo considerable de definiciones de gramáticas para generadores de analizadores sintácticos como ANTLR [9] o JavaCC [10]. Además, los artefactos software se programan normalmente con lenguajes de programación con bastante difusión, como COBOL, C, o Java, y crear la gramática de un lenguaje de programación desde cero es una tarea difícil y que conlleva mucho tiempo. Las aproximaciones de modernización dirigida por modelos deberían permitir la reutilización de las definiciones de gramáticas para algún generador de analizadores sintácticos existentes. ISSN SISTEDES,

5 Con estos problemas en mente, hemos definido un DSL para la extracción de modelos denominado Gra2MoL [11], cuyas dos características más relevantes son: (i) incorpora un potente lenguaje de consultas para recorrer el árbol sintáctico y recuperar la información del código fuente, (ii) la gramática es utilizada para poder referenciar a los elementos de ésta en las consultas al árbol sintáctico. Gra2MoL nos permite especificar explícitamente las relaciones entre los elementos de la gramática origen y los elementos de un metamodelo destino, y trata el código fuente como un modelo usando la definición de gramática subyacente como si se tratara de un metamodelo. La Figura 4 ilustra el esquema de Gra2MoL. Fig. 4. Esquema de Gra2MoL. El código fuente P G es conforme a la gramática G y el modelo M T es conforme a el metamodelo MM T. T denota al processo de transformación y Mapping Gra2M ol son las correspondencias expresadas con Gra2MoL entre G y MM T. La entrada de una transformación Gra2MoL es código fuente junto con la definición de la gramática a la que conforma y una definición de transformación (mapping). En primer lugar el código fuente se analiza sintácticamente para construir un árbol sintáctico y la definición de la transformación trata con dicho árbol, utilizando la gramática para tipar los nodos. En los árboles sintácticos, las referencias entre elementos se establecen implícitamente por medio de identificadores. Por otra parte, los modelos son grafos donde las referencias entre elementos son explícitas. Transformar una referencia basada en identificadores en una referencia explícita implica buscar el nodo identificado que puede estar fuera del ámbito de la regla que realiza la transformación. Por tanto, las transformaciones gramática a modelo realizan un uso intensivo de consultas sobre todo el árbol sintáctico para recuperar información que está fuera del ámbito de la regla actual. En [12] este tipo de transformaciones se denomina transformaciones global a local. Si se usase la notación punto para escribir estas consultas, se necesitaría una larga cadena de navegación. Por esta razón hemos desarrollado un lenguaje de consultas inspirado en Xpath [13] para extraer información que está dispersa a lo largo del código fuente y para permitir la navegación del árbol sintáctico sin necesidad de especificar cada paso de navegación, con lo que se evita especificar largas expresiones de navegación. En el caso de estudio Struts2JSF, Gra2MoL nos ha permitido extraer modelos del código fuente Java del sistema Struts. Para ello hemos implementado una definición de transformación entre los elementos de la gramática Java y los elementos del metamodelo StrutsBeans. Por ejemplo, el siguiente código muestra una regla que extrae un elemento ValidateMethod del metamodelo a partir de un elemento methoddeclaration de la gramática 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 SISTEDES,

6 name.identifier = md.identifier; name.strvalue = md.identifier; parameters = fp; statements = st; returntype = t; end_rule Una regla Gra2Mol tiene cuatro secciones. La sección from especifica los símbolos no terminales de la gramática origen (en el ejemplo es methoddeclaration y filtra los métodos llamados validate) y declara una variable que será ligada a un nodo del árbol cuando se aplique la regla (en el ejemplo es cbd). Esta variable puede ser usada en cualquier expresión dentro de la regla. La sección to especifica la metaclase del elemento del metamodelo destino (en el ejemplo es ValidateMethod). La sección de consultas (queries) contiene un conjunto de expresiones de consulta que sirven para asignar a variables determinados elementos del código fuente. Finalmente, la sección mappings contiene un conjunto de bindings para asignar valores a las propiedades de los elementos del modelo destino en base a las variables definidas en la sección de consultas. Estos bindings son un tipo especial de asignación utilizada en lenguajes de transformación de modelos como RubyTL [14] y ATL [15]. Atendiendo a la parte de las consultas, una consulta se compone de un conjunto de operadores 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 notación punto. Por otra parte, los operadores // y /// permiten la navegación de todos hijos del nodo (directos e indirectos) recuperando todos los nodos de un tipo dado. Estos dos operadores permiten ignorar nodos superfluos intermedios, facilitando la definición de la consulta, dado que se especifica qué tipo de nodos deben ser encontrados pero no cómo alcanzarlos. El operador /// difiere ligeramente del operador //. Mientras que el operador /// busca recursivamente en el árbol sintáctico, el operador // solo selecciona aquellos nodos cuya profundidad es menor o igual que la profundidad del primer nodo seleccionado. De este modo el operador /// sólo se utiliza para extraer información de estructuras gramaticales recursivas. Por ejemplo, en la consulta /cbd//formalparameters///#formalparameterdecls de la regla ValidateMethod, una vez que se ha seleccionado un elemento formalparameters, se recupera la lista de parámetros del método. Los operadores de consulta pueden incluir expresiones de filtro opcionales y una expresión de tipo índice tales que solo aquellos nodos que satisfagan dichas expresiones serán seleccionados. En el ejemplo anterior, la consulta /cbd//#methoddeclaration{identifier.exists} define una expresión de filtro de modo que solo se seleccionarán aquellos nodos de tipo methoddeclaration que tiene una hoja del árbol de tipo Identifier. En cuanto a la extracción de modelos a partir de ficheros XML, un sistema Struts involucra un fichero de configuración XML que es conforme a un esquema XML. Actualmente existen herramientas para construir un puente entre los espacios tecnológicos XML y modelware, tales como las existentes en el proyectos EMF de la plataforma Eclipse. En este caso de estudio hemos utilizado EMF para extraer modelos de los ficheros de configuración. Estos modelos, aunque reflejan la estructura del esquema XML, han resultado adecuados dado que la definición de la transformación de los ficheros de configuración es prácticamente directa. 4.2 Extracción de modelos a partir de texto no bien formado En esta sección abordaremos el problema de la extracción de modelos a partir de texto que no es conforme a ningún formalismo (como una gramática o un esquema XML), por lo que son necesarios reconocedores dedicados. En aplicaciones web el ejemplo prototípico son las páginas HTML y las plantillas como JSP o ASP. Los navegadores web tienen reconocedores dedicados para tratar con las diferentes variantes de HTML. Los lenguajes de plantillas no ISSN SISTEDES,

7 consideran el contenido de la plantilla sino que simplemente se encargan de ejecutar el código scriptlet añadiendo el resultado a la salida estándar. Por ejemplo, el siguiente fragmento de código JSP es una página HTML que contiene etiquetas HTML, etiquetas Struts y código scriptlet. <%@ taglib uri=" prefix="html"%> <%@ taglib uri=" 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 válido por dos razones: (i) no se permite código scriptlet en un XML y (ii) algunas etiquetas como <p> no están cerradas. Es importante destacar que incluso aunque es una mala práctica escribir código como éste, la mayoría de los sistemas existentes están construidos con este estilo. Para tratar con el primer problema hemos creado un pequeño preprocesador basado en el uso de expresiones regulares que sustituye código scriptlet por comentarios XML. Posteriormente un paso de postprocesamiento extraerá el código scriptlet de los comentarios. Daremos más detalles más adelante. Para el segundo problema no es posible usar una plantilla XSLT, un analizador XML, el framework EMF o Gra2MoL porque el código HTML puede ser inconsistente, es decir, no es un XML válido o no es conforme a la gramática HTML. Por esta razón habría que crear un analizador dedicado. Sin embargo, crear este analizar sintáctico consume tiempo y es propenso a errores debido a la variedad de casos que debe manejar. Por tanto hemos definido la siguiente aproximación. Primero hemos utilizado una de las API existente en Ruby (HTree [16]) para convertir texto HTML 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 siguiente paso 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 ellos aplicar un lenguaje de transformación de modelos. Sin embargo, los únicos elementos que deseamos hacer corresponder entre plataformas son las etiquetas específicas de Struts y JSF, mientras que el resto de las etiquetas HTML se traducirán a una etiqueta genérica (GenericHTMLTag). Por lo tanto un mecanismo para establecer correspondencias genéricas entre patrones del nombre de la etiqueta HTML aumentaría la legibilidad, productividad y la facilidad de mantenimiento que la aplicación de un lenguaje de transformación de modelos, donde es necesario escribir reglas con diferentes filtros para tratar cada tipo de etiqueta. Por esta razón, para abordar el problema de los artefactos XML no bien formados, hemos ideado un lenguaje de transformación específico del dominio denominado H2MoL implementado como un DSL embebido en Ruby. Este lenguaje nos permite especificar qué partes de la página JSP serán ignoradas (que no son conformes a XML) con el fin de realizar la etapa de preprocesamiento. Internamente se utiliza HTree para transformar el código HTML en XHTML que posteriormente es procesado con un analizador sintáctico XML. Además, proporciona construcciones para especificar como transformar etiquetas XML en elementos del metamodelo destino. Es importante destacar que este DSL no está acoplado con nuestro metamodelo JSP sino que puede ser utilizado con cualquier metamodelo destino. El único requisito es que el metamodelo destino tenga estructura de árbol. A continuación se muestra un fragmento de código H2MoL utilizado para establecer la correspondencia entre páginas JSP con etiquetas Struts a nuestro metamodelo JSP de JSF. ISSN SISTEDES,

8 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 utilizan para 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 último parámetro de la sentencia (por ejemplo, un elemento GenericHTMLTag se almacena en la propiedad tags del elemento padre). Los tipos de sentencias son los siguientes: sub. Toma una expresión regular con el fin de reconocer un fragmento de texto XML no legal. También se puede utilizar una metaclase para especificar un elemento del modelo que se creará cuando el texto se reconozca. El motor de ejecución es el encargado de sustituir la porción de texto con un comentario XML como se ha explicado antes y de establecer las correspondencias necesarias. map. Reconoce cualquier etiqueta XML cuyo prefijo y nombre concuerden con el identificador o expresión regular dados. pre. Reconoce cualquier etiqueta XML prefijada por la etiqueta indicada o que concuerda con la expresión regular dada. generic. Cualquier nodo XML que no forme parte de una de las correspondencias anteriores es tomado por esta sentencia. Es importante destacar que solo es posible definir una sentencia de este tipo. En cuanto a la ejecución de las sentencias, conviene mencionar que una vez que una sentencia se ejecuta con un nodo XML el resto de sentencias no se ejecutan. De hecho, el orden de prioridad de las sentencias es el siguiente: sub, map, pre, generic. El uso de esta aproximación aporta varias ventajas sobre la creación de un inyector y el uso de un lenguaje de transformación de modelos general [12]: La operación sub nos permite aplicar esta estrategia para JSP, ASP y cualquier otro motor de ejecución de plantillas de un modo genérico. La sentencia generic hace posible la realización de correspondencias genéricas. Además tratar con prioridades es más sencillo que escribir filtros en reglas de transformación para asegurar una estrategia de aplicación de reglas apropiada. Este DSL se ejecuta directamente sobre el texto HTML sin apoyarse en ficheros XMI intermedios con lo que se obtiene una mejora del rendimiento. 5 Trabajo relacionado La extracción de modelos a partir de código fuente es un área que todavía no tiene la madurez deseada, aunque ya se han presentado varias propuestas interesantes. Entre ellas destacamos el framework MoDisco y las propuestas para conectar las técnicas propias de las gramáticas (grammarware) con las técnicas del DSDM (modelware), como son la herramienta xtext incluida en el toolkit openarchitectureware y los trabajos de Wimmer y Kunert. MoDisco (Model Discovery) [17] es una aproximación extensible para ofrecer soporte a la extracción de modelos de sistemas existentes que ha sido definida como parte del proyecto GMT [18] de Eclipse. Los componentes del framework MoDisco son: un metamodelo basado en KDM [8], un mecanismo de extensión del metamodelo, varias facilidades de manipulación de modelos, y una metodología para diseñar extensiones. Actualmente, debido a que está en desarrollo sólo ofrece la infraestructura para manejar y crear modelos. MoDisco define el ISSN SISTEDES,

9 concepto de discoverer, que es un componente software capaz de analizar un sistema existente (por ejemplo código Java), y extraer un modelo mediante la infraestructura proporcionada. La finalidad de MoDisco no es cubrir todos los aspectos de un proceso de modernización sino únicamente ofrecer la infraestructura necesaria para la construcción de discoverers. De esta forma, Gra2MoL puede ser utilizado para la implementación de los discoverers. xtext [5] es un lenguaje que pertenece al framework openarchitectureware [19] y permite construir DSLs textuales en la plataforma Eclipse. En este lenguaje, la sintaxis concreta textual del DSL se especifica por medio de un lenguaje de definición de gramáticas similar a EBNF. A partir de la gramática especificada se genera automáticamente el metamodelo del DSL, un analizador sintáctico para reconocer la sintaxis del DSL y para instanciar el metamodelo, y un editor específico del DSL. Wimmer [6] et. al. han propuesto un framework genérico para conectar el grammarware y el modelware. El funcionamiento de este framework se resume en dos etapas. En una primera etapa, se aplican un conjunto básico de reglas para generar un metamodelo no refinado a partir de una gramática EBNF tales como las generadas por xtext. En la segunda etapa se aplican varias heurísticas para mejorar dichos metamodelos. De forma similar, en Kunert [7] se opta por añadir anotaciones a la gramática con el objetivo de guiar el proceso de generación. Es importante destacar que no existen herramientas que soporten estas dos últimas aproximaciones. Las principales desventajas de xtext y los trabajos de Wimmer et. al y Kunert se han comentado en la sección 4.1. Gra2MoL carece de estas deficiencias dado que permite crear directamente modelos que conformen a un metamodelo cualquiera como puede ser KDM o un metamodelo AST. Para ello, se especifica la definición de una transformación de una gramática a un metamodelo. Dado que Gra2MoL ha sido diseñado explícitamente para trabajar con este tipo de transformaciones, es más fácil escribir estas transformaciones que cuando se utiliza un lenguaje de transformación de modelos común. Gra2MoL también nos permite acceder a información tales como la línea y columna donde se localiza un nodo en el código fuente. Además, puesto que Gra2MoL no utiliza un lenguaje especial para definir la gramática, sino ANTLR [9], se promueve la reutilización de gramáticas existentes. 6 Conclusiones y trabajo futuro En los próximos años, la realización de casos de estudio será crucial para que la Modernización de Software Dirigida por Modelos madure como disciplina. La experimentación con los casos de estudio ayudará a identificar qué cuestiones deben ser resueltas, así como probar las aproximaciones propuestas. En este artículo hemos presentado parte de los resultados de un proyecto de migración de un sistema Struts a un sistema JSF, en concreto, el trabajo relacionado con la fase de extracción de modelos. Los retos que hemos identificado relacionadas con esta fase son: (i) necesidad de diseñar metamodelos modulares para promover la separación de conceptos y la reutilización y (ii) utilización de técnicas eficientes y efectivas de extracción de modelos de artefactos fuente. Hemos presentado una aproximación para cada uno de estos retos. Los metamodelos han sido diseñados de una forma modular de modo que compartan conceptos comunes, facilitando así su mantenimiento y reutilización. Hemos analizado diversas soluciones para la extracción de modelos a partir de código conforme a una gramática y hemos justificado el uso de Gra2MoL frente a otras alternativas como xtext. Para la extracción de código conforme a un esquema XML hemos recurrido al framework EMF, y para la extracción de modelos de texto no bien formado hemos creado un DSL llamado H2MoL con la finalidad de tratar con código HTML no bien formado. En cuanto al trabajo futuro, continuaremos trabajando en Gra2MoL. Actualmente estamos estudiando la adecuación de la estructura de reglas (que actualmente es dirigida por el ISSN SISTEDES,

10 origen), ya que la experiencia adquirida en este caso de estudio nos ha inducido a cuestionar la necesidad de una aproximación dirigida por el destino. También seguiremos mejorando H2MoL para que sea posible incluir condiciones de filtrado más complejas. Finalmente en este caso de estudio hemos trabajado con metamodelos ad-hoc para representar las plataformas, pero una alternativa para afrontar la fase de metamodelado es el uso de KDM. Sin embargo, debido al reducido número de casos de estudio prácticos con KDM, todavía no están claras las ventajas de éste. Como línea de trabajo futuro, planeamos estudiar esta alternativa en profundidad. Agradecimientos Este trabajo ha sido parcialmente financiado por los proyectos TIC-INF 06/ de la Consejería de Educación y Cultura (CARM) y 05645/PI/07 de la Fundación Séneca. Javier Luis Cánovas Izquierdo dispone de una beca FPI de la Fundación Séneca y Jesús Sánchez Cuadrado dispone de una beca FPU del Ministerio de Educación y Ciencia. Referencias 1. ADM ADM Task Force. Architecture-driven modernization scenarios. Scenario White Paper(pdf).pdf 3. Struts JSR 127 Java Server Faces (JSF) Specification Efftinge, Sven. openarchitectureware 4.1 Xtext language reference xtextreference.pdf 6. Wimmer, Manuel and Kramler, Gerhard. Bridging Grammarware and Modelware. Satellite Events at the MoDELS 2005 Conference Andreas Kunert. Semi-automatic Generation of Metamodels and Models from Grammars and Programs. Fifth Intl. Workshop on Graph Transformation and Visual Modeling Techniques Electronic Notes in Theorical Computer Science 8. ADM Task Force. Knowledge Discovery Meta-Model (KDM) Parr, Terence. The Definitive ANTLR Reference: Building Domain-Specific Languages. Pragmatic Programmers Java Compiler Compiler J. Cánovas Izquierdo, J. Sánchez Cuadrado and J. García Molina. Gra2MoL: A domain specific transformation language for bridging grammarware to modelware in software modernization. 2nd Workshop on Model-Driven Software Evolution. 12th European Conference on Software Maintenance and Reengineering J. van Wijngaarden and E. Visser. Program Transformation Mechanics. A Classification of Mechanisms for Program Transformation with a Survey of Existing Transformation Systems. Technical Report UU-CS Department of Information and Computing Sciences, Utrecht University Xpath J. Sánchez Cuadrado and J. García Molina. A plugin-based language to experiment with model transformation. 9th International Conference in Model Driven Engineering Languages and Systems. Volume 4199 of Lecture Notes in Computer Science. Springer (2006) F. Jouault and I. Kurtev. Transforming Models with ATL HTree MoDisco project GMT project Open Architecture Ware. ISSN SISTEDES,

11 A Domain Specific Language for the Internet of Things Pau Giner, Joan Fons, y Vicente Pelechano Centro de Investigación en Métodos de Producción de Software Universidad Politécnica de Valencia Camino de Vera s/n, Valencia, Spain {pginer,jjfons,pele}@pros.upv.es Resumen. Information Systems supporting organizational Business Processes usually deal with real-world objects. The information about these physical elements is commonly provided by human beings, which is far from being efficient. Automatic identification technologies can improve this linkage. Thanks to RFID, books in a library can be borrowed just by picking them up. However, due to technological heterogenity and the fast-changing requirements of Business Processes, ad-hoc solutions difficult system maintainability and evolution. The present work, based on the foundations of Model Driven Engineering, introduces modeling primitives to capture the requirements for this physical-virtual connection. These primitives permit to define an abstract specification that is useful to reason about the system and can guide its development, or even derive the system automatically. Finally, this paper presents how these ideas have been applied to the Smart Toolbox application. 1 Introduction Information Systems are no longer constrained into the Digital Space. Business Processes usually deal with physical objects such as products in a supermarket or baggage pieces in an 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 virtual worlds. Thanks to Ubiquitous Computing (Ubicomp) technologies, Information Systems can get closer to the real world [16]. The linkage between physical elements and their digital counterparts gets automated, and people can focus on their real world activities, while the system is hidden in the background. Automatic Identification (Auto-ID) technologies enable real-world objects to be taken automatically in consideration by a software system, thus objects become smart as they are not human-dependent anymore [15]. Traditionally, identification aspects have been completely overlooked in the design of Information Systems as there were few options available to identify any physical object. Normally the common identification mechanism was to delegate in human skills such as reading a serial number to extract the identity of an object and transfer this by means of conventional interaction devices mainly keyboards and mice to the 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 Identifications (RFID), Smartcards, barcodes, magnetic strips, and contact memory buttons to name 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 specification perspective by the use of Domain Specific Languages (DSLs) [8]. The integration of real-world objects in Information Systems is commonly faced from a technological perspective. 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 TIN and cofinanced by FEDER. ISSN SISTEDES,

12 the evolution of the system, as identification mechanisms are coupled with a certain technological solution. Thus, benefits provided by DSLs in terms of easy of specification and maintenance [3], are quite relevant for this kind of applications. The main contribution of this work is the definition of a DSL to specify the linkage between digital and physical worlds in Information Systems. With the proposed DSL, system descriptions are kept close to the domain facilitating system specification and they are technologically independent improving system evolution. Developers for the Internet of Things can use this language to state their requirements in a technology-agnostic fashion and the modeling community has an opportunity to apply their tools and techniques for the development of this new kind of systems. The remainder of the paper is structured as follows. In section 2, a precise characterization is given about the kind of system this work is dealing with. Section 3 introduces the DSL defined. Section 4 gives some insights about the application of the DSL for the development of a case study. Related work is presented in section 5. Finally, section 6 presents conclusions and further work. 2 Domain Analysis DSLs describe concisely problems of a certain domain. Thus, domain knowledge is vital for the definition of a DSL. Prior to the design of the language [12], the analysis of the domain is necessary. In order to do so, the following steps are required [17, 3]: identify the problem domain of interest, gather all relevant knowledge of this domain, and cluster this knowledge in a handful notions and operations on them. Each of these steps are detailed below for the kind of applications considered in this work. Once domain concepts are clearly defined, a DSL based on these concepts can be designed. 2.1 Domain Identification The present work deals with Information Systems that integrate real-world elements to support Business Processes in an organization. This definition is quite broad but we are focused on applications where this linkage is highly exploited and identification specially Auto-ID is relevant. These systems contain several elements suitable to be identified by means of potentially different technologies. In order to illustrate the DSL defined in the present work, we are using examples based on the Smart Toolbox [10] application. This case study consists in monitoring the tools used for aircraft maintenance tasks. During aircraft reparations, the system should prevent tools from being lost and causing potential damage. In order to do so, the content, the location and the carrier of the toolbox is sensed automatically in real-time. This application improves the 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 specific to this domain in order to characterize it. For our domain of interest, the core concept is the identification mechanism. The identification mechanism is in charge of preserving the real-virtual linkage. In the present section we define the aspects that are particular to this mechanism in order to better characterize the domain. A conceptual framework for the description of the elements involved in the identification process was presented in [7]. Ubicomp systems integrate different services sensors and actuators seamlessly in the environment. Identification mechanisms can be considered as a specific kind of sensor and ISSN SISTEDES,

13 actuator combination e.g., a printing service combined with a barcode reading one. However, some properties specific to identification, not present when considering these sensors and actuators independently, emerge when they are part of an identification system. These properties are described below. Limited replaceability. The functionality that an identification system provides is wellknown [9]. Functions to create or acquire identifiers are common to any identification technology. However, in contrast to common sensors, the replaceability of services involved 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 digital word is not trivial. Some compensatory measures such as label all products with RFID 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 and their virtual counterpart is not always one to one. Physical elements can share the same identifier i.e.: products that are labelled indicating their product type or contain multiple identifiers i.e.: a human-readable numeric code accompanying a barcode. Distributed processes. Systems of this kind usually expand across organizations involving diverse computing resources. Labels are commonly produced by one system and read by 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 several modelling dimensions in order to better structure the domain knowledge and reduce dependencies among concepts. These are data dimension, technological dimension and responsibility dimension. Each dimension represents a different viewpoint of the system. Data dimension stresses the relevance of information. The Technological dimension perceives the identification mechanism as a device that bridges digital and physical spaces. Finally, the Responsibility dimension describes the organization of elements for a certain task in a compositional view. More detail 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 modelling primitives that conform the abstract syntax of the DSL are detailed below for each detected dimension. The Smart Toolbox example has been used to illustrate the proposal. Fig. 1 presents the specification of the example using the DSL. However, the concrete syntax used in examples is not normative. Further research is needed to determine the best concrete syntax 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 of information are organized in classes and relationships between these classes. The relevant information for all the members of a class is expressed by means of attributes. It can be modelled 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 to this toolbox. There are different types of tools. A ToolKind represents the tools of the same ISSN SISTEDES,

14 Fig. 1. Specification for the example using the DSL type and it provides information regarding tool lifetime. In this model there is no distinction between information that is pure digital such as ToolKind and the information that has some real-world object associated with it. To manage the complexity in the multiplicity of the real-virtual linkage, we consider that even information without a physical counterpart can 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 elements with the services used for identification. Several primitives are defined to make this relationship as flexible as possible. The defined primitives are mediums, codifications and technologies. The identity of an element is expressed following a codification at the Digital Space. This identity can be represented in the Physical Space in different mediums and some technologies 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 paper or a radio wave emitted by an RFID tag. Different mediums can be defined as needed. They can be related in a hierarchy to specialize 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 allow the extraction of the identifier. Two specializations are defined to distinguish an identifier expressed by means of numbers readable by humans from one expressed by means of an image more likely to be processed by a machine. ISSN SISTEDES,

15 Codifications Codifications represent a family of identifiers. Codifications usually are based on numbering schemas such as Electronic Product Code (EPC). We define some information to characterize the Codification primitive: Supported mediums: this is a set of mediums that are capable to hold a physical representation of an identifier for the present codification. An EPC code can have a numeric representation or it can be represented by means of radio weaves. The indicated mediums are possible representations. The final system will only support a subset of these mediums. Elements following the codification: indicated classes from the data model need to be identified by using the present codification. These restrictions usually respond to requirements of external organizations. Some companies such as Wal-Mart require their providers to use specific codifications for their products and adopting these codifications is a must to interoperate with their systems. If a class is required to be codified in more than one codification, all of them are considered. Data handling services: Codifications rely on services for retrieving the information about the identified elements, generate new identifiers and establish conversions between codifications. For this to work a common data format is assumed. XML or a more specific language such as Physical Markup Language (PML [4]), can be considered. Codifications represent the different ways in which the information at the Data dimension can be expressed, the mediums where this information can be transferred and the services that permit to do so. Technology Technologies in this context are defined as families of services that can be used for a certain codification in a given medium. In the example see Fig. 1, mechanics are identified on a numbers on paper medium. This means that reading services belonging to the Text Label technology can be used. This services could be a keyboard for the mechanic to introduce her identification number or an OCR device to read it automatically. The codification 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 the identification process. Services can act as minters the ones that generate physical representations of identifiers or readers services in charge of transmitting identifiers from the physical to the digital world. A printer can play the role of minter to translate identifiers to a barcode representation. A general video camera can be used as a reader for these barcodes but not for RFID tags. So there is a need to specify which services can be used for a certain technology. In addition, the multiplicity supported in identification should be indicated. Barcode readers usually read barcodes one-by-one, while RFID antennas can detect several tags per read. 3.3 Responsibility Dimension In an environment where objects are aware of other objects, the responsibility of identification cannot be assumed. In the case study, the responsible for determine which tools are contained in a certain toolbox is the own toolbox. This responsibility, previous to the usage of RFID technology was for the mechanic. These two scenarios responsibility for tool identification on (a) mechanic or (b) toolbox define completely different systems. Both scenarios are depicted in Figure 2, to illustrate the relevance of this aspect. In the scenario (a), mechanics can be equipped with a PDA and they indicate by hand which toolbox they are carrying and the tools that are contained in it. In the scenario (b), the toolbox can be equipped with an RFID antenna to detect labels on tools and mechanics. ISSN SISTEDES,

16 Fig. 2. Different possible responsibilities Evolving the system from one scenario to the other only requires to do the corresponding modification at modeling level. Responsibility Dimension presents real-world objects that are identifiable by the system and a hierarchy of responsibility of its identification. This model includes the relationships that each object is responsible of informing about for a certain task. This should be consistent with relationships established in the Data Dimension. Identifiable elements can be related using relationships of two kinds: responsibility and delegated responsibility. Responsibility relationship: The source element should obtain the information about the target element. Delegated responsibility relationship: The target element is considered an extension of the source element. This causes that the responsible of obtaining the source element is also responsible for the target element acquisition. In Figure 2, the dotted line between the toolbox and its tools in scenario (a), means that the Mechanic is in charge of identifying the tools. So the system should offer the needed mechanisms not only to indicate 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 by means of radio and numbers on paper mediums. Although identification of physical elements is the common case marked as sensed in the figure, alternatively it is also possible to mark a relationship as new or known. Elements marked as known are retrieved from the information repository whereas the new elements require the creation of the information at the digital space but also the minting of the associated physical element. Events Identification mechanisms are a kind of sensors that can detect interesting events of business level e.g., when the repairing task of the example is completed. In the example two events are defined. LocationChange and ContentMismatch. The first represents the toolbox going out of a particular location; the later indicates that the actual content is not the one 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 global event is defined combining both to indicate a mismatch in the content of a toolbox when the reparation has finished. 4 Applying the DSL The presented concepts have been formalized in a DSL by means of metamodeling technologies. A prototype of the Smart Toolbox example has been developed in order to detect how DSL concepts map to a specific implementation solution. ISSN SISTEDES,

17 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 constructs can be used and how they can be combined for the creation of models. Therefore, the language 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 definition of metamodels with precise semantics. The defined metamodel for this work is organized in different packages one for each detected dimension plus a core package with general concepts such as service or task. Figure 3 presents an excerpt of the metamodel 1, where some of the concepts from the technological dimension and relationships among them are shown. Using EMF facilities for the edition of models, a specification for the case study conforming to the DSL was defined see right hand side of Fig Driving the Implementation of the Case Study We have developed the Smart Toolbox case study example in order to detect how DSL concepts can map to a specific implementation architecture. These technological mappings help to 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 distribution and replaceability, the Smart Toolbox application has been implemented following a Service Component Architecture 2 (SCA). SCA is a vendor, technology and language neutral model for implementing Service Oriented Architectures (SOAs). Different technologies can be used for the implementation of SCA components and bindings, and an asynchronous communication model is provided. The configuration of components and their connection is decoupled from the implementation favouring replaceability of components. In addition, SCA components can be distributed in different computing nodes, from different threads in the same machine to different computers. For data 1 The complete metamodel can be obtained from ISSN SISTEDES,

18 interoperability we have used Service Data Objects (SDO). SDO makes it possible to hide the back-end data source, as it offers homogeneous access for XML, relational or file based data sources among others [14]. For our specific domain, we have defined two kind of components, Identification Components (ICs) and Services readers and minters. ICs are in charge of retrieving information using the different services or other identification components. Services encapsulate the technologies 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 connected to each other. Technological Mappings In the present section we illustrate how the different concepts defined in the DSL can be mapped to the target architecture. In this way, the production of the case study prototype is systematized. The knowledge obtained from the definition of these mappings is liable to be formalized in transformation rules and automate the development 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 Apache Tuscany was the chosen implementation of the SCA and SDO specifications. How DSL concepts 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 expressed as 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 data types to be used in the system. Technological dimension: In this dimension the required Services are detected e.g., we need Fiducial, Text Label and RFID readers. This components wrap existing technologyspecific solutions. The RFID middelware used was Accada [5]. Fiducials were detected ISSN SISTEDES,

19 using reactivision 3 and a wide-angle lens webcam. Text Label is implemented as a web page that allows the user to introduce an identifier using the keyboard. When wiring these components, replaceability limitations captured in this dimension are considered. Services can only be connected to an IC if these services are based on a technology that supports the required mediums and codifications. Responsibility dimension: From the information captured in this dimension, the required ICs and their wiring are defined. Toolbox, Location, Mechanic and Tools implement the IDElement interface see Fig. 4 at the bottom-left side to act as an IC implementation. SCA annotations are used to indicate that (1) the interface can be used in a distributed environment it is remotable (2) the getelement method has not immediate 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 asynchronous communication. In Fig. 4, code for IdElement and IdElementCallback interfaces is shown. Components accessing an IC should implement the setelement method to receive the data and the updated method to get notifications of changes. Component wiring is defined in a XML-based composite specification see Fig. 4 at the top-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 defining architectures that support Auto-ID has lead to the development of frameworks and middleware 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 independent fashion has been also developed [1, 11, 18]. However, although frameworks provide domain-specific primitives, the usage of general purpose languages such as Java to implement their extensions does not enforce the usage of domain-specific concepts, so framework usage 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 mapping them into a specific framework. Physical Markup Language (PML [4]) is a format for the exchange of data captured by the sensors in an Auto-ID infrastructure. PML concepts are targeted at describing the physical world, while our approach provides concepts to also describe the linkage with the digital world and aspects at requirement level. In [13] Muñoz presents a method for the development of pervasive systems based on MDE. However the specific needs regarding identification are not considered. 6 Conclusions and Further Work The development of applications for the emerging Internet of Things requires to respond to many challenges at different levels technological, data, requirements, etc.. The use of modelling techniques can help to integrate all these aspects. The DSL introduced in this work covers the physical-virtual gap that exist when realworld objects are involved in Information Systems from a modelling perspective. According to the analysis of the application domain, we have detected the aspects that are relevant for the physical-virtual linkage. We have defined a conceptual framework that captures the relevant concepts in order to constitute a language that describes this linkage. A description of the identification aspect of a system can be mapped systematically to a 3 ISSN SISTEDES,

20 target architecture that supports the requirements detected for this kind of applications in component replaceability and distribution terms. In this work, we have established a systematic path from identification requirements expressed in a technologically-independent fashion to technological-specific solutions supporting these requirements. In order to evaluate the expressivity of the defined DSL, the development of more case studies in production environments is required. The feedback of development teams and final users would be really valuable. This feedback could also help to find a concrete syntax for the primitives defined in the language. The development of tools to support the process and the integration with existing modeling solutions in the area would provide a great value to the work. The integration with PervML [13] would allow the definition of some aspects such as service behavior that are 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. In 5th GI/ITG KuVS Fachgespräch, Stuttgart, Germany, C. Bornhövd, T. Lin, S. Haller, and J. Schaper. Integrating automatic data acquisition with business processes experiences with sap s auto-id infrastructure. In vldb 2004: Proceedings of the Thirtieth international conference on Very large data bases, pages VLDB Endowment, A. Deursen and P. Klint. Little languages: little maintenance? Technical report, Amsterdam, The Netherlands, C. Floerkemeier, D. Anarkat, T. Osinski, and M. Harrison. Pml core specification. White Paper. University of St. Gallen. Auto-ID Center., October Version C. Floerkemeier, C. Roduner, and M. Lampe. Rfid application development with the accada middleware platform. IEEE Systems Journal, Special Issue on RFID Technology, Dec N. Gershenfeld, R. Krikorian, and D. Cohen. The internet of things. Scientific American, 291(4):46 51, P. Giner, M. Albert, and V. Pelechano. Physical-virtual connection in ubiquitous business processes. In Proceedings of the 10th International Conference on Enterprise Information Systems, volume 2, pages , Barcelona (Spain), June J. Gray, J.-P. Tolvanen, S. Kelly, A. Gokhale, S. Neema, and J. Sprinkle. Domain-Specific Modeling (in CRC Handbook of Dynamic System Modeling), chapter 7, page (in publication). CRC Press, T. Kindberg. Implementing physical hyperlinks using ubiquitous identifier resolution. In WWW 02: Proceedings of the 11th international conference on World Wide Web, pages , New York, NY, USA, ACM Press. 10. M. Lampe, M. Strassner, and E. Fleisch. A ubiquitous computing environment for aircraft maintenance. In SAC 04: Proceedings of the 2004 ACM symposium on Applied computing, pages , New York, NY, USA, ACM. 11. M. Langheinrich, F. Mattern, K. omer, and H. Vogt. First steps towards an event-based infrastructure for smart things. Ubiquitous Computing Workshop, PACT Philadelphia., October M. Mernik, J. Heering, and A. M. Sloane. When and how to develop domain-specific languages. ACM Comput. Surv., 37(4): , J. Muñoz and V. Pelechano. Building a software factory for pervasive systems development. In CAiSE, pages , 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 on Management of data, pages , New York, NY, USA, ACM. 15. K. Römer, T. Schoch, F. Mattern, and T. Dübendorfer. Smart identification frameworks for ubiquitous computing applications. Wirel. Netw., 10(6): , ISSN SISTEDES,

21 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 on Pervasive Computing, pages 62 74, Pervasive2002, April A. van Deursen, P. Klint, and J. Visser. Domain-specific languages: an annotated bibliography. SIGPLAN Not., 35(6):26 36, J. Vermeulen, R. Thys, K. Luyten, and K. Coninx. Making bits and atoms talk today: A practical architecture for smart object interaction. In First international workshop on Design and Integration Principles for Smart Objects (DIPSO 2007), Innsbruck (Austria), September R. Want, K. P. Fishkin, A. Gujar, and B. L. Harrison. Bridging physical and virtual worlds with electronic tags. In CHI 99: Proceedings of the SIGCHI conference on Human factors in computing systems, pages , New York, NY, USA, ACM Press. ISSN SISTEDES,

22 Perfiles UML y Desarrollo Dirigido por Modelos: Desafíos y Soluciones para Utilizar UML como Lenguaje de Modelado Específico de Dominio Giovanni Giachetti 1, Beatriz Marín 1 y Oscar Pastor 1 1 Centro de Investigación en Métodos de Producción de Software Universidad Politécnica de Valencia Camino de Vera s/n, 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 SISTEDES,

23 (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 SISTEDES,

24 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 SISTEDES,

25 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 SISTEDES,

26 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 SISTEDES,

27 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 SISTEDES,

28 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. Diferencia de la cardinalidad mínima: Clase1.atr1 = 1 UMLClase1.atr1 = 0 Metamodelo LMED Clase1 atr1 atr2 [2..2] atr3 Superestructura UML UMLClase1 atr1 [0..1] atr2 [2..*] Diferencia de la cardinalidad máxima: Clase1.atr2 = 2 UMLClase1.atr2 = * <<metaclass>> UMLClase1 <<stereotype>> Clase1 atr3 Perfil UML self.atr1->size > 0 self.atr2->size < 3 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 SISTEDES,

29 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 SISTEDES,

30 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. Herramientas de modelado propietarias Modelo LMED Herramienta de intercambio Modelo UML Herramienta de modelado UML Paso 1: Definir metamodelo EMOF del LMED Paso 2: Redefinición del metamodelo Metamodelo LMED Metamodelo LMED Metamodelo Opcional, este paso se realiza solo si la redefinición es requerida Paso 3: Mapeo de las equivalencias entre metamodelos Perfil UML Mapeo entre el perfil UML y el metamodelo LMED Metamodelo + Mapeo Paso 4: Identificación de extensiones Metamodelo + Mapeo + Extensiones Paso 5: Generación del perfil 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 SISTEDES,

31 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 TIN 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, 4. Eclipse: ATL Project, 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, (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 Springer (2008) 8. Harel, D., Rumpe, B.: Meaningful Modeling: What's the Semantics of "Semantics"? In: IEEE Computer, vol. 37 nº 10, (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 (2007) 10. OMG: MOF 2.0 Core Specification 11. OMG: Object Management Group Web site, OMG: UML Infrastructure Specification 13. OMG: UML 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, (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 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 (2007) ISSN SISTEDES,

32 Patrones de optimización de rendimiento para transformaciones de modelos Jesús Sánchez Cuadrado 1, Frédéric Jouault 2, Jesús García Molina 1, y Jean Bézivin 2 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 desarrollo de software dirigido por modelos (DSDM). Conseguir un rendimiento adecuado de las mismas es un requisito fundamental para que la disciplina madure. En este trabajo se presentan cinco patrones de optimización que identican posibles cuellos de botella y explican como abordarlos. Asímismo se presenta un framework general para la creación de benchmarks para transformaciones, que ha sido usado para identicar 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 por modelos (DSDM) y en los últimos años han aparecido un buen número de lenguajes de transformación. A medida que la disciplina ha madurado, se han escrito transformaciones para resolver problemas cada vez más complejos y continuamente crece el número de desarrolladores que denen transformaciones. Así, el DSDM se aplica actualmente en contextos como el desarrollo basado en DSL, la modernización basada en modelos o el megamodeling[2]. Además, en algunos de estos contextos el tamaño de los modelos que se manejan es muy grande, incluso por encima del millón de elementos. Este contexto requiere que los desarrolladores de transformaciones y de motores para lenguajes de transformación deban considerar cuestiones de rendimiento para conseguir tiempos de ejecución que permitan el uso de los sistemas software que incorporan transformaciones de modelos. Para evaluar cuándo el rendimiento es apropiado una estrategia es la denición de una serie de benchmarks, como se propone en [8]. Estos benchmarks servirían para comparar datos experimentales sobre el tiempo de ejecución de una misma denición de transformación escrita de diferentes formas. Por ejemplo, podrían variar características como la estrategia para encontrar la solución, el lenguaje utilizado o el tamaño del modelo de entrada. 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ón de los benchmarks podría servir para (a) comparar y mejorar diferentes lenguajes de transformación y sus implementaciones, y (b) identicar una serie de patrones y buenas prácticas relativas a la optimización del código de las deniciones de transformación. Este artículo presenta una doble contribución relacionada con los benchmarks de transformaciones de modelos: un framework para la especicación de benchmarks y varios patrones de optimización de rendimiento. El framework está siendo utilizado actualmente para denir un conjunto de benchmarks para la comparación de lenguajes de transformación, y como resultado de este trabajo se han identicado algunos patrones de optimización. En este trabajo ISSN SISTEDES,

33 se describen cinco de los patrones identicados. Para cada patrón se dará su motivación, un ejemplo concreto en el que aparece, así cómo una discusión sobre las diferentes alternativas para su implementación. Puesto que estos patrones han sido identicados a partir de los datos experimentales obtenidos a través de una librería de benchmarks, se mostrarán datos comparativos de cada alternativa de implementación. El artículo se estructura como sigue: en la siguiente sección se presenta nuestro framework para benchmarks, en la Sección 3 se presentan los patrones identicados a partir de los datos experimentales. En la Seccion 4 se discute sobre el balance entre legibilidad y eciencia, y nalmente en la Sección 5 se dan las conclusiones. 2 Framework para benchmarks Para facilitar la especicación, ejecución y presentación de los resultados de benchmarks de transformaciones de modelos se ha creado un framework cuya arquitectura se muestra en la Figura 1. El framework está destinado a medir el rendimiento de uno o varios lenguajes de transformación con respecto a una o más características. Los benchmarks se organizan siguiendo una estructura de directorios, donde toda la información relativa a cada benchmark se almacena en un directorio. Se ha denido un DSL para especicar la información necesaria para ejecutar benchmarks. Estas especicaciones son interpretadas para lanzar la ejecución de los benchmarks. Cada uno de ellos es ejecutado n veces, y el valor medio del tiempo de ejecución es calculado. Opcionalmente se pueden descartar los m primeros tiempos para evitar sesgos. El resultado de la ejecución de los benchmarks es almacenado en un modelo (no se muestra su metamodelo por razones de espacio), que puede ser luego transformado en una representación adecuada para su visualización y para la comparación de las medidas. Nosotros hemos denido una transformación que toma un modelo de medidas de rendimiento y 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 chero CSV para su exportación en una hoja de cálculo. Las grácas comparativas de este artículo han 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 especicación del DSL para la ejecución de benchmark consta de dos partes: la denición del benchmark y un conjunto de suites de tests del benchmark. La denición del benchmark especica un conjunto de metamodelos origen y destino, un conjunto de transformaciones a aplicar y un conjunto de modelos de entrada. Cada denición de benchmark debe ir acompañada de una o más suites formadas por un conjunto de benchmark cases. Cada benchmark case ja los valores de los pará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 SISTEDES,

34 Fig. 2. Metamodelo de la sintaxis abtracta del lenguaje para describir benchmarks. A continuación se muestra un ejemplo de especicación del DSL destinada a ejecutar un benchmark para comparar la eciencia de las colecciones. La denición del benchmark incluye dos transformaciones que tienen el mismo metamodelo de entrada y salida, Tree, y un solo modelo de entrada. Se ha denido una única suite con dos benchmark case, uno por cada transformación, que se ejecutan para los dos modelos y para la misma máquina virtual de 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 => 'model_16000.xmi' model => '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 denición del benchmark y las suites con respecto a los benchmarks case evita de una forma muy sencilla escribir una y otra vez la información sobre las transformaciones a ejecutar. Como se muestra en el ejemplo, es posible expresar diferentes combinaciones de parámetros de la ejecución de un benchmark, tal como los modelo de entrada para los que se ejecutará la transformación ISSN SISTEDES,

35 (por ejemplo, para comparar el rendimiento según el tamaño del modelo o su estructura) o qué implementación del lenguaje se usará (para comparar implementaciones). Hasta el momento se han denido benchmarks que se clasican en dos categorías: microbenchmarks que miden aspectos concretos de un lenguaje o de las transformaciones y examples que corresponden a optimizaciones en ejemplos reales de transformaciones. El benchmark del fragmento anterior de especicación del DSL sería un ejemplo de microbenchmark. Una transformación UML a Java donde se consideran casos complejos tales como la herencia 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 transformaciones. Estos patrones están justicados por los datos experimentales obtenidos de la ejecución de los correspondientes benchmarks 3 con el framework de la sección anterior. La mayor 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 identican uno o más cuellos de botella para la transformación y se solucionan. Después se crea un microbenchmark por cada cuello de botella, a partir del cual probablemente se identicará un patrón, de manera que se aisla el problema en particular. Los datos experimentales que se mostrarán para cada patrón corresponden a microbenchmarks. Los patrones siguientes se ilustrarán para el lenguaje ATL 4, pero las conclusiones obtenidas son generales para cualquier lenguaje basado en reglas, como QVT[6] o RubyTL[7], puesto que en todos ellos la navegación se hace utilizando un lenguaje de consultas basado en iteradores 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, en este 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 origen mediante una consulta con OCL (o un lenguaje similar). Normalmente tales consultas implican expresiones booleanas. Cuando las consultas son complejas y los modelos de entrada son grandes, el orden en que las condiciones son evaluadas puede inuir considerablemente en el rendimiento, ya que si el el lenguaje de transformación soporta evaluación de expresiones booleanas en corto-circuito [1] es posible escribir la expresión de modo que sólo se evalúen las condiciones necesarias para determinar el valor de la expresión. Datos experimentales. La Figura 3(a) muestra el resultado de ejecutar una transformación con una única regla que se aplica según una expresión booleana or, de la forma condicionsimple or condicioncompleja. Se comprueba el efecto de utilizar evaluación en corto-circuito o no. La condición simple es una operación cuyo tiempo es constante y no depende del número de elementos de entrada, mientras que la consulta compleja depende del tamaño del modelo de entrada. 3 Se ha utilizado una máquina con las siguientes características: Intel Pentium Centrino 1.5Ghz, 1GB de memory RAM. Java version sobre Linux kernel Se ha utilizado la versión 2006 y la máquina virtual EMFVM sobre Eclipse 3.4 ISSN SISTEDES,

36 (a) (b) Fig. 3. (a) Expresiones booleanas con y sin evaluación en corto-circuito. (b) Diferentes formas the obtener una referencia inversa. Recomendaciones. Como es bien conocido, hay dos estrategias para mejorar el rendimiento de 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, es decir, 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, es decir, 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 cuando el resultado de la expresión es verdad. Si el lenguaje de transformación no soporta evaluación en cortocircuito, como es el caso de OCL estándar (tal y como está implementado en ATL), cualquier expresión puede ser reescrita siguiendo las reglas de la tabla siguiente para conseguir el mismo efecto. Con cortocircuito Sin cortocircuito AND 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 modelos a 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 denido una referencia inversa a una referencia dada, la navegación en los dos sentidos se realiza de manera eciente. Pero en muchas ocasiones no existe tal referencia inversa, de manera que la operación de navegación en sentido inverso puede ser costosa ya que implica recorrer todos los posibles elementos destino de la referencia inversa 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 posible para un lenguaje de transformación explotar la relación única de contención entre un elemento y su padre (esto es, todo elemento está contenido en uno o ningún elemento) para ofrecer una operación que obtenga de manera genérica el elemento padre. Por ejemplo, en ATL esta operación se llama refimmediatecomposite(). ISSN SISTEDES,

37 Datos experimentales. El microbenchmark para probar este patrón básicamente consiste en una consulta que debe devolver el paquete en el que está contenida una clase (se asume un metamodelo similar al de UML pero sin la referencia para navegar hacia el paquete contenedor). Se denen 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 tres modelos de clases con diferente número de paquetes y clases (paquetes clases). Evidentemente la opción con refimmediatecomposite es la más eciente. Sin embargo, utilizar una tabla hash es una alternativa casi equivalente, pero sólo si disponemos de operaciones mutables (o si el motor de transformación es capaz de evitar la copia). El algoritmo iterativo demuestra ser ineciente. También es interesante destacar que la forma del modelo de entrada puede tener impacto: el algoritmo iterativo mostrado antes depende fuertemente de cómo esté organizado el modelo, mientras que esta dependencia es mucho menor en el caso de precalcular una tabla (o utilizar refimmediatecomposite). Recomendaciones. Si se tiene que navegar a través de una referencia que es inversa a otra referencia contenedora, y no se dispone de ella, se debería comprobar que el lenguaje de transformación utilizado ofrece una operación genérica tal como refimmediatecomposite. Si no existe la referencia inversa y además no es contenedora, se debería precalcular utilizando una tabla hash que permita operaciones mutables. 3.3 Uso de colecciones Los lenguajes de transformación suelen ofrecer distintos tipos de colecciones, y cada tipo ofrece mejor rendimiento para cierto tipo de operaciones. Elegir el tipo adecuado para cada circunstancia 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 las operaciones OCL including (que añade un elemento a una colección) e includes (que comprueba 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 igual forma, se han creado benchmarks similares para comparar operaciones, como any o exists. Datos experimentales. El microbenchmark para la operación including consiste en iterar una lista de n elementos y en cada paso añadir el elemento actual a otra lista. El tiempo de ejecución para diferentes tamaños de entrada y para los tres tipos de colecciones se muestra en 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. El tiempo de ejecución para diferentes tamaños de entrada y para los tres tipos de colecciones se muestra en la Figura 4(b). ISSN SISTEDES,

38 (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 eciente para secuencias que para conjuntos. Esto es razonable ya que las inserciones se hacen por la cola y no hay que comprobar duplicados. El coste de includes es mayor para secuencias. Sin embargo, debe tenerse en cuenta que el coste convertir una colección en un conjunto (con asset) es grande y puede no merecer la pena si las operaciones de consulta no son frecuentes. Recomendaciones. A la hora de utilizar colecciones se debería elegir el tipo concreto según las operaciones más frecuentes que se vayan a utilizar. En particular, a no ser que sea necesario asegurar que no haya duplicados en una colección (o que la propia lógica de la transformación no pueda asegurarlo), se debería utilizar el tipo secuencia, en caso contrario utilizar un conjunto. En el caso de la consulta includes, se debería utilizar un conjunto ya que el contrato de esta operación en conjuntos asegura más eciencia en caso de que la implementación cambie. 3.4 Uso de iteradores La forma en se especican las consultas, normalmente en OCL, tiene un impacto en el tiempo de ejecución de una transformación. Al ser OCL un lenguaje que promueve un estilo funcional, cuando se escriben consultas es frecuente no tener en cuenta la eciencia de las expresiones, 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 elemento que cumpla una condición se utiliza la consulta (a). Sin embargo, la consulta (b) es mucho más eciente 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 denido un microbenchmark que maneja una lista en la que la condición de búsqueda es satisfecha por todos los elementos que se encuentran a partir de la mitad de la lista. Eso signica que la opción (a) obtendrá una lista con n/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 los benchmarks 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 termina la ejecución tan pronto se encuentra un elemento, sino que es equivalent a select()->rst. ISSN SISTEDES,

39 Por tanto, se creo una versión optimizada de any que sí termina la iteración tan pronto como es posible, es decir, cuando encuentra el elemento que satisface la condición. Como muestra 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ódigo común de búsqueda. Recomendaciones. Se debería evitar el uso de select cuando no sea necesario recorrer toda una colección. En cambio se debería utilizar any, exists, includes, etc. para obtener el valor deseado sin iterar sobre toda la colección. En ocasiones es preferible sacricar la legibilidad de una consulta en aras de la eciencia utilizando la operación iterate para disponer de más exibilidad. Un ejemplo de esto es el 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 intermedia para almacenar tales elementos. El código (b) hace lo mismo pero evita crear una nueva lista. (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 eciente a medida que el número de elementos a contar crezca, ya que simplemente incrementa un entero en cada iteración, en vez de crear y enlazar una celda para la lista intermedia. 3.5 Identicar expresiones constantes Un aspecto intrínseco a las transformaciones de modelos, utilizando lenguajes basados en reglas, 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 metaclase origen). Esto signica que las expresiones que aparezcan dentro de una regla se pueden ejecutar más de una vez. Cuando estas expresiones dependen completamente del elemento origen de la regla, entonces es inevitable ejecutarlas siempre. En cambio, aquellas partes de la expresión que son independientes de variables ligadas a la regla pueden ser factorizadas en una constante para ser ejecutadas sólo una vez. Actualmente los motores de transformación no 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 para su aplicación es que el clasicador sea apuntado por otro elemento que determina si es ISSN SISTEDES,

40 dibujable o no (Drawable). Puesto que el ltro se comprueba para cada clasicador, todos los 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 eciente es calcular en una constante todos los elementos que son dibujables, 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) se muestran los resultados para los siguientes casos: (1) sin factorizar el código en una constante y utilizando la versión original de exists, (2) igual que el anterior pero utilizando una versió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 algoritmica O(n + m)), mientras que (1) tiene un coste de O(n m), donde n es el número de elementos 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 identicar expresiones que no dependen de variables de la regla ya que suelen utilizar una operación como allinstances() (o similarmente obtienen todos los elementos a partir de un elemento raíz). En tal caso es posible utilizar una constante para precalcular informació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, para crear variables locales es otra práctica recomendable para factorizar expresiones a nivel local. 4 Legibilidad vs. eciencia En general, cuando el código es escrito para mejorar el rendimiento su legibilidad tiende a empeorar. El uso de los patrones anteriores no es una excepción, y en muchos casos provoca que el código no sea claro. Por ejemplo, el siguiente método recursivo que comprueba si una clase es superclase de otra es legible, pero resulta ineciente si el lenguaje de transformación usado 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 SISTEDES,

41 Escribir una versión eciente implica utilizar un mapa para precalcular todas las superclases con un algoritmo complejo. Al igual que en el caso de un programa, una transformación debe escribirse procurando que resulte lo más legible posible para facilitar el mantenimiento, de modo que un balance adecuado entre legibilidad y rendimiento es fundamental. El reto es identicar los cuellos de botella que afectan a la eciencia. El uso de prolers permite conocer con exactitud cuáles son las operaciones más costosas. Por otra parte, un framework tal como el que se propone en la Seccion 2 puede ser útil para comparar diferentes versiones de la misma transformación y elegir la más adecuada. 5 Conclusiones y trabajo futuro En este trabajo se ha presentado un framework para la ejecución de benchmarks y el estudio del rendimiento de las transformaciones de modelos. A partir de los datos obtenidos con el uso del framework se han identicado una serie de patrones de optimización relacionados con 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 deciencias en la implementación del lenguaje de transformación ATL. Así, este framework también resulta útil para probar que las implementaciones de los lenguajes son efectivamente ecientes y para su posible comparación. Como trabajo futuro se pretende crear un plugin para Eclipse que permita, a través de puntos de extensión, añadir nuevos lenguajes de transformación sin necesidad de modicar el framework. Por último, se seguirán realizando más pruebas de rendimiento de cara a identicar una conjunto completo de patrones de rendimiento para transformaciones. Agradecimientos Este trabajo ha sido parcialmente nanciado por los proyectos TIC-INF 06/ de la Consejerí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 computer science and information processing). Addison-Wesley, M. Barbero, F. Jouault, and J. Bézivin. Model driven management of complex systems: Implementing the macroscope's vision. In ECBS, pages IEEE Computer Society, K. Beck. Implementation Patterns. Addison-Wesley Professional, 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 1221, New York, NY, USA, ACM. 5. F. Jouault and I. Kurtev. Transforming Models with ATL. In MoDELS 2005: Proceedings of the Model Transformations in Practice Workshop, Oct OMG. MOF 2.0 Query/Views/Transformations. Technical Report ptc/ , Nov Available at 7. J. Sánchez, J. García, and M. Menarguez. RubyTL: A Practical, Extensible Transformation Language. In 2 nd European Conference on Model Driven Architecture, volume 4066, pages Lecture Notes in Computer Science, June 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 7988, Washington, DC, USA, IEEE Computer Society. ISSN SISTEDES,

42 Providing an open Virtual-Machine-based QVT implementation Adolfo Sánchez-Barbudo 1, E. Victor Sánchez 1, Víctor Roldán 1, Antonio Estévez 1, y José Luis Roda 2 1 Open Canarias, S.L., C/. Elías Ramos González, 4 - Oficina Santa Cruz de Tenerife, Spain {adolfosbh,vsanchez,vroldan,aestevez}@opencanarias.com 2 Universidad de La Laguna, La Laguna, Spain jlroda@ull.es Abstract. Now that OMG s MOF 2.0 QVT specification has finally reached official status it will be interesting to witness how much impulse it will represent to the evolution of the Model-Driven Engineering field. The Eclipse platform is developing its own open QVT solutions, but they are not ready yet for industrial production. This paper discusses an Eclipse-based QVT open implementation that Open Canarias has been developing for several years. The distinctive trait of this implementation is that at its core lies a Virtual-Machine model transformation technology, driven by a language named Atomic Transformation Code (ATC). We will explain this QVT solution and the whole process QVT model transformation instances follow until they can be executed, which will reflect how this virtual-machine approach influences its overall architecture. Keywords: Model Transformations, QVT, Virtual Machine, ATC. 1 Introduction The Object Management Group TM (OMG TM ) defines itself as an international, open membership, not-for-profit computer industry standards consortium. This organization periodically releases public open specifications, many of which become standards that contain recognized best practices that help in driving the industry towards achieving milestones and confronting further challenges. Modeling and Model-Driven Software Development (MDSD) are covered by several OMG specifications gathered together under the Model-Driven Architecture (MDA) umbrella. Similarly, Eclipse is an open source community, whose projects are focused on building an open development platform comprised of extensible frameworks, tools and runtimes for building, deploying and managing software across the lifecycle. Eclipse focuses on providing open-source implementation solutions related with the most common problems software and software 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 implementation for a particular OMG specification, such as SBVR, UML2, or OCL. Examples of alignment between 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 give support to the procedural Operational Mappings, which is led by Borland, has been under development as an Eclipse project since at least as early as ISSN SISTEDES,

43 But the QVT specification has not reached official 1.0 status until recently [10]. The whole process has taken about six whole years, and there are still some unpolished details that need further revision. Anyways it is now when QVT has to demonstrate its full potential into becoming a true industrial standard, or else be relegated to becoming a referential notation much in the sense as UML has traditionally been used for documentation and the sharing of ideas, as discussed in [15]. The quality of the available QVT implementations will highly determine the success of QVT in the upcoming years. Back in 2005 Open Canarias S.L. started a model transformation project whose primary goal was to comply with MDA, therefore the QVT specification was targeted. A preliminary work on this topic was published in [12]. The fundamental trait of this solution is that it is built upon a Virtual-Machine technology, driven by its own byte-code model transformation language named Atomic Transformation Code (ATC). In this paper we will discuss our QVT implementation project in terms of the different steps involved in the process that ultimately leads to execution of the source QVT model transformations, applied over a set of models, via this virtual machine. We will cover several of the difficulties encountered throughout its development. Some alternatives to different aspects of this work will also be addressed. The paper is structured as follows. Section 2 makes a brief overview of the QVT specification, Section 6 details the chosen technology upon which the QVT model transformation engine is based, Section 4 reviews the architecture of the presented QVT implementation solution in terms of the three stages it comprises. Related work follows in Section 5 and Section 7 finishes with the conclusions. 2 QVT The OMG s MOF Query/View/Transformation (QVT) specifies three different, complementary, statically-typed languages to describe model transformations in the scope of the MDA framework. Two of them enjoy a declarative nature, and the third one is imperative. The specification is structured around the architecture depicted in Figure 1. It includes a section explaining 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 a set of variables and evaluating conditions over those variables against a set of models. The language uses a model-based trace mechanism to record what ocurred during a transformation execution. The trace metamodel must be explicitly provided in the definition of model transformations, thus it neither depends on the QVTc language nor is implicitly inferred from the contents of such transformations. The Relations (QVTr) language allows us to specify a set of relationships between MOF models. It supports complex object pattern maching. Additionally, trace instances are im- ISSN SISTEDES,

44 plicitly created and maintained, which saves the user from having to explicitly manage trace information. Although QVTr and QVTc are meant to be semantically equivalent, QVTr is defined at a higher level of abstraction, so it is more user-friendly. The specification defines a reltocore model transformation to translate among both languages abstract representations. 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 it also carries a complement of constructs designed to handle (create, modify, etc.) MOF model extents. 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 sideeffect imperative expressions provided by the ImperativeOCL component. 3 Atomic Transformation Code (ATC) Overview ATC [8] is an imperative, structured, low-level dynamically-typed model transformation language 3 whose instances are defined as models. ATC s instruction set basically comprises the semantics of a general-purpose programming language enriched with a complement of indivisible, combinable primitives (called atoms) carefully designed to provide model transformation functionality at a low abstraction level. Among these, we find AtcGetFeature to query the value of a model element s feature, or AtcCreateElement to instantiate a desired type defined in a metamodel. Many of these instructions are explained in [8]. Implementation of constructs specific to model transformations are based on the API of the Eclipse s metamodeling infrastructure, Eclipse Modeling Framework. The language supports some rough automated extensibility mechanism. They are not as powerful as pure dynamic polymorfism, but this is not an issue, since ATC model transformations will be usually 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 eventually be made available at: ISSN SISTEDES,

45 Where the updated visibility is accessed as a property of the implicit self variable, which corresponds 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 sequential instructions 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 of information. 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 difficult to understand and thus implement. We will explain our particular adopted approach that provides a functional, executable implementation of the QVT specification. The process involved has been partitioned into a sequence of stages. First, textual model transformations are parsed to obtain their equivalent abstract representation, which can be seen as a model. Once a QVT model is obtained, it can serve as input in a model transformation that converts it into a semantically equivalent version given in terms of the byte-code ATC language, since ATC instances are models themselves. The final step is to execute this ATC model transformation upon real models via its virtual-machine engine. A more 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 along with their abstract syntax description. The first step towards execution is to link both representations, therefore obtaining an abstract syntax model representation of the textually written source transformation. This stage consists of parsing the original text in order to produce a model in a user-friendly development environment. The two main topics involved in its development are a parser capable of generating a QVT output model from QVT textual input, and an editor to assist in the programming of QVT model transformations in textual notation (syntax highlighting, context assist, error marking,... ). 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 and QVTc. All the three editors follow a similar alignment with the MDT-OCL project, which includes grammar extension of the LALR Parser Generator (LPG) and variable environment sharing. Since QVT is defined as an extension of two other OMG specifications, EMOF (Essential MOF) and Essential OCL, extending the Eclipse Modeling Framework, EMF (as a legitimate Essential MOF implementation) and MDT-OCL was required. Additionally, GMT-UMLX provides a useful infrastructure to easily integrate the developed parser into a multi-page editor which offers several views and notations of the same source transformation integrated in a single window. By attaching our QVTo editor to this infrastructure we enjoyed the reuse of many features which helped the QVTo editor become a more solid and productive environment than it would have been. The mechanisms that drive parsing QVT input textual files to generate QVT output models are based on the same principles MDT-OCL uses to parse OCL textual expressions, and are summarized here: ISSN SISTEDES,

46 Defining an Ecore-Based Metamodel for the QVT language (which has been contributed to the GMT-UMLX project). This QVT metamodel extends the Ecore and the Ecorebound 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 the MDT-OCL EssentialOCL grammar and involves the specification of production rules for some QVT-specific concepts, including ImperativeOCL. Defining a CST-building infrastructure for creating CST nodes. It uses and extends MDT-OCL s own infrastructure. Defining the AST-building infrastructure for creating AST nodes, which also uses and extends MDT-OCL s. Defining the validation actions to validate the generated models, which actually extend the 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 specification, and as is usual for any programming language s standard library, has been defined in terms of its language. Consequently, in this case it is represented as a model that conforms to the QVTo metamodel. This stage poses certain technological challenges. For instance, the MDT-OCL project s design did not originally account for language extensions. QVT is not the only language that builds upon OCL. The same does, for instance, the M2T language. Enhancements to the MDT-OCL project s language extensibility are being successfully contributed. A previously attempted alternative to supporting QVTo via ATC consisted of eliciting ATC models directly from QVTo text parsing in a monolithic Java approach. A working prototype 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 alternative were that it was difficult to keep QVTo textual parsing and ATC generation mixed together in a single module. The task of increasing language support incrementally was not always found 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 produce AST models from QVT textual parsing in order for them to achieve true QVT model transformation 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 file via the editor-parser process, the next step would be to make it executable in our virtual engine. 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 transformation engine capable of interpreting and executing QVT models. However, the use of an intermediate layer, a Virtual-Machine model transformation engine, implies beneficial gains in terms of flexibility, diversity of languages supported and the exploiting of optimization opportunities. Reflective Model-Driven Engineering [4] is a powerful instrument in the evolution of the MDE field. Once model transformation instances take the shape of models, they can be ISSN SISTEDES,

47 Fig. 3. QVTo model translation schema. VTE stands for Virtual Transformation Engine, and is the 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 s PIM-PSM evolution approach. This can be seen as a model transformation development process [14]. Since both source and target artifacts on the stage explained in this section are models, a model transformation to automatically produce the target from the source is an adequate 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 a conversion similar to horizontal, domain mapping transformations, where domain elements from either language are often bound by a nearly one-to-one relationship between each other. 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 relationship is 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 engine existed and was reliable. We have used a notation close to ATC but of a higher level of abstraction for productivity reasons. Other working language alternatives should be equally valid for this purpose. Both model transformations have been designed around a common core structure that takes charge of translating MOF constructs (model parameters, operation parameters, and basic transformation structuring), and also OCL expressions. The latter includes the OCL Standard Library, which defines a respectable quantity of operations on basic types for which code that installs their semantics on translated ATC models must be developed. Additionally, QVTo defines a Standard Library on its own, and QVTc2ATC must account for two different execution modes: checking and enforcement. ATC-based execution support for QVTr models is pending. QVTc being a lower-level version of QVTr, a model transformation named reltocore is defined in the QVT specification to translate QVTr models into QVTc models, a process analogous to the more general Virtual-Machine concept applied in this work. The problem with this reltocore transformation is that it is not written in terms of the QVTc language, which would have allowed us to translate it into ATC via QVTc2ATC Instead, it is written in QVTr, which means we have to find a suitable QVTr model transfor- ISSN SISTEDES,

48 mation engine, such as, perhaps, MOMENT-QVT [13], that must be capable of producing the 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 specification states that in QVTr only first order sets are allowed, i.e., Elements cannot have type set of sets, but unfortunately, the transformation makes use of these collections of collections constructs at some point. While waiting for the specification to fix this issue, a QVTr2ATC model transformation capable of translating QVTr models directly into semantically equivalent ATC counterparts may be worth trying. This stage has led to improvements on the ATC language in terms of scalability. Imports between transformation components have been installed and blind virtual invocations have been incorporated to the language. 4.3 QVT Execution Now we already know how a translated ATC model transformation is obtained. It is semantically equivalent to the parsed textual QVT transformation. The third final step consists of 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 input and output models that are involved in the transformation execution. We have developed a generic 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 a generic launcher, to which any model transformation engine, even different versions of the same engine, can be bound. A binding for VTE is provided. Other automated alternatives are worth considering, such as defining a model transformation chain that might represent part of a Software Product Line, in which models to be transformed are always the same, thus their locations, along with that of the transformation to be executed, do not change. Automating the sequential execution of several transformations may be useful when user interaction is minimized or not required at all. The complete QVT execution process comprising the three stages explained throughout this work is summarized in Figure 5. ISSN SISTEDES,

49 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 is maintained by some of the people in charge of the QVT specification. In the scope of Eclipse s M2M project, there are two separate project initiatives to bring support to QVTr and QVTc (by Obeo) and QVTo (by Borland). Concerning QVTo, collaboration between Open Canarias and Borland currently involves exchanging ideas and sharing test cases. Borland has announced that it will refactor its QVTo solution so it becomes capable of generating QVTo conforming models out from parsed text. Eclipse has its own official byte-code model transformation language, the ATL-Virtual Machine, toward which several languages are being compiled, including QVT [9], with an approach that shares many commonalities with ours. Not surprisingly, the group behind this approach is working to extend compatibility to other languages, just like the ATC technology is (see [7], [3]). The importance of these achievements is that work on either infrastructure may be easily made interoperable with the other by simply providing a translation transformation 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 specify model queries and constraints. OCL being declarative, it is independently translated into the 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 most distinctive aspect is the use of an intermediate, byte-code model transformation language named Atomic Transformation Code which was originally developed precisely to support execution of the QVT specification. Several projects are picked up and combined in an integral solution capable of executing model transformations specified in the QVT textual concrete syntax. Eclipse [6] has been selected as our target platform to implement the solution. Reasons behind this election are unsurprising: ISSN SISTEDES,

50 Eclipse is a powerful open-source platform whose evolution and adoption rate have been growing at a very fast pace, and whose flexibility, extensibility, ease of use, etc. make it an ubiquitous platform. Eclipse provides a lot of modeling-related functionality which includes EMF [5], as a sound metamodeling infrastructure, or the MDT-OCL project, as an implementation of the OCL language. There are several open-source projects we base our QVT execution project on. A list of related 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 QVT implementation solution, since the three QVT languages rely upon the OCL specification for their definition. Our solution has been aligned with the infrastructure developed for the MDT-OCL project where appropriate. UMLX [17]: Another official Eclipse project, currently under the Generative Modeling Technologies (GMT) section. UMLX provides a lot of common functionality related to the edition of QVT files. Editors for writing QVTc and QVTr model transformations are being provided in the context of this project. LPG: The LALR(k) Parser Generator is a non-eclipse project hosted in Sourceforge that is used by the MDT-OCL project to parse OCL expressions. It provides grammar extensibility mechanisms, an ideal feature for QVT languages. Atomic Transformation Code (ATC) [8]: An open, non-official, Eclipse-based project that consists of a byte-code model transformation language and its related virtual-machine engine. ATC has been built on top of Eclipse and the EMF project. This is the project that actually performs the execution of QVT model transformations and the one which confers the Virtual-Machine quality to the whole solution. 7 Conclusions In this paper a Virtual-Machine-based QVT engine implementation has been described in terms 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 translate them into the byte-code language named ATC that drives the model transformation Virtual Machine. Finally, these semantically equivalent ATC models can be executed, the user being hidden from the inner details by the UI. Work is currently very advanced, medium-sized model transformations can usually be smoothly programmed and executed. However, there are still some unfinished areas, such as both the OCL Standard Library, which concerns the three QVT languages, and the QVTo Standard Library. Fortunately there are not currently any technological barriers to achieve full support on that matter. Also, translation support for sophisticated modular component reuse such as QVTo s mapping operations inheriting each other, or even refining QVTr Relations, is still unsupported. Ideally, translation transformations should be writable in terms of a higher-level language than 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 representation obtained via the editor-parser as source for the executable version of QVTo2ATC model transformation written in ATC, to generate an identical or similar version as an output. The semantical equivalence between the output artifact and the handwritten QVTo2ATC version could serve as a powerful test case to assert correctness of the procedure and to further enhance and extend the transformation itself. ISSN SISTEDES,

51 Acknownledgements Paper co-funded by the MEC (PTR OP), the Plan Nacional de Investigación Científica, Desarrollo e Innovación Tecnológica of the Ministerio de Industria, Turismo y Comercio (FIT ) and the Gobierno de Canarias (IDT-TF-07/013). Thank you Orlando Avila, Verónica Bollati, Christian Damus, Nuria Tejera and Dr. Edward Willink for your invaluable insight and contributions to this whole project. References 1. ikv++ homepage SmartQVT, a MOF 2.0 Operational Language Model Transformation Implementation 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 2007 ACM Symposium on Applied Computing, track on Model Transformation, pages ACM Press, Mar J. Bézivin, N. Farcet, J.-M. Jézéquel, B. Langlois, and D. Pollet. Reflective Model Driven Engineering. In Int. Conf. on UML, pages , Available at 5. F. Budinsky, D. Steinberg, E. Merks, R. Ellersick, and T. J. Grose. Eclipse Modeling Framework (EMF). Addison Wesley, Aug D. Carlson. Eclipse Distilled. Addison Wesley, J. S. Cuadrado, E. V. Sánchez, J. G. Molina, and A. Estévez. RubyTL a ATC: un caso real de transformación de transformaciones. In DSDM 07: Proceedings del IV Taller Sobre Desarrollo de Software Dirigido por Modelos, MDA y Aplicationes, Sep A. Estévez, J. Padrón, E. V. Sánchez, and J. L. Roda. ATC: A low-level model transformation language. In MDEIS 2006: Proceedings of the 2nd International Workshop on Model Driven Enterprise Information Systems, May F. Jouault and I. Kurtev. On the architectural alignment of ATL and QVT. In 1st track on MT - SAC 2006: Proceedings of the Symposium on Applied Computing. ACM Press, Apr OMG. MOF 2.0 Query/View/Transformation specification. Formal Specification formal/ , OMG, Apr OMG. MOF Model to Text Transformation Language. Technical Report formal/ , OMG, Jan J. Padrón, J. D. García, E. V. Sánchez, and A. Estévez. Implementación de un motor de transformaciones con soporte MOF 2.0 QVT. In DSDM 05: Proceedings of the II Taller sobre Desarrollo de Software Dirigido por Modelos. MDA y Aplicaciones, Sep Available at P. Queralt, L. Hoyos, A. Boronat, J. A. Carsí, and I. Ramos. Un motor de transformación de modelos con soporte para el lenguaje QVT Relations. In DSDM 06: Proceedings of the III Taller sobre Desarrollo de Software Dirigido por Modelos, MDA y Aplicaciones, Oct Available at E. V. S. Rebull, O. Avila-García, J. L. R. García, and A. E. García. Applying a modeldriven approach to model transformation development. In MDEIS 2007: Proceedings of the III International Workshop on Model-Driven Enterprise Information Systems, Jun E. V. Sánchez, V. Roldán, A. Estévez, and J. L. Roda. Making a case for supporting a bytecode model transformation approach. In Symposium on Eclipse Open Source Software and OMG Open Specifications, Jun J. B. Warmer and A. G. Kleppe. The Object Constraint Language: Precise Modeling With UML. Addison Wesley, E. D. Willink. On re-use of OCL for QVT model-checking editors. Technical report, Eclipse UMLX Project, Jun Available at TIF07/MDD-TIF07-QVTEditors.pdf. ISSN SISTEDES,

52 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, Abstract. El proceso de desarrollo de los Lenguajes Especícos del Dominio (DSL) puede afrontarse desde diversos espacios tecnológicos tales como XML, el Grammarware o la Ingeniería Dirigida por Modelos (MDE). En el caso de usar MDE, la denición de una sintaxis concreta para un DSL textual suele requerir la creación de un puente entre este espacio tecnológico y el Grammarware. Recientemente han sido propuestas diversas soluciones para este problema en las cuales el acoplamiento existente entre las sintaxis concreta y abstracta provoca una duplicación de información durante el proceso de desarrollo de DSLs. Por otra parte, en dichos enfoques la reusabilidad de sintaxis concretas no ha sido considerada. En este artículo presentamos el enfoque MSS (Metamodel Syntactic Sheets) para la denición de sintaxis concretas textuales. MSS ha sido ideado para promover la reutilización de sintaxis concretas textuales y para evitar la duplicación de información. En MSS los metamodelos son anotados con propiedades sintácticas. Un mecanismo de propagación reduce el número de anotaciones necesarias, así como el acoplamiento entre las sintaxis concreta y abstracta. Las sintaxis concretas textuales pueden ser reutilizadas anotando sintácticamente el lenguaje de metamodelado, lo cual hace posible la compartición de dialectos sintácticos (convenciones textuales) entre diferentes DSLs. 1 Introducción El proceso de desarrollo de los Lenguajes Especícos del Dominio (DSL) puede abordarse desde diversos espacios tecnológicos como XML, el Grammarware o la Ingeniería Dirigida por Modelos (MDE). Las técnicas y herramientas de MDE proporcionan claras ventajas para el proceso de desarrollo tales como la denición de modelos del dominio, gracias a la expresividad de los lenguajes de metamodelado, o la obtención de procesos de desarrollo automáticos. Sin embargo, los DSL textuales dependen de gramáticas para especicar sus sintaxis concretas, por lo que es necesario tender un puente entre los espacios tecnológicos de MDE y Grammarware. Como se menciona en [1], existe una signicativa redundancia entre la gramática de la sintaxis concreta textual y el metamodelo de la sintaxis abstracta. Esto ISSN SISTEDES,

53 es debido al acoplamiento entre ambos y es un problema común a todos los enfoques existentes para denir puentes entre Grammarware y MDE ([1], [2], [3], [4], [5]). Estos enfoques tampoco han prestado atención a la reusabilidad de sintaxis concretas, por lo que son necesarias nuevas propuestas orientadas a evitar la duplicación de la información y a promover la reutilización en el proceso de desarrollo de DSLs. Un ejemplo de la necesidad de reutilización de sintaxis concretas son las familias de DSLs textuales, cuyos miembros son lenguajes que comparten convenciones sintácticas, por lo que tienen sintaxis concretas similares. En este artículo introducimos el término dialecto sintáctico para referirnos a dichas convenciones. La aplicación de dialectos sintáticos suele involucrar la repetición de construcciones sintácticas a lo largo de la especicación de la sintaxis concreta, lo cual incrementa los costes de desarrollo y mantenimiento. En este sentido, las técnicas de reutilización podrían hacer más eciente la denición de dialectos sintácticos. MSS (Metamodel Syntactic Sheets) es un enfoque para la especicación de sintaxis 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 denición de dialectos sintácticos. En MSS, una denición de sintaxis concreta textual consiste de hojas sintácticas que contienen un conjunto de propiedades sintácticas que se aplican a los elementos del metamodelo. Un mecanismo de propagación difunde las propiedades sintácticas a través de las relaciones existentes entre los conceptos de metamodelado, tales como la herencia entre metaclases. La reutilización y la creación de familias de DSLs se consiguen gracias a este mecanismo de propagació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 2 la denición de patrones sintácticos como base del enfoque MSS. En la Sección 3 se describe el DSL utilizado para denir las sintaxis concretas textuales. En la Sección 4 se explica el mecanismo de propagación que permite la creación de familias de DSLs y la Sección 5 ofrece las conclusiones. 2 Patrones sintácticos En este artículo presentamos un enfoque para la denición de sintaxis concretas textuales 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 la Figura 1 se muestra el metamodelo de dicho DSL, llamado DataForm, cuyo propósito es denir formularios de datos consistentes en grupos de campos de datos. Este lenguaje de ejemplo presenta una estructura sintáctica anidada, una característica común en los DSLs textuales. El siguiente texto muestra un ejemplo de instancia de DataForm. ISSN SISTEDES,

54 NamedElement name: String Form data: String title: String groups fields Group Field required: Boolean label: String Text maxlength: Integer Date format: String Password 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 mayor claridad, los nombres de los símbolos no terminales se denen de acuerdo a los elementos del metamodelo; por ejemplo, metaclass-form se reere a la declaración de una metaclase Form y feature_form_data se corresponde con la denición de la propiedad data en la metaclase Form. metaclass_form := 'Form' ID '{' feature_form_data ';' feature_form_title ';' feature_form_groups '}' ; ISSN SISTEDES,

55 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 establecen la forma de las reglas de producción. Estas reglas podrían ser clasicadas de acuerdo a tres tipos de construcciones que se dan en el lenguaje: la cabecera y las construcciones de propiedad y agregación, que conforman el cuerpo. Las reglas de producción que pertenecen a una misma categoría tienen la misma estructura. Por ejemplo, las producciones feature_form_data y feature_form_title especican construcciones de propiedad y dieren únicamente en el primer símbolo terminal, `data' y `title', respectivamente; y las producciones feature_form_groups y feature_group_elds especican asociaciones de agregación y tienen también la misma estructura. Por lo tanto, cada tipo de construcción sintáctica puede considerarse un patrón sintáctico o plantilla que puede ser parametrizada con símbolos terminales. Esta idea de patrón sintáctico gramatical ha inuído en la denición del enfoque MSS. Usaremos el término propiedad sintáctica para referirnos a los parámetros de los patrones, y el término anotación sintáctica para la asignación de un valor a una propiedad. Algunos ejemplos de propiedades sintácticas podrían ser los delimitadores de inicio y n del cuerpo (llaves en el ejemplo), las palabras clave usadas para identicar los conceptos, el orden de las características (construcciones de propiedad y de agregación) dentro del cuerpo, los elementos que separan las características entre sí, las características que se declaran en la cabecera, etc. Los patrones sintácticos pueden ser aplicados a elementos tanto a nivel M2 como a nivel M3 de la arquitectura de cuatro niveles del paradigma de modelado, siendo los aplicados a éstos últimos los más generales, ya que pueden aplicarse a varios DSLs. Obviamente, los patrones generales son más interesantes ya que la anotación de propiedades sintácticas a nivel del lenguaje de metamodelado permite la reutilización de sintaxis concretas textuales. En este sentido, MSS incorpora un mecanismo de propagación que se encarga de propagar las anotaciones sintácticas a través de las relaciones entre 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 las sintaxis concretas y hace posible compartir dialectos sintácticos entre DSLs. La Sección 4 explica en detalle el mecanismo de propagación de anotaciones sintácticas. ISSN SISTEDES,

56 3 Metamodel Syntactic Sheets Esta sección describe el DSL propuesto para la anotación de metamodelos con propiedades sintácticas, al que también nos referimos como MSS (Metamodel Syntactic Sheet). El metamodelo que representa la sintaxis abstracta de MSS se muestra en la Figura 2. MSS proporciona los conceptos de syntactic sheet (hoja sintáctica) y de syntactic rule (regla sintá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 o más propiedades sintácticas a aplicar a un elemento concreto de un metamodelo (target). Una regla tiene un selector que identica el elemento objetivo (es decir, metaclase o característica) y un cuerpo que contiene una lista de anotaciones sintácticas. FeatureRule SyntacticSheet metamodeluri rules 0..* Rule target ClassRule Annotation property value annotations 0..* Fig. 2. Sintaxis abstacta del DSL de MSS A continuación se muestra una hoja sintáctica para el metamodelo DataForm de la Figura 1. Las palabras clave class y feature se usan para distinguir entre los dos tipos de regla. metamodel " 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 SISTEDES,

57 } Precediendo al conjunto de reglas de la hoja encontramos una sentencia que dene la URI de referencia del metamodelo a anotar sintácticamente. El propósito de las reglas declaradas en el ejemplo se describe a continuación. La primera regla se aplica sobre la metaclase abstracta NamedElement, y expresa dos propiedades: i) el valor del atributo name denido en la metaclase debe ser usado para identicar los conceptos del DSL y ii) la denición de un concepto del DSL empieza con el nombre de la metaclase. Esta regla se aplica a la metaclase que es el ancestro de 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 le asigna a la regla un valor de prioridad para resolver posibles colisiones de anotaciones sintácticas. En la Sección 4 se discute la técnica usada para resolver las colisiones como parte del mecanismo de propagación. La segunda regla se aplica a la metaclase Group. Esta regla dene la cadena - > como el separador entre los nombres y valores de las características de la metaclase. La metaclase Group sólo tiene una característica (elds), pero esta regla podría aplicarse a nuevas características, ya que se apoya en la relación de contención entre las metaclases y las características para propagar las anotaciones sintácticas. La tercera regla se aplica a la metaclase Field. Expresa tres propiedades: i) la declaración de campos de datos usa el nombre de la metaclase en mayúsculas, ii) la característica required preja la declaración y iii) la característica label está incluída en la cabecera de la declaración del concepto. La última regla se aplica a la característica groups perteneciente a la metaclase Form. Esta regla contiene dos propiedades que denotan que deben omitirse el nombre de la característica y el separador. Como hemos indicado anteriormente, MSS permite la denición de dialectos sintácticos mediante la anotación del lenguaje de metamodelado con propiedades sintácticas que son compartidas por diversos DSLs. Esto se consigue mediante la propagación de las anotaciones sintácticas desde el meta-metamodelo hacia los metamodelos. Las convenciones sintácticas establecidas para una familia de DSLs se expresan en una hoja sintáctica denida para el lenguaje de metamodelado. La hoja sintáctica que se muestra a continuación es un ejemplo de un dialecto sintáctico denido para el lenguaje de metamodelado Ecore. La primera regla dene las propiedades sintácticas comunes a todas las metaclases ya que el elemento objetivo es EClass, mientras que la segunda se aplica a la metaclase EStructuralFeature y tiene anotaciones sintácticas para las propiedades estructurales de las metaclases, es decir, atributos y asociaciones. metamodel " 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 SISTEDES,

58 class EStructuralFeature { multivalued-begin-delimiter: "[" ; multivalued-end-delimiter: "]" ; multivalued-separator: "," ; } La denición de una sintaxis concreta textual requiere de una o más hojas sintácticas: aunque es suciente con la hoja sintáctica para el metamodelo puede usarse otra hoja para el lenguaje de metamodelado. La hoja del lenguaje de metamodelado podría incluso ser suciente si el DSL no tuviera una notación especíca; en tal caso no existiría acoplamiento entre la sintaxis concreta textual y el metamodelo. En esta sección hemos introducido dos hojas sintácticas para ilustrar las ventajas de la reutilización de un dialecto sintáctico y la opción de ajustar las propiedades sintácticas para elementos especí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 las anotaciones de propiedades sintácticas a través de los elementos del metamodelo. Este mecanismo se ilustra con la propagación de las anotaciones de las dos hojas sintácticas introducidas en la sección anterior. En una hoja las reglas sintácticas se usan para denir los valores asignados a las propiedades de un elemento objetivo, si bien una regla no necesita proporcionar el valor para cada propiedad, ya que las anotaciones pueden ser obtenidas mediante propagación, a través de las relaciones existentes entre los conceptos de metamodelado. En concreto, se utilizan tres relaciones: i) la relación de herencia entre metaclases, ii) la relación de contención entre una característica y la metaclase que la contiene y iii) la relación de instancia entre un elemento del metamodelo y su metaclase en el metametamodelo (por ejemplo, Form es una instancia de la metaclase Ecore EClass). En el proceso de propagación las metaclases pueden obtener sus anotaciones sintácticas de sus padres, así como las características pueden obtener sus anotaciones de la metaclase a la que pertenecen. Esto reduce notablemente el número de anotaciones sintácticas a incluir en la hoja sintáctica del metamodelo. Por ejemplo, la anotación de metaclases abstractas, tales como NamedElement en la Figura 1, nos permite compartir la denición de propiedades sintácticas a lo largo de varios elementos de un metamodelo. Por otro lado, la anotación sintáctica del meta-metamodelo proporciona el mayor nivel de reutilización de sintaxis concretas textuales ya que las anotaciones de propiedades sintácticas pueden compartirse entre varios DSLs. Dado un elemento de un metamodelo, la propagación de las anotaciones sintácticas puede causar colisiones cuando hay varias anotaciones aplicables. Este problema se resuelve parcialmente priorizando las tres relaciones usadas para la propagación. Las relaciones de herencia y de contención entre metaclase y característica no pueden ser aplicadas al mismo elemento (clase o característica) al mismo tiempo por lo que sólo es necesario denir la prioridad de la relación de instancia frente a las relaciones de herencia y de contención. Hemos decidido priorizar la herencia y la contención sobre la instancia, ya que las anotaciones sintácticas denidas en el metamodelo son más especícas que las anotaciones denidas en el lenguaje de metamodelado. Por otro lado, como las metaclases pueden tener más de un padre, pueden aparecer colisiones en la propagación basada en herencia. Puede observarse que en la hoja ISSN SISTEDES,

59 sintáctica de metamodelo de la Sección 4 se ha asignado un valor de prioridad a las anotaciones de la metaclase NamedElement. Este valor se usa en caso de colisión debida a herencia, por lo que la resolución de las colisiones depende de la correcta asignación de prioridades que haga el usuario. El mecanismo de propagación funciona de la siguiente manera: primero se comprueban las anotaciones de propiedades sintácticas de cada metaclase. Después se solicitan las anotaciones no declaradas a las metaclases padres. Si una propiedad puede ser obtenida de varias metaclases padres se comprueban las prioridades de cada una. Las anotaciones no resueltas por la herencia pueden ser obtenidas a partir de la metametaclase (EClass en el lenguaje Ecore) a través de la relación de instancia. Una vez que la propagación ha sido aplicada a las metaclases del metamodelo, el proceso de continúa con las características de las metaclases. Después, la propagación usa la relación de contención en lugar de la relación de herencia. La relación de instancia se usa para propagar anotaciones desde las meta-metaclases que representan atributos (EAttribute en Ecore) y asociaciones (EReference en Ecore). Metamodelo DataForm NamedElement main-feature: "name" metaclass-identifier: "auto" Propagación Group.fields Propagación por la Relación de Contención Group por la Relación de Herencia value-separator: "->" feature-identifier: "auto" multivalued-separator: "," multivalued-end-delimiter: "]" multivalued-begin-delimiter: "[" value-separator: "->" metaclass-identifier: "auto" main-feature: "name" feature-identifier: "auto" content-begin-delimiter: "{" content-end-delimiter: "}" content-features-separator: ";" true-boolean-pattern: "is-" false-boolean-pattern: "not-" Propagación por la Relación de Instancia Propagación por la Relación de Instancia EReference multivalued-begin-delimiter: "[" multivalued-end-delimiter: "]" multivalued-separator: "," EStructuralFeature EClass metaclass-identifier: "auto-lowercase" value-separator: ":" false-boolean-pattern: "not-" true-boolean-pattern: "is-" content-features-separator: ";" content-end-delimiter: "}" content-begin-delimiter: "{" feature-identifier: "auto" multivalued-separator: "," multivalued-end-delimiter: "]" multivalued-begin-delimiter: "[" Propagación por la Relación de Herencia Lenguaje Ecore Fig. 3. Propagación de las anotaciones sintácticas para la metaclase Group y su característica fields ISSN SISTEDES,

60 Ahora vamos a ilustrar el mecanismo de propagación analizando las anotaciones aplicadas 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 en la Sección 4. La Figura 3 muestra todas las propagaciones que se aplican, las cuales se explican a continuación. En la hoja sintáctica del metamodelo, la metaclase Group está anotada con una regla que tiene un solo valor de propiedad, por lo que el resto de las anotaciones sintácticas deben ser obtenidas mediante propagación (las propiedades sintácticas requeridas para las metaclases se presentaron en la Sección 3). En un primer momento la relación de herencia proporcionaría dos anotaciones de la metaclase NamedElement. Las anotaciones 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 una colisión para la propiedad metaclass-identier, pero que la herencia prevalece sobre la relación de instancia como se indicó anteriormente. La caracteristica elds de Groups no ha sido anotada en la hoja sintáctica del metamodelo, 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 característica, pero sólo se obtienen dos anotaciones. Por lo tanto, las propiedades restantes se obtienen a partir del lenguaje de metamodelado, siendo elds es una instancia de la metaclase EReference de Ecore, que no ha sido anotada en la hoja sintáctica para Ecore, pero hereda las anotaciones sintácticas de EStructuralFeature. 5 Conclusiones y trabajo futuro En este artículo hemos presentado el enfoque MSS para la denición de sintaxis concretas textuales. Comparado con los enfoques existentes, MSS se caracteriza por dos conceptos principales: propiedades sintácticas y propagación de anotaciones de propiedades sintácticas. MSS ofrece las llamadas hojas sintácticas como una forma cómoda de organizar en reglas las anotaciones sintácticas para los elementos del metamodelo. La propagación de anotaciones sintácticas facilita dos formas de reutilización de sintaxis concretas textuales: i) reutilización de anotaciones dentro de un mismo metamodelo y ii) reutilización de dialectos sintácticos denidos mediante la anotación del lenguaje de metamodelado. Las principales contribuciones del enfoque MSS serían: Introducción de técnicas de reutilización para el desarrollo de sintaxis concretas textuales. Creación de dialectos sintácticos. Reducción de la duplicación de información gracias a la reducción del acoplamiento entre 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 existentes como el lenguaje de transformación de modelos RubyTL. Actualmente se están considerando nuevos patrones sintácticos y propiedades para mejorar la expresividad de las sintaxis concretas y MSS está siendo integrado en un framework para el desarrollo de DSLs. ISSN SISTEDES,

61 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/ References 1. Frédéric Jouault, Jean Bézivin, and Ivan Kurtev. TCS: a DSL for the Specication of Textual Concrete Syntaxes in Model Engineering. In Stan Jarzabek, Douglas C. Schmidt, and Todd L. Veldhuizen, editors, GPCE, pages ACM, OpenArchitectureWare Manuel Wimmer and Gerhard Kramler. Bridging Grammarware and Modelware. In MoDELS 2005 Conference Satellite Events, volume 3824, pages Lecture Notes in Computer Science, Andreas Kunert. Semi-automatic Generation of Metamodels and Models from Grammars and Programs. In Fith Intl Workshop on Graph Transformation and Visual Modeling Techinques. Electronic Notes in Theorical Computer Science, Tony Clark, Paul Sammut, and James Willans. Applied Metamodelling, A Foundation for Language Driven Development, Second Edition. Xactium, ISSN SISTEDES,

62 Verificación de la ejecutabilidad de operaciones definidas con Action Semantics Elena Planas 1, Jordi Cabot 1 y Cristina Gómez 2 1 Estudis 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 cristina@lsi.upc.edu 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 SISTEDES,

63 Persona nombre: String String context Persona::añadirPersona(n:String, e:string){ p: p Persona; * TrabajaEn 1 Departmento p:=createobject(persona); nombre: String addstructuralfeature(p,nombre,n); addstructuralfeature(p, ,e); } Fig 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). BehavioralFeature method Behavior +specification * * +node ActivityNode ExecutableNode * Operation StateMachine Activity activity Action StructuredActivityNode 0..1 ConditionalNode LoopNode SequenceNode Fig 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 UML 1 : 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 al 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,p 1 :InstanceSpecification,p 2 :InstanceSpecification): Crea un nuevo enlace de la asociación binaria 2 as entre los objetos p 1 y p 2. 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]. ISSN SISTEDES,

64 5. destroylink(as:classifier,p 1 :InstanceSpecification,p 2 :InstanceSpecification): Destruye el enlace de la asociación binaria as entre los objetos p 1 y p 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. titulo: String {disjoint,complete} Articulo * EsAutorDe 1..* Person a * TrabajaEn 1 autor nombre : String String Departmento nombre: String EnRevision Aceptado fechaacept : date Rechazado comentarios: String Fig Extracto del diagrama de clases de un sistema de gestión de congresos. 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 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 Persona::despedir() { destroylink(trabajaen,self,self.departmento); } Fig 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]. ISSN SISTEDES,

65 El digrafo MBCFG op = (V op, A op ) 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 V op. - Un arco desde un vértice v 1 hasta otro vértice v 2 se crea en A op si v 1 precede inmediatamente v 2 en la secuencia ordenada de nodos. - Un vértice v que representa un nodo condicional n, se enlaza con los vértices v 1 v n, 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 v next, 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 v next en A op. - 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 v next, 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 finderevision: if Operación enviararticulo: a:=createobject (EnRevision) reclassifyobject (self,rechazado, ) if reclassifyobject (self,aceptado, ) addstructuralfeature (a,titulo,tit) while createlink (EsAutorDe,a,autores[i]) addstructuralfeature (self,comentarios,com) addstructuralfeature (self,fechaaccept,d) Operación despedir: destroylink (TrabajaEn,self,self.department o) Fig 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 MBCFG op G, el conjunto de caminos de ejecución de op se define como c op =caminos(mbcfg op ) 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 c op 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. ISSN SISTEDES,

66 La Fig. 3.2 muestra los caminos de ejecución de los grafos de la Fig Operación finderevision: c 1 = { } c 2 = {<1,reclassifyObject(self,Rechazado, )>, <1,addStructuralFeature(self,comentarios,com)>} c 3 = {<1,reclassifyObject(self,Aceptado, )>, <1,addStructuralFeature(self,fechaAcept,d)>} Operación enviararticulo: c 1 = {<1,a:=createObject(EnRevision)>, <1,addStructuralFeature(a,titulo,tit)>} c 2 = {<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 ejecutable 4. 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 SISTEDES,

67 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 ac 1 (antecedente) y otra acción ac 2 (consecuente) expresa que la acción ac 2 se debe incluir en todos los caminos de ejecución donde aparece ac 1, con el fin de evitar violar las restricciones del diagrama de clases. Puede suceder que ac 1 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 ac 1 (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 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 (addstructuralfeature(p, ,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 SISTEDES,

68 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(c i,as) y max(c i,as) denotan la multiplicidad mínima y máxima de la clase c i 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,o 2 )> para cada asociación as no derivada donde c o una superclasse de c No tiene una participación obligatoria. destroyobject(o:c) <min(c,as),destroylink(as,o,o 2 )> para cada asociación as no derivada donde c o una superclase de c tiene una No participación obligatoria. createlink(as,o 1 :c 1,o 2 :c 2 ) destroylink(as,o1,o 3 ) (si min(c 2,as) <> max(c 2,as)) No (donde min(c 1,as) = max(c 1,as)) que se repetirá en el otro OR createobject(o 1 ) OR reclassifyobject(o 1,c 1,Ø) Si Si ext remo destroylink(as,o 1 :c 1,o 2 :c 2 ) createlink(as,o 1,o 3 ) (si min(c 2,as) <> max(c 2,as)) No (donde min(c 1,as) = max(c 1,as) OR destroyobject(o 1 ) Si que se repetirá en el otro extremo OR reclassifyobject(o 1,Ø,c 1 ) 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,o 3 )> para cada c nc y para cada asociación as no derivada donde c tiene una No particpación obligatoria. 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 Si instancia de cc AND <min(c,as),destroylink(as,o,o 3 )> para cada clase c de oc y para cada asociación as no derivada donde c tiene una participació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 4.2 Determinación de las Acciones Requeridas Para cada dependencia d devuelta por la función obtenerdependencias 5, 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 SISTEDES,

69 concuerdan con los parámetros de n.accion y (4) n.numero=d.numero 6 (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 Verificación de la ejecutabilidad débil del segundo camino de ejecución de la operación enviararticulo. Operación: enviararticulo Entrada: c 2 = { <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,o 2)> } 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 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,o 2)> OR <1,destroyObject(self)> } accionesreq = { <1,createLink(TrabajaEn,self,o 2)> OR <1,destroyObject(self)> } caux = { <1,1,destroyLink(TrabajaEn,self,self.departmento)> } Salida : accionesreq = { <1,createLink(TrabajaEn,self,o 2)> 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 SISTEDES,

70 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 contraejemplo, 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 SISTEDES,

71 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., (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, , (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, (2001) 5. Gallardo, M.M., Merino, P., Pimentel, E.: Debugging UML Designs with Model Checking. Journal of Object Technology, 1(2), (2002) 6. Egyed, A.: Instant Consistency Checking for the UML. Int. Conf. on Soft. Eng., (2006) 7. Emerson, E. A.: Temporal and Modal Logic. Handbook of Theoretical Computer Science, 8, (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, (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, (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), (1999) 15. Lilius, J., Paltor, I. P.: Formalising UML State Machines for Model Checking. Int. Conf. on the Unified Modeling Language, LNCS, 1723, (1999) 16. McAllister, A. J., Sharpe, D.: An Approach for Decomposing N-Ary Data Relationships. Software- Practice & Experience, 28(1), (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), (2006) 19. Object Management Group (OMG): UML 2.0 Superstructure Specification. OMG Adopted Specification (ptc/ ) (2007) 20. Object Manage ment Group (OMG): Semantics of a Foundational Subset for Executable UML Models RFP (ad/ ) (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, (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, (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, (2003) 24. Xie, F., Levin, V., Browne, J. C.: Model Checking for an Executable Subset of UML. Int. Conf. on Automated Soft. Eng, (2001) ISSN SISTEDES,

72 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, 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 SISTEDES,

73 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 SISTEDES,

74 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 r 2 de MW define una relación entre a 2 y a 3 de Ma y b 1 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. Ma Weaving Model Mw Mb a 1 a 1 r 1 b 1 b 1 a 3 a 2 a 2 r 2 b2 b 2 a Modelos de Anotación Fig. 1. Vista general de un modelo de weaving 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 preprocesamiento, 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 SISTEDES,

75 CREATE OR REPLACE TYPE Jefe_ProyectoAS (Codigo_Id NUM BER, Nombre VARCHAR2(30), Telefono NUM BER, Dirige REF Proyecto); Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 2, No. 3, 2008 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: ATL MOFScript PIM PSM OR Model SQL Conceptual Data Model CONTENT XML Model WORKING CODE UML2 c2 Conceptual Model SOURCE AMW Core Weaving Metamodel Extends Annotation Metamodel Annotation Model for ORDB SOURCE UML2modeloOR.atl TARGET Fig. 2. a) Dimensión del contenido en MIDAS y b) Uso de modelos de weaving para el DDM de BDOR c2 ORDB Metamodel c2 ORDB Model 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 SISTEDES,

76 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. Model Restriction 0..* -Name : string 0..* * Datatype «fk» Foreign Key «pk» Primary Key «unique» Unique «not null» Not Null * 1..1 Table * «nt» Nested Table Type -Name : String Basic Data Type -Name : String 0..* «array» Varray -Name : String -NumElements : Integer «ref» Reference Type -Name : String 1..* «udt» Structured Type -Name : String 0..* supertype Name : String - «persistent» Typed Table * * * Stored Nested Table -Name : String 1..1 Primitive Type LOB Type -unidad : Char 0..* 0..* Attribute -Name : String -size : Integer 1..* 0..* 0..* 0..* «method» Method -Name : String 1..1 overrides 0..1 Fig. 3. Metamodelo para el modelado de BDOR en Oracle 10g ISSN SISTEDES,

77 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. -model 1..* WElement -name : String -description : String -ownedelement 1 child WModel WRef ref : String WLink parent wovenmodel end 1 - * WModelRef WElementRef element 1-* link WLinkEnd Core Weaving Metamodel ownedelementref modelref * AnnotatedModel referencedmodel 1 1AnnotationModel Annotation AnnotatedModelElement contents annotatedmodelelement * Property Key Value * properties 1 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 SISTEDES,

78 de tipo Varray que se incluyan en el modelo de la BDOR serán de tamaño 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 SISTEDES,

79 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') to a : 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') to a : modeloor!attribute ( ) } Fig. 7. Parte de las reglas para la transformación de atributos o propiedades multivaluadas ISSN SISTEDES,

80 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 attribute helper context UML!Property def: mapto() : String = if self.getlink().oclisundefined() then 'NT' else if 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 SISTEDES,

81 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 (TIN /) y el proyecto M-DOS (URJC-CM 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, Bernstein, P A. Applying Model Management to Classical Meta Data Problems. First Biennial Conference on Innovative Data Systems Research, Asilomar, CA, USA Bertino, E. y Marcos, E. Object Oriented Database Systems. In: Advanced Databases: Technology and Design, O. Díaz y M. Piattini (Eds.). Artech House, 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, 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 Gerber, A., Lawley, M., Raymond, K., Steel, J., Wood, A.: Transformation: The Missing Link of MDA. International conference on Graph Transformation (2002) ISO / IEC 9075 Standard, Information Technology Database Languages SQL:2003, International Organization for Standardization, Jouault, F. y Kurtev, I. Transforming Models with ATL. En: Proc. of the Model Transformations in Practice Workshop. MoDELS Conference, Jamaica Marcos, E. Vela, B., Cáceres, P. y Cavero, J.M. MIDAS/DB: a Methodological Framework for Web Database Design. DASWIS Yokohama (Japan), Noviembre, LNCS 2465, Springer- Verlag, pp , Septiembre, Marcos, E., Vela, B. y Cavero, J.M. Extending UML for Object-Relational Database Design. Fourth Int. Conference on the Unified Modeling Language, UML Toronto (Canada), LNCS 2185, Springer-Verlag, pp Octubre, Marjan, M., Jan, H. y Anthony, M.S.: When and how to develop domain-specific languages. ACM Comput. Surv. 37 (2005) pp Microsoft SQL Server 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 , Oracle Corporation. Oracle Database 10g. Release 2 (10.2). In: Selic, B. The pragmatics of Model-Driven development, IEEE Software, Vol. 20, 5, Sept.-Oct Stonebraker, M. y Brown, P., Object-Relational DBMSs. Tracking the Next Great Wave. Morgan Kauffman, 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 , 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 Varró, D., Pataricza, A.: Generic and Meta-Transformations for Model Transformation Engineering. UML th International Conference, Vol Springer (2004) ISSN SISTEDES,

82 Una Aproximación MDA para Modelar Transacciones de Negocio a Nivel CIM José Bocanegra 1, Joaquín Peña 2, y Antonio Ruiz-Cortés 2 1 Facultad de Ingeniería, Universidad de la Amazonia Florencia-Colombia jbocanegra@uniamazonia.edu.co 2 Departamento de Lenguajes y Sistemas Informáticos, Universidad de Sevilla Sevilla-España {joaquinp, aruiz}@us.es Resumen. Con la globalización de los mercados, las transacciones de negocio están adquiriendo una importancia significativa porque permiten tener una visión abstracta de las interacciones que tienen lugar entre las distintas organizaciones que colaboran para el cumplimiento de sus objetivos de negocio. Esto ha permitido el desarrollo de numerosos trabajos de investigación que tratan de modelar de una u otra forma las transacciones de negocio. No obstante, ninguno de estos trabajos toma como referencia modelos a nivel CIM que estén enfocados a observar la interacción entre empresas desde el punto de vista de los gestores de las mismas. Por otra parte, M. Papazoglou propone un modelo que aglutina toda la información relevante para este tipo de interacciones llamado Business Transaction Model (BTM) cuyas características lo hacen ser óptimo para el nivel CIM. Sin embargo, el autor no propone una notación gráfica de este modelo. Además, el modelo no presenta la rigurosidad necesaria para una implementación basada en MDA/MDD. En este artículo proponemos un metamodelo adaptado a MDA/MDD y una notación basada en Colaboraciones UML2 con pequeñas extensiones para la instanciación del modelo BTM y desarrollamos una transformación MDD que permite mapear algunas características de BTM a procesos de negocio usando notación BPMN y viceversa. Palabras clave: Transacciones de Negocio, MDD, Servicios Web. 1. Introducción El panorama económico actual hace que las empresas tengan que ser altamente competitivas y necesiten implantar y actualizar continuamente sus procesos de producción. Este contexto obliga a las empresas a hacer un uso extensivo de la tecnología de la información para poder soportar sus propios procesos de negocio y agilizar las complejas interacciones que se dan con sus socios comerciales. M. Papazoglou ha denominado a estas interacciones como transacciones de negocio [5] definiéndolas como sigue: Una transacción de negocio es una interacción entre múltiples participantes, que buscan cumplir un objetivo de negocio. Las transacciones se extienden por largos períodos de tiempo y finalizan cuando se cumplen con éxito las condiciones convenidas. Las transacciones de negocio, además de modelar la interacción entre dos o más negocios, también muestran información de alto nivel orientada a los gestores empresariales. Esto hace que presenten información complementaria a la que se suele usar en los modelos CIM en áreas de investigación como los procesos de negocio o la interacción entre empresas gracias a Servicios Web compuestos. Concretamente, en [5], M. Papazoglou propone un modelo llamado Business Transaction Model (nos referiremos a él como BTM). En BTM, el autor, además del proceso de negocio, ISSN SISTEDES,

83 incluye cinco elementos adicionales para dotar de más expresividad al modelo CIM: (i) las partes y los roles, (ii) las restricciones e invariantes, (iii) los documentos, (iv) funciones de negocio predefinidas y (v) un conjunto de atributos y relaciones. Una explicación más detallada de esta propuesta puede verse en la Sección 2. Con el fin de aclarar las diferencias entre los modelos CIM más extendidos y el propuesto por Papazoglou vamos a presentar un ejemplo típico de una transacción de negocio. En la Figura 1 puede verse el flujo de información y bienes que se origina entre una agencia de viajes y una aerolínea cuando un viajero decide adquirir un plan turístico. La figura está elaborada usando la notación 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 actividades, el orden en el cual se realizan y los actores que participan. Por ejemplo, podemos ver que el rol Viajero realiza la actividad Buscar Viaje para después pasarle el control al rol Agencia de Viajes. En un proceso de negocio también podemos observar los documentos intercambiados y los mensajes que se originan. Por ejemplo, el Viajero suministra la información del itinerario a la Agencia de Viajes. Sin embargo, los elementos fundamentales para una transacción de negocio definidos por Papazoglou, como son las restricciones legales, las condiciones económicas o los perfiles de los roles que llevan a cabo cada parte en la transacción no son tenidos en cuenta. En la Tabla 1 podemos ver un ejemplo de una transacción de negocio que complementa el proceso de negocio de este mismo ejemplo. De este modo, podemos observar la restricción que limita al rol Aerolínea, en este caso, que sea de bajo costo. Así mismo podemos observar las operaciones de negocio que debe estar en capacidad de proveer el rol Agencia de Viajes: buscar plan y entregar plan. Elemento Descripción Transacción de negocio Proveer un plan de viaje Roles Aerolínea, Viajero y Agencia de Viajes Restricciones Sólo se contrata con aerolíneas de bajo costo Documentos Itinerario de viaje, billetes Operaciones de negocio: rol Agencia de Viajes Buscar plan y entregar plan Tabla 1. Ejemplo textual de una transacción de negocio basada en el modelo BTM Aunque el modelo BTM avanza el estado del arte mejorando los modelos usados a nivel CIM, el autor no entra en detalle en varios aspectos importantes: (i) no propone una notación gráfica para la instanciación del metamodelo, (ii) no muestra la correlación que existe entre los procesos de negocio (tenidos en cuenta en el metamodelo) y los modelos de transacción, ISSN SISTEDES,

84 (iii) el metamodelo presenta algunas deficiencias al no haber sido probado en un entorno de implementación, y (iv) no define transformaciones MDA/MDD del modelo CIM a otros modelos PIM o PSM, sino que sugiere, sin entrar en detalle, algunas posibles correlaciones con estándares WS-*. Con respecto al resto de propuestas estudiadas para el modelado a nivel CIM de este tipo de transacciones, éstas sólo han centrado sus esfuerzos en modelar únicamente los procesos de negocio, dejando de lado información importante que debe estar representada en un modelo de transacciones, p.e. [3], [9], [1]. Estos problemas, nos motivan a complementar la propuesta de Papazoglou para modelos CIM y su correlación con el proceso de implementación haciendo uso de una aproximación MDD. Por tal razón, en este artículo presentamos las siguientes aportaciones: Proporcionamos un metamodelo adaptado a MDA/MDD y una notación basada en Colaboraciones UML2 con pequeñas extensiones para la instanciación del modelo BTM (Sección 3). En esta sección y a raíz del descubrimiento de algunas deficiencias en el metamodelo de BTM, hemos realizado algunas mejoras/adaptaciones del mismo. Desarrollamos una transformación MDD que permite mapear algunas características estáticas de un modelo BTM basado en colaboraciones UML2 a procesos de negocio usando notación BPMN y viceversa. Esto nos permite mantener ambas vistas de una transacción coherentes entre sí (Sección 4). Para la validación tanto del modelado como de la transformación hemos desarrollado un prototipo que presentamos en la Sección 5, usando los lenguajes de transformación ATL, MoF script y la herramienta Eclipse GMF. 2. Trabajo relacionado En esta sección hacemos un análisis de las propuestas que han tratado el tema de modelado de transacciones de negocio. El resumen de este análisis puede verse en la Tabla 2. Propuestas Característica Elemento [5] [3] [9] [1] Nuestra propuesta Partes y roles - - Restricciones e invariantes Objetos - - Modelo CIM Funciones de negocio - - Procesos de negocio Atributos Notación gráfica Transformaciones Modelo estático a dinámico Tabla 2. Comparativa de propuestas 2.1. Modelos CIM para transacciones de negocio Como referencia para determinar cuál es la información que debe estar disponible en un modelo CIM para una transacción de negocio, hemos tomado la propuesta que hace M. Papazoglou en [5]. La Figura 2, representa el metamodelo UML de la propuesta, donde cada paquete hace referencia a un bloque: ISSN SISTEDES,

85 La parte o partes que interactúan en la transacción 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 se aceptan de común acuerdo entre las partes (Paquete 2). Ej: la parte que juegue el rol Aerolínea debe ser exclusivamente de bajo costo. Los documentos usados en la transacción (Paquete 3). Ej: el itinerario de viaje suministrado por el Viajero. Un conjunto de funciones de negocio predefinidas. Una función de negocio es una descripción de principios de negocio claramente definidos (Paquete 4). Ej: una función predefinida para ordenar un billete aéreo. Los procesos que se ejecutan en la interacción (Paquete 5). Las funciones de negocio y un conjunto de atributos y relaciones (Paquete 6). Ej: buscar plan, entregar plan. Fig. 2. Metamodelo BTM representado mediante notación UML No obstante, y a pesar de ser una de las aproximaciones más completas, el autor no propone una notación gráfica para la instanciación del modelo. Esta situación genera dificultades para el procesamiento automático del mismo. Adicionalmente, existen otras deficiencias que deben ser subsanadas, entre ellas el hecho de que en el metamodelo no se establecen los atributos de las clases, por ejemplo, para determinar la información asociada a un rol y la existencia de relaciones duplicadas entre dos clases, por ejemplo, entre la clase Business- Transaction y la clase Party. Por tal razón se hace necesaria una extensión de este modelo con el fin de dar soporte para la aplicación de técnicas MDA. Otras propuestas, como la presentada en [9], además del proceso de negocio cubre aspectos como los servicios y la información. Desafortunadamente, los modelos propuestos están ubicados a nivel PIM, es decir, orientados más hacia la construcción del software que hacia los directivos de las organizaciones. Como podemos observar en la Tabla 2, las demás propuestas estudiadas sólo se limitan a modelar el proceso de negocio. ISSN SISTEDES,

86 2.2. Transformaciones La propuesta de Papazoglou sólo se limita a mencionar un conjunto de estándares WS-* que pueden dar soporte para la ejecución de la transacción. Desafortunadamente no existen detalles sobre el mapeo entre el modelo y los estándares. En [3], López et al. proponen una división de la transacción de negocio en diferentes niveles: CIM, PIM y PSM. En esta propuesta ya se menciona el tema de MDD, y de cómo este puede ayudar en el proceso de transformación entre niveles. La propuesta plantea un conjunto de transformaciones MDD así: de PIM a PSM, de PIM a PIM y de PSM a PSM. El modelo de datos mapea a un modelo OR/XML schema. El modelo de navegación se mapea a un modelo XML/HTML. Los modelos de casos de uso de la transacción se mapean a modelos WSDL/BPEL. Desafortunadamente, esta propuesta no proporciona transformaciones entre el modelo CIM y PIM, ni transformaciones entre los modelos PSM y texto. En [1], Ibrahim et al. proponen tres niveles de división de la transacción: organizacional, de negocios y técnico. Aunque la propuesta no menciona elementos de MDD, podemos asumir que los tres niveles de la transacción pueden ser considerados como los tres niveles propuestos por MDD: organizacional a nivel de CIM, de negocios a nivel PIM y técnico a nivel PSM. Sin embargo, como se observa en la tabla, no hemos encontrado ninguna propuesta que proponga transformaciones CIM2CIM para mantener la correlación entre una vista dinámica, por ejemplo BPMN, y una vista estática, por ejemplo Casos de Uso o colaboraciones UML, como es nuestro caso. Esto nos permite afirmar que la transformación propuesta supone un avance respecto del estado del arte actual. 3. Propuesta de Modelado para BTM Como se mencionó en la sección anterior, hemos tomado como referencia para el modelado de transacciones de negocio la propuesta de Papazoglou. Aunque el autor no sugiere una notación gráfica para instanciar el modelo, optamos por usar modelos de colaboración UML2. Esta decisión está motivada porque en el campo de los agentes software, que organizan los agentes imitando las organizaciones de personas, uno de los elementos utilizados para modelar organizaciones de agentes y sus interacciones son las colaboraciones [6]. En contraposición, otras notaciones como las basadas en casos de uso no permiten especificar la información necesaria sin realizar cuantiosas extensiones, lo que motiva de nuevo el uso de colaboraciones como modelos base para la extensión Extensiones/modificaciones realizadas al modelo BTM y las colaboraciones UML2 Nótese que la inclusión de la notación nos ha motivado a realizar algunas modificaciones al metamodelo original [6]. Estas modificaciones han requerido: Incluir una clase denominada Organization. Esto permite agrupar los roles/actores por organizaciones y de esta forma, al momento de hacer el mapping a BPMN poder tener una Pool por cada organización. Además, complementa BTM proporcionando una información que es relevante para los modelos CIM. Incluir dos tipos de Business Objects (In y Out) para detallar si un artefacto es de entrada o salida. Esto permite establecer el orden de ejecución de las actividades. Como se observa, complementamos BTM añadiendo información de que productos / documentos / servicios son necesarios para una transacción y que productos / documentos / servicios son producidos ISSN SISTEDES,

87 Con relación a las colaboraciones UML, hemos realizado un conjunto de transformaciones basadas en trabajos anteriores de uno de los autores [6,7,8]. Las extensiones propuestas son las siguientes: Dividir los íconos de colaboración en tres compartimientos para incluir la siguiente información: (i) el tipo de colaboración (transacción o actividad), (ii) el nombre de la transacción o de la actividad, y (iii) los documentos manejados, tanto de entrada como de salida. Dividir los CollaborationsRoles en tres compartimientos para incluir la siguiente información: (i) el nombre del rol, (ii) los documentos manejados, y (iii) las funciones de negocio o capacidades que ofrece el role en la transacción Notación para modelos estáticos de BTM La siguiente es la notación que hemos usado para la instanciación de modelo: Una transacción de negocio (BusinessTransaction) se representa mediante una colaboración UML2 que presenta una notación gráfica en forma de elipse punteada dividida en tres compartimientos. En el primer compartimiento ubicamos el nombre de la transacción, en el segundo una descripción, y en el tercero, los documentos asociados a esa transacción. Los roles (Role) son representados usando CollaborationsRoles de UML2. En los CollaborationsRoles incluimos la siguiente información: (i) el nombre del rol, (ii) los documentos/productos manejados de entrada y salida y (iii) las operaciones ejecutadas. Las restricciones de negocio (BusinessConstraints) son representadas mediante una expresión dentro de corchetes y ubicada en una nota textual unida con el ícono de colaboración. Los objetos de negocio (BusinessObjects) se representan mediante compartimientos tanto en los roles como en la transacción de negocio. También adjuntamos un modelo de clases a la colaboración que representa las relaciones entre los objetos de negocio involucrados en la transacción. Esto nos permite representar las primitivas de negocio referenciales (dependencias entre objetos) como dependencias UML y las descriptivas (posibles valores para un objeto de negocio) como posibles valores de un enumerado UML. Las operaciones de negocio (BusinessOperations) son representadas como métodos en los roles. Las funciones de negocio (BusinessFunctions), es decir, transacciones de negocio por defecto, son representadas mediante un modelo de colaboración parametrizado. Las actividades (Activity) son representadas mediante los íconos de colaboración en los cuales se descompone una colaboración de mayor nivel de abstracción. Las primitivas de negocio (BusinessPrimitive) están divididas en dos tipos: por una parte, las primitivas de tipo referencial (Referential) se representan como dependencias UML entre clases; por otra parte, las primitivas de tipo descriptivas (Descriptive) se representan mediante enums de UML. La Figura 3 representa una transacción de negocio usando la notación propuesta. El objetivo de la transacción es Proveer un plan de viaje de acuerdo a las exigencias del Viajero. Esta transacción de negocio está regida por una restricción, la cual establece que la línea aérea que suministre el servicio de transporte debe ser exclusivamente de bajo costo. En la transacción 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 sólo podría hacerse cuando se defina quien va a jugar cada uno de los roles. Por ejemplo, la parte denominada Vueling puede jugar el rol Aerolínea. ISSN SISTEDES,

88 Las funciones de negocio (BusinessFunctions) son transacciones de negocio predefinidas para ordenes, pagos, transporte y entrega. UML2 proporciona modelos para parametrizar las colaboraciones. Aunque por razones de espacio no podemos mostrar estos modelos, son los que proponemos usar para definir transacciones parametrizadas que después pueden ser instanciadas para concretarse, por ejemplo, en una orden donde lo solicitado es un viaje. Fig.3. Notación: modelo estático 3.3. Notación para modelos dinámicos de BTM La Figura 4 representa la correlacion entre el metamodelo de BTM y los procesos de negocio usando notación BPMN. La correlación utilizada es la siguiente: La transacción en conjunto es representada por un proceso de negocio. Las organizaciones que agrupan a los roles son representadas mediante Pools. Los roles de cada organización son representados mediante Lanes. Las actividades en BTM son representadas como actividades en BPMN Los objetos de negocio son representados como DataObjects 4. Transformaciones de modelos estáticos de transacciones de negocio a BPMN Como hemos expuesto anteriormente, BTM propone la utilización de procesos para detallar las transacciones. Dado que entre los modelos de transacción y los de procesos existe ISSN SISTEDES,

89 Fig.4. Notación: modelo dinámico la correlación expuesta anteriormente, hemos desarrollado dos transformaciones ATL que permiten obtener parte de una colaboración UML partiendo de un BPMN, y viceversa. Para el ejemplo utilizado, tenemos una transacción de negocio que genera un proceso de negocio. Los roles Aerolínea, Viajero y Agencia de Viajes se trasforman en tres Lanes con el mismo nombre. A su vez, las tres actividades de BTM (buscar viaje, evaluar preferencias y suministrar tiquete) son transformadas a tres actividades BPMN. El modelo BPMN obtenido luego de la transformación, no es un modelo completo, sólo una estructura inicial. En algunos casos, es posible obtener el orden de ejecución de las actividades teniendo en cuenta los objetos de negocio intercambiados. 5. Implementación Mediante una infraestructura tecnológica hemos desarrollado un prototipo inicial que valide la viabilidad de obtener un prototipo ejecutable usando los modelos propuestos a nivel CIM. Para conseguir esto, en primer lugar se desarrolló la infraestructura necesaria para dar soporte a los modelos y transformaciones. Para el modelo estático de la transacción desarrollamos un editor de modelos usando la herramienta Eclipse GMF. Para el modelado de los procesos de negocio hemos utilizado un plugin de Eclipse que permite la elaboración de modelos BPMN. Finalmente, y haciendo uso del lenguaje de transformación ATL, desarrollamos dos transformaciones para obtener un modelo BPMN a partir de un modelo BTM y viceversa. La Figura 5 detalla el modelo BTM obtenido a partir del editor desarrollado, y el aspecto del proceso de negocio una vez aplicada la transformación. Adicionalmente, se han desarrollado un conjunto de pruebas para la transformación del modelo propuesto a infraestructuras de servicios web, por ejemplo, a WSDL, asumiendo que cada uno de los roles tendrá un único servicio web que lo represente. Teniendo esto en cuenta, hemos supuesto que existirán varios servicios web que probablemente serán compuestos para ofrecer la interfaz del servicio que representa a cada uno de los roles. Así pues, las operaciones de negocio que debe ejecutar cada rol se han transformado en métodos concretos del servicio ISSN SISTEDES,

90 Fig.5. Aspecto del editor de modelos y la transformación obtenida web y los documentos de entrada y salida de los roles, representados mediante agregaciones de tipos de datos XSD, han sido mapeados como parámetros de métodos setter y getter. La orquestación del proceso de negocio debe hacerse a mano, dado que el directivo que proporciona el modelo a nivel CIM no se preocupa por esos detalles. Como trabajo futuro, deseamos tomar como referencia las propuestas [3] y [1] para dividir la transacción en varios niveles: CIM, PIM, PSM y código y de esta forma generar transformaciones automáticas o semiautomáticas entre cada uno de los niveles. 6. Conclusiones En este trabajo hemos proporcionado un metamodelo adaptado a MDA/MDD, una notación basada en Colaboraciones UML2 y un conjunto de extensiones para la instanciación de un modelo de transacciones de negocio (BTM). De igual forma hemos desarrollado una transformación MDD que permite mapear algunas características de un modelo BTM basado en colaboraciones UML2 a procesos de negocio usando notación BPMN y viceversa lo que permite mantener ambas vistas de una transacción coherentes entre sí. Finalmente, y con el objetivo de realizar la validación tanto del modelado como de la transformación hemos desarrollado un prototipo usando los lenguajes de transformación ATL, MoF script y la herramienta Eclipse GMF. Los resultados obtenidos, nos permiten afirmar que información que otros autores utilizan a 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 no vinculados a las tecnologías de la información, como por ejemplo los integrantes de un departamento de ventas de las organizaciones implicadas. ISSN SISTEDES,