QVT Query View Transformation

Contenido
CONTENIDO.................................................................................................1 INTRODUCCIN............................................................................................3 DESARROLLO DE SOFTWARE DIRIGIDO POR MODELOS MDD............................5 ELEMENTOS CLAVES EN MDD: MODELOS Y TRANSFORMACIONES............................................................5 Transformacin.........................................................................................................5 Modelos....................................................................................................................5 Metamodelo. ............................................................................................................6 MDA (ARQUITECTURA DIRIGIDA POR MODELOS).............................................7 MOF ...........................................................................................................7 OCL............................................................................................................8 TRANSFORMACIN DE MODELOS...............................................................10 CARACTERSTICAS DE LOS ENFOQUES DE TRANSFORMACIN...................................................................10 Especiacin (opcional)............................................................................................10 Reglas de transformacin.......................................................................................11 Aplicacin de las reglas..........................................................................................12 Organizacin de Reglas..........................................................................................12 Relacin origen-destino..........................................................................................13 Incrementalidad......................................................................................................13 Direccionalidad.......................................................................................................13 Trazabilidad............................................................................................................13 QVT.........................................................................................................16 HISTORIA .................................................................................................16 DEFINICINES DE QVT................................................................................16 ARQUITECTURA QVT ..................................................................................18 EL LENGUAJE RELATIONS..........................................................................................................19 EL LENGUAJE CORE................................................................................................................19 ANALOGA DE MQUINA VIRTUAL.................................................................................................19 IMPLEMENTACIONES IMPERATIVAS..............................................................19 Operational Mapping. .............................................................................................20 Implementacin Black-box. ....................................................................................20 ESCENARIOS DE EJECUCIN........................................................................21 METAMODELOS MOF..................................................................................22 EL LENGUAJE RELATIONS............................................................................23 TRANSFORMACIONES Y TIPOS DE MODELOS......................................................................................23 Direccin de ejecucin de una transformacin........................................................23 RELACIONES Y DOMINIOS..........................................................................................................24 Clusulas when y where.........................................................................................24

QVT Query View Transformation

Relaciones Top-level...............................................................................................25 Check y Enforce......................................................................................................26 PATTERN-MATCHING...............................................................................................................26 KEYS Y CREACIN DE OBJETOS USANDO PATRONES.............................................................................28 EL LENGUAJE OPERATIONAL MAPPING.........................................................29 ANLISIS DE HERRAMIENTAS PARA TRANSFORMACIN DE MODELOS............32 CARACTERSTICAS DE LAS HERRAMIENTAS DE TRANSFORMACIN..............................................................32 IMPLEMENTACIONES DE QVT.....................................................................................................33 Borland QVT (Borland Together Architect)...............................................................33 SmartQVT...............................................................................................................33 MOMENT.................................................................................................................34 Eclipse M2M Project - Operational and Declerative(Core and Relation)....................34 MediniQVT..............................................................................................................34 MEDINI QVT...............................................................................................36 HISTORIA............................................................................................................................36 CARACTERSTICAS..................................................................................................................36 BIBLIOGRAFIA............................................................................................38

QVT Query View Transformation

Introduccin
La demanda actual de software en nuestra sociedad es cada vez ms elevada, pero el proceso de desarrollo tambin es ms costoso, esto lleva buscar estrategias que permitan la reutilizacin de software y adems facilite el proceso de desarrollo, se busca elevar el nivel de abstraccin y elevar la reutilizacin, 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 reutilizacin y transformacin de modelos. El principio fundamental de MDA son la Abstraccin, automatizacin y la estandarizacin. El proceso central de MDA es la transformacin de modelos que por medio de su evolucin, permiten de manera sistemtica obtener un producto final. La OMG con el propsito de lograr un estndar para la transformacin de modelos inicia un proceso de estandarizacin del cual surge Query View Transformatios QVT, con el cual se pretende establecer un lenguaje para la transformacin de modelos y un lenguaje para la definicin y generacin de vistas que facilite el anlisis de modelos desde diferentes perspectivas de los desarrolladores.

QVT Query View Transformation

Teora General de MDD

QVT Query View Transformation

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 travs de un proceso guiado por modelos y soportado por potentes herramientas que generan cdigos a partir de modelos. MDD tiene como objetivo organizar los niveles de abstraccin y las metodologas de desarrollo, todo ello promoviendo el uso de modelos como artefactos principales a ser construidos y mantenidos. MDD cubre amplias reas de investigacin: Lenguajes para la descripcin de modelos. Definicin de lenguajes de transformacin entre modelos Construccin 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.

Elementos claves en MDD: Modelos y Transformaciones.

Transformacin. Transformacin es la generacin automtica de un modelo destino a partir de un modelo origen de acuerdo a una especificacin. Existen dos tipos de transformaciones: Transformaciones modelo a modelo (M2M) Transformaciones modelo a texto (M2T) Estndares : M2M: ATL, QVT M2T: MOF-to-text, XPand Modelos. Un modelo est constituido por un conjunto de elementos que proporcionan una descripcin sinttica y abstracta de un sistema, concreto o hipottico. Los modelos no son solo documentativos, son la esencia y el cdigo es una consecuencia de los modelos. Frecuentemente se presenta a un modelo como una combinacin de dibujos y texto. El texto puede estar en un lenguaje de modelado o en lenguaje natural.

