documentacion qvt

QVT Query View Transformation

Contenido

INTRODUCCIÓN......................................................................................................................................... 3

1.1. DESARROLLO DE SOFTWARE DIRIGIDO POR MODELOS MDD.........................................................5

1.1.1. ELEMENTOS CLAVES EN MDD: MODELOS Y TRANSFORMACIONES..............................................................51.1.1.1. Transformación........................................................................................................................51.1.1.2. Modelos...................................................................................................................................51.1.1.3. Metamodelo............................................................................................................................5

1.2. MDA (ARQUITECTURA DIRIGIDA POR MODELOS)..........................................................................6

1.3. MOF............................................................................................................................................. 6

1.4. OCL............................................................................................................................................... 7

2. TRANSFORMACIÓN DE MODELOS.....................................................................................................9

2.1. CARACTERÍSTICAS DE LOS ENFOQUES DE TRANSFORMACIÓN...........................................................................92.1.1. Especiación (opcional)..............................................................................................................92.1.2. Reglas de transformación......................................................................................................102.1.3. Aplicación de las reglas..........................................................................................................102.1.4. Organización de Reglas..........................................................................................................112.1.5. Relación origen-destino.........................................................................................................112.1.6. Incrementalidad.....................................................................................................................122.1.7. Direccionalidad......................................................................................................................122.1.8. Trazabilidad...........................................................................................................................12

3. QVT................................................................................................................................................. 14

3.1. HISTORIA.................................................................................................................................... 14

3.2. DEFINICIÓNES DE QVT................................................................................................................. 14

3.3. ARQUITECTURA QVT................................................................................................................... 16

3.3.1. EL LENGUAJE RELATIONS...............................................................................................................163.3.2. EL LENGUAJE CORE.......................................................................................................................163.3.3. ANALOGÍA DE MÁQUINA VIRTUAL.......................................................................................................17

3.4. IMPLEMENTACIONES IMPERATIVAS............................................................................................17

3.4.1. Operational Mapping.............................................................................................................173.4.2. Implementación Black-box.....................................................................................................17

3.5. ESCENARIOS DE EJECUCIÓN......................................................................................................... 18

3.6. METAMODELOS MOF.................................................................................................................. 19

3.7. EL LENGUAJE RELATIONS............................................................................................................. 21

3.7.1. TRANSFORMACIONES Y TIPOS DE MODELOS..........................................................................................213.7.1.1. Dirección de ejecución de una transformación......................................................................21

1


3.7.2. RELACIONES Y DOMINIOS..................................................................................................................223.7.2.1. Cláusulas when y where.........................................................................................................223.7.2.2. Relaciones Top-level...............................................................................................................233.7.2.3. Check y Enforce......................................................................................................................23

3.7.3. PATTERN-MATCHING.......................................................................................................................243.7.4. KEYS Y CREACIÓN DE OBJETOS USANDO PATRONES................................................................................26

3.8. EL LENGUAJE OPERATIONAL MAPPING........................................................................................27

4. ANÁLISIS DE HERRAMIENTAS PARA TRANSFORMACIÓN DE MODELOS.............................................30

4.1. CARACTERÍSTICAS DE LAS HERRAMIENTAS DE TRANSFORMACIÓN...................................................................304.2. IMPLEMENTACIONES DE QVT................................................................................................................31

4.2.1. Borland QVT (Borland Together Architect).............................................................................314.2.2. SmartQVT..............................................................................................................................314.2.3. MOMENT...............................................................................................................................324.2.4. Eclipse M2M Project - Operational and Declerative(Core and Relation)................................324.2.5. MediniQVT.............................................................................................................................32

5. APLICACIÓN DE QVT EJEMPLO.........................................................................................................34

5.1. MEDINI QVT................................................................................................................................ 34

5.1.1. HISTORIA......................................................................................................................................345.1.2. CARACTERÍSTICAS............................................................................................................................34

Bibliografia.......................................................................................................................................................36

2


IntroducciónLa demanda actual de software en nuestra sociedad es cada vez más elevada, pero el proceso de desarrollo también es más costoso, esto lleva buscar estrategias que permitan la reutilización de software y además facilite el proceso de desarrollo, se busca elevar el nivel de abstracción y elevar la reutilización, reduciendo el esfuerzo e incrementando la calidad.

La Arquitectura dirigida por modelos (MDA) es una iniciativa que nació de la Object Management Group OMG que propone un marco de trabajo basado en la reutilización y transformación de modelos. El principio fundamental de MDA son la Abstracción, automatización y la estandarización. El proceso central de MDA es la transformación de modelos que por medio de su evolución, permiten de manera sistemática obtener un producto final.

La OMG con el propósito de lograr un estándar para la transformación de modelos inicia un proceso de estandarización del cual surge Query View Transformatios QVT, con el cual se pretende establecer un lenguaje para la transformación de modelos y un lenguaje para la definición y generación de vistas que facilite el análisis de modelos desde diferentes perspectivas de los desarrolladores.

3


Teoría General de MDD

4


1.1. Desarrollo de software dirigido por modelos MDD.El nuevo paradigma del desarrollo de software surgió en los 70 (Structured Analysis and System Specification), que promete una mejora de la productividad y de la calidad del software a través de un proceso guiado por modelos y soportado por potentes herramientas que generan códigos a partir de modelos.

MDD tiene como objetivo organizar los niveles de abstracción y las metodologías de desarrollo, todo ello promoviendo el uso de modelos como artefactos principales a ser construidos y mantenidos. MDD cubre amplias áreas de investigación:

Lenguajes para la descripción de modelos.

Definición de lenguajes de transformación entre modelos

Construcción de herramientas de desarrollo.

Para dar respuesta a los problemas en el contexto de MDD, el Object management Gruop (OMG) ha lanzado la iniciativa Model Driven Arquitect (MDA) como proceso de desarrollo.

1.1.1. Elementos claves en MDD: Modelos y Transformaciones.

1.1.1.1. Transformación.Transformación es la generación automática de un modelo destino a partir de un modelo origen de acuerdo a una especificación.

Existen dos tipos de transformaciones: Transformaciones modelo a modelo (M2M) Transformaciones modelo a texto (M2T) Estándares :

– M2M: ATL, QVT– M2T: MOF-to-text, XPand

1.1.1.2. Modelos.Un modelo está constituido por un conjunto de elementos que proporcionan una descripción sintética y abstracta de un sistema, concreto o hipotético. Los modelos no son solo documentativos, son la esencia y el código es una consecuencia de los modelos. Frecuentemente se presenta a un modelo como una combinación de dibujos y texto. El texto puede estar en un lenguaje de modelado o en lenguaje natural.

5


1.1.1.3. Metamodelo. Un metamodelo define modelos y establece sus propiedades de forma precisa. Como es un modelo, se expresa en lenguaje de modelado.

6


