MCGEN: UN ENTORNO PARA LA GENERACIÓN AUTOMÁTICA DE COMPILADORES DE MODELOS ESPECÍFICOS DE DOMINIO

Transcripción

1 XV Jornadas de Ingeniería del Software y Bases de Datos JISBD 2006 José Riquelme - Pere Botella (Eds) CIMNE, Barcelona, 2006 MCGEN: UN ENTORNO PARA LA GENERACIÓN AUTOMÁTICA DE COMPILADORES DE MODELOS ESPECÍFICOS DE DOMINIO Manuel Llavador, José H. Canós, Patricio Letelier y Carlos Solís Grupo de Ingeniería del Software y Sistemas de Información Departamento de Sistemas Informáticos y Computación Universidad Politécnica de Valencia Camino de Vera S/N, C.P , Valencia (España) {mllavador, jhcanos, letelier, web: Palabras clave: Compiladores de Modelos, MDA, Software Factories, XSL, Semántica Resumen. A pesar de las expectativas abiertas en cuanto a mejoras en productividad y calidad, los paradigmas basados en factorías de software y desarrollo dirigido por modelos no han sido adoptados en un grado significativo por la industria del software. Uno de los mayores obstáculos para la aplicación de esta tecnología es el coste asociado a la construcción de los Compiladores de Modelos en los que se basan. En este trabajo presentamos un entorno orientado a servicios para la generación automática de Compiladores de Modelos específicos de dominio. La generación automática reduce drásticamente los costes así como los posibles errores de implementación. 1. INTRODUCCIÓN La generación automática de código permite obtener el código fuente de una aplicación a partir de modelos que describen, de forma gráfica o textual, su arquitectura y/o comportamiento. Los programas que dan soporte a ese proceso son conocidos de forma genérica como Compiladores de Modelos. La capacidad de generar código de forma automática a partir de modelos tiene un gran impacto en la productividad y calidad asociada al proceso de producción de software permitiendo la validación de las aplicaciones, sin coste añadido, reduciendo los tiempos de desarrollo, evitando posibles errores de implementación y permitiendo la reutilización de soluciones a problemas previamente modelados. El paradigma de Desarrollo de Software guiado por Modelos (Model-Driven Development, MDD [1]) propone la definición y uso de modelos a diferentes niveles de abstracción para la especificación de las aplicaciones y entiende el proceso de desarrollo como una secuencia de transformaciones en las que los modelos más abstractos (independientes de plataforma) se van refinando en modelos más concretos (específicos de plataforma) hasta que, en el paso final, se obtiene el código fuente de la aplicación como resultado de la compilación de los modelos concretos. Este nuevo tipo de herramientas CASE (Computer-Aided Software Engineering) proporcionan un conjunto de aplicaciones de soporte para la especificación de las aplicaciones (diseñadores gráficos, validadores, depuradores, etc.), basadas en un conjunto

2 de metamodelos, y compiladores de modelos que permiten la transformación de los modelos para llegar al código fuente. El mayor problema de esta aproximación es la necesidad de implementar un compilador de modelos para cada lenguaje. Además, aún suponiendo que tuviéramos un metamodelo capaz de describir cualquier tipo de aplicación, implementar el compilador de modelos correspondiente sería una tarea tanto o más compleja que la de implementar la propia aplicación y, por tanto, con los mismos problemas de errores en la implementación, baja productividad, calidad y reutilización. Como alternativa, recientemente han aparecido herramientas METACASE para la definición de Lenguajes Específicos de Dominio (Domain Specific Languages, DSL [2]) y generación automática de Factorías de Software (Software Factories [3]). La idea de partida consiste en proporcionar herramientas capaces de definir metamodelos sencillos, especializados en un dominio de aplicación, así como los compiladores de modelos correspondientes, con el objetivo de poder construir de forma automática herramientas CASE especializadas. Dentro de este paradigma se encuentran herramientas como Microsoft DSL Tools [4] o MetaEdit+ [5]. Al trabajar con modelos más específicos, los compiladores de los modelos son más sencillos de implementar. Sin embargo, en los entornos de desarrollo actuales la implementación de los mismos se sigue realizando con lenguajes imperativos específicos para cada herramienta (por ejemplo, C# en el caso de DSL Tools o un lenguaje de scripts propio en MetaEdit+) introduciendo de nuevo los mismos problemas de implementación, costes, etc. En este artículo presentamos MCGen, un entorno para la generación automática de compiladores de modelos que resuelve los problemas mencionados. Partiendo de modelos específicos de domino, expresados en formato XML, y de la gramática del lenguaje destino, MCGen permite definir de forma visual e intuitiva las transformaciones que debe aplicarse para obtener el código fuente asociado a una instancia de un modelo específico de dominio. Para ello, se basa en las relaciones semánticas entre el metamodelo y el lenguaje destino. Como característica adicional, MCGen sigue el paradigma orientado a servicios permitiendo su integración con otros entornos y herramientas, como las actuales herramientas METACASE. El resto del trabajo está estructurado como sigue: la siguiente sección presenta el proceso seguido para la generación del compilador de modelos. La Sección 3 presenta la arquitectura así como las características de cada uno de los componentes. En la sección 4 se expone un caso de estudio. Finalmente, la sección 5 presenta algunas conclusiones y sugiere trabajos futuros. 2. PROCESO DE GENERACIÓN DE LOS COMPILADORES DE MODELOS El objetivo común de todo compilador de modelos es aplicar una función de transformación que toma como entrada una instancia de un metamodelo cualquiera (el modelo origen) y devuelve como resultado el código fuente equivalente (el modelo destino). MCGen es capaz de generar compiladores de modelos para cualquier metamodelo origen y cualquier lenguaje destino cuya gramática sea conocida. Para ello se sigue un proceso en tres etapas: 2

3 especificación de la función de transformación, generación del compilador de modelos y prueba de la transformación. En esta sección presentamos en detalle cada una de las etapas. En la Sección 3 se presentará la arquitectura y los componentes que lo soportan Especificación del metamodelo origen, gramática destino y relaciones semánticas Una función de transformación se define en base a las relaciones semánticas existentes entre el metamodelo origen y la gramática del lenguaje destino. Dado que, a día de hoy, la mayoría de herramientas para la especificación de modelos son capaces de almacenar e importar los modelos en formato XML, MCGen admite cualquier modelo expresado en tal lenguaje. Eso significa, por tanto, que los metamodelos vendrán expresados como esquemas XSD. Por su parte, la sintaxis de un lenguaje de implementación se define mediante una gramática formada por un conjunto de símbolos terminales, que representan fragmentos del código fuente final, y un conjunto de símbolos no-terminales que representan reglas de reescritura al estilo de los lenguajes funcionales. Para poder construir el compilador de modelos, el primer paso consiste en establecer un conjunto de relaciones semánticas de equivalencia entre el metamodelo origen y la gramática destino. Esta es la única tarea que debe realizar el ingeniero de software de forma manual, como explicamos en la sección Generación automática del compilador de modelos Dado que nuestro objetivo es transformar modelos representados en formato XML, los compiladores de modelos creados por MCGen serán plantillas de transformación XSL. Una plantilla XSL está formada por elementos estructurales y elementos de selección de datos. Los primeros permiten construir la estructura del documento destino mientras que los segundos permiten inyectar datos del documento origen en el documento resultado de la transformación. Nótese que, si bien una plantilla XSL se emplea generalmente para transformar un documento XML en otro documento XML, en este caso se va a generar un programa sintácticamente correcto de acuerdo a la gramática del lenguaje destino. La forma en que los elementos del modelo origen se transforman en partes del código fuente depende exclusivamente del tipo de símbolo de la gramática con los que se relacionan, como se verá más adelante Prueba de la transformación Una vez generada la plantilla, MCGen aplica la transformación a una instancia del metamodelo mostrando al usuario el código fuente generado. Esto permite al usuario comprobar si el resultado es el esperado. En caso contrario el usuario tiene la posibilidad de volver al punto inicial. 3. ARQUITECTURA Y COMPONENTES DEL ENTORNO DE TRABAJO El proceso definido en la sección anterior viene soportado por el conjunto de componentes de que consta MCGen. Como se mencionó anteriormente, la única actividad del proceso que 3

4 1 XSDInferer 2 1 Modelo Origen.xml 1 Modelo Origen.xml 2 XPathInferer Servicios Web DSLXSLGenerator y 5 DSLXSMapper 5 Usuario gramar.dll Figura 1 Representación gráfica de la arquitectura y los componentes del entorno de MCGen requiere intervención por parte del usuario es la definición de las relaciones semánticas entre el metamodelo origen y la gramática destino. Para ello, MCGen dispone de una herramienta gráfica para la definición de las relaciones semánticas. Como complemento, tres Servicios Web implementan el resto de actividades automáticas. La Figura 1 muestra los distintos componentes de la arquitectura, que describimos en esta sección. Los números incluidos en la figura definen la secuencia de interacciones que implementan el proceso XSDInferer Es frecuente encontrarse con situaciones en las que los usuarios disponen de modelos instancia ejemplo pero no de los metamodelos correspondientes. Sin embargo, ya hemos comentado que la función de transformación se basa en el esquema XSD del metamodelo origen. El servicio Web XSDInferer * permite obtener de forma automática el metamodelo en formato XSD correspondiente a un modelo instancia dado. XSDInferer toma como entrada un documento XML que representa el modelo origen, y devuelve como resultado un esquema XSD respecto al cual el documento es válido. Para ello, de forma automática, realiza un recorrido secuencial sobre el documento XML, identificando los elementos y atributos que contiene y construyendo las correspondientes etiquetas <xsd:complextype > para cada elemento, <xsd:element > para cada subelemento, y <xsd:attribute > para cada atributo del esquema XSD XPathInferer Las relaciones semánticas entre los símbolos de la gramática y los elementos del metamodelo se almacenan asociando a cada símbolo de la gramática el conjunto de expresiones XPath en las que se encuentran los datos del modelo origen que se emplean para * 4

5 aplicar una determinada regla de transformación. Estas expresiones pueden llegar a ser muy complicadas de calcular, por lo que MCGen incorpora un servicio Web, XPathInferer, capaz de obtener automáticamente el listado de conceptos (elementos y atributos del modelo) y las expresiones XPath en las que aparecen dentro de un documento XML dado. En [6] se explican en detalle los algoritmos empleados para ello. De esta manera, las relaciones semánticas que definen la transformación están compuestas por relaciones entre los conceptos del metamodelo origen y los símbolos de la gramática destino, ocultando al usuario la complejidad de las expresiones XPath Biblioteca Gramar Una gramática, como ya se ha comentado, está formada por un conjunto de símbolos terminales, que representan el código fuente, y un conjunto de no-terminales que representan las reglas reescritura. Los terminales pueden ser de dos tipos: conceptos o texto. Los conceptos representan valores de elementos o atributos del modelo origen, y los de tipo texto representan cadenas de caracteres constantes. Los no-terminales pueden ser de dos tipos: reglas o enumeraciones. La diferencia entre las reglas y las enumeraciones radica en que las primeras se aplican a un solo elemento del modelo origen, mientras que las enumeraciones permiten transformar un conjunto de elementos. Dado que los elementos de una enumeración pueden ser heterogéneos, se definen distintos formatos de enumeración para cada tipo de elemento a transformar. Opcionalmente, tanto las reglas como las enumeraciones pueden venir condicionadas por cláusulas de navegación (campos where). MCGen proporciona una biblioteca de clases para la construcción de las gramáticas de forma sencilla. Esta biblioteca de clases se ha representado en la Figura 1 con el nombre gramar.dll DSLXSLGenerator El servicio Web DSLXSLGenerator permite obtener automáticamente la plantilla XSL que implementa el compilador de modelos partiendo de las relaciones semánticas. La forma en que los modelos origen se transforman en el código fuente depende exclusivamente del tipo de símbolo de la gramática que los representa. Para los símbolos terminales, se inyectarán los valores en el código. Para los no-terminales, se aplicarán las reglas de reescritura recursivamente. Los terminales de tipo texto no se enlazan, ya que no toman datos del modelo origen, y simplemente inyectan texto constante en la plantilla. El Algoritmo 1 describe la construcción de la plantilla XSL DSLXSMapper DSLXSMapper es la herramienta gráfica que permite definir la gramática y establecer las relaciones semánticas con el metamodelo origen. Además, se encarga de soportar el proceso 5

6 1) Partiendo de un documento XML vacío se añade una cabecera stylesheet para indicar que se trata de una plantilla XSL: <xsl:stylesheet version="1.0" xmlns:xsl= 2) Se añade un elemento output para indicar que el resultado de la transformación será de tipo textual: <xsl:output method="text"/>. A continuación, partiendo de la regla raíz 3) Se añade un elemento template. El atributo match toma como valor la ruta en la que se encuentran los datos del modelo origen a inyectar en el código fuente y el atributo mode el nombre del símbolo: <xsl:template match="ruta" mode="nombre "> 4) Se añaden elementos para cada símbolo en los que se descompone la regla: a. Para símbolos de tipo texto, un elemento text con el contenido de la cadena: <xsl:text>texto_constante_a_inyectar</xsl:text> b. Para conceptos, un elemento value-of con atributo select con la ruta/s en las que se encuentran los datos del modelo origen contextualizadas en función del valor del atributo match de la template (rutas relativas). En caso de haber definido una cláusula where de navegación se añadirá a la ruta entre corchetes: <xsl:value-of select="ruta_de_los_datos_contextualizada[cláusula_where]"/> c. Para reglas, un elemento apply-templates con atributo select con valor de la ruta, igual que en los conceptos, y atributo mode con el nombre de la regla. Recursivamente se aplica el algoritmo desde el punto 3 para cada símbolo en los que se descompone: <xsl:apply-templates select="ruta[cláusula]" mode="nombre "> d. Para enumeraciones, un apply-templates igual que en el caso de las reglas. Además, un template igual que en el punto 3 con un elemento choose que representa los distintos formatos de enumeración en elementos when donde el atributo test contiene la condición del formato de enumeración y un apply-templates. Recursivamente se volverá al punto 3 para cada símbolo sobre el que se reescribe cada uno de los formatos de enumeración <xsl:choose> <xsl:when test="condición"> un when por cada formato <xsl:apply-templates > </xsl:when> </xsl:choose> Algoritmo 1 Construcción de la plantilla XSL que representa el compilador de modelos completo de desarrollo de los compiladores de modelos invocando los distintos servicios Web de forma transparente al usuario. La parte izquierda de la Figura 2 muestra una captura de pantalla tomada durante la definición de la gramática que utilizaremos en el caso de estudio presentado en la siguiente sección. La interfaz está compuesta por un conjunto de botones, que representan cada una de los símbolos de la gramática, donde cada tipo de símbolo se identifica por un color distinto, y un conjunto de botones constructores identificados por tres puntos ( ). Figura 2 Capturas de pantalla de la herramienta durante la definición de la gramática destino y definición de las relaciones semánticas entre los conceptos del modelo origen y los símbolos de la gramática 6