QVT Query View Transformation

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

QVT Query View Transformation

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 tecnologa e integracin. La idea principal de MDA es usar modelos, de modo que las propiedades y caractersticas de los sistemas queden plasmadas de forma abstracta, y por tanto, los modelos no seran afectados por tales cambios. MDA permite la construccin de software a partir de modelos los cuales a travs de transformaciones se convierten en cdigo. En este contexto en MDA se abordan desde el punto de vista de los estndares abiertos. En este caso, el estndar Meta Object Facility (MOF) , proporciona un mecanismo para definir metamodelos. El estndar Query/Views/Transformations (QVT) indica cmo 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.

MOF
MOF (Meta Object Facility) es el metamodelo facilitado por MDA como vocabulario Bsico o metamodelo, los metamodelos y modelos se suelen organizar en una estructura de cuatro capas M3-M0 con la siguiente distribucin: En el nivel M1 se sitan los modelos, tal y como los hemos introducido aqu, descripciones abstractas de un sistema En el nivel M2, se sitan 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 aproximacin 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 sitan los datos, es decir las instancias del sistema bajo estudio.

QVT Query View Transformation

OCL
Object Constraint Language (OCL) es un lenguaje notacional para el anlisis y diseo de sistemas software. Est definido como lenguaje estndar para dar soporte al Unified Modeling Language (UML), el cual es un estndar de OMG para el anlisis y diseo orientado a objetos. OCL da soporte a UML para la especificacin de restricciones y consultas sobre modelos, permitiendo definir y documentar los modelos UML de forma ms precisa. Un modelo UML, como por ejemplo un diagrama de clases o un diagrama de estados, no constituye una especificacin lo suficientemente precisa y libre de ambigedades de un sistema. Las expresiones OCL completan esta especificacin, convirtindose en informacin vital para los modelos orientados a objetos y otros objetos para el modelado. Esta informacin a menudo no puede ser expresada mediante un diagrama. Cada expresin OCL se refiere a tipos (por ejemplo, clases, interfaces,. . . ) definidos en diagramas UML. De esta manera, una expresin OCL estar siempre ligada a un diagrama UML (no tendra 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 tambin la referencia a un objeto, una coleccin de valores, o una coleccin de referencias a objetos. Una expresin OCL puede representar, por ejemplo, un valor booleano usado en la condicin de un diagrama de estados, o un mensaje en un diagrama de interaccin. Una expresin OCL puede referirse a un objeto especfico en un diagrama de interaccin o de objetos.

QVT Query View Transformation

Transformacin de modelos

QVT Query View Transformation

Transformacin de modelos
La transformacin de modelos juega un papel clave en el desarrollo dirigido por modelos, puesto que sern 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, transformacin de modelos hace referencia al proceso de convertir un modelo en otro modelo del mismo sistema (Hebach 2006). La transformacin de modelos se considera el proceso central de MDA. La transformacin 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 estandarizacin promovida por QVT y atendiendo a las necesidades prcticas de la transformacin de modelos, surgen diversas estrategias de transformacin que van ms all del uso de elementos del metamodelo y definen mecanismos de transformacin basados en tipos de elementos, patrones, informacin de la plataforma y otros modelos e informacin adicional. Otras estrategias de transformacin son VIATRA y ATL (OMG-MDA, 2003). En la siguiente figura representa la arquitectura de transformacin de modelos; en ella se muestra cmo se definen y aplican las transformaciones que se basan en el uso de metamodelos (Jezequel, 2005).

Caractersticas de los enfoques de transformacin.

Especiacin (opcional) Esta caracterstica refiere a los mecanismos de especificacin provistos para definir la transformacin como podran ser precondiciones y pos condiciones expresadas en OCL. Por lo general estas especiaciones describen relaciones y no son ejecutables.

1 0

QVT Query View Transformation Resulta de inters conocer si es posible especificar transformaciones de alto nivel (transformaciones sobre transformaciones) o si la especificacin posee propiedades matemticas que faciliten algn tipo de prueba. Reglas de transformacin. Una regla de transformacin es la mnima unidad de transformacin. El ejemplo ms comn son reglas con un lado izquierdo (LHS) y derecho (RHS). Tambin son reglas de transformacin las funciones o los procedimientos que implementan un paso de la transformacin. Las reglas pueden tomar como entrada uno o ms dominios. Los modelos que se pueden describir estn determinados por el lenguaje asociado a la especificacin de las reglas. Los dominios en una transformacin pueden ser de entrada y/o salida. Cuando los dominios de entrada y salida son descriptos por un mismo metamodelo hablamos de transformaciones endgenas. En caso contrario se trata de transformaciones exgenas. La determinacin del tipo de dominio (entrada y/o salida) es esttica y opcionalmente dinmica. El dominio debe contar adems con metavariables (contenedores de elementos del modelo) y opcionalmente con patterns (segmentos con una o ms variables) y expresiones lgicas (ejecutables o no). En algunos enfoques puede existir una separacin sintctica 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 ejecucin 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 mayora de las estructuras intermedias son persistidos luego de la transformacin. En algunos enfoques es posible la parametrizacin de las reglas, volvindolas ms reusables. Otra caracterstica 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 tambin de las reglas que los afectan. La utilizacin de aspects brinda los beneficios de mayor modularidad y facilidad para separar distintas visiones sobre las transformaciones.

1 1

QVT Query View Transformation Aplicacin de las reglas Esta caracterstica busca analizar los mecanismos brindados para especificar la seleccin y ejecucin de reglas y determinar los elementos del modelo origen afectados. A continuacin se profundizar en cada uno de estos aspectos. La determinacin de ubicacin 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 representacin interna), no determinista (ej: aplicacin concurrente en todos los elementos que cumplan con cierto criterio) o interactiva con el usuario. La planificacin (Figura 5) determina el orden en que son aplicadas las reglas. Los diferentes mecanismos de planificacin pueden ser agrupados en las siguientes categoras: La forma de la planificacin es implcita si el usuario no tiene ningn tipo de control explcito sobre el algoritmo de planificacin de la herramienta. La nica forma de incidir es diseando patrones y lgica para asegurar cierto orden (ej: chequear precondiciones para ejecutar una regla). En cambio, es explcita si existen construcciones dedicadas para especificar el orden de ejecucin, las cuales pueden ser externas, separadas de la lgica de las reglas, o internas. La seleccin de las reglas a ejecutar puede especificarse por una condicin explcita, por una condicin no determinista, por un mecanismo de resolucin de conflictos o mediante interaccin con el usuario. La iteracin de reglas provista por el enfoque puede contener recursin, ciclos o FIXPOINT ITERATIONS (la regla se aplica repetidamente hasta no detectar cambios). Las reglas podran organizarse en fases. Estas tienen un propsito especfico y slo ciertas reglas pueden ejecutarse en cada una de ellas.