1.2. MDA (Arquitectura dirigida por modelos)La arquitectura dirigida por modelos es un marco de trabajo cuyo objetivo central es resolver el problema del cambio de tecnología e integración. La idea principal de MDA es usar modelos, de modo que las propiedades y características de los sistemas queden plasmadas de forma abstracta, y por tanto, los modelos no serían afectados por tales cambios.

MDA permite la construcción de software a partir de modelos los cuales a través de transformaciones se convierten en código. En este contexto en MDA se abordan desde el punto de vista de los estándares abiertos. En este caso, el estándar Meta Object Facility (MOF) , proporciona un mecanismo para definir metamodelos. El estándar Query/Views/Transformations (QVT) indica cómo proporcionar soporte tanto para transformaciones como para consultas. A diferencia de otros lenguajes nuevos, QVT se apoya en el ya existente lenguaje Object Constraint Language (OCL) para realizar las consultas sobre los artefactos software.

1.3. MOF MOF (Meta Object Facility) es el metamodelo facilitado por MDA como vocabulario Básico o metamodelo, los metamodelos y modelos se suelen organizar en una estructura de cuatro capas M3-M0 con la siguiente distribución:

En el nivel M1 se sitúan los modelos, tal y como los hemos introducido aquí, descripciones abstractas de un sistema

En el nivel M2, se sitúan los metamodelos, «vocabularios para definir modelos».

El nivel M3, que cierra la estructura por arriba, contiene el vocabulario base que permite definir metamodelos. Cabe resaltar que este nivel suele contener un único vocabulario, que caracteriza la aproximación de modelos escogida.

Es imperativo que este vocabulario o metametamodelo esté definido utilizando como vocabulario así mismo, de ahí que se cierre la estructura.

El nivel inferior, denominado M0, es en el que se sitúan los datos, es decir las instancias del sistema bajo estudio.

7


1.4. OCLObject Constraint Language (OCL) es un lenguaje notacional para el análisis y diseño de sistemas software. Está definido como lenguaje estándar para dar soporte al Unified Modeling Language (UML), el cual es un estándar de OMG para el análisis y diseño orientado a objetos. OCL da soporte a UML para la especificación de restricciones y consultas sobre modelos, permitiendo definir y documentar los modelos UML de forma más precisa.

Un modelo UML, como por ejemplo un diagrama de clases o un diagrama de estados, no constituye una especificación lo suficientemente precisa y libre de ambigüedades de un sistema. Las expresiones OCL completan esta especificación, convirtiéndose en información vital para los modelos orientados a objetos y otros objetos para el modelado. Esta información a menudo no puede ser expresada mediante un diagrama.

Cada expresión OCL se refiere a tipos (por ejemplo, clases, interfaces,. . . ) definidos en diagramas UML. De esta manera, una expresión OCL estará siempre ligada a un diagrama UML (no tendría sentido de manera aislada).

Las expresiones OCL pueden ser usadas en cualquier punto de un modelo para indicar un valor. Un valor puede ser un valor simple, como un entero, pero puede ser también la referencia a un objeto, una colección de valores, o una colección de referencias a objetos. Una expresión OCL puede representar, por ejemplo, un valor booleano usado en la condición de un diagrama de estados, o un mensaje en un diagrama de interacción. Una expresión OCL puede referirse a un objeto específico en un diagrama de interacción o de objetos.

8


Transformación de modelos

9


2. Transformación de modelosLa transformación de modelos juega un papel clave en el desarrollo dirigido por modelos, puesto que serán un conjunto de transformaciones las que, partiendo de un conjunto de modelos que especifican un sistema, permitan conseguir el software ejecutable sobre una plataforma concreta. En este contexto, transformación de modelos hace referencia al proceso de convertir un modelo en otro modelo del mismo sistema (Hebach 2006).

La transformación de modelos se considera el proceso central de MDA. La transformación es el proceso que, basado en una serie de reglas, define los mecanismos para el paso de un modelo origen a un modelo destino. A partir de la estandarización promovida por QVT y atendiendo a las necesidades prácticas de la transformación de modelos, surgen diversas estrategias de transformación que van más allá del uso de elementos del metamodelo y definen mecanismos de transformación basados en tipos de elementos, patrones, información de la plataforma y otros modelos e información adicional. Otras estrategias de transformación son VIATRA y ATL (OMG-MDA, 2003).

En la siguiente figura representa la arquitectura de transformación de modelos; en ella se muestra cómo se definen y aplican las transformaciones que se basan en el uso de metamodelos (Jezequel, 2005).

2.1. Características de los enfoques de transformación.

2.1.1. Especiación (opcional)Esta característica refiere a los mecanismos de especificación provistos para definir la transformación como podrían ser precondiciones y pos condiciones expresadas en OCL. Por lo general estas especiaciones describen relaciones y no son ejecutables.

Resulta de interés conocer si es posible especificar transformaciones de alto nivel (transformaciones sobre transformaciones) o si la especificación posee propiedades matemáticas que faciliten algún tipo de prueba.

10


2.1.2. Reglas de transformación.Una regla de transformación es la mínima unidad de transformación. El ejemplo más común son reglas con un lado izquierdo (LHS) y derecho (RHS). También son reglas de transformación las funciones o los procedimientos que implementan un paso de la transformación.

Las reglas pueden tomar como entrada uno o más dominios. Los modelos que se pueden describir están determinados por el lenguaje asociado a la especificación de las reglas. Los dominios en una transformación pueden ser de entrada y/o salida. Cuando los dominios de entrada y salida son descriptos por un mismo metamodelo hablamos de transformaciones endógenas. En caso contrario se trata de transformaciones exógenas. La determinación del tipo de dominio (entrada y/o salida) es estática y opcionalmente dinámica. El dominio debe contar además con metavariables (contenedores de elementos del modelo) y opcionalmente con patterns (segmentos con una o más variables) y expresiones lógicas (ejecutables o no).

En algunos enfoques puede existir una separación sintáctica de las reglas (ej: lado izquierdo y derecho).

Las reglas pueden ser multidireccionales, es decir pueden ejecutarse en diferentes direcciones.

En algunos casos pueden definirse precondiciones (o guardas) para aplicar la regla (ej: when en QVT)

La ejecución de una regla podrá hacer uso de estructuras intermedias que no forman parte de los modelos de origen y destino. Un ejemplo de este tipo de estructuras son los traceability links, que a diferencia de la mayoría de las estructuras intermedias son persistidos luego de la transformación.

En algunos enfoques es posible la parametrización de las reglas, volviéndolas más reusables.

Otra característica opcional es el soporte para reflection y aspects. En particular, reflection permite una mayor navegabilidad de las propiedades de los elementos a transformar y potencialmente también de las reglas que los afectan. La utilización de aspects brinda los beneficios de mayor modularidad y facilidad para separar distintas visiones sobre las transformaciones.

2.1.3. Aplicación de las reglasEsta característica busca analizar los mecanismos brindados para especificar la selección y ejecución de reglas y determinar los elementos del modelo origen afectados. A continuación se profundizará en cada uno de estos aspectos.

