Tecnologias MDA

MDA está compuesto de varias tecnologías que le permiten llevar a cabo el enfoque de transformaciones entre modelos de forma automática, además de la validación y ejecución de los mismos. En este articulo estudiaremos las mas importantes, las cuales citamos a continuacion.

Meta Object Facility (MOF)

Meta Object Facility (MOF) sirve como manejador de metadatos para MDA. Surge de la necesidad de estandarizar el intercambio de datos entre aplicaciones MDA, se encarga de definir datos acerca de los datos, es esencial para la especificación de las estructuras y el significado de los datos. MOF provee un estándar para especificar metamodelos, por ejemplo un meta-metamodelo, el cual es la raíz de la jerarquía de metamodelado, como se describió en el articulo anterior. MOF es reflexiva que significa que por sí mismo puede definirse con el mismo MOF.

Son importantes los mapeos que realiza MOF para manejar el intercambio de metadatos y su manipulación y de esta forma convertirse en el pilar de un exitoso uso de MDA. Para la interoperabilidad de las herramientas de UML, el mapeo al formato XMI (XML Metadata Interchange) es esencial.  Los detalles acerca del mapeo a DTD (XML Document Type Definitions)  y a definiciones de esquemas XML (XML Schema definitions) pueden revisarse en Unified Modeling Language (UML), Version 2.0 . También existen otro tipo de mapeos habilitados para el lenguaje de programación Java denominado JMI (Java Metadata Interface).

Las especificaciones de MOF están divididas en dos paquetes. El paquete EMOF (Essential MOF) y el paquete CMOF (Complete MOF),  que corresponden a diferentes niveles de interoperabilidad de las herramientas. EMOF por ejemplo compromete las capacidades del núcleo del metamodelado de MOF y está estrechamente relacionado a las facilidades encontradas en los lenguajes de programación orientados a objetos. El objetivo principal de EMOF es el de permitir metamodelados simples que son definidos con conceptos simples mientras que los metamodelos CMOF pueden expresarse como metamodelos EMOF usando los mecanismos de extensión de EMOF (muy similar a los perfiles de UML).

 Arquitectura MOF

Estructura de Metamodelado MOF

Unified Modeling Language (UML)

Hablar de UML, es mencionar que se trate del lenguaje de propósito general para el modelado de sistemas de software más ampliamente reconocido y adoptado, es el lenguaje de modelado estándar para especificar, visualizar y documentar los sistemas. Es extensible, esto significa que provee mecanismos para personalizar el lenguaje de modelado, el resultado de esta personalización son los perfiles UML (UML profiles). La sintaxis abstracta de UML se especifica utilizando metamodelos MOF. También UML puede ser usado para modelar aspectos estáticos y dinámicos de los sistemas. Un modelo UML puede editarse utilizando una herramienta de modelado generalmente a través de diagramas, que se conocen como vistas del modelo UML. La especificación  del metamodelado de UML 2  se estructura en las siguientes partes:

• La infraestructura, define el núcleo de conceptos estáticos de UML, como ser la definición de clases y asociaciones. Esta especificación es reutilizada para la especificación de la capa M3 de MOF es decir el meta-metamodelo, al cual la especificación de infraestructura le adiciona nuevos conceptos como son los casos de uso o las actividades.
• El lenguaje OCL (Object Constraint Language), es un lenguaje de definicion formal para escribir expresiones en los modelos UML en base a reglas, las expresiones pueden representar invariantes, precondiciones, postcondiciones, inicializaciones, guardias, reglas de derivación, así como consultas a objetos para determinar sus condiciones de estado.
• La superestructura, se organiza en paquetes como por ejemplo Clases, Casos de Uso Actividades, Acciones, etc. Cada paquete está dividido en diferentes niveles de complejidad.

 Superestructura UML 2, paquetes de nivel superior

Extensiones de UML

Las extensiones de UML (UML Profiles) se basan en modificaciones al metamodelo de UML, es decir que la semántica original del modelado de elementos cambia, este cambio puede acarrear diferentes complicaciones como por ejemplo la incompatibilidad en las herramientas de UML. Las extensiones se pueden dividir en extensiones ligeras y extensiones pesadas.

