Implementando la semántica de QVT mediante el mecanismo de

Implementando la semántica de QVT mediante el
mecanismo de transformación de modelos
A.P.U. Silvana Mossi
A.C. Carina Moldes
Directora de Tesis
Dra. Claudia Pons
Facultad de Informática
Universidad Nacional de La Plata
Indice
CAPÍTULO 1 ............................................................................................................................................... 3
INTRODUCCIÓN ...................................................................................................................................... 3
MOTIVACIÓN ............................................................................................................................................ 3
CAPÍTULO 2 ............................................................................................................................................... 5
CONCEPTOS BÁSICOS ........................................................................................................................... 5
DESARROLLO DE SOFTWARE DIRIGIDO POR MODELOS ............................................................................ 5
OBJETIVO DEL DESARROLLO DIRIGIDO POR MODELOS ............................................................................ 5
ARQUITECTURA DIRIGIDA POR MODELOS ................................................................................................ 6
Conceptos básicos de MDA ................................................................................................................ 6
Funcionamiento de MDA .................................................................................................................. 7
Mapeo y transformación de modelos ............................................................................................... 10
Métodos específicos de transformación de modelos ....................................................................... 11
Base tecnológica de MDA ................................................................................................................ 12
Herramientas MDA ......................................................................................................................... 14
CAPÍTULO 3 ............................................................................................................................................. 16
QVT : EL ESTÁNDAR DE OMG PARA TRANSFORMACIONES .................................................. 16
OBJETIVOS DE QVT.............................................................................................................................. 16
Descripción general de QVT ............................................................................................................ 17
QVT OPERATIONAL ............................................................................................................................. 18
Operational transformations ........................................................................................................... 19
Mapping operations ......................................................................................................................... 19
CAPÍTULO N ............................................................................................................................................ 22
ANÁLISIS DE HERRAMIENTAS PARA TRANSFORMACIÓN DE MODELOS ......................... 22
2
Capítulo 1
Introducción
En este capítulo se describe la motivación y el contexto en el que se enmarca esta tesis,
nuestra propuesta para los problemas a resolver y los objetivos a cumplir. A modo de
introducción presentamos los principales aportes del Desarrollo de Software dirigido
por Modelos (MDD) para la automatización del desarrollo de software.
Motivación
Los modelos proveen abstracciones de un sistema físico que permiten a los ingenieros
analizar el sistema ignorando detalles complejos mientras se enfocan en las partes más
relevantes, como puede ser la lógica del negocio. Todas las formas de ingeniería se
basan en el uso de modelos para facilitar la comprensión de sistemas complejos, los
modelos son utilizados en muchas formas: para predecir la calidad de un sistema,
razonar acerca de propiedades específicas cuando ciertos aspectos del sistema cambian,
y para comunicar características claves del sistema a todos los involucrados en el
desarrollo.
Los modelos pueden ser los precursores de la implementación física del sistema o ser
generados de sistemas ya existentes para comprender su funcionamiento.
En el mundo del software, el modelado existe desde hace tiempo, se remonta a los
primeros días de la programación. El estado actual de esta práctica emplea el lenguaje
de modelado unificado o UML (Unified Modeling Laguage) como el arma principal en
la notación del modelado. UML permite a los equipos de desarrollo capturar una
variedad de características importantes de un sistema, en modelos. Durante el proceso
de desarrollo de software, se realizan transformaciones entre modelos, por ejemplo, el
modelo de análisis es transformado en un modelo de diseño y así sucesivamente hasta
llegar al código. Sin embargo, la transformación entre estos modelos es
primordialmente manual, lo que tiende a ser complejo. Una forma útil de describir la
distintas maneras en que es utilizado el modelado en la actualidad, es observar las
distintas formas en que el código es sincronizado con el modelo, éstas aproximaciones
al modelado van desde no utilizar modelos en ninguna fase del desarrollo hasta
proyectos donde sólo se realizan modelos conceptuales sin llegar a nunca a codificar.
Actualmente buena parte de los desarrolladores toma la aproximación de “solo código”
y utilizan poco los modelos. Esta aproximación hace difícil la evolución de estos
sistemas dado que en muchos de los casos los desarrolladores originales del sistema no
se encuentran durante las fases de mantenimiento del mismo.
Una mejora es proveer de visualizaciones de código en alguna notación adecuada, esto
es, mientras el desarrollador va generando el código, éste es visualizado para entender
de mejor manera su estructura. Las ventajas del modelado pueden ser apreciadas en
mayor grado cuando se habla de ingeniería de ida y vuelta (RTE por sus siglas en inglés
RoundTrip Engineering) que ofrece un intercambio bidireccional entre el modelo
abstracto que describe la arquitectura del sistema y el código. Esta aproximación
requiere de mucha disciplina de los participantes ya que puede ocurrir un defasaje entre
los modelos y su implementación si no hay comunicación y procesos bien establecidos.
En la aproximación centrada en el modelo, los modelos del sistema tienen un nivel de
3
detalle lo suficientemente completo como para permitir la generación completa de la
implementación del sistema basándose solo en los modelos. El proceso de generación
del código puede llegar a aplicar una serie de reglas de transformación, los cuales
generalmente le permiten al desarrollador la elección entre los distintos patrones que
podrán ser aplicados a los modelos para transformarlos en modelos más complejos o
código.
La última aproximación está basada sólo en modelos, en ésta, los desarrolladores usan
los modelos sólo como ayuda para entender y comprender el negocio o el dominio del
problema, o simplemente para analizar la arquitectura de una solución posible
4
Capítulo 2
Conceptos básicos
Desarrollo de Software Dirigido por Modelos
El Desarrollo de Software Dirigido por Modelos (MDD) y más concretamente la
propuesta MDA (Model Driven Architecture) de OMG constituyen una aproximación
para el desarrollo de sistemas software, basada en la separación entre la especificación
de la funcionalidad esencial del sistema y la implementación de dicha funcionalidad
usando plataformas de implementación específicas.
La iniciativa MDA cubre un amplio espectro de áreas de investigación (metamodelos
basados en MOF, perfiles UML, transformaciones de modelos, definición de lenguajes
de transformación (QVT), construcción de modelos PIM y PSM y transformaciones
entre ellos, construcción de herramientas de soporte, aplicación en métodos de
desarrollo y en dominios específicos, etc.). Algunos de estos aspectos están bien
fundamentados y se están empezando a aplicar con éxito, otros sin embargo están
todavía en proceso de definición. En este contexto son necesarios esfuerzos que
conviertan MDA y sus conceptos y técnicas relacionados en una aproximación
coherente, basada en estándares abiertos, y soportada por técnicas y herramientas
maduras.
Con la generación completa del código, es poco probable, o innecesario la inspección
del código, sólo se tienen los modelos tal como ocurre en la actualidad con los lenguajes
de 3a. generación donde no es necesario inspeccionar el código en ensamblador. Las
herramientas y técnicas para hacer esto posible han llegado a un estado de madurez
donde se ha vuelto práctico incluso para aplicaciones a gran escala. Como parte de este
esfuerzo para hacer más incremental la aceptación del enfoque MDD, la OMG creó una
serie de estándares de soporte a MDD a los cuales agrupo en las especificaciones de
MDA.
Así MDA es un estándar que promueve a MDD y agrupa a varios lenguajes que pueden
ser utilizados para seguir un enfoque dirigido por modelos en una organización, MDA
intenta estandarizar MDD, que durante muchos años ha estado a la deriva. MDA no
define técnicas, etapas ni artefactos, pero si proporciona una estructura tecnológica y
conceptual para poder implementar de manera correcta MDD.
Objetivo del Desarrollo Dirigido por Modelos
El objetivo principal del DSDM lleva a resolver problemas de tiempo, costes y calidad
asociados a la creación de software. En este contexto MDA proporciona un marco de
trabajo en que es posible especificar modelos, en diferentes niveles de abstracción, y
pasar desde un modelo a otro por medio de transformaciones. Dichas transformaciones
de modelos deben ser expresadas de manera clara y precisa usando un lenguaje definido
para ese propósito, como por ejemplo, ATL o QVT.
5
Arquitectura Dirigida por Modelos
Model Driven Architecture (MDA): es la estandarización de la OMG como plataforma
para soportar MDD.
Conceptos básicos de MDA
Algunos de los conceptos más importantes que forman parte de la especificación MDA
son:
Modelo. Es una descripción o especificación mediante un lenguaje visual de un sistema.
Metamodelo. Es la descripción y especificación de los elementos y reglas que se
utilizan para crear modelos semánticamente correctos para un dominio en particular.
También puede definirse como el modelo de un lenguaje de modelado.
Dirigido por modelos (Model Driven). Se dice que es dirigido (o guiado) por modelos
porque provee mecanismos que usan modelos para dirigir el curso del diseño, la
construcción, la implementación, la operación, el mantenimiento y la modificación de
una aplicación. Es decir, el proceso depende de los modelos.
Arquitectura. La arquitectura de un sistema es la especificación de las partes y
conectores del sistema, así como las reglas de interacción éstas.
Vista. Es una representación del sistema desde la perspectiva de un punto de vista
determinado.
Plataforma. Es un conjunto de subsistemas y tecnologías que proveen un conjunto
coherente de funcionalidad que puede ser usada en cualquier aplicación sin tener en
cuenta detalles de cómo la funcionalidad es implementada
Punto de vista. Un punto de vista en un sistema es una técnica de abstracción que
utiliza un conjunto selecto de conceptos arquitecturales y reglas de estructuración, de
manera que se enfoque la atención sólo en un problema particular del sistema. MDA
especifica tres puntos de vista sobre un sistema: el punto de vista independiente de la
computación, el punto de vista independiente de la plataforma y el punto de vista
específico de la plataforma.
• Punto de vista independiente de la computación. Este se enfoca en el ambiente del
sistema y los requerimientos del mismo, es decir, la lógica del negocio. Los detalles de
la estructura y el procesamiento del sistema están escondidos o no han sido
determinados.
• Punto de vista independiente de la plataforma. Se enfoca en la operación del sistema
mientras oculta los detalles específicos para cierta plataforma, es decir, muestra la parte
de la implementación que es idéntica de una plataforma a otra.
• Punto de vista específico de una plataforma. Combina el punto de vista independiente
de la plataforma con el detalle del uso de una plataforma especifica.
Modelo independiente de la computación (CIM Computer Independent Model).
Es una descripción de la lógica del negocio desde una perspectiva independiente de la
computación. Es un modelo del dominio
6
Modelo Independiente de la plataforma (PIM Platform Independent Model). Es
una descripción de la funcionalidad del sistema en forma independiente de las
características de plataformas de implementación específicas
Modelo especifico a una plataforma (PSM Platform Specific Model). Es una vista
del sistema desde el punto de vista de plataforma específica. Un PSM combina las
especificaciones en el PIM con los detalles de como el sistema utiliza un tipo de
plataforma en particular. Es una descripción del sistema en términos de una plataforma
específica. Por ejemplo, .NET, J2EE, relacional,…
Modelo específico de implementación (ISM (Implementation Specific Model) Es
una descripción (especificación) del sistema a nivel de código. Por ejemplo, Java,
C#,etc.
Transformación de modelos. Es el proceso de convertir un modelo a otro modelo del
mismo sistema. Generalmente el PIM es combinado con alguna información adicional
para producir un PSM.
Funcionamiento de MDA
En la actualidad, existe un amplio conocimiento sobre como traducir, por compilación o
interpretación, un lenguaje de alto nivel (Java o SQL) a operaciones que un
microprocesador es capaz de ejecutar. De igual manera, en MDA existen
“compiladores” capaces de traducir modelos de datos o de la aplicación basados en
UML a lenguajes de alto nivel y por lo tanto a las distintas plataformas de los sistemas
actuales, pero más importante, a las plataformas del futuro. La idea es que, como en la
actualidad sucede en la industria automotriz, donde mucho del proceso de desarrollo de
nuevos vehículos se hace en computadoras y simuladores, para después construir las
partes y ensamblar los vehículos de forma automatizada, en la industria de software
suceda algo similar: que el proceso de desarrollo de software se base en modelos en una
7
computadora los cuales, inicialmente, serán PIMs y mediante transformaciones hechas
por la computadora, poder generar los PSMs para una o varias plataformas, y al final
transformar éstos a código que implemente la solución descrita en los modelos.
Si nuevas tecnologías surgen, solo hay que transformar los modelos independientes de
la plataforma a los modelos específicos de la nueva plataforma y regenerar la
aplicación. Si la aplicación requiere integrarse con otras aplicaciones, se modifican los
modelos, y después se regeneran las aplicaciones. Así, entre las metas de MDA se
tienen: la portabilidad, la interoperabilidad y la reutilización. La figura resume el
proceso de desarrollo utilizando MDA. En MDA un desarrollador sólo crea PIMs que
son interpretados por una computadora para generar PSMs y posteriormente el código
para distintas plataformas. De ésta forma el proceso de desarrollo es acelerado de
manera considerable.
Esta es la premisa principal de una arquitectura manejada por modelos, el permitir la
definición de modelos de datos y aplicaciones que puedan ser transformados por una
computadora permitiendo la flexibilidad a largo plazo de:
• Implementación. Nueva infraestructura de implementación puede ser integrada o
generada de los diseños existentes, para después regenerar el código de la aplicación.
• Integración. Se puede también automatizar la producción de puentes de integración de
datos y la conexión entre aplicaciones.
• Mantenimiento. Se da acceso directo a la especificación del sistema, lo que facilita su
mantenimiento, se da mantenimiento a los modelos, no al código.
• Pruebas y simulación. Los modelos pueden ser validados contra los requerimientos,
probados para varias infraestructuras y usados para, de manera directa, simular el
comportamiento del sistema que se está diseñando.
Para utilizar MDA uno de los primeros pasos del proceso es modelar los requerimientos
funcionales del sistema en un CIM, el cual describirá los aspectos relacionados con el
uso de la aplicación, y ayuda a presentar de manera precisa qué es lo que se espera que
el sistema haga, esto será útil no sólo como ayuda para comprender el problema, sino
también como una fuente donde se genera un vocabulario compartido que será utilizado
en otros modelos.
Mas tarde un PIM es desarrollado, éste describe el funcionamiento del sistema pero no
los detalles de su implementación en una plataforma especifica y puede ser creado para
implementar una o más arquitecturas. El arquitecto entonces escoge una o varias
plataformas que le permitan implementar el sistema con las características
arquitecturales definidas, de aquí el arquitecto genera un PSM .
Finalmente el PSM es traducido a código propio de la plataforma especificada. Una
forma de comprender todo el funcionamiento de MDA y sus elementos principales es
8
observando su metamodelo. La figura expresa el metamodelo de la descripción de
MDA, el cual resume todos los elementos que se han mencionado. Se puede apreciar
que la base de todo en MDA es la definición de un metamodelo, es decir, un lenguaje de
modelado, el cual es utilizado para la creación de PIM's, PSM's y CIM's. El metamodelo
de MDA también muestra que para hacer el mapeo entre los distintos modelos es
necesario establecer reglas o técnicas de mapeo entre los distintos modelos.
De manera más sintética, los pasos a seguir en el proceso MDA de desarrollo de
software son los siguientes:
1. Definir un CIM que muestre el sistema dentro del entorno en el que va a operar, este
modelo nos ayudará a entender exactamente lo que el sistema va a hacer
independientemente de cómo se implementará.
2. Construir un PIM, que describe el sistema, pero no muestra los detalles de su
implementación en ninguna plataforma.
3. En este estadío del proceso el arquitecto de software ha de elegir una o varias
plataformas que permitan la implementación del sistema con las cualidades
arquitectónicas deseadas.
4. El arquitecto marca los elementos del PIM para indicar los mappings que han de ser
usados para llevar a cabo la transformación de ese PIM en un PSM; o bien, si se utilizan
transformaciones de metamodelos, se utilizará una máquina de transformación.
5. Transformar el PIM marcado en un PSM –que puede ser realizado manualmente o
con ayuda de una herramienta- ; la entrada de la transformación será el PIM marcado y
el mapping; la salida es el PSM y el registro de la transformación.
6. Un PSM puede proporcionar más o menos detalle, dependiendo de su propósito, ya
que un PIM puede ser una implementación si proporciona toda la información necesaria
para construir un sistema y ponerlo en operación, o bien puede ser el PIM de la
9
siguiente iteración del proceso MDA hasta que se consiga una implementación
adecuada del sistema.
Mapeo y transformación de modelos
El mapeo es un conjunto de reglas y técnicas usadas para modificar un modelo de
manera que se pueda generar uno nuevo. El mapeo es utilizado para transformar de:
• PIM a PIM. Esta transformación es utilizada cuando los modelos son mejorados,
filtrados o especializados durante el ciclo de vida de desarrollo sin necesitar ninguna
información dependiente de la plataforma. Una de las formas de mapeo más obvias es
entre los modelos de análisis y el diseño.
• PIM a PSM. Esta transformación es utilizada cuando el PIM está lo suficientemente
refinado para ser proyectado a una infraestructura de ejecución. La proyección está
basada en las características de la plataforma utilizada.
• PSM a PSM. Esta transformación puede requerirse en la implementación y realización
de componentes. Por ejemplo, el empaquetado de un componente se realiza
seleccionando servicios y configuración. Una vez empaquetado, la entrega del
componente puede ser realizada especificando los datos de inicialización, servidores de
instalación, generación y configuración del contenedor, etc. Esta transformación está
ligada al refinamiento de un modelo PSM a un PSM mejorado y más completo.
• PSM a PIM. Esta transformación puede ser requerida para abstraer modelos de
implementaciones existentes en una tecnología específica a una independiente de la
plataforma. Este procedimiento es sin duda uno de los más complicados y difícilmente
puede ser automatizado.
• PSM a Código. Esta transformación es la última de la cadena y permite generar el
código específico para una plataforma en particular utilizando un PSM. Una vez
mejorados los PSM o actualizados debido al surgimiento de nuevos requerimientos una
transformación de este tipo es necesaria para regenerar el sistema.
Para implementar definir las reglas de transformación de mapeo se requiere conocer los
metamodelos de los modelos de entrada y salida. Las reglas de la ejecución de la
transformación pueden ser generadas utilizando herramientas UML. Existen diversas
formas
de
transformar
PIMs
expresados en UML en su correspondientes PSMs:
1. Una persona puede estudiar el PIM y manualmente construir un PSM y quizás
construir o refinar el mapeo entre los dos.
2. Una persona puede estudiar el PIM y utilizar patrones de refinamiento conocidos para
reducir la carga en la construcción del PSM y la relación entre ambos.
3. Un algoritmo puede ser aplicado al PIM y crear un esqueleto del PSM, el cual sera
mejorado de manera manual, quizás utilizando alguno de los patrones de refinamiento
de 2.
10
4. Un algoritmo puede crear un PSM completo de un PIM detallado. Este deberá de
manera implícita o explícita grabar los patrones de refinamiento para ser utilizados por
otras herramientas automatizadas.
Una consideración adicional es que es más fácil generar código ejecutable de
características estructurales de un modelo que de características de comportamiento. La
automatización de transformaciones es mas trazable cuando la transformación está
parametrizada de alguna manera, como por ejemplo, cuando una persona selecciona
opciones de un conjunto predefinido que determinará como será realizada la
transformación.
Generalmente se debe de realizar un proceso de marcado del PIM, en el cual se
seleccionarán ciertas características no funcionales que se desea tenga el PSM,
características que no pueden ser determinadas con la información que ofrece el PIM.
Las marcas en un modelo también pueden especificar la calidad de la implementación,
estas podrían requerir parámetros, por ejemplo, una marca que indique “soporte de
múltiples conexiones” puede requerir un parámetro que indique el límite máximo de
conexiones que aceptará, o alguno que indique políticas de limite de tiempo (timeout).
Para que las marcas sean utilizadas de manera apropiada es recomendable que sean
estructuradas, limitadas y modeladas, por ejemplo, un conjunto de marcas mutuamente
exclusivas necesitaran ser agrupadas, de manera que el arquitecto sepa que no más de
una de estas marcas puede ser aplicada a la transformación de un mismo elemento.
El mapeo también debe incluir plantillas, que son modelos parametrizados que
especifican tipos particulares de transformaciones, son como patrones de diseño, pero
incluyen especificaciones más detalladas para guiar la transformación. Un conjunto de
marcas en un modelo pueden estar asociadas a una plantilla, de manera que éstas marcas
indiquen que las instancias de un modelo en particular deberán ser transformadas de
acuerdo a ésta platilla. Otras marcas pueden ser utilizadas para llenar parámetros
requeridos por una plantilla.
Métodos específicos de transformación de modelos
Transformación por marcado. En un modelo son colocadas una serie de marcas que
serán utilizadas para guiar la transformación (figura). Una vez que se tiene el modelo
marcado, se aplican reglas de mapeo definidas para una plataforma específica para
transformar el PIM en un PSM.
Transformación por metamodelo. Un modelo es construido usando un lenguaje
independiente de la plataforma especificado por algún metamodelo. Se hace la
11
transformación de este modelo a un lenguaje específico de la plataforma especificado en
algún otro metamodelo. Es decir se transforma de un lenguaje de modelado a otro
(figura). Se tiene un lenguaje de modelado fuente que será transformado en un lenguaje
de modelado objetivo.
Transformación por patrones. Patrones pueden ser utilizados en la especificación del
mapeado (figura). El mapeado incluirá entonces patrones y marcas correspondientes a
elementos de dichos patrones.
Se debe notar que sea cual sea el método de transformación seleccionado para pasar de
un modelo a otro se debe determinar un conjunto de reglas de transformación, en las
cuales se indica que elementos del modelo nuevo serán generados tomando como base
elementos del modelo original. Así el mapeo consiste en determinar estas reglas de
transformación, mapear los elementos de un modelo a los de otro, y de esta forma,
facilitar el proceso de transformación.
Base tecnológica de MDA
MDA esta basado en tecnologías de la OMG (Object Managment Group) que es una
organización no lucrativa encargada de definir estándares en el dominio de la
orientación a objetos. Estas se describen brevemente a continuación a manera de
introducción.
12
UML
El lenguaje de modelado unificado (UML) es un lenguaje de modelado estándar para la
visualización, especificación y documentación de sistemas de software. Los modelos de
MDA pueden ser especificados usando UML. UML resuelve el problema de la
arquitectura, objetos e interacciones entre objetos. Los artefactos capturados en UML
(en términos de casos de uso, clases,diagramas de actividad, etc.) pueden ser exportados
a otras herramientas del proceso de desarrollo usando XMI (XML Metadata
Interchange).
XMI
XMI (XML Metadata Interchange) es un mecanismo para estándar de intercambio de
modelos de manera textual siguiendo un formato XML entre distintas herramientas,
repositorios y middleware. XMI es parte fundamental del mundo del modelado y juega
un rol importante en el uso de XML como parte importante de MDA.
OCL (Object Constraint Language)
En el modelado orientado a objetos, un modelo como el de clases no es suficiente para
lograr una especificación precisa. Puede ser necesario describir características
adicionales sobre los objetos del modelo. Muchas veces estas características se
describen en lenguaje natural. La práctica ha revelado que muy frecuentemente esto
produce ambigüedades. Para escribir especificaciones correctas se han desarrollado los
lenguajes formales.OCL es un lenguaje formal para expresar restricciones libres de
efectos colaterales. Los usuarios de UML y de otros lenguajes visuales pueden usar
OCL para especificar restricciones y otras expresiones incluidas en sus modelos. OCL
tiene características de un lenguaje de expresión, de un lenguaje de modelado y de un
lenguaje formal. Es un lenguaje formal, fácil de leer y escribir. Ha sido desarrollado
como un lenguaje de modelado para negocios dentro de la división de seguros de IBM.
OCL es un lenguaje de expresión puro. Por lo tanto, garantiza que una expresión OCL
no tendrá efectos colaterales; no puede cambiar nada en el modelo. Esto significa que el
estado del sistema no cambiará nunca como consecuencia de la evaluación de una
expresión OCL. Todos los valores de todos los objetos, incluyendo todos los enlaces, no
cambiarán cuando una expresión OCL es evaluada, simplemente devuelve un valor.
OCL no es un lenguaje de programación, por lo tanto, no es posible escribir lógica de
programa o flujo de control en OCL. No es posible invocar procesos o activar
operaciones que no sean consultas en OCL.
Construcción de PIM's y PSM's en UML
El poder de UML (a diferencia de otros lenguajes) radica en que fue definido basándose
en los conceptos más importantes del modelado. Sumado a esto se tiene la ventaja de
que los modelos en UML pueden ser representados tanto de forma gráfica como textual
utilizando XMI, lo que facilita la transformación entre modelos. Los modelos
representados en UML pueden ser muy ricos semánticamente, ya que UML provee
elementos para la definición de restricciones y comportamiento tales como:
• Indicar limitaciones sobre un conjunto de atributos.
• Indicar pre y postcondiciones para especificar métodos.
• Indicar si el valor de un parámetro puede ser nulo.
• Indicar si una operación tiene efectos colaterales.
• Indicar patrones de especificaciones y diseño.
13
Especificar las restricciones en un lenguaje formal (como OCL) en lugar de utilizar
lenguaje normal permite reducir la ambigüedad de la especificación y por lo tanto
facilita la implementación de importantes aspectos:
Provee al programador de instrucciones más precisas, eliminando la probabilidad de que
éste tenga que interpretar las decisiones que tomó el diseñador.
Disminuye la cantidad de trabajo requerido para hacer que diferentes implementaciones
de la misma especificación trabajen juntas, o integrar implementaciones de dos
especificaciones cuyos modelos estan relacionados.
Provee la base para definir pruebas de conformidad para diferentes implementaciones.
Estandariza la especificación de restricciones de manera que herramientas pueden
comunicarse entre si siguiendo este lenguaje. Debido a que UML es un lenguaje
diseñado específicamente para ser independiente de la plataforma resulta una solución
natural para realizar la construcción de PIM’s.
Herramientas MDA
Aunque las herramientas de transformación son el corazón del desarrollo en MDA, no
son las únicas herramientas que éste enfoque requiere. Algunas de las herramientas
necesarias en un ambiente de desarrollo MDA son:
• Editor de código (IDE). Las funciones que proveen los ambientes de desarrollo
integrado (IDE), como la depuración, compilación y edición de código, no deben
pasarse por alto.
• Repositorio de modelos. Una base de datos de modelos.
• Editor de modelos (herramienta CASE). Donde los modelos pueden ser construidos y
modificados.
• Validador de modelos. Los modelos usados para la generación de otros modelos deben
de estar extremadamente bien definidos. Los validadores revisan los modelos contra un
conjunto de reglas (predefinidas o definidas por el usuario) para asegurar que el modelo
está listo para ser usado en una transformación.
• Editor de definición de transformaciones. Un editor para crear y modificar una
definición.
• Repositorio de definiciones de transformación. Un lugar de almacenamiento de las
definiciones de transformaciones que son utilizadas para pasar de modelo a otro.
• Ejecución de modelos. Un motor que provee una plataforma virtual donde se pueden
ejecutar los modelos.
Una parte fundamental de las herramientas que soportan MDA debe ser la capacidad de
dividir los modelos en CIM, PIM y PSMs, así como el marcado de estos y la definición
de las transformaciones, para después generar transformaciones entre modelos y
generación de código a partir de ellos (y no solo a la generación de código a partir del
14
diagrama
de
clases
como
manejan
algunas
herramientas
CASE).
Existen a la vez dos tipos de herramientas MDA, aquellas que generan el código y
aquellas que “ejecutan” el modelo. El código generado del primer grupo de
herramientas tiene que ser en la mayoría de los casos modificado, ya que no es código
terminado que pueda ser compilado y ejecutado (es más bien un 'esqueleto'), eso sin
tomar en cuenta que en la mayoría de los casos los programadores tienden a cambiar la
estructura del código generado, de tal forma que el modelo queda desactualizado.
Algunas herramientas intentan resolver este problema mediante lo que se conoce como
ingeniería inversa, con la cual es posible volver a actualizar el modelo a partir del
código modificado, sin embargo aun así debe de existir disciplina en los cambios para
evitar desincronización entre modelos.
El segundo tipo de herramientas utiliza UML y algunas extensiones del mismo para
modelar a detalle una aplicación de tal forma que el modelo pueda ser ejecutado dentro
de la herramienta.
Algunas de estas herramientas generan código como Java, C++ o algún lenguaje propio
y generan una serie de paquetes que pueden ser ejecutados dentro del servidor de la
misma aplicación. El principal problema de estas herramientas es que el generar un
modelo UML que pueda ser ejecutado no es sencillo, se debe tener un amplio
conocimiento de UML para obtener beneficios reales de una herramienta de este tipo. A
continuación se presenta un conjunto de herramientas encontradas durante el proceso de
investigación para la escritura de este trabajo.
15
Capítulo 3
QVT : el estándar de OMG para transformaciones
Una regla de transformación de modelos debe definir, evitando cualquier ambigüedad,
la relación implícita que existe entre sus partes. MDA no especifica ni prescribe ningún
lenguaje para la transformación de modelos. El estándar actualmente establecido por
OMG para crear consultas, vistas y transformaciones de modelos es QVT (Query,
Views, Transformations). Las transformaciones, en el contexto de QVT se clasifican en
relación (relation) y función (mapping); las relaciones especifican transformaciones
multidireccionales, no permiten crear o modificar modelos, pero sí chequear la
consistencia entre dos o más modelos relacionados. Las funciones, en
cambio, implementan la transformación, es decir, transforman elementos de un dominio
en elementos de otro. Se han propuesto varios lenguajes de transformación: BOTL;
ATL; Tefkat; Kent Model y también el uso de sentencias OCL para especificar las
transformaciones. Todos estos lenguajes asumen que los modelos involucrados en la
transformación cuentan con una definición formal de su sintaxis, expresada en términos
de metamodelos MOF.
“Query-View-Transformations”,da respuesta a la necesidad de transformaciones entre
modelos cuyos lenguajes están definidos con MOF,con los siguientes elementos:
• Query (Consulta): es una expresión evaluada sobre un modelo dado que tiene como
resultado 1 ó más instancias de tipos (del modelo fuente o en el lenguaje de consulta):
• View (Vista): es un modelo derivado completamente de otro modelo. Son más
generales que las Consultas. Suelen ser entidades de sólo lectura.
• Transformation: genera un modelo destino desde un modelo fuente. Las relaciones
especifican las transformaciones y las correspondencias (mappings) las implementan.
Objetivos de QVT
• Requisitos obligatorios:
• Lenguaje de Consulta
• Lenguaje de Transformación del lenguaje fuente al lenguaje destino.
• Definido con metamodelos MOF
• Ejecutable / Transportable versus Caja-Negra XForms
• Definición de vistas
• Transformaciones declarativas / incrementales
16
• Requisitos opcionales:
• Transformaciones bidireccionales
• Registro de las transformaciones
• Reutilización y extensión de transformaciones genéricas
• Las transformaciones con semática de transacciones: commit, rollback.
• Tranformaciones dentro de un Lenguaje específico.
Descripción general de QVT
QVT es el estándar de OMG para transformaciones. Comprende tres diferentes
lenguajes M2M: dos lenguajes declarativos llamados Relations y Core, y un tercer
lenguaje, de naturaleza imperativa, llamado Operational Mappings. La especificación de
QVT define tres paquetes principales, uno por cada lenguaje definido: QVTCore,
QVTRelation y QVTOperational. Estos paquetes principales se comunican entre sí y
comparten otros paquetes intermedios. El paquete QVTBase define estructuras comunes
para transformaciones. El paquete QVTRelation usa expresiones de patrones template
definidas en el paquete QVTTemplateExp. El paquete QVTOperational extiende al
QVTRelation, dado que usa el mismo framework para trazas. Usa también las
expresiones imperativas definidas en el paquete ImperativeOCL. Todos los paquetes
QVT dependen del paquete EssentialOCL de OCL 2.0, y a través de él también
dependen de EMOF (EssentialMOF).
La parte declarativa de QVT está dividida en una arquitectura de dos niveles. Las capas
son:

un lenguaje Relations amigable para el usuario, que soporta pattern matching
complejo de objetos y creación de template para objetos. Las trazas entre
elementos del modelo involucrados en una transformación se crean
implícitamente. Soporta propagación de cambios, ya que provee un mecanismo
para identificar elementos del modelo destino.
17

un lenguaje Core definido usando extensiones minimales de EMOF y OCL. Las
trazas no son automáticamente generadas, se definen explícitamente como
modelos MOF, y pueden crearse y borrarse como cualquier otro objeto. El
lenguaje Core no soporta pattern matching para los elementos de modelos. Esta
propuesta absolutamente minimal lleva a que el Core sea el “assembler” de los
lenguajes de transformación.
Relations
Los modelos tienen nombre, y los elementos que contienen deben ser de tipos
correspondientes al metamodelo que referencian. Es una especificación declarativa de
las relaciones entre modelos MOF. En este lenguaje, una transformación entre modelos
se especifica como un conjunto de relaciones que deben establecerse para que la
transformación sea exitosa.
Relations top-Level
Una transformación puede definir dos tipos de relaciones: topLevel y no topLevel. La
ejecución de una transformación requiere que se puedan aplicar todas sus relaciones
topLevel, mientras que las no topLevel se deben cumplir solamente cuando son
invocadas, directamente o a través de una cláusula where de otra relación:
transformation umlRdbms (uml : SimpleUML, rdbms : SimpleRDBMS) {
Top relation PackageToSchema {…}
top relation ClassToTable {…}
relation AttributeToColumn {…}
}
Una relación topLevel tiene la palabra top antecediéndola para distinguirla
sintácticamente. En el ejemplo de arriba, PackageToSchema y ClassToTable son
relaciones topLevel, mientras que AttributeToColumn es una relación no topLevel, que
será invocada por alguna de las otras para su ejecución.
QVT Operational
Además de sus lenguajes declarativos, QVT proporciona dos mecanismos para
implementaciones de transformaciones: un lenguaje estándar, Operational Mappings, e
implementaciones no-estándar o Black-box.
El lenguaje Operational Mappings se especificó como una forma estándar para proveer
implementaciones imperativas. Proporciona una extensión del lenguaje OCL mediante
el agregado de nuevas construcciones con efectos laterales que permiten un estilo más
procedural, y una sintaxis que resulta familiar a los programadores. Este lenguaje puede
ser usado en dos formas diferentes:


Primero, es posible especificar una transformación únicamente en el lenguaje
Operational Mappings. Una transformación escrita usando solamente
operaciones Mapping es llamada Transformación Operacional.
Alternativamente, es posible trabajar en modo híbrido. El usuario tiene entonces
que especificar algunos aspectos de la transformación en el lenguaje Relations (o
18
Core), e implementar reglas individuales en lenguaje imperativo a través de
operaciones Mappings.
Operational transformations
Una transformación Operacional representa la definición de una transformación
unidireccional, Tiene una signatura indicando los modelos involucrados en la
transformación y define una operación entry, llamada “main”, la cual representa el
código inicial a ser ejecutado para realizar la transformación. La signatura es
obligatoria, pero no así su implementación. Esto permite implementaciones de caja
negra definidas fuera de QVT.
El ejemplo que sigue muestra la signatura y el punto de entrada de una transformación
llamada Uml2Rdbms, que transforma diagramas de clase UML en tablas RDBMS.
La signatura de esta transformación en particular declara que un modelo rdbms de tipo
RDBMS será derivado desde un modelo uml de tipo UML. En el ejemplo, el cuerpo de
la transformación (main) especifica que en primer lugar se recupera la lista de objetos
de tipo Paquete y luego se aplica la operación de mapeo (mapping operation) llamada
packageToSchema() sobre cada paquete de dicha lista. Esto último se logra utilizando la
operación predefinida map() que itera sobre la lista.
Mapping operations
Una MappingOperation es una operación implementando un mapping entre uno o más
elementos del modelo fuente, en uno o más elementos del modelo destino.
Una mappingOperation se describe sintácticamente mediante una signatura, una guarda
(su cláusula when), el cuerpo del mapping y una poscondición (su cláusula where). La
operación puede no incluir un cuerpo (es decir, que oculta su implementación) y en ese
caso se trata de una operación de caja negra (black-box).
Una mapping operation siempre refina una relación, donde cada dominio se corresponde
con un parámetro del mapping. El cuerpo de una operación mapping se estructura en
tres secciones opcionales:



La sección de inicialización es usada para crear los elementos de salida,
la intermedia, sirve para asignarle valores a los elementos de salida
y la de finalización, para definir código que se ejecute antes de salir del cuerpo.
19
La operación mapping que sigue define cómo un paquete UML se transforma en un
esquema
RDBMS.
La relación implícita asociada con esta operación mapping tiene la siguiente estructura:
La relación PackageToSchema indica que el dominio para el modelo “uml” está
marcado como checkonly y el dominio para el modelo “rdbms” está marcado enforce.
Estas marcas habilitan la modificación (creación/borrado) de elementos en el modelo
“rdbms”, pero no en el modelo “uml”, el cual puede ser solamente leído pero no
modificado.
Operational Transformation parte del metamodelo

EntryOperation [0..1]: Una operación actuando como punto de entrada para la
ejecución de la transformación operacional. El nombre de una entry operation es
main.
20




ModelParameter [1..*]: Indica la signatura de esta transformación operacional.
Un parámetro de modelo indica un tipo de dirección (in/out/inout) y un tipo
dado por un tipo de modelo. Cada parametro tiene un tipo de ModelType.
ModelType: Cada parametro de modelo se corresponde a un tipo de modelo que
esta definido por la transformacion. Un tipo de modelo esta definido por el
metamodelo.
VarParameter: un parametro variable es un concepto abstracto que fue
introducido para permitir referenciar parametros de la misma manera que las
variables, especialmente en las expresiones OVL.
RelationalTransformation: es una especialización de Transformation y
representa una definición de transformación escrita en el lenguaje QVTRelation.
21
Capítulo N
Análisis de herramientas para transformación de modelos
ATL es un framework para administrar transformaciones basadas en modelos. Es un
lenguaje mixto, es decir, es una mezcla de construcciones imperativas y declarativas.
Un modelo fuente se transforma en un modelo destino mediante una definición de
transformación escrita en ATL, que también es un modelo. Los modelos fuente, destino
y la definición de la transformación, responden a sus metamodelos respectivos y, a su
vez, todos los metamodelos se ajustan a MOF. La parte básica de ATL incluye todos los
componentes requeridos para configurar y ejecutar transformaciones, en particular, el
EMF (Eclipse Modelling framework) y MDR (Meta Data repository) que permiten,
respectivamente, manejar modelos definidos de acuerdo a la semántica Ecore y MOF.
Para que ATL pueda ejecutar las transformaciones necesita los metamodelos fuente y
destinos en un formato tal que permita dar soporte al metamodelado, dicho formato es el
ecore (metamodelo de EMF).
Para obtener los modelos en formato de ecore, se analizaron diferentes herramientas con
el fin de generar a partir de un archivo de texto, los metamodelos de QVT y Lambda
cálculo.
AMMA (Atlas Model Management Architecture) es una plataforma de gestión de
modelos diseñada y desarrollada por INRIA. Esta plataforma es un plugin de Eclipse.
Está basada en el estándar de la OMG, MOF, y utiliza Ecore como lenguaje de
modelado. MOF propone el modelo MOF como lenguaje abstracto para definir todo
tipo de modelos y “arquitectura de nivel cuatro” que está enfocada a MDA. AMMA
proporciona ATL (Atlas Transformation Language), un lenguaje declarativo e
imperativo (lenguaje híbrido) para la transformación de modelos. A pesar de que no está
basado en el estándar QVT, se utiliza actualmente en numerosos grupos y proyectos de
investigación, e incluso hay proyectos que han utilizado ATL, como el proyecto
ModelWare.
XMI XSLT es un marco de trabajo tecnológico que no está basado en QVT y
proporciona soporte para el manejo de modelos. El uso de esta herramienta permite la
transformación de modelos definiendo los modelos como documentos XMI y utilizando
XSLT para transformar de un documento a otro. El problema que tiene este marco de
trabajo es que la transformación está basada en sintaxis y no en semántica.
Borland Together 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.
22
SmartQVT 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.
Por ser la herramienta que presenta mayor nivel de madurez en la actualidad, se
investigó con mayor profundidad la posibilidad de usar esta herramienta como
generadora de los metamodelos que luego serían el punto de partida de las
transformaciones ejecutadas con ATL.
SmartQVT, es un plugin de eclipse que permite, a partir de un archivo escrito en
lenguaje QVT, generar los metamodelos y ejecutar las transformaciones escritas entre
los mismos.
Por la madurez y la posibilidad de generar los metamodelos que presenta la herramienta,
se decidió realizar una investigación más profunda acompañada de pruebas con
ejemplos concretos para ver el funcionamiento de la misma.
La herramienta trabaja en dos etapas, en una primera etapa, genera a partir de un
archivo escrito en lenguaje QVT (en el cual se escribió únicamente la estructura de
ambos metamodelos) un árbol sintáctico que representa dichos modelos. En una
segunda etapa, genera a partir del árbol sintáctico antes generado, las clases java
correspondientes a cada elemento del metamodelo. El hecho de que esta generación
automática se realizara en dos etapas, nos permitió pensar que podríamos usar la
herramienta solo en su primera etapa, es decir generar solo el árbol sintáctico que luego
urtilizaríamos en ATL. El inconveniente es que el archivo obtenido, es generado en un
formato interno de la herramienta, es decir, un formato que sólo es útil dentro de la
herramienta. Investigamos diferentes maneras de serializar dicho archivo para
convertirlo a un xml o un ecore, pero no tuvimos éxito en las pruebas y por tal motivo
se descartó el uso de SmartQVT.
openArchitectureWare es un generador de entornos de trabajo modular implementado
en Java. Esta herramienta ofrece soporte a la trasformación de un modelo a otro, de
texto a modelo, y de modelo a texto. Está basado en la plataforma Eclipse y soporta
modelos basados en EMF pero puede trabajar con otros modelos.
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.
GME (Generic Modelling Environment) es un conjunto de herramientas
configurables para crear modelos de diseño específico. Para crear uno de dichos
modelos es importante tener en cuenta que el peso de la correcta definición del dominio
recae sobre el metamodelo, es decir, en la configuración del metamodelo se debe
modelar el dominio correcto de la aplicación. El metamodelo de entrada debe contener
23
toda la sintaxis, semántica e información del dominio; conceptos que serán utilizados
para construir modelos, ver qué relaciones pueden existir entre ellos, cómo pueden estar
organizados y cómo los verá el ingeniero de modelos. El metamodelo también debe
contener
las
reglas
que
gobiernan
la
construcción
de
modelos.
El lenguaje de metamodelado está basado en los diagramas de clases UML y en las
restricciones OCL. Lo metamodelos que especifican el modelo se utilizan para generar
automáticamente un entorno de dominio específico. Este entorno se utiliza después para
construir modelos específicos de dominio que se almacenan en una base de datos de
modelos o en formato XML. Estos modelos se utilizan para generar automáticamente
las aplicaciones.
GME tiene una arquitectura modular y extensible. GME es fácilmente extensible; los
componentes definidos fuera del ámbito de la herramienta y utilizados para la extensión
de la misma pueden escribirse en cualquier lenguaje que soporte COM (C++, Visual
Basic, C#, Python etc.). GME tiene muchas características avanzadas y dispone de un
elemento ya integrado que impone todas las restricciones de dominio durante la
construcción de los modelos, denominado “director”. GME soporta múltiples aspectos
del modelado como son la combinación de lenguajes de modelado y el soporte de
bibliotecas de modelos para su reutilización.
GMF (Graphical Modelling Framework) proporciona un generador de modelos.
GMF está embebido en Eclipse, plataforma de desarrollo que permite la ejecución de
los editores gráficos generados por GMF a partir de un modelo. Eclipse está construido
y trabaja en Java. GMF está basado en EMF (Eclipse Modelling Framework) y en GEF
(Graphical Eclipse Framework), ambos proporcionados por la plataforma Eclipse. En
GMF se ha adoptado el término “toolsmith” para referirse a los desarrolladores que
utilizan la herramienta para construir extensiones que posteriormente se integran como
parte de la misma. Estas extensiones reciben el nombre de plugins. Otro término,
“practitioner”, se utiliza para referirse a aquellos que utilizan los plugins como medio
para el desarrollo. Durante la utilización de GMF para la generación de un modelo, la
descripción del modelo se realiza una sola vez, al comienzo. Una vez realizada la
especificación del dominio, la herramienta se encarga de interpretar las
correspondencias con el modelo durante el resto de proceso de generación del editor.
24