Organizacin de Reglas Este tem comprende los aspectos de composicin y estructuracin, como modularizacin y reuso. Se proponen tres reas de variacin: Mecanismos de modularizacin: las reglas se agrupan en mdulos que pueden importar a otros mdulos para acceder a su contenido. Mecanismos de reuso: definicin de una regla basada en otras reglas, utilizando mecanismos de herencia entre reglas y/o mdulos y composicin lgica de las mismas.

1 2

QVT Query View Transformation Estructura organizacional: las reglas pueden organizarse segn la estructura del lenguaje de origen, del lenguaje destino o usando una organizacin independiente de ambos.

Relacin origen-destino Este tem describe la relacin entre los modelos de origen y destino de la transformacin. 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. En otros enfoques (ej: VIATRA) solo se permite actualizaciones in-place: el modelo origen y destino deben ser una misma instancia. Las actualizaciones podran ser destructivas o nicamente permitir extensiones del modelo. Tambin existen enfoques (ej: QVT) que permiten tanto actualizaciones al modelo origen como la creacin de nuevos modelos. Incrementalidad. La incrementalidad (Figura 8) puede ser descrita por tres caractersticas: Incrementalidad del objetivo (o propagacin de cambios): Capacidad de actualizar los modelos objetivos existentes teniendo en cuenta cambios en los modelos de origen. Incrementalidad del origen: Minimizacin de la cantidad de informacin del modelo origen que debe ser reanalizada tras una modificacin en el mismo. Preservacin 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.

Direccionalidad Se 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. Trazabilidad Se refiere a los mecanismos para registrar la ejecucin de la transformacin. La forma ms comn de realizarlo es mediante traceability links, que conectan elementos del modelo origen y de destino.

1 3

QVT Query View Transformation Esta informacin puede ser til para realizar un anlisis de impacto y para realizar debugging. Algunos enfoques proveen un mecanismo dedicado para trazabilidad. Aunque este no existiera, podra ser creado como un elemento ms en el modelo destino.

1 4

QVT Query View Transformation

QVT: Query/View/Transformation

1 5

QVT Query View Transformation

QVT. Historia
En 2002, OMG emiti una solicitud de propuestas (RFP) en MOF Query / View / Transformation a buscar un estndar compatible con la recomendacin MDA suite (UML, MOF, OCL, etc.) Varias respuestas fueron dadas por una serie de empresas e instituciones de investigacin que se desarrollaron durante tres aos para elaborar una propuesta comn que fue presentado y aprobado. El proceso de definicin del estndar culmin a finales de 2005 con la primera versin final de la especificacin [MOF05]. QVT versin 1.1 fue lanzado en enero de 2011.