Ejemplo de Extensiones UML

Las extensiones ligeras son usualmente conocidas como “perfiles UML” y se basan en los mecanismos de extensión de UML. Un perfil consiste en un número de “estereotipos” (stereotype), los cuales representan extensiones de las metaclases de UML. Por otro lado los estereotipos por si mismos son especializaciones de clases y por lo tanto contienen atributos conocidos como “value tags”. El efecto de nuevas meta-asociaciones entre profiles puede almacenarse de forma limitada adicionando nuevos constraints en el perfil (profile) que especializan el uso de alguna asociación del metamodelo de referencia, o extendiendo la metaclase de “dependencia” (dependency) con un estereotipo y definiendo constraints específicos en ese estereotipo.

Desafortunadamente, las capacidades de modelado de las herramientas UML tienen que ser adecuadas cuando se define un nuevo perfil UML. Por el momento, no es posible definir relaciones de dependencia entre cualquier tipo de elementos de modelado, como por ejemplo entre propiedades que son miembros de una asociación. Sin embargo, una solución más pragmática es el uso de nombres calificados de elementos de modelado para referencias a terminaciones de meta-asociaciones.

Las extensiones pesadas son conocidas como “extensiones perfiladas” (profiliable extensions o extensiones UML), lo que significa que es posible mapear el metamodelo a un perfil UML. Por lo tanto las herramientas de modelado UML que soportan perfiles UML, estereotipos,  “tagged values” y constraints OCL pueden ser usadas para crear modelos que extiendan un metamodelo. 

Adicionalmente pueden definirse meta-transformaciones, las cuales pueden transformar hacia atrás o hacia adelante desde una definición de perfil UML a una definición de metamodelo pesado. La siguiente figura ilustra este tipo de transformaciones. 

Transformaciones entre metamodelos y perfiles UML

Object Constraint Language OCL

El Object Constraint Language OCL es un lenguaje formal para definir restricciones (constraints) en diferentes modelos UML. El lenguaje es muy poderoso, porque puede usarse en diferentes capas del modelado. Por ejemplo, en la capa de modelo un modelador de negocios puede usar OCL para especificar restricciones de negocio. En el metamodelado, OCL ha mostrado su importancia porque permite definir restricciones semánticas mucho más claras y sin ambiguedad que solo usando la notación grafica de UML. 

En los últimos años, el “núcleo grafico” de UML ha sido aceptado por una gran parte de desarrolladores de Software como herramienta de visualización y de documentación en el análisis y diseño. Sin embargo, el lenguaje formal OCL ha sido usado predominantemente para objetivos académicos. Pensamos que una razón para que ocurra este fenómeno es por la ausencia de herramientas adecuadas. Por otro lado, OCL incita cierto miedo a los usuarios para aprenderlo y aplicarlo como un lenguaje. Sin embargo, estamos seguros que OCL es comprensible y adiciona precisión y detalle a los modelos de Software.

Es también menester mencionar que la notación grafica de UML carece de formalismo semántico, OCL puede verse como un método semántico formal que se le añade a UML para hacerlo más atractivo y proveerle de descripciones lógico-matemáticas formales.

OCL como lenguaje formal puede especificar restricciones de tipo: invariante, pre- y post- condiciones, como también describir guardas y restricciones en operaciones. Las expresiones OCL no tienen efectos adversos, esto significa que cuando son evaluados el estado del sistema no cambia . Ya que OCL es un lenguaje tipado, las expresiones tienen un tipo bien definido, aunque algunas de ellas pueden resultar de un tipo no definido.

Para explicar algunas características de OCL, consideremos el siguiente diagrama de clases para un sistema de control de Recursos Humanos en Proyectos de Desarrollo de Software, que contiene las clases: Company, Person, Department, Job y Project.

Diagrama de Clases Sistema Recursos Humanos

Empecemos considerando una invariante (inv) sobre la clase Job (context Job). La siguiente restricción indica que el atributo salary del objeto actual de la clase Job debe ser mayor que 1000.