11


La determinación de ubicación consiste en determinar los lugares del modelo en donde las reglas deben aplicarse. La estrategia para realizar esta tarea puede ser determinista (ej: recorrer una representación interna), no determinista (ej: aplicación concurrente en todos los elementos que cumplan con cierto criterio) o interactiva con el usuario.

La planificación (Figura 5) determina el orden en que son aplicadas las reglas. Los diferentes mecanismos de planificación pueden ser agrupados en las siguientes categorías:

La forma de la planificación es implícita si el usuario no tiene ningún tipo de control explícito sobre el algoritmo de planificación de la herramienta. La única forma de incidir es diseñando patrones y lógica para asegurar cierto orden (ej: chequear precondiciones para ejecutar una regla). En cambio, es explícita si existen construcciones dedicadas para especificar el orden de ejecución, las cuales pueden ser externas, separadas de la lógica de las reglas, o internas.

La selección de las reglas a ejecutar puede especificarse por una condición explícita, por una condición no determinista, por un mecanismo de resolución de conflictos o mediante interacción con el usuario.

La iteración de reglas provista por el enfoque puede contener recursión, ciclos o FIXPOINT ITERATIONS (la regla se aplica repetidamente hasta no detectar cambios).

Las reglas podrían organizarse en fases. Estas tienen un propósito específico y sólo ciertas reglas pueden ejecutarse en cada una de ellas.

2.1.4. Organización de ReglasEste ítem comprende los aspectos de composición y estructuración, como modularización y reuso. Se proponen tres áreas de variación:

Mecanismos de modularización: las reglas se agrupan en módulos que pueden importar a otros módulos para acceder a su contenido.

Mecanismos de reuso: definición de una regla basada en otras reglas, utilizando mecanismos de herencia entre reglas y/o módulos y composición lógica de las mismas.

Estructura organizacional: las reglas pueden organizarse según la estructura del lenguaje de origen, del lenguaje destino o usando una organización independiente de ambos.

2.1.5. Relación origen-destinoEste ítem describe la relación entre los modelos de origen y destino de la transformación.

En algunos enfoques (ej: ATL) se debe crear un nuevo modelo objetivo que debe ser diferente del modelo origen. Sin importar si los metamodelos de origen y destino coinciden, el motor de transformaciones trabaja con instancias diferentes de los mismos.

12


En otros enfoques (ej: VIATRA) solo se permite actualizaciones in-place: el modelo origen y destino deben ser una misma instancia. Las actualizaciones podrían ser destructivas o únicamente permitir extensiones del modelo.

También existen enfoques (ej: QVT) que permiten tanto actualizaciones al modelo origen como la creación de nuevos modelos.

2.1.6. Incrementalidad.La incrementalidad (Figura 8) puede ser descrita por tres características:

Incrementalidad del objetivo (o propagación de cambios): Capacidad de actualizar los modelos objetivos existentes teniendo en cuenta cambios en los modelos de origen.

Incrementalidad del origen: Minimización de la cantidad de información del modelo origen que debe ser reanalizada tras una modificación en el mismo.

Preservación de los cambios de usuario en el objetivo: capacidad de cambiar el objetivo en base a cambios del origen, pero preservando cambios manuales del usuario en el destino.

2.1.7. DireccionalidadSe refiere a si las transformaciones pueden ser ejecutadas en forma unidireccional o multidireccional.

La multidireccionalidad puede ser lograda mediante reglas multidireccionales o definiendo reglas unidireccionales complementarias.

2.1.8. TrazabilidadSe refiere a los mecanismos para registrar la ejecución de la transformación. La forma más común de realizarlo es mediante traceability links, que conectan elementos del modelo origen y de destino.

Esta información puede ser útil para realizar un análisis de impacto y para realizar debugging. Algunos enfoques proveen un mecanismo dedicado para trazabilidad. Aunque este no existiera, podría ser creado como un elemento más en el modelo destino.

13


QVT: Query/View/Transformation

14


3. QVT.

3.1. Historia En 2002, OMG emitió una solicitud de propuestas (RFP) en MOF Query / View / Transformation a buscar un estándar compatible con la recomendación MDA suite (UML, MOF, OCL, etc.)

Varias respuestas fueron dadas por una serie de empresas e instituciones de investigación que se desarrollaron durante tres años para elaborar una propuesta común que fue presentado y aprobado. El proceso de definición del estándar culminó a finales de 2005 con la primera versión final de la especificación [MOF05].

QVT versión 1.1 fue lanzado en enero de 2011.

3.2. Definiciónes de QVT.QVT es la propuesta del OMG para resolver el problema de la transformación de modelos. Se trata de un estándar para la definición de transformaciones sobre modelos MOF.

La especificación de QVT depende de otros dos estándares de la OMG como son MOF y OCL. De esta manera, la utilización de la especificación de QVT para especificar transformaciones, aporta reutilización de tecnología que sigue estándares y reducción de la curva de aprendizaje de la herramienta.

La dimensión del lenguaje define los diferentes lenguajes de transformación presentes en la especificación QVT. Concretamente son tres: Relations, Core y Operational, y la principal diferencia entre ellos es su naturaleza declarativa o imperativa.

En la dimensión de la interoperabilidad se encuentran aquellas características que permiten a una herramienta que cumple el estándar QVT interoperar con otras herramientas.

Concretamente, son cuatro: sintaxis ejecutable, XMI ejecutable, sintaxis exportable y XMI exportable.

La sintaxis ejecutable se traduce en una implementación que facilite la importación o lectura, y posterior ejecución de una sintaxis concreta que describa una transformación definida en el lenguaje dado por la dimensión del lenguaje.

XMI ejecutable dictamina que una implementación debe facilitar la importación o lectura, y posterior ejecución de una serialización XMI de una transformación que conforma con el metamodelo de MOF del lenguaje dado por la dimensión del lenguaje.

15

http://translate.googleusercontent.com/translate_c?depth=1&hl=es&ie=UTF8&prev=_t&rurl=translate.google.com.bo&sl=en&tl=es&u=http://en.wikipedia.org/wiki/Meta-Object_Facility&usg=ALkJrhieMqfK_rvvK5mbjnHeJ8TgR-5pvg


La sintaxis exportable establece que una implementación debe proporcionar facilidad para exporta una transformación entre modelos en la sintaxis concreta del lenguaje dado por la dimensión del lenguaje.

XMI exportable es el nivel de interoperabilidad que debe facilitar la exportación de transformaciones entre modelos como serializaciones XMI que conformen con el metamodelo MOF del lenguaje dado por la dimensión del lenguaje.

El estándar QVT define tres abstracciones fundamentales, que se corresponden con sus siglas [Heb05]:

Consultas (Queries) Una consulta es una expresión que se evalúa sobre un modelo. Los resultados de una consulta son una o varias instancias de los tipos definidos en el modelo transformado, o en el propio lenguaje de consulta. Para la realización de consultas se utilizará un lenguaje de consultas.