Definicines de QVT.
QVT es la propuesta del OMG para resolver el problema de la transformacin de modelos. Se trata de un estndar para la definicin de transformaciones sobre modelos MOF. La especificacin de QVT depende de otros dos estndares de la OMG como son MOF y OCL. De esta manera, la utilizacin de la especificacin de QVT para especificar transformaciones, aporta reutilizacin de tecnologa que sigue estndares y reduccin de la curva de aprendizaje de la herramienta. La dimensin del lenguaje define los diferentes lenguajes de transformacin presentes en la especificacin QVT. Concretamente son tres: Relations, Core y Operational, y la principal diferencia entre ellos es su naturaleza declarativa o imperativa. En la dimensin de la interoperabilidad se encuentran aquellas caractersticas que permiten a una herramienta que cumple el estndar QVT interoperar con otras herramientas. Concretamente, son cuatro: sintaxis ejecutable, XMI ejecutable, sintaxis exportable y XMI exportable. La sintaxis ejecutable se traduce en una implementacin que facilite la importacin o lectura, y posterior ejecucin de una sintaxis concreta que describa una transformacin definida en el lenguaje dado por la dimensin del lenguaje.

1 6

QVT Query View Transformation XMI ejecutable dictamina que una implementacin debe facilitar la importacin o lectura, y posterior ejecucin de una serializacin XMI de una transformacin que conforma con el metamodelo de MOF del lenguaje dado por la dimensin del lenguaje. La sintaxis exportable establece que una implementacin debe proporcionar facilidad para exporta una transformacin entre modelos en la sintaxis concreta del lenguaje dado por la dimensin del lenguaje. XMI exportable es el nivel de interoperabilidad que debe facilitar la exportacin de transformaciones entre modelos como serializaciones XMI que conformen con el metamodelo MOF del lenguaje dado por la dimensin del lenguaje.

El estndar QVT define tres abstracciones fundamentales, que se corresponden con sus siglas [Heb05]: Consultas (Queries) Una consulta es una expresin que se evala 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 realizacin 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 ms generales que las Consultas. Suelen ser entidades de

slo lectura. Una vista es una proyeccin realizada sobre un modelo, creada mediante una transformacin. Una vista puede verse como el resultado de una consulta sobre un modelo, ofreciendo como resultado un punto de vista de ste, restringindolo de acuerdo a alguna condicin impuesta.
Transformaciones (Transformations) Una transformacin genera un modelo a partir de otro modelo de origen. Ambos modelos podrn ser dependientes o independientes, segn exista o no una relacin que mantenga ambos sincronizados una vez se produzca la transformacin. Las vistas son un tipo especfico de transformacin. 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 transformacin, o crean uno nuevo a partir de los modelos de entrada. Si se modifica una vista, la correspondiente transformacin debe ser bidireccional para reflejar los cambios en el modelo fuente. Las transformaciones se definirn utilizando un lenguaje de transformacin. El lenguaje de transformacin debe servir para generar vistas de un metamodelo, debe ser capaz de expresar toda la informacin necesaria para generar automticamente la transformacin de un modelo origen a

1 7

QVT Query View Transformation uno destino, y debe adems 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 transformacin, 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 transformacin sern adems instancias de metamodelos MOF 2.0. Una vez descrito el planteamiento conceptual de QVT conviene describir la solucin propuesta por la especificacin finalmente adoptada [MOF05]. Como lenguaje de consulta se definen extensiones al estndar OCL 2.

Arquitectura QVT
La especificacin de transformaciones se propone una solucin de naturaleza hbrida declarativa e imperativa. La parte declarativa se divide en una arquitectura de 2 capas, que sirve como marco para la semntica de ejecucin de la parte imperativa. La parte declarativa de esta especificacin 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 creacin de plantillas de objetos y la creacin implcita 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 abstraccin que Relations pero con la misma potencia, definido usando extensiones mnimas de EMOF y OCL. La especificacin de QVT define las reglas que permiten mapear la semntica 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 explcitamente y slo soporta reconocimiento de patrones sobre un conjunto plano de variables, no sobre objetos complejos como en Relations.

1 8

QVT Query View Transformation

El lenguaje Relations
El lenguaje Relations proporciona una especificacin declarativa de relaciones entre modelos MOF. Soporta pattern matching de objetos complejos y de manera implcita crea clases de trazabilidad y sus instancias correspondientes, de forma que permite guardar todo lo que ocurre durante la ejecucin de una transformacin.

El lenguaje Core
Este 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 simtrica y su potencia es equiparable a la del lenguaje Relations. Esto se debe, a que por su relativa simplicidad su semntica puede ser definida de manera ms sencilla, aunque la definicin de transformaciones sea ms verbosa. Adems, los modelos de trazabilidad han de ser definidos de manera explcita y no pueden deducirse de la definicin de la transformacin como ocurra en el lenguaje Relations. El modelo Core debe ser implementado directamente, o simplemente usado como referencia para la semntica del Relations, la cual est mapeada a Core a travs de una transformacin.

Analoga de mquina virtual