context Job inv:

self.salary> 1000

Para ver como OCL puede trabajar como un lenguaje de navegación, accediendo a objetos a través de las asociaciones entre clases, usamos la siguiente invariante: al navegar a través de la clase Department a la clase Project (self.projects), contar cuantos proyectos tiene asociada la clase Department (size()), e indicar que este monto sea menor o igual a 10.

context Department

inv: self.projects->size() <= 10

La siguiente restricción OCL asegura que todas las personas que trabajan en un proyecto deben finalizarlo.

context Person

inv projectFinished:

self.worksOn->forAll(p: Project | p.isFinished() = false)

En OCL las condiciones pre y post se manifiestan explícitamente usando las palabras reservadas pre y post. Por ejemplo, el método hire requiere que una persona (p) no debe ser (exclude(p)) un empleado (self.employees) provista por la clase HumanResources. Si la pre-condicion se cumple entonces la persona ahora debe ser incluida (including(p)) en la colección de empleados de la clase HumanResources.

context HumanResources::hire(p: Person)

pre: self.employees->exclude(p)

post: self.employees->including(p)

Query/Views/Transformations QVT

QVT se origina en el documento Requests for Proposals de OMG para MOF 2.0. De ocho secciones presentadas las más prometedoras fueron QVT-P y ATL que fueron enviadas por el grupo QVT-Merge. La primera versión del estándar QVT está actualmente en la fase de finalización. El estándar QVT es un lenguaje de transformación hibrido que contiene especificaciones declarativas e imperativas, la parte declarativa está dividida en una arquitectura de dos niveles, estas capas son:
Un metamodelo de usuario llamado de Relaciones (Relations) y su correspondiente lenguaje que soporta búsqueda y emparejamiento de patrones de objetos complejos y creación de templetas de objetos. La trazabilidad entre los elementos involucrados en la transformación son creados implícitamente.

Un metamodelo llamado Núcleo (Core) y su correspondiente lenguaje, definido usando extensiones mínimas de EMOF y OCL. La trazabilidad de todas las clases son explícitamente definidas como modelos MOF, y las instancias de trazabilidad para la creación y eliminación se definen de la misma forma como la creación y eliminación de cualquier otro objeto.

Las Relaciones (Relations) pueden mapearse al modelo Core, que representa el lenguaje declarativo de bajo nivel de QVT para la ejecución de una maquina que implemente la semántica del Core. El lenguaje Core solo soporta búsqueda de patrones sobre un conjunto amplio de variables mediante la evaluación de condiciones sobre dichas variables a lo largo del conjunto de modelos. Todos los elementos del modelo tanto orígenes como destinos son tratados simétricamente.

Debido a que los modelos Relations pueden mapearse a modelos Core, este se usa principalmente para implementar la parte declarativa de QVT. Como en ATL (véase la próxima sección) existe una analogía entre Java y la Java Virtual Machine: Relations corresponde al lenguaje Java y el Core a la Java Virtual Machine que ejecuta una transformación o programa respectivamente. Las transformaciones que mapean modelos Relations a modelos Core juegan el rol del compilador Java.
Existen dos mecanismos para invocar implementaciones imperativas de transformaciones desde Relations o desde Core: un lenguaje estándar, llamado Mapeo Operacional (Operational Mappings) que usa OCL, y uno no estándar llamado Implementaciones de Caja-Negra (Black-box Implementations) que usa operaciones MOF 2.0. También existe un mapeo uno a uno (one-to-one) entre operaciones de implementaciones imperativas a relaciones existentes en el modelo Core, esto significa que aun si solo la parte imperativa de QVT es usada, entonces siempre existe una especificación declarativa implícita que se refina por la implementación imperativa. La siguiente figura ilustra las diferentes partes de QVT:

Relaciones entre partes de QVT

Ejemplos y tutoriales  de QVT pueden encontrarlos en SDO Wiki. Un tutorial de QVT Relations pueden encontrarlo en http://projects.ikv.de/qvt/wiki/tutorial. Para usar QVT Relations pueden instalarse Medini QVT plugin para Eclipse http://projects.ikv.de/qvt.