7 Al pulsar sobre un botón, aparece un menú contextual que permite modificar las propiedades del símbolo (para los botones de símbolos) o añadir nuevos símbolos a la gramática (para los constructores). Los menús contextuales dependen del tipo de símbolo, y permiten mostrar formularios para la especificación de sus propiedades. Por ejemplo, para las reglas se debe especificar el nombre de la regla, los conceptos del metamodelo origen con los que se relacionan semánticamente y las clausulas where a aplicar; para los símbolos de tipo texto, se indica el texto a inyectar; y para el resto de elementos se actúa de forma similar. A modo de ejemplo, en la parte derecha de la Figura 2 se muestra el formulario para la definición de una regla. Obsérvese que los conceptos del metamodelo origen se presentan al usuario junto con las expresiones XPath de forma automática, sin que el usuario tenga que teclear las expresiones manualmente. La herramienta también permite almacenar y recuperar definiciones de gramáticas. En la siguiente sección presentamos un caso de estudio en el que se realiza el proceso completo de generación de un compilador de modelos. 4. CASO DE ESTUDIO: DE ESQUEMA RELACIONAL A SQL Como caso de estudio se ha escogido un ejemplo típico en el campo de la transformación de modelos y compilación automática consistente en obtener el código SQL correspondiente a un esquema relacional. El modelo origen, el esquema relacional de la base de datos, se expresa como instancia del metamodelo representado en la parte izquierda de la Figura 3. La clase abstracta RModelElement representa los campos comunes a todos los símbolos del esquema relacional donde name representa el nombre del símbolo y es de tipo cadena. La clase Schema representa el esquema relacional completo, el cual está formado por un conjunto de tablas representadas por la clase Table. Cada tabla está formada por un conjunto de columnas, un conjunto de claves y un conjunto de claves ajenas, respectivamente Column, Key y Figura 3 Representación gráfica del metamodelo y modelo de ejemplo propuestos. 7