Es posible trazar una analoga con la arquitectura JavaTM, donde el lenguaje Core es como Java Byte Code y la semntica de Core se comporta como la mquina virtual Java. El lenguaje Relations desempea el rol del lenguaje Java, y la transformacin estndar de Relations a Core es la especificacin de un compilador Java que genera Byte Code.

Implementaciones Imperativas
Adems de las relaciones y lenguajes declarativos fundamentales que encarnan la misma semntica en dos niveles diferentes de abstraccin, hay dos mecanismos para invocar implementaciones imperativas de transformaciones

1 9

QVT Query View Transformation desde los lenguajes Relations o Core: un lenguaje estndar, Operational Mappings, as como una implementacin no estndar Black-box MOF Operation. Cada relacin se define una clase que se crear una instancia de rastrear entre los elementos del modelo son transformada, y tiene una asignacin uno a uno con una firma de la operacin que la cartografa operativa o Negro caja implementos. Operational Mapping. Este lenguaje est especificado como estndar para proporcionar implementaciones imperativas. Proporciona extensiones OCL con efectos laterales que da un mayor estilo procedural y una sintaxis ms cercana a la programacin imperativa (incluye construcciones imperativas tales como bucles y condiciones). Este lenguaje define operaciones de mappings que pueden ser usadas para implementar una o ms Relations a partir de una especificacin Relations, cuando sea difcil proporcionar una especificacin declarativa ms 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, denominndose este tipo de transformaciones: transformaciones operacionales. Implementacin Black-box. No se trata de un lenguaje, sino de un mecanismo que permite enlazar cdigo escrito en cualquier lenguaje. Para ello, se utiliza el lenguaje Relations para derivar una operacin MOF de una transformacin. Esta operacin ser el punto de enlace con el lenguaje deseado, que deber definir la operacin a ejecutar con la misma signatura, y soportar un enlace con la implementacin 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 semntica de su ejecucin se define mediante descripciones en texto plano. Para cada uno de ellos se proporciona una sintaxis textual concreta definida mediante gramticas EBNF [Cue01]. Para el lenguaje Relations se define adems una notacin grfica especfica. 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 implementacin de una operacin MOF con la misma signatura. Esto resulta beneficioso por las siguientes razones: Permite codificar algoritmos complejos en cualquier lenguaje de programacin con correspondencia a MOF.

2 0

QVT Query View Transformation Permite el uso de libreras especficas de dominio para calcular ciertas propiedades del modelo. Por ejemplo, en matemticas, en ingeniera y en otros muchos campos existen grandes libreras que almacenan algoritmos especficos de dominio, que seran muy difciles de expresar usando OCL. Permite ocultar la implementacin de algunas partes de una transformacin.

Sin embargo, esta integracin puede resultar peligrosa puesto que la implementacin asociada a esta integracin tiene libre acceso a las referencias de objetos en los modelos. Las implementaciones Black-box no tienen una relacin implcita hacia Relations, y cada Black-box debe implementar explcitamente una relacin que sea responsable de conservar la trazabilidad entre los elementos del modelo relacionado con la implementacin de la operacin MOF. En aras de extender la analoga 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).

Escenarios de ejecucin.
La semntica del lenguaje Core (y el lenguaje Relaciones) debe tener en cuenta los siguientes escenarios de ejecucin: Entradas a slo transformaciones para verificar que los modelos se relacionan de una manera especfica. Transformaciones sola direccin. Transformaciones bidireccionales. (De hecho, ms de dos direcciones son posibles, pero dos es el caso ms comn). 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 direccin) cuando un modelo relacionado se cambia despus de una ejecucin 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 slo la especificacin de transformaciones en una sola direccin. Las transformaciones bidireccionales slo son posibles si una aplicacin operativa inversa se proporciona por separado. Sin embargo, todas las otras funciones definidas anteriormente son disponibles con ejecuciones imperativas e hbridos.

2 1

QVT Query View Transformation