El siguiente ejemplo usa dos reglas que mapean paquetes y su contenido de clases UML a clases Java:

relation Package2Package

{

checkonly domain uml p : Package

{

name = pn

}

enforce domain java jp : Package

{

name = pn,

isImported = false

}

}

relation Class2JavaClass

{

checkonly domain uml c : Class

{

name = cn, package = p : Package {}

}

enforce domain java jc : JavaClass

{

name = cn, package = jp : Package {}

}

when

{

Package2Package( p, jp );

}

}

Uso de reglas QVT con parte when para mapear paquetes y clases UML a paquetes y clases Java.

Atlas Transformation Language ATL

AtlasTransformation Language, es la respuesta del grupo de investigación ATLAS INRIA & LINA al documento de propuesta de la OMG MOF/QVT RFP. Es un lenguaje de transformación de modelos, en el campo de MDA, ATL provee a los desarrolladores un medio para producir un número de modelos destino desde un conjunto de modelos origen.

El lenguaje ATL es hibrido con programación declarativa e imperativa. El estilo preferido para escribir transformaciones es el declarativo, ya que permite expresar mapeos simples entre elementos origen y destino del modelo. Sin embargo, ATL también provee constructores imperativos a fin de facilitar la especificación de mapeos que pueden expresarse con mucho trabajo declarativamente.

Un programa de transformación ATL está compuesto de reglas que definen como los elementos del modelo origen son emparejados y navegados para crear e instanciar los elementos del modelo destino. Además del modelo básico de transformaciones, ATL define un modelo adicional de consulta que permite especificar peticiones a los modelos. ATL también permite la factorización de código a través de la definición de librerías ATL.

Desarrollado bajo la plataforma Eclipse, el ATL Integrated Development Environment (ATL IDE) provee una seria de herramientas de desarrollo estándares (verificador de sintaxis, depurador, etc.) cuyo objetivo es el de diseñar transformaciones ATL de manera simple. El ambiente de desarrollo de ATL también ofrece un número de facilidades adicionales dedicadas al manejo de modelos y metamodelos. Estas características incluyen una notación textual simple dedicada a la especificación de metamodelos, pero también de un número de enlaces o puentes estándares entre sintaxis comunes y su correspondiente representación en el modelo.

Para introducir los conceptos básicos de ATL, consideremos un pequeño ejemplo de transformación, donde se requiere transformar un metamodelo de Autores (Author) a un metamodelo de Personas (Person), la siguiente figura ilustra el ejemplo mencionado:

Metamodelo de Autores y Personas.

Como se observa, en ambos modelos se tiene el mismo número y nombre de propiedades (name, surname, gender y age). El objetivo será el de diseñar una transformación ATL que permita generar un modelo para Person a partir del modelo Author. La transformación se diseñara implementando las siguientes semánticas (muy simples y obvias): (ATLAS.group, LINA, INRIA, & Nantes, 2005).

• Cada elemento de Person se genera a través de los elementos de Author;
• El nombre (name) de la Persona generada tiene que ser inicializada con el nombre del Autor
• El apellido (surname) de la Persona generada tiene que ser inicializada con el apellido del Autor.

La siguiente figura, provee una vista del proceso de transformación del modelo Author al modelo Person:

Resumen de la transformación ATL de Author a Person.

El codigo ATL que ejecuta la transformacion sera el siguiente:

module Author2Person;  -- Module Template

create OUT : Person from IN : Author;

rule Author {

from

 a : Author!Author

 to

 p : Person!Person (

 name <- a.name="" span="">

 surname <- a.surname="" span="">

 )

}

Resumen

El presente articulo introdujo al lector en las tecnologias mas importantes que utiliza MDA de manera teorica y abordando los aspectos mas relevantes de cada una, para siguientes articulos mostraremos el Eco-Sistema de herramientas existentes en MDA, estudiaremos a mayor detalle el lenguaje ATL y comenzaremos con tutoriales de aplicaciones MDA especificas.



Hasta la proxima...