1. No category

Taller de Ingeniería Dirigida
por Modelos (TMDE)
Transformaciones de Modelos
Objetivos de hoy
• Comprender la importancia y rol de las
transformaciones de modelos en MDE
• Introducir las transformaciones modelto-model (M2M)
• Introducir las tecnologías que permiten
su aplicación práctica
jueguemos a… mejor no
Transformaciones
• El concepto de transformación no es nuevo
• La computación puede verse como un proceso
de transformación de datos
• En MDE encontramos:
– Generación de modelos a más bajo nivel, y
finalmente código, a partir de modelos a alto nivel
– Sincronización y mapping entre modelos al mismo o
diferentes niveles de abstracción
– Creación de vistas basadas en consultas a un
sistema
– Aplicación a la ingeniería inversa para obtener
modelos de alto nivel a partir de otros de bajo nivel
Transformación de Modelos
• En términos generales pueden verse como
programas que toman un modelo (o más de
uno) como entrada y devuelven otro modelo
(o más de uno) como salida
Transformación de Modelos
• Los modelos de origen y
destino conforman con
metamodelos
Object Management Group. Query/View/Transformation Specification Version 1.1, 2009
Transformación de Modelos
• Las transformaciones se suelen
definir como un conjunto de
reglas que describen la
correspondencia entre elementos del
metamodelo origen y del metamodelo destino
relation ClassToTable {
cn : String;
domain uml c : Class { name = cn };
domain rdbms t : Table { name = cn };
}
Transformación de Modelos
• El motor interpreta las reglas y
ejecuta la transformación sobre
un modelo de entrada
(o verifica la correspondencia entre pares)
Clasificación
• Transformaciones verticales
– Relacionan modelos con distintos niveles de
abstracción y pueden aplicarse tanto en sentido
descendente como ascendente
– Ejemplos: Clases a Tablas, BPMN a SoaML
• Transformaciones horizontales
– Relacionan modelos que describen un sistema
desde un nivel de abstracción similar.
– Ejemplos: Refactoring, consistencia de códigos
entre diferentes lenguajes de programación
Clasificación
• Por tipo de lenguaje: declarativos,
imperativos o híbridos (ambos tipos de
forma combinada)
• Direccionalidad:
– Transformaciones unidireccionales: las
reglas se ejecutan en una sola dirección.
– Transformaciones bidireccionales: se
pueden aplicar en ambas direcciones
Clasificación
• Dependiendo de los modelos origen y destino
– Transformaciones exógenas: los metamodelos origen
y destino son distintos. (ej. Clases a Tablas)
– Transformaciones endógenas: los metamodelos
origen y destino son el mismo (son llamadas
transformaciones in-place) (ej. Refactoring)
• Dependiendo del tipo de modelo destino
– Transformaciones modelo a modelo (M2M): generan
modelos a partir de otros modelos.
– Transformaciones modelo a texto (M2T): generan
cadenas de texto a partir de modelos.
Mecanismos de Transformación
• Manipulación directa
– Implementación de las reglas de transformación
desde cero, en un lenguaje de programación de
propósito general como Java
• Operacional
– Similar a la manipulación directa pero ofrece soporte
más orientado a transformación de modelos
– Una solución típica es extender la sintaxis de un
lenguaje de modelado mediante el agregado de
facilidades para expresar las transformaciones, ej:
OCL con constructores imperativos
– Lenguajes: Operational Mappings de QVT y Kermeta
Mecanismos de Transformación
• Relacional
– Reglas declarativas como relaciones matemáticas entre
elementos de los metamodelos origen y destino
– Soportan naturalmente reglas multi-direccionales
– Lenguajes: Relations de QVT, Tefkat
• Basada en transformaciones de grafos
– Basadas en la teoría de transformaciones de grafos
tipados, etiquetados y con atributos
– Lenguajes: AGG, VIATRA
• Híbrida
– Combinan diferentes técnicas (como componentes
separados o unificados)
– Lenguajes: QVT, ATL
Requisitos de Lenguajes M2M
• Suele requerirse que las reglas tengan la habilidad
de determinar qué elementos ya han sido
calculados por otras reglas. El motor debe tener la
habilidad de hacer un registro de la traza de la
transformación
• Si luego de transformado el modelo origen sufre
modificaciones, la propagación de cambios sobre el
modelo destino debería realizarse sólo donde
corresponda (en lugar de regenerar todo el modelo
destino desde cero). Se necesita un mecanismo de
identificación sobre el modelo destino (la traza
suele contener esta información)
Requisitos de Lenguajes M2M
• En ciertos casos una transformación puede ser
usada para verificar si dos modelos preexistentes
satisfacen la relación y opcionalmente modificar el
modelo destino para que la misma se cumpla. La
transformación puede no haberse ejecutado nunca
(no es propagación de cambios)
• Si el modelo fuente es muy grande y es necesario
propagar cambios, debería ser posible realizar un
análisis de impacto para saber cuáles reglas de la
transformación deben ser ejecutadas y sobre qué
elementos del modelo origen se aplicarán. Esto
suele llamarse actualización incremental
Requisitos de Lenguajes M2M
• Puede requerirse que los modelos destino sean
modificados manualmente luego de generados. El
motor debería respetar estos cambios en caso de
producirse una nueva transformación. Este
problema se conoce como política de conservación
• Los elementos del modelo destino pueden ser
construidos incrementalmente. Por ejemplo,
ciertos elementos son transformados en otros en
una primera fase, y en una segunda las relaciones
entre ellos se transforman en relaciones entre los
elementos generados previamente
Requisitos de Lenguajes M2M
• Las transformaciones bidireccionales se definen
sólo para describir una relación de isomorfismo. Se
logran escribiendo dos o más transformaciones
unidireccionales, o una transformación que pueda
ejecutarse en ambas direcciones (posible sólo en un
escenario declarativo)
• Los lenguajes deben permitir definir una
transformación compleja en términos de otras más
simples
• Si bien las transformaciones pueden implementarse
utilizando un enfoque de manipulación directa, esto
no satisface los requisitos mencionados. Por ello se
han definido lenguajes específicos para M2M
QVT-Relations
QVT-Relations
• Query/Views/Transformations
http://www.omg.org/spec/QVT/1.1/
• La propuesta es híbrida
– Relations: lenguaje declarativo basado en
relaciones entre los elementos
– Core: lenguaje declarativo simplificado
– Operational Mappings: lenguaje imperativo
que extiende Relations
QVT-Relations
• Lenguaje declarativo basado en relaciones
definidas sobre los elementos del metamodelo
• Define patrones que pueden ser detectados e
instanciados (pattern matching)
• Manipulación automática de trazas de
transformación
• Escenarios soportados:
– Check-only (verifica si los modelos se corresponden)
– Transformaciones multidireccionales
– Actualización incremental de modelos existentes
QVT-Relations :: Relación
• Una transformación es definida como un
conjunto de relaciones entre los metamodelos
de origen y destino
transformation uml2rdbms(uml:UML, rdbms:RDBMS){}
• Una relación declara restricciones que deben
ser satisfechas por los elementos de los
modelos candidatos
– Domains
– When Pattern
– Where Pattern
QVT-Relations :: Dominios
• Variables se pueden asociar a elementos de un
modelo de un tipo determinado
• Un dominio tiene patrones: conjunto de
variables y restricciones que los elementos de
un modelo asociados a dichas variables deben
satisfacer para calificar como un patrón válido
relation PackageToSchema{
pn : String;
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
QVT-Relations :: When/Where
• When: especifica pre-condiciones que debe
satisfacer una relación
• Where: especifica las condiciones que deben
ser satisfechas por todo elemento participante
de la relación (post-condiciones)
• La cláusulas when y where pueden contener
expresiones OCL arbitrarias además de las
expresiones de invocación de relaciones
QVT-Relations :: Ejemplo
top relation ClassToTable {
cn : String;
top: se debe
checkonly domain uml c : Class {
cumplir siempre
namespace = p:Package{},
kind = 'Persistent',
name = cn
checkonly: verifica si existe
};
un match válido
enforce domain rdbms t : Table {
schema = s:Schema{},
name = cn,
enforce: el modelo es
};
modificado para satisfacer
la relación
when { PackageToSchema(p, s); }
where { AttributeToColumn(c, t); }
}
Bibliografía
1.
2.
3.
4.
M. Brambilla, J. Cabot, M. Wimmer (2012). Model-Driven Software
Engineering in Practice. Morgan Claypool. ISBN: 9781608458820
K. Czarnecki, S. Helsen. Feature-based survey of model transformation
approaches. IBM Systems Journal, 45(3):621–646, 2006
F. Durán, J. Troya, A. Vallecillo. Desarrollo de software dirigido por
modelos. Universitat Oberta de Catalunya
C. Pons, R. Giandini, G. Pérez. Desarrollo de software dirigido por
modelos: conceptos teóricos y su aplicación práctica. Universidad
Nacional de La Plata.
Epílogo…
• Identifiquen 2 cosas que se llevan de ésta clase
• Para las próximas clases
– Miércoles 1 de junio (Lab) :: Metamodelado en EMF
+ Transformaciones de Modelos en MediniQVT
– Lunes 6 de junio (Teo) :: Control de lectura sobre
transformaciones M2T