Metamodelos MOF.
Esta especificacin define tres paquetes principales, uno para cada uno de los idiomas definidos: QVTCore (Seccin 9.17), QVTRelation (Seccin 7.11.3), y QVTOperational (Seccin 8.2). El paquete QVTBase define la estructura comn para las transformaciones (Seccin 7.11.1). Adems, el paquete QVTRelation utiliza expresiones de plantilla de patrones definidos en el paquete QVTTemplateExp (Seccin 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 (Seccin 8.2.2). Todos QVT depende del paquete EssentialOCL de OCL 2,0, y todos los paquetes de idioma dependen de EMOF.

2 2

QVT Query View Transformation

El Lenguaje Relations
El lenguaje Relations ofrece una aproximacin declarativa para la especificacin de transformaciones. Dado un par de modelos candidatos para la transformacin, que debern 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 relacin del lenguaje Relations: se definen mediante dos o ms dominios y mediante una pareja de predicados when (cundo) y where (cmo). Los dominios especifican, mediante un patrn, qu elementos de los modelos candidatos participarn en la transformacin. Por su parte, la clusula when especifica la relaciones que determinan cundo la relacin indicada debe sostenerse; y la clusula where especifica la condicin que deben satisfacer todos los elementos de modelos que participan en la relacin [MOF05].

Transformaciones y tipos de modelos

En el lenguaje Relations, una transformacin entre modelos candidatos se especifica como un conjunto de relaciones que han de tener lugar para llevar a cabo la transformacin. Un modelo candidato es cualquier modelo que conforme a un tipo de modelo o metamodelo, que es una especificacin 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 declaracin del modelo candidato. Por ejemplo:
transformation uml2Rdbms (uml : SimpleUML, rdbms : SimpleRDBMS) {

Declaracin de una transformacin en QVT-Relations. En esta declaracin de transformacin 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. Direccin de ejecucin de una transformacin Una transformation invocada para realizar una transformacin se ejecuta en una direccin determinada seleccionando uno de los modelos candidatos como modelo destino u objetivo. El modelo destino debe estar vaco o contener elementos para ser relacionados por la transformacin. El procedimiento de

2 3

QVT Query View Transformation transformacin se basa en comprobar que todas las relaciones definidas en la transformacin se cumplen y para aquellas relaciones que no se cumplen, se intenta cumplirlas creando, eliminando o modificando el modelo destino.

Relaciones y dominios
Las relaciones en una transformacin definen restricciones que deben satisfacer los elementos de los modelos candidatos. Una relacin o relation definida para dos o ms dominios, y un par de predicados when y where, especifica una relacin 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 patrn que puede ser visto como un grafo de nodos de objetos, cuyas propiedades y links de asociacin se originan de una instancia del tipo del dominio. Alternativamente, un patrn 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 vlida de ese patrn. Un patrn 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 relacin. En el siguiente ejemplo, se declaran dos dominios que correspondern a elementos de los modelos uml y rdbms. Cada dominio especifica un patrn 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 deberan tener el mismo valor:

relation PackageToSchema { domain uml p: Package {name=pn} domain rdbms s: Schema {name=pn} }
Declaracin de una relation en QVT-Relations. Clusulas when y where Como se muestra en el siguiente ejemplo de la relacin ClassToTable, una relacin puede estar limitada por dos conjuntos de predicados, una clusula when y una clusula where. La clusula when define las condiciones bajo las cuales se necesita satisfacer la relacin, por lo que la relacin ClassToTable se cumplir solo cuando se cumpla la relacin PackageToSchema, es decir, cuando el paquete contiene la clase y el esquema contiene la tabla. La clusula where define la condicin que deben satisfacer todos los elementos de todos los modelos que participan en la relacin, y puede restringir cualquiera de las variables en la

2 4

QVT Query View Transformation relacin y sus dominios. Por tanto, siempre que se cumpla la relacin ClassToTable, la relacin AttributeToColumn tambin se cumplir.
relation ClassToTable /* map each persistent class to a table */ { domain uml c:Class { namespace = p:Package {}, kind='Persistent', 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 clusulas when y where pueden contener cualquier expresin OCL adems de las expresiones de invocacin de la relacin. La invocacin de relaciones permite componer relaciones complejas a partir de relaciones ms simples. Relaciones Top-level. Una transformacin contiene dos tipos de relaciones: las top-level y las no-toplevel. La ejecucin de una transformacin 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 clusula where de otra relacin.
transformation umlRdbms (uml : SimpleUML, rdbms : SimpleRDBMS) { top relation PackageToSchema {} top relation ClassToTable {} relation AttributeToColumn {} }

Declaracin de relaciones top-level en QVT-Relations Una relacin top-level tiene la palabra clave top que la distingue sintcticamente. En el ejemplo anterior, tanto PackageToSchema como ClassToTable son relaciones top-level mientras que AttributeToColumn es una relacin no-top-level.

2 5

QVT Query View Transformation Check y Enforce El que una relacin sea de transformacin o no viene determinado por el dominio destino, que estar marcado como checkonly o enforce. Cuando una transformacin se satisface en la direccin de un dominio checkonly, simplemente se comprueba si existe una correspondencia vlida en el modelo relevante que satisfaga la relacin. Cuando ransformacin se ejecuta en la direccin de un dominio enforce, si la comprobacin falla, se modifica el modelo destino tanto como sea necesario para que satisfaga la relacin. 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.
relation PackageToSchema { checkonly domain uml p: Package { name=pn } enforce domain rdbms s: Schema { name=pn } }

Declaracin de dominion checkonly y enforce en QVT-Relations. Si estuviramos ejecutando en la direccin de uml y existiera un esquema en rdbms para el cual no tenemos un paquete correspondiente con el mismo nombre en uml, se detectara una inconsistencia pero no se creara el paquete puesto que el modelo uml es checkonly y no enforce. Sin embargo, si estuviramos ejecutando la transformacin uml2Rdbms en la direccin de rdbms, entonces para cada paquete en el modelo de uml, la relacin primero comprobara si existe un esquema con el mismo nombre en el modelo rdbms, y si no es as, se creara un nuevo esquema en ese modelo con el nombre dado. Para considerar una variacin del caso propuesto, si ejecutamos la transformacin en la direccin 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 aplicacin de las reglas depende nicamente del dominio destino.

Pattern-Matching
Los patrones o patterns asociados a los dominios reciben el nombre de object template expressions. Para ilustrar cmo 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 utilizarn 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

2 6

QVT Query View Transformation

}

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 estn 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 expresin (c, p, y cn), empezando desde la variable raz del domino c de tipo Class. En este ejemplo, la variable p debera tambin estar ligada como resultado de la evaluacin de la expresin PackageToSchema(p,s) en la clusula 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 clusula 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 vlido dar como resultado una nica tupla que represente la unin de un valor con una variable. En una invocacin a una relacin dada, puede haber varios matchings vlidos para una template expression, la manera de procesar esta multiplicidad depende de la direccin en la que ejecutemos la relacin.

2 7

QVT Query View Transformation Por ejemplo, si se ejecuta la relacin ClassToTable con rdbms como modelo destino, entonces por cada matching vlido del dominio uml, tendra que existir al menos un matching vlido del dominio rdbms que satisfaga la clusula where. Si para un matching vlido del dominio uml, no existe un matching vlido 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. Tambin, para cada matching vlido del dominio rdbms, tendra que existir al menos un matching vlido del dominio uml que satisfaga la clusula where (esto exige que el dominio uml est marcado como checkonly); en otro caso los objetos se eliminarn del modelo rdbms por lo que no seguir siendo un matching vlido.

Keys y creacin de objetos usando patrones

Como se mencion anteriormente, un object template expression tambin sirve como plantilla para crear un objeto en un modelo destino. Cuando para un matching vlido dado de un patrn de dominio origen, no existe un matching en el patrn del dominio destino, entonces se utiliza el object template expression del dominio destino como plantilla para crear objetos en el modelo 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 } }

Creacin 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. Anlogamente, 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 cundo actualizar objetos existentes o no permitir la creacin 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 identificarn de manera nica el objeto instancia de una clase del modelo. Una clase puede tener mltiples keys al igual que ocurre en las bases de datos relacionales.

2 8

QVT Query View Transformation Por ejemplo, continuando con el ejemplo de la relacin 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 };