8 ForeignKey. Las claves hacen referencia a columnas de la tabla y las claves ajenas hacen referencia a columnas de la tabla y a una clave de la tabla a la que referencian. Por último, el campo type de las columnas representa el tipo de datos que contendrán. Este metamodelo puede representarse con un esquema XSD (disponible, como el resto de esquemas y documentos mencionados en esta sección, en Como ejemplo instancia del metamodelo propuesto se ha utilizado el modelo de esquema relacional representado en la parte derecha de la Figura 3. Este modelo está formado por tres tablas: Order, Item y USAddress. Cada tabla está formada por un conjunto de columnas con sus respectivos tipos de datos. Además, existe una clave para cada tabla y tres claves ajenas, dos que relacionan la tabla Order con la tabla USAddress y una que relaciona la tabla Item con la tabla Order. Este modelo está almacenado en formato XML. Por otra parte, como lenguaje destino se ha escogido un subconjunto del lenguaje SQL que permite crear la base de datos correspondiente a cualquier modelo instancia del metamodelo propuesto. Este lenguaje se especifica con la gramática de la Figura 4. En la figura, la regla raíz se ha representado en negrita y subrayado, las reglas se representan subrayadas, las enumeraciones en cursiva con los formatos entre paréntesis, los textos entre comillas dobles con el texto simple en negrita y los símbolos en cursiva, los conceptos en negrita y las distintas alternativas en las reescrituras separadas por el símbolo. Es importante mencionar que, aunque primarykeycolumns, foreignkeycolumns y foreignkeyprimarykeycolumns se reescriben al mismo término (columns), no representan el mismo concepto semántico y por tanto deben ser reglas distintas. Esto nos permite enlazarlos correctamente con los conceptos del modelo origen al definir la función de transformación. Las símbolos y representan el carácter salto de línea y tabulación respectivamente. Haciendo uso de DSLXSMapper se puede construir gráficamente, y de forma incremental, la gramática estableciendo las relaciones semánticas con el metamodelo origen (representadas en la parte izquierda de la Figura 5). Figura 4 Gramática para los scripts SQL resultado de la compilación de los modelos 8

9 Figure 5 Relaciones semánticas y resultado de la transformación Una vez definida la gramática y las relaciones semánticas, pulsando el botón END de la interfaz se invoca el servicio Web DSLXSLGenerator para obtener automáticamente la plantilla de transformación XSL. La Figura 6 muestra un fragmento de la plantilla XSL resultante. En la última fase, DSLXSMapper prueba la plantilla generada sobre el modelo instancia, obteniendo el resultado mostrado en la parte derecha de la Figura 5. Figure 6 Fragmento de la plantilla XSL que representa el compilador de modelos 9

10 5. CONCLUSIONES Y TRABAJOS FUTUROS En este trabajo se ha presentado MCGen, un entorno para la generación automática de compiladores de modelos basados en plantillas de transformación XSL. Con nuestro enfoque se reducen drásticamente los costes de implementación de los compiladores, cuello de botella de las aproximaciones actuales para el desarrollo de software basado en factorías y MDD. El hecho de poder generar automáticamente la plantilla, sin coste adicional, facilita la construcción incremental de los compiladores de modelos permitiendo realizar pruebas a medida que se va construyendo la gramática para comprobar que se obtiene el resultado esperado, mejorando aún más la calidad del resultado. La aproximación basada en el uso de conceptos semánticos permite abstraer los detalles estructurales del formato de almacenamiento de los modelos origen, permitiendo al ingeniero de software centrarse en la definición de la función de trasformación de conceptos en fragmentos del código fuente. Como trabajo futuro se plantea incorporar ontologías que permitan automatizar más el proceso así como hacer uso de las funciones de transformación de los lenguajes XSLT y XPath para permitir transformaciones sobre los valores (por ejemplo, concatenación o subcadenas). Gracias a la implementación de los componentes como servicios Web, todo el proceso de generación se realiza en un servidor. Esto nos permite construir un catálogo de transformaciones y relaciones semánticas entre metamodelos y lenguajes de programación que permitirá en un futuro automatizar aún más el proceso infiriendo automáticamente, o al menos sugiriendo las relaciones semánticas que servirán como guía al diseñador. Por otra parte, la orientación a servicios hace que la solución sea independiente de plataforma y fácil de integrar en otros entornos o herramientas, como por ejemplo las herramientas METACASE o los graficadores de metamodelos existentes en el mercado. Así, está previsto integrar el entorno presentado en este artículo en un ambiente software para la generación automática de herramientas gráficas que den soporte a la especificación de modelos basados en metamodelos específicos de dominio. Esto completa el ciclo de desarrollo de herramientas CASE específicas de dominio consiguiendo una aproximación totalmente automatizada. REFERENCIAS [1] Stuart Kent, Model Driven Engineering, LNCS 2335, [2] Marjan Mernik, Jan Heering y Anthony M. Sloane. When and how to develop domainspecific languages. ACM Computing Surveys, 37(4): , [3] Jack Greenfield, Keith Short, Steve Cook y Stuart Kent, Software Factories, Assembling Applications with Patterns, Models, Frameworks and Tools. Wiley [4] Microsoft Visual Studio 2005 Domain-Specific Language Tools, [5] Domain Specific Modeling with MetaEdit+. [6] Manuel Llavador, José H. Canós, Un entorno para la generación semiautomática de plantillas de transformación entre documentos XML, Proyecto Final de Carrera, Facultad de Informática de la Universidad Politécnica de Valencia