Vistas (Views) Una vista es un modelo obtenido en su totalidad a partir de otro modelo base. Son más generales que las Consultas. Suelen ser entidades de sólo lectura. Una vista es una proyección realizada sobre un modelo, creada mediante una transformación. Una vista puede verse como el resultado de una consulta sobre un modelo, ofreciendo como resultado un punto de vista de éste, restringiéndolo de acuerdo a alguna condición impuesta.

Transformaciones (Transformations) Una transformación genera un modelo a partir de otro modelo de origen. Ambos modelos podrán ser dependientes o independientes, según exista o no una relación que mantenga ambos sincronizados una vez se produzca la transformación. Las vistas son un tipo específico de transformación. Las relaciones especifican las transformaciones y las correspondencias (mappings) las implementan. Son especificaciones que toman como entrada uno o varios modelos, y lo relacionan de manera que cumplan las condiciones de la transformación, o crean uno nuevo a partir de los modelos de entrada. Si se modifica una vista, la correspondiente transformación debe ser bidireccional para reflejar los cambios en el modelo fuente. Las transformaciones se definirán utilizando un lenguaje de transformación. El lenguaje de transformación debe servir para generar vistas de un metamodelo, debe ser capaz de expresar toda la información necesaria para generar automáticamente la transformación de un modelo origen a uno destino, y debe además soportar cambios incrementales en un modelo origen que se ven reflejados en el modelo destino [MOF05].

De estas abstracciones se desprenden por lo tanto dos lenguajes, de consulta y de transformación, a los que se impuso como requisito que estuvieran definidos como metamodelos MOF 2.0. Un último requisito fundamental de la propuesta QVT es relativo a los modelos manipulados: todos los modelos manipulados por los mecanismos de transformación serán además instancias de metamodelos MOF 2.0.

16


Una vez descrito el planteamiento conceptual de QVT conviene describir la solución propuesta por la especificación finalmente adoptada [MOF05]. Como lenguaje de consulta se definen extensiones al estándar OCL 2.

3.3. Arquitectura QVT La especificación de transformaciones se propone una solución de naturaleza híbrida declarativa e imperativa. La parte declarativa se divide en una arquitectura de 2 capas, que sirve como marco para la semántica de ejecución de la parte imperativa.

La parte declarativa de esta especificación está estructurada en una arquitectura de dos capas:

Un metamodelo Relations define un lenguaje declarativo para expresar relaciones entre modelos MOF. Este lenguaje soporta reconocimiento de patrones, la creación de plantillas de objetos y la creación implícita de las trazas necesarias para registrar los cambios que se producen cuando se transforman modelos.

Un metamodelo Core y un lenguaje declarativo de menor nivel de abstracción que Relations pero con la misma potencia, definido usando extensiones mínimas de EMOF y OCL. La especificación de QVT define las reglas que permiten mapear la semántica de Relations a la de Core, y dichas reglas las define en base a transformaciones descritas utilizando a su vez Core. En este lenguaje, los objetos de traza deben definirse explícitamente y sólo soporta reconocimiento de patrones sobre un conjunto plano de variables, no sobre objetos complejos como en Relations.

3.3.1. El lenguaje RelationsEl lenguaje Relations proporciona una especificación declarativa de relaciones entre modelos MOF. Soporta pattern matching de objetos complejos y de manera implícita crea clases de trazabilidad y sus instancias correspondientes, de forma que permite guardar todo lo que ocurre durante la ejecución de una transformación.

3.3.2. El lenguaje CoreEste es un lenguaje/modelo que solo soporta pattern-matching sobre un conjunto de variables, evaluando condiciones sobre variables de un conjunto de modelos. Core trata a todos los elementos del modelo origen, destino y de trazabilidad de manera simétrica y su potencia es

17


equiparable a la del lenguaje Relations. Esto se debe, a que por su relativa simplicidad su semántica puede ser definida de manera más sencilla, aunque la definición de transformaciones sea más verbosa. Además, los modelos de trazabilidad han de ser definidos de manera explícita y no pueden deducirse de la definición de la transformación como ocurría en el lenguaje Relations.

El modelo Core debe ser implementado directamente, o simplemente usado como referencia para la semántica del Relations, la cual está mapeada a Core a través de una transformación.

3.3.3. Analogía de máquina virtualEs posible trazar una analogía con la arquitectura JavaTM, donde el lenguaje Core es como Java Byte Code y la semántica de Core se comporta como la máquina virtual Java.

El lenguaje Relations desempeña el rol del lenguaje Java, y la transformación estándar de Relations a Core es la especificación de un compilador Java que genera Byte Code.

3.4. Implementaciones ImperativasAdemás de las relaciones y lenguajes declarativos fundamentales que encarnan la misma semántica en dos niveles diferentes de abstracción, hay dos mecanismos para invocar implementaciones imperativas de transformaciones desde los lenguajes Relations o Core: un lenguaje estándar, Operational Mappings, así como una implementación no estándar Black-box MOF

Operation. Cada relación se define una clase que se creará una instancia de rastrear entre los elementos del modelo son transformada, y tiene una asignación uno a uno con una firma de la operación que la cartografía operativa o Negro caja implementos.

3.4.1.Operational Mapping. Este lenguaje está especificado como estándar para proporcionar implementaciones imperativas. Proporciona extensiones OCL con efectos laterales que da un mayor estilo procedural y una sintaxis más cercana a la programación imperativa (incluye construcciones imperativas tales como bucles y condiciones).

Este lenguaje define operaciones de mappings que pueden ser usadas para implementar una o más Relations a partir de una especificación Relations, cuando sea difícil proporcionar una especificación declarativa más pura. Estas operaciones pueden invocar otras operaciones de mappings con el objetivo de crear modelos de trazabilidad entre elementos de modelos.

Es posible escribir transformaciones completas utilizando operaciones de mapping, denominándose este tipo de transformaciones: transformaciones operacionales.

3.4.2. Implementación Black-box. No se trata de un lenguaje, sino de un mecanismo que permite enlazar código escrito en cualquier lenguaje.

18


Para ello, se utiliza el lenguaje Relations para derivar una operación MOF de una transformación. Esta operación será el punto de enlace con el lenguaje deseado, que deberá definir la operación a ejecutar con la misma signatura, y soportar un enlace con la implementación de MOF que se esté utilizando.

QVT define por lo tanto tres DSL: Relations, Core y Operational Mappings. Para todos ellos define una sintaxis abstracta en base a sus metamodelos MOF. La semántica de su ejecución se define mediante descripciones en texto plano. Para cada uno de ellos se proporciona una sintaxis textual concreta definida mediante gramáticas EBNF [Cue01]. Para el lenguaje Relations se define además una notación gráfica específica. Finalmente, para los lenguajes Relations y Operational Mappings se definen diversas extensiones de OCL.