Declaracin de Keys en QVT-Realations. Las keys se utilizan en el tiempo de la creacin 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 semntico de patrones, el modelo rdbms no tiene un matching vlido para el patrn asociado a la Table, por lo que es necesaria la creacin de objetos que cumplan esa relacin. Sin embargo, desde que la tabla existente hace 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.

El Lenguaje Operational Mapping

El lenguaje Operational Mapping permite definir transformaciones utilizando bien una aproximacin imperativa o bien una aproximacin hbrida, complementando las transformaciones relacionales declarativas con operaciones imperativas que implementen las relaciones. Una transformacin operacional define una transformacin unidireccional expresada de forma imperativa. Se compone de una signatura que indica los modelos involucrados en la transformacin y de una definicin de la ejecucin de la transformacin. En la prctica, una transformacin operacional se trata de una entidad instanciable con propiedades y operaciones. Este lenguaje de QVT permite la definicin de transformaciones mediante un lenguaje imperativo. Permite tambin definir mappings para complementar las relaciones desarrolladas con el lenguaje Relational (enfoque hbrido). Entidad instanciable que posee operaciones y propiedades. Representa la definicin de una transformacin unidireccional expresada de manera imperativa.

2 9

QVT Query View Transformation Define: Signatura indicando los modelos involucrados. Operacin main de entrada.

3 0

QVT Query View Transformation

Herramientas

3 1

QVT Query View Transformation

Anlisis de herramientas para transformacin de modelos

Caractersticas de las herramientas de transformacin.
En esta seccin complementamos las caractersticas para categorizar enfoques de transformacin con y algunos criterios propios. Estas caractersticas estn relacionadas con las herramientas que implementan los diferentes enfoques para transformacin de modelos. A continuacin describiremos brevemente aquellas que consideramos de inters para analizar una herramienta: reas de aplicacin: esta caracterstica 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 aplicacin de transformaciones: se relaciona con la interactividad con el usuario descrita en la seccin previa y describe en que forma la herramienta asiste al usuario para descubrir aquellas reglas de transformacin que pueden ser de inters en una determinado modelo a transformar. Tipo de licencia de distribucin: la herramienta puede ser software propietario o distriburse con algn tipo de licencia de cdigo abierto. Historia de la herramienta: comprende el origen de la misma (por ejemplo: acadmico o emprendimiento privado), su antigedad y la continuidad de su soporte. Soporte brindado al usuario: refiere al tipo de documentacin brindada: manuales, tutoriales, ejemplos, foros y todo tipo de soporte disponible. Comunidad de usuarios y aceptacin: refiere a la cantidad de usuarios activos de la herramienta y la aceptacin obtenida por la misma dentro de la comunidad. Mecanismos ofrecidos para garantizar correctitud de las transformaciones: refiere a las garantas ofrecidas por la herramienta de que el resultado producido es correcto sintctica y semnticamente. 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.

3 2

QVT Query View Transformation Mecanismos ofrecidos para verificacin y validacin de transformaciones: a diferencia de la correctitud, esto se refiere a los mecanismos ofrecidos para verificar que una transformacin desarrollada presenta el comportamiento deseado por el programador. Un ejemplo de esto podra ser asistir al usuario en la generacin de casos de prueba. Escalabilidad de transformaciones y de modelos: refiere a la capacidad de la herramienta para manejar complejidad y tamao creciente ya sea en las transformaciones o en los modelos a transformar.

Implementaciones de QVT
Las implementaciones ms sobresalientes de QVT son las siguientes: 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. Slo soporta las transformaciones operacionales (imperativas). Soporta adems OCL en su versin 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 cul se basa en EMF SmartQVT,

SmartQVT SmartQVT [BD06] es una implementacin de cdigo abierto de la especificacin 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 implementacin completa en java del lenguaje operacional QVT. La herramienta se distribuye como un complemento a Eclipse de libre distribucin y se caracteriza por estar implementada de forma imperativa. Tambin utiliza EMF para especificar el metamodelo de QVT. Su funcionamiento se basa en una transformacin en dos fases: En una fase inicial se traduce la sintaxis textual concreta del lenguaje operacional de QVT a instancias del metamodelo de QVT.

3 3

QVT Query View Transformation En una segunda fase, se transforma el modelo de QVT en un programa Java basado en EMF que ejecuta la transformacin. Para serializar el modelo QVT de entrada se utiliza XMI 2.0.

MOMENT MOdel manageMENT [QHB+06] es un prototipo de motor de transformacin que implementa el lenguaje Relations de la especificacin QVT. En su implementacin utiliza EMF para la especificacin de metamodelos. A partir del cdigo del lenguaje Relations, instancia el metamodelo QVT que implementa la herramienta. Como paso previo a obtener el modelo transformado en trminos de EMF, se genera una especificacin intermedia en el lenguaje Maude [CDE+03], aprovechndose de sus propiedades intrnsecas, como la concordancia de patrones, la parametrizacin y la reflexin. 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 transformacin de modelo a modelo. ATL (Lengua de transformacin del ATLAS) (lengua de transformacin del ATLAS) de INRIA (Inria) Procedural QVT, de Borland (Borland) Declarative QVT, de Obeo (Obeo)

MediniQVT Es una herramienta de transformacin 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 aplicacin incluye herramientas para el desarrollo de transformaciones, as como un depurador grfico y un editor. Estos componentes son de libre distribucin pero slo para uso no comercial. MediniQVT efecta las transformaciones QVT expresadas en la sintaxis concreta del lenguaje de relaciones de QVT (QVT relations).MediniQVT est integrado en Eclipse. La aplicacin posee un editor con asistente de cdigo que permite especificar las relaciones modelo origen modelo destino, ya sea el elemento o sus propiedades. MediniQVT proporciona tambin 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.

3 4

QVT Query View Transformation

Aplicacin de QVT ejemplo.

3 5

QVT Query View Transformation

1.

Aplicacin de QVT ejemplo.

La herramienta a utilizar es Medini QVT.

Medini QVT
Historia
MediniQVT 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 estndar 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 ao 2008 cuando se liber el cdigo fuente bajo la licencia de cdigo abierto EPL Eclipse Public License.

Caractersticas.
Desde el punto de vista de la tecnologa, MediniQVT se basa en EMF como entorno de modelado y metamodelado. Para la definicin de transformaciones emplea el lenguaje QVT-Relations, dando soporte a transformaciones modelo-amodelo, e internamente, el motor de evaluacin de expresiones OCL est basado en OSLO (Open Source Library for OCL [21]). Las principales caractersticas de la herramienta completa son: Ejecucin de transformaciones QVT expresadas en la sintaxis concreta textual del lenguaje QVT-Relations Editor con resaltado y completado de cdigo. Depurador para trazar la ejecucin de transformaciones paso a paso a travs de las reglas. Implementacin del concepto de clave (key) del lenguaje QVT, permitiendo las transformaciones para actualizaciones incrementales. Transformaciones con n-dominios participantes. Transformaciones bidireccionales (cuando la definicin 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 ejecucin de transformaciones el que es pblico y de cdigo abierto. Todos los plugins que implementan funcionalidad adicional (editor textual, depuracin, etc.) son de cdigo cerrado.

3 6

QVT Query View Transformation Por ello, para la construccin del prototipo presentado en este trabajo, slo se ha tomado aquella parte que es de cdigo abierto y reutilizable, habindose implementado expresamente para el trabajo un conjunto de plugins y herramientas que permiten la invocacin de forma amigable de transformaciones QVT. En la seccin 6.4 se describe en detalle el conjunto de plugins desarrollados, y en la seccin 8 se muestra indica su gua de uso.

3 7

QVT Query View Transformation

Bibliografia
M. Hebach MDA with QVT. Borland Together 2006 Presentation.
http://www.ikv.de/)

3 8