Las operaciones MOF deben poder derivarse de Relations haciendo posible integrarlas con cualquier implementación de una operación MOF con la misma signatura. Esto resulta beneficioso por las siguientes razones:

Permite codificar algoritmos complejos en cualquier lenguaje de programación con correspondencia a MOF.

Permite el uso de librerías específicas de dominio para calcular ciertas propiedades del modelo. Por ejemplo, en matemáticas, en ingeniería y en otros muchos campos existen grandes librerías que almacenan algoritmos específicos de dominio, que serían muy difíciles de expresar usando OCL.

Permite ocultar la implementación de algunas partes de una transformación.

Sin embargo, esta integración puede resultar peligrosa puesto que la implementación asociada a esta integración tiene libre acceso a las referencias de objetos en los modelos. Las implementaciones Black-box no tienen una relación implícita hacia Relations, y cada Black-box debe implementar explícitamente una relación que sea responsable de conservar la trazabilidad entre los elementos del modelo relacionado con la implementación de la operación MOF.

En aras de extender la analogía con la arquitectura Java, la habilidad para invocar implementaciones «Black-Box» y «Operational Mappings», puede considerarse equivalente con la llamada a la Java Native Interface (JNI).

3.5. Escenarios de ejecución.La semántica del lenguaje Core (y el lenguaje Relaciones) debe tener en cuenta los siguientes escenarios de ejecución:

Entradas a sólo transformaciones para verificar que los modelos se relacionan de una manera específica.

Transformaciones sola dirección. Transformaciones bidireccionales. (De hecho, más de dos direcciones son posibles, pero

dos es el caso más común).

19


La capacidad de establecer relaciones entre los modelos preexistentes, ya sean desarrollados de forma manual, o mediante alguna otra herramienta o mecanismo.

Las actualizaciones incrementales (en cualquier dirección) cuando un modelo relacionado se cambia después de una ejecución inicial.

La capacidad de crear y eliminar objetos y valores, al mismo tiempo ser capaz de especificar los objetos y los valores que no pueden ser modificados.

Los enfoques operational mapping y Black-box, incluso cuando se ejecuta en conjunto con las relaciones, restringir estos escenarios permitiendo sólo la especificación de transformaciones en una sola dirección. Las transformaciones bidireccionales sólo son posibles si una aplicación operativa inversa se proporciona por separado. Sin embargo, todas las otras funciones definidas anteriormente son disponibles con ejecuciones imperativas e híbridos.

3.6. Metamodelos MOF.Esta especificación define tres paquetes principales, uno para cada uno de los idiomas definidos: QVTCore (Sección 9.17), QVTRelation (Sección 7.11.3), y QVTOperational (Sección 8.2). El paquete QVTBase define la estructura común para las transformaciones (Sección 7.11.1). Además, el paquete QVTRelation utiliza expresiones de plantilla de patrones definidos en el paquete QVTTemplateExp (Sección 7.11.2).QVTOperational extiende QVTRelation, ya que utiliza el mismo marco de rastros definidos en ese paquete. Utiliza expresiones imperativas definidas en el paquete ImperativeOCL (Sección 8.2.2).

Todos QVT depende del paquete EssentialOCL de OCL 2,0, y todos los paquetes de idioma dependen de EMOF.

20


3.7. El Lenguaje RelationsEl lenguaje Relations ofrece una aproximación declarativa para la especificación de transformaciones. Dado un par de modelos candidatos para la transformación, que deberán ser instancias de metamodelos MOF, ésta quedará definida como un conjunto de restricciones que los elementos de los modelos deben satisfacer.

Estas restricciones constituyen el concepto de relación del lenguaje Relations: se definen mediante dos o más dominios y mediante una pareja de predicados when (cuándo) y where (cómo). Los dominios especifican, mediante un patrón, qué elementos de los modelos candidatos participarán en la transformación. Por su parte, la cláusula when especifica la relaciones que determinan cuándo la relación indicada debe sostenerse; y la cláusula where especifica la condición que deben satisfacer todos los elementos de modelos que participan en la relación [MOF05].

3.7.1. Transformaciones y tipos de modelosEn el lenguaje Relations, una transformación entre modelos candidatos se especifica como un conjunto de relaciones que han de tener lugar para llevar a cabo la transformación.

Un modelo candidato es cualquier modelo que conforme a un tipo de modelo o metamodelo, que es una especificación de los diferentes tipos que pueden tener los elementos del modelo que lo conforma. Los modelos candidatos tienen un nombre y los tipos de los elementos que pueden contener, los cuales quedan restringidos al paquete al que se hace referencia en la declaración del modelo candidato. Por ejemplo:

transformation uml2Rdbms (uml : SimpleUML, rdbms : SimpleRDBMS) {

Declaración de una transformación en QVT-Relations.

En esta declaración de transformación llamada «uml2Rdbms», hay dos modelos candidatos: «uml» y «rdbms». El modelo «uml» se declara referenciando el paquete «SimpleUML» como su metamodelo, y el modelo «rdbms» hace lo propio con el paquete «SimpleRDBMS ». Una «transformation» puede invocarse tanto para comprobar la consistencia de dos modelos como para transformar un modelo en otro.

3.7.1.1. Dirección de ejecución de una transformaciónUna «transformation» invocada para realizar una transformación se ejecuta en una dirección determinada seleccionando uno de los modelos candidatos como modelo destino u objetivo. El modelo destino debe estar vacío o contener elementos para ser relacionados por la transformación. El procedimiento de transformación se basa en comprobar que todas las relaciones definidas en la transformación se cumplen y para aquellas relaciones que no se cumplen, se intenta cumplirlas creando, eliminando o modificando el modelo destino.

21


3.7.2. Relaciones y dominiosLas relaciones en una transformación definen restricciones que deben satisfacer los elementos de los modelos candidatos. Una relación o relation definida para dos o más dominios, y un par de predicados when y where, especifica una relación que se debe satisfacer entre los elementos de los modelos candidatos.

Un dominio o domain es una variable tipada que puede hacer matching en un modelo de un metamodelo dado. Un dominio tiene un patrón que puede ser visto como un grafo de nodos de objetos, cuyas propiedades y links de asociación se originan de una instancia del tipo del dominio. Alternativamente, un patrón puede ser considerado como un conjunto de variables y un conjunto de restricciones, que los elementos del modelo vinculados a esas variables deben satisfacer para logar una correspondencia válida de ese patrón. Un patrón de dominio o domain pattern puede considerarse como una plantilla para objetos, y sus propiedades han de ser localizadas, modificadas o creadas en un modelo candidato para satisfacer la relación.

En el siguiente ejemplo, se declaran dos dominios que corresponderán a elementos de los modelos «uml» y «rdbms». Cada dominio especifica un patrón simple, un paquete con un nombre y un esquema con un nombre. Ambas propiedades de «nombre» se corresponden con la misma variable «pn», lo que implica que deberían tener el mismo valor:

relation PackageToSchema { domain uml p: Package {name=pn} domain rdbms s: Schema {name=pn}}

Declaración de una relation en QVT-Relations.

3.7.2.1. Cláusulas when y whereComo se muestra en el siguiente ejemplo de la relación «ClassToTable», una relación puede estar limitada por dos conjuntos de predicados, una cláusula when y una cláusula

where. La cláusula when define las condiciones bajo las cuales se necesita satisfacer la relación, por lo que la relación «ClassToTable» se cumplirá solo cuando se cumpla la relación «PackageToSchema», es decir, cuando el paquete contiene la clase y el esquema contiene la tabla. La cláusula where define la condición que deben satisfacer todos los elementos de todos los modelos que participan en la relación, y puede restringir cualquiera de las variables en la relación y sus dominios. Por tanto, siempre que se cumpla la relación «ClassToTable», la relación «AttributeToColumn» también se cumplirá.

relation ClassToTable /* map each persistent class to a table */ { domain uml c:Class { namespace = p:Package {}, kind='Persistent',

22


name=cn } domain rdbms t:Table {

schema = s:Schema {}, name=cn, column = cl:Column {

name=cn+'_tid',type='NUMBER'},

primaryKey = k:PrimaryKey {name=cn+'_pk', column=cl}

} when { PackageToSchema(p, s); } where { AttributeToColumn(c, t); }

}Las cláusulas when y where pueden contener cualquier expresión OCL además de las expresiones de invocación de la relación. La invocación de relaciones permite componer relaciones complejas a partir de relaciones más simples.

3.7.2.2. Relaciones Top-level.Una transformación contiene dos tipos de relaciones: las top-level y las no-top-level.

La ejecución de una transformación requiere que todas sus relaciones top-level se cumplan, mientras que las relaciones no-top-level solo han de ser satisfechas cuando son invocadas directa o transitivamente desde la cláusula where de otra relación.

transformation umlRdbms (uml : SimpleUML, rdbms : SimpleRDBMS) { top relation PackageToSchema {…} top relation ClassToTable {…} relation AttributeToColumn {…}

}Declaración de relaciones top-level en QVT-Relations

Una relación top-level tiene la palabra clave «top» que la distingue sintácticamente. En el ejemplo anterior, tanto «PackageToSchema» como «ClassToTable» son relaciones top-level mientras que «AttributeToColumn» es una relación no-top-level.

3.7.2.3. Check y EnforceEl que una relación sea de transformación o no viene determinado por el dominio destino, que estará marcado como checkonly o enforce. Cuando una transformación se satisface en la dirección de un dominio checkonly, simplemente se comprueba si existe una correspondencia válida en el modelo relevante que satisfaga la relación. Cuando ransformación se ejecuta en la dirección de un dominio enforce, si la comprobación falla, se modifica el modelo destino tanto como sea necesario para que satisfaga la relación.

En el ejemplo siguiente, el dominio para el modelo «uml» está marcado como checkonly y el dominio para el modelo «rdbms» está marcado como enforce.

23


relation PackageToSchema {checkonly domain uml p: Package { name=pn }enforce domain rdbms s: Schema { name=pn }

}Declaración de dominion checkonly y enforce en QVT-Relations.

Si estuviéramos ejecutando en la dirección de «uml» y existiera un esquema en «rdbms» para el cual no tenemos un paquete correspondiente con el mismo nombre en «uml», se detectaría una inconsistencia pero no se crearía el paquete puesto que el modelo «uml» es checkonly y no enforce.

Sin embargo, si estuviéramos ejecutando la transformación «uml2Rdbms» en la dirección de «rdbms», entonces para cada paquete en el modelo de «uml», la relación primero comprobaría si existe un esquema con el mismo nombre en el modelo «rdbms», y si no es así, se crearía un nuevo esquema en ese modelo con el nombre dado. Para considerar una variación del caso propuesto, si ejecutamos la transformación en la dirección de «rdbms» y no hay un paquete con el mismo nombre que en «uml», entonces el esquema se eliminará del modelo «rdbms» para forzar la consistencia en el dominio enforce.

La aplicación de las reglas depende únicamente del dominio destino.

3.7.3. Pattern-MatchingLos patrones o patterns asociados a los dominios reciben el nombre de «object template expressions». Para ilustrar cómo tiene lugar el matching de estos patrones utilizaremos el ejemplo del «ClassToTable» utilizado con anterioridad.

«ClassToTable» define varias expresiones de tipo «object template expression» que se utilizarán para hacer pattern matching en los modelos candidatos. Por ejemplo, el siguiente

«object template expression» está asociado al dominio de «uml»:

c: Class { namespace = p: Package { }, kind = ’Persistent’, name = cn

}Pattern-matching en QVT-Relations.

Las combinaciones resultantes de un «object template expression» unen elementos de un modelo candidato con variables declaradas en el dominio. Un «object template expression» debe efectuarse en un contexto donde algunas de las variable del domino estén enlazadas con elementos de un modelo. En este caso el «object template expression» solo encuentra enlaces para tres variables del dominio.

El pattern matching ligará todas las variables de la expresión («c», «p», y «cn»), empezando desde la variable raíz del domino «c» de tipo «Class». En este ejemplo, la variable «p» debería también estar ligada como resultado de la evaluación de la expresión

24


«PackageToSchema(p,s)» en la cláusula when. El proceso de matching pasa por filtrar todos los objetos de tipo «Class» en el modelo «uml», eliminando cualquier objeto que no tenga los mismos valores literales que el «object template expression». En el ejemplo, cualquier «Class» con su propiedad «kind» distinta de «Persistent» es eliminada.

Para propiedades que se comparan con variables, como «name=cn», aparecen dos casos. Si la variable «cn» tiene un valor asignado, entonces cualquier «Class» que no tenga el mismo valor para su propiedad «name» será eliminada. Si la variable «cn» es libre, como sucede en el ejemplo, se le asignará el valor de la propiedad del nombre de todas las clases que han sido eliminadas filtrando, debido a una incompatibilidad con otras comparaciones de la propiedad.

Entonces el matching avanza a propiedades cuyos valores son comparados con «object template expressions» anidadas. Por ejemplo, la propiedad «namespace = p: Package » hará matching solo con aquellas clases cuya propiedad «namespace» tenga una referencia no nula a un «Package». Al mismo tiempo, la variable «p» apuntará al «Package». Sin embargo, puesto que en nuestro ejemplo «p» toma valor en la cláusula when, solo se hará pattern matching con aquellas clases cuyas propiedades «namespace» tengan una referencia al mismo paquete al que se refiere «p».

Se permite el anidamiento profundo de «object template expressions», y el matching y la toma de valores de las variables se realiza recursivamente hasta que haya una serie de tuplas de valores que correspondan a variables de un dominio y su «object template expression». Por ejemplo las tres variables: «c», «p» y «cn», crean una 3-tupla, y cada match válido dará como resultado una única tupla que represente la unión de un valor con una variable.

En una invocación a una relación dada, puede haber varios matchings válidos para una «template expression», la manera de procesar esta multiplicidad depende de la dirección en la que ejecutemos la relación.

Por ejemplo, si se ejecuta la relación «ClassToTable» con «rdbms» como modelo destino, entonces por cada matching válido del dominio «uml», tendría que existir al menos un matching válido del dominio «rdbms» que satisfaga la cláusula where. Si para un matching válido del dominio «uml», no existe un matching válido del dominio «rdbms», entonces puesto que el dominio «rdbms» es enforce, se crean objetos y las propiedades se ponen en la «template expression» asociada con el dominio «rdbms». También, para cada matching válido del dominio «rdbms», tendría que existir al menos un matching válido del dominio «uml» que satisfaga la cláusula where (esto exige que el dominio «uml» esté marcado como checkonly); en otro caso los objetos se eliminarán del modelo «rdbms» por lo que no seguirá siendo un matching válido.

3.7.4. Keys y creación de objetos usando patronesComo se mencionó anteriormente, un «object template expression» también sirve como plantilla para crear un objeto en un modelo destino. Cuando para un matching válido dado de un patrón de dominio origen, no existe un matching en el patrón del dominio destino, entonces se utiliza el «object template expression» del dominio destino como plantilla para crear objetos en el modelo

25


destino. Por ejemplo, cuando se ejecuta «ClassToTable» con «rdbms» como modelo destino, el siguiente «object template expression» sirve como plantilla para crear objetos en el modelo «rdbms»:

t: Table { schema = s: Schema { }, name = cn, column = cl: Column { name=cn+’_tid’, type=’NUMBER’ }, primaryKey = k: PrimaryKey { name=cn+’_pk’, column=cl }

}Creación de objetos usando patrones en QVT-Relations.

La plantilla asociada con «Table» especifica que un objeto de este tipo debe crearse con las propiedades «schema», «name», «column» y «primaryKey» inicializadas a los valores de la «object template expression». Análogamente, las plantillas asociadas con «Column», «PrimaryKey», etc, especifican como deben crearse sus respectivos objetos.

Cuando se creen objetos, se debe asegurar que no se creen objetos duplicados cuando los objetos requeridos ya existen. Sin embargo, en ocasiones, simplemente se querrá actualizar objetos existentes, lo que deriva en un problema sobre cuándo actualizar objetos existentes o no permitir la creación de un objeto cuando éste ya existe con el fin de evitar objetos duplicados. MOF permite etiquetar como identificador una sola propiedad de una clase, sin embargo, para muchos metamodelos esto resulta insuficiente. El metamodelo Relations introduce el concepto de Key, que define un conjunto de propiedades de clase que identificarán de manera única el objeto instancia de una clase del modelo. Una clase puede tener múltiples keys al igual que ocurre en las bases de datos relacionales.

Por ejemplo, continuando con el ejemplo de la relación «ClassToTable», queremos especificar que en los modelos de tipo «simpleRDBMS», una tabla está identificada únicamente por dos propiedades: su nombre y el esquema al que pertenece.

key Table { schema, name };

Declaración de Keys en QVT-Realations.

Las keys se utilizan en el tiempo de la creación de objetos si un «object template

expression» tiene las propiedades que corresponden a una key de la clase asociada, entonces las keys se utilizan para localizar un matching de objeto en el modelo; se crea un objeto solo cuando no existe un matching de objeto.

En el ejemplo, tomando el caso en el que se tiene una clase persistida llamada «foo» en el modelo «uml», y existe una tabla con un matching de nombre «foo» en un matching de esquema en el modelo «rdbms» pero la tabla no tiene matching de valores con las propiedades «column» y «primaryKey». En este caso, de acuerdo con el matching semántico de patrones, el modelo «rdbms» no tiene un matching válido para el patrón asociado a la «Table», por lo que es necesaria la creación de objetos que cumplan esa relación. Sin embargo, desde que la tabla existente hace

26


matching con las propiedades especificadas por la key, no es necesario crear una nueva tabla, tan solo hay que actualizar las propiedades «column» y «primaryKey» de la tabla.

3.8. El Lenguaje Operational MappingEl lenguaje Operational Mapping permite definir transformaciones utilizando bien una aproximación imperativa o bien una aproximación híbrida, complementando las transformaciones relacionales declarativas con operaciones imperativas que implementen las relaciones.

Una transformación operacional define una transformación unidireccional expresada de forma imperativa. Se compone de una signatura que indica los modelos involucrados en la transformación y de una definición de la ejecución de la transformación. En la práctica, una transformación operacional se trata de una entidad instanciable con propiedades y operaciones.

Este lenguaje de QVT permite la definición de transformaciones mediante un lenguaje imperativo. Permite también definir mappings para complementar las relaciones desarrolladas con el lenguaje Relational (enfoque híbrido).

Entidad instanciable que posee operaciones y propiedades. Representa la definición de una transformación unidireccional expresada de manera imperativa.

Define:

Signatura indicando los modelos involucrados.

Operación main de entrada.

27


Herramientas

28


4. Análisis de herramientas para transformación de modelos

4.1. Características de las herramientas de transformación.

En esta sección complementamos las características para categorizar enfoques de transformación con y algunos criterios propios. Estas características están relacionadas con las herramientas que implementan los diferentes enfoques para transformación de modelos. A continuación describiremos brevemente aquellas que consideramos de interés para analizar una herramienta:

Áreas de aplicación: esta característica pretende describir la clase de problemas que la herramienta puede resolver, los casos de estudio en que fue aplicada y las aplicaciones industriales.

Sugerencia de aplicación de transformaciones: se relaciona con la interactividad con el usuario descrita en la sección previa y describe en que forma la herramienta asiste al usuario para descubrir aquellas reglas de transformación que pueden ser de interés en una determinado modelo a transformar.

Tipo de licencia de distribución: la herramienta puede ser software propietario o distribuírse con algún tipo de licencia de código abierto.

Historia de la herramienta: comprende el origen de la misma (por ejemplo: académico o emprendimiento privado), su antigüedad y la continuidad de su soporte.

Soporte brindado al usuario: refiere al tipo de documentación brindada: manuales, tutoriales, ejemplos, foros y todo tipo de soporte disponible.

Comunidad de usuarios y aceptación: refiere a la cantidad de usuarios activos de la herramienta y la aceptación obtenida por la misma dentro de la comunidad.

Mecanismos ofrecidos para garantizar correctitud de las transformaciones: refiere a las garantías ofrecidas por la herramienta de que el resultado producido es correcto sintáctica y semánticamente.

Manejo de modelos incompletos o inconsistentes: refiere a como maneja la herramienta situaciones en las cuales el modelo no está especificado por completo o contiene inconsistencias.

Mecanismos ofrecidos para verificación y validación de transformaciones: a diferencia de la correctitud, esto se refiere a los mecanismos ofrecidos para verificar que una

29


transformación desarrollada presenta el comportamiento deseado por el programador. Un ejemplo de esto podría ser asistir al usuario en la generación de casos de prueba.

Escalabilidad de transformaciones y de modelos: refiere a la capacidad de la herramienta para manejar complejidad y tamaño creciente ya sea en las transformaciones o en los modelos a transformar.

4.2. Implementaciones de QVTLas implementaciones más sobresalientes de QVT son las siguientes:

4.2.1. Borland QVT (Borland Together Architect)Es un producto que integra Java IDE, que originalmente nace de JBuilder con una herramienta de modelado UML. Tiene soporte para Eclipse y los diagramas pueden crearse de forma importada. Genera soporte para UML, Java 6, C++ y CORBA.

La herramienta implementa un motor QVT pero no soporta el lenguaje declarativo de Relations. Sólo soporta las transformaciones operacionales (imperativas). Soporta además OCL en su versión 2, y lo extiende siguiendo las directrices de QVT. En cuanto a las operaciones de caja negra (Black-box MOF Operation), la herramienta permite importar e invocar sentencias Java desde las transformaciones QVT.

Para las transformaciones de modelos a texto (text-to-model) la herramienta utiliza el motor de plantillas JET [Pop03], del proyecto Eclipse [Ecl06a] el cuál se basa en EMF

SmartQVT,

4.2.2. SmartQVTSmartQVT [BD06] es una implementación de código abierto de la especificación QVT realizada por France Telecom R&D. Al igual que Together Architect, se basa en metamodelos EMF para los modelos que intervienen en las transformaciones y únicamente considera el lenguaje Operational Mapping.

Es una implementación completa en java del lenguaje operacional QVT. La herramienta se distribuye como un complemento a Eclipse de libre distribución y se caracteriza por estar implementada de forma imperativa.

También utiliza EMF para especificar el metamodelo de QVT. Su funcionamiento se basa en una transformación en dos fases:

En una fase inicial se traduce la sintaxis textual concreta del lenguaje operacional de QVT a instancias del metamodelo de QVT.

En una segunda fase, se transforma el modelo de QVT en un programa Java basado en EMF que ejecuta la transformación. Para serializar el modelo QVT de entrada se utiliza XMI 2.0.

30


4.2.3. MOMENTMOdel manageMENT [QHB+06] es un prototipo de motor de transformación que implementa el lenguaje Relations de la especificación QVT.

En su implementación utiliza EMF para la especificación de metamodelos. A partir del código del lenguaje Relations, instancia el metamodelo QVT que implementa la herramienta. Como paso previo a obtener el modelo transformado en términos de EMF, se genera una especificación intermedia en el lenguaje Maude [CDE+03], aprovechándose de sus propiedades intrínsecas, como la concordancia de patrones, la parametrización y la reflexión.

4.2.4. Eclipse M2M Project - Operational and Declerative(Core and Relation)Es un unaimplentacion de Eclipse del estandar de OMG QVT. Es un subproyecto de Eclipse ;odeling Project (EMP).

Tiene tres compones habilitados para la transformación de modelo a modelo.

ATL (Lengua de transformación del ATLAS) (lengua de transformación del ATLAS) de INRIA (Inria)

Procedural QVT, de Borland (Borland)

Declarative QVT, de Obeo (Obeo)

4.2.5. MediniQVT Es una herramienta de transformación de modelos. MediniQVT está implementado para realizar las transformaciones que se instauraron desde la OMG, es decir, siempre basando sus transformaciones de modelos en QVT. La aplicación incluye herramientas para el desarrollo de transformaciones, así como un depurador gráfico y un editor. Estos componentes son de libre distribución pero sólo para uso no comercial. MediniQVT efectúa las transformaciones QVT expresadas en la sintaxis concreta del lenguaje de relaciones de QVT (QVT relations).MediniQVT está integrado en Eclipse. La aplicación posee un editor con asistente de código que permite especificar las relaciones modelo origen modelo destino, ya sea el elemento o sus propiedades. MediniQVT proporciona también un depurador para efectuar las transformaciones y de esta forma evitar errores en el modelo destino. Un hecho a destacar es que permite las transformaciones bidireccionales.

31

http://es.knowledger.de/8580810/Obeo

http://es.knowledger.de/0108157/Borland

http://es.knowledger.de/3741562/Inria

http://es.knowledger.de/0669749/LenguaDeTransformacionDelATLAS


Aplicación de QVT ejemplo.

32


5. Aplicación de QVT ejemplo.

La herramienta a utilizar es Medini QVT.

5.1. Medini QVT

5.1.1. HistoriaMediniQVT es una herramienta enteramente implementada en Java, e integrada en Eclipse como un conjunto de plugins para dar soporte a transformaciones de modelos empleando el estándar QVT del OMG. Ha sido desarrollada por la empresa ikv++ technologies ag [33], con sede en Alemania. El motor fue inicialmente lanzado como un producto cerrado aunque gratuito en 2007, y fue a inicios del año 2008 cuando se liberó el código fuente bajo la licencia de código abierto EPL Eclipse Public License.

5.1.2. Características.Desde el punto de vista de la tecnología, MediniQVT se basa en EMF como entorno de modelado y metamodelado. Para la definición de transformaciones emplea el lenguaje QVT-Relations, dando soporte a transformaciones modelo-a-modelo, e internamente, el motor de evaluación de expresiones OCL está basado en OSLO (Open Source Library for OCL [21]).

Las principales características de la herramienta completa son:

Ejecución de transformaciones QVT expresadas en la sintaxis concreta textual del lenguaje QVT-Relations

Editor con resaltado y completado de código.

Depurador para trazar la ejecución de transformaciones paso a paso a través de las reglas.

Implementación del concepto de clave (key) del lenguaje QVT, permitiendo las transformaciones para actualizaciones incrementales.

Transformaciones con n-dominios participantes.

Transformaciones bidireccionales (cuando la definición de éstas así lo permite).

Toda esta funcionalidad está implementada en diversos plugins de Eclipse. En este sentido, debe aclararse que es únicamente el plugin que contiene el motor de ejecución de transformaciones el que es público y de código abierto. Todos los plugins que implementan funcionalidad adicional (editor textual, depuración, etc.) son de código cerrado.

Por ello, para la construcción del prototipo presentado en este trabajo, sólo se ha tomado aquella parte que es de código abierto y reutilizable, habiéndose implementado expresamente para el trabajo un conjunto de plugins y herramientas que permiten la invocación de forma amigable de

33


transformaciones QVT. En la sección 6.4 se describe en detalle el conjunto de plugins desarrollados, y en la sección 8 se muestra indica su guía de uso.

34


BibliografiaM. HebachMDA with QVT.Borland Together 2006 Presentation.http://www.ikv.de/)

35

documentacion qvt

Documents