Transformaciones de modelos

Prof. Dr. Ricardo TESORIERO – Departamento de Sistemas Informáticos- Universidad de Castilla-La Mancha
[ricardo.tesoriero@uclm.es]
Métodos Avanzados de Desarrollo de Software
Asignatura Optativa de 4º Año
Grado en Informática
Departamento de Sistemas Informáticos
Universidad de Castilla-La Mancha
Métodos avanzados de
desarrollo de software
Tema VII: Arquitecturas dirigidas por Modelos.
Transformaciones de modelos

Índice
• Repaso
• Motivación
• Definición
• Ejemplo informal
• Modelo de análisis
• Modelo de diseño
• Reglas de transformación
• Funciones de transformación
• Escenarios de transformación
• Refinamiento
• Abstracción
• Representación
• Migración
• Mezcla

Repaso
Capas de abstracción
CIM
PIM
PSM
ISM
ABSTRACTO
CONCRETO
Transformación
Transformación
Transformación
CIM
PIM
PSM

Repaso
Transformación de modelos
Figura basada en la presentada en [1].

PIM a PSM
PIM sin marcar
PIM sin marcar
Marcas para la
Plataforma A
Marcas para la
Plataforma B
PIM sin marcar
Marcas para la
Plataforma A
Marcas para la
Plataforma B
PIM sin marcar
Marcas para la
Plataforma A
Marcas para la
Plataforma B
PSM sin
marcar para la
Plataforma A
PSM sin
marcar para la
Plataforma B
Transformación Transformación

Motivación
Ejemplo
• Consideremos:
• Un modelo independiente de la plataforma, modelado:
• Sin referencia a la distribución de objetos
• Ni al acceso remoto
• Una tecnología que ofrece el acceso remoto a los objetos.
• Asumamos que queremos que el diseño utilice el acceso
remoto , por completo => todo acceso es remoto.
• En una propuesta tradicional basada en código,
modificaríamos el modelo independiente de la plataforma
para mostrar el acceso a los objetos remotos

Motivación
Consecuencias
• Este modelo modificado sería tratado como un modelo de
diseño.
• El mismo modelo tiene información
• del modelo de la aplicación
• del modelo de la implementación
• Algunos procesos tratan este modelo como una única
expresión del sistema.
• => Mezclan los detalles de implementación, con los de la
aplicación
• => la imposibilidad de cambiar la plataforma.
• Otros retienen ambos modelos
• => lo que puede llevar a divergencias entre ambos.

Transformación de modelos
• Para evitar estos problemas, MDA mantiene una función de mapeo (o
transformación) que transforma el modelo origen en el modelo destino
• Es una solución a:
• los problemas de mezcla de código
• de divergencia de modelos
• ¿Por qué?
• El modelo destino no se modifica, se genera.
• Las dos características principales del modelo de transformación son:
• la construcción
• la sincronización
• Las transformaciones se usan para construir modelos destino, desde
modelos fuente.
• Las transformaciones son aplicaciones de funciones de transformación,
definidos en términos de:
• Las reglas de transformación representan decisiones de diseño
repetibles.

Un ejemplo informal
• Veamos la transición entre un modelo de análisis y un modelo de
diseño
• Asumamos también que el modelo de análisis contiene los
elementos Banco, Cliente, Cuenta y Transferencia
• Notemos que hay información de la aplicación que tiene que
sobrepasar el tiempo de vida de la aplicación, mientras hay otras
que no.
• Los EJBs proveen dos formas de beans:
• Entity Bean (POJO Persistente @Persist en JEE5/6 de la JPA)
• Objeto accesible remotamente que guarda su estado en una base de
datos
• Stateful Session Bean
• Objeto accesible remotamente que «vive» lo que «vive» un cliente (ej.
sesión Web)

Información del modelo de análisis
• Un Banco
• Conoce sus Clientes y Cuentas
• Puede establecer y romper las relaciones con sus Clientes
• Un Cliente
• Sabe su nombre
• Puede abrir Cuentas
• Puede cerrar una Cuenta que le pertenece
• Conoce las Cuentas que le pertenecen
• Puede hacer una Transferencia de una cantidad de dinero desde
una Cuenta que le pertenece a otra Cuenta.

• Una Cuenta
• Conoce su número de cuenta
• Conoce su balance
• Conoce el Cliente que le pertenece
• Puede retirar un monto de dinero de su balance
• Puede depositar un monto de dinero en su balance
• Una Transferencia
• Conoce el monto de dinero a transferir
• Conoce las Cuentas fuente y destino
• Ejecuta la retirada de un monto especificado de dinero de la
Cuenta fuente y lo deposita en la cuenta destino

Paso del análisis al diseño
Respecto del tiempo de vida de estos elementos:
• El Banco existe el mismo tiempo que existe el sistema
• El Cliente existe desde el momento que establece una relación
con el Banco hasta el momento que cierra todas sus cuentas y
termina su relación con el Banco
• Una cuenta existe desde el momento que se abre hasta el
momento que se cierra
• Una transferencia existe desde el momento que la ejecuta el
Cliente hasta el momento que se ejecuta

Información del modelo de diseño
• Un Banco
• Es un Entity Bean con atributos persistentes apuntando a los Clientes y a las
Cuentas
• Tiene operaciones para establecer y cerrar relaciones con sus Clientes
• Un Cliente
• Es un Entity Bean con atributos persistentes que mantiene su nombre y
apunta a sus Cuentas
• Tiene operaciones para abrir y cerrar Cuentas y para ejecutar Transferencias
• Una Cuenta
• Es un Entity Bean con atributos persistentes que mantiene su número de
cuenta y balance, además de apuntar al Cliente al que pertenece
• Tiene operaciones para retirar y depositar montos de dinero
• Una Transferencia
• Es un Stateful Session Bean con atributos transient que mantienen la
cantidad de dinero, las Cuentas fuente y destino.
• Tiene una operación para ejecutar la transferencia

¿Cómo pasamos del análisis al diseño?
Reglas de la función de transformación
• Una clase cuyas instancias deben necesitar ser persistentes el
tiempo que dure el sistema, se representan por un Entity Bean
• Una clase cuyas instancias deben persistir un tiempo
indeterminado – menos que el del sistema pero más que
cualquier ejecución de una función - deben representarse con
un Entity Bean
• Una clase cuyas instancias existen solo por un período
relativamente corto de tiempo, que lleva información
relacionada con los Entity Beans, debe ser representado por
un Stateful Session Bean
• Todo Entity Bean y Stateful Session Bean tendrá los atributos
necesarios que reflejen la información necesaria sobre las
asociaciones en el modelo de análisis

Funciones de transformación
• Estas reglas forman la función de transformación
• La transformación particular del modelo de análisis del sistema
bancario es la aplicación de la función de transformación
• La diferencia entre este proceso y el dirigido por código es que el del
código pierde la transformación una vez ejecutado.
• Como consecuencia:
• No puede repetirse sobre el mismo modelo
• No puede ser aplicado en un modelo que requiere un modelo similar.
• Así definimos,
• Una «función de transformación» como una colección de reglas o
algoritmos que definen cómo funciona un «transformación».
• Una «transformación» es la aplicación o ejecución de una «función
de transformación» para transformar un modelo en otro

Funciones de transformación
• Las funciones de transformación se definen sobre los meta-
modelos, pero operan sobre los modelos
• Ejemplo: «Transforma cada clase con al menos un atributo
persistente en un Entity Bean»
• La reglas no se basan en elementos del modelo, se basa en los
tipos de ese modelo
• Las reglas no son específicas de un modelo, se aplican a todos
los modelos que se crean a partir del meta-modelo, lo que las
hace «reusables».

Formalismos de transformación
Query, View and Transform (QVT)
• Para cumplir con las dos características del mapeo de
modelos: construcción y sincronización, las transformaciones
deben ejecutase automáticamente
• Lo que lleva a: acortar los plazos de arreglos, escalar a grandes
modelos, evitar el trabajo manual => menos errores y mejora
de la calidad general
• Para que la máquina pueda llevar a cabo esto, se necesita un
formalismo para expresar las reglas y expresar los modelos.

1. Imperativo
2. Basados en arquetipos
3. Declarativo
MM de Entrada M de Entrada MMSalida
Entidad
parent
Paquete
nombre:String
nombre:String
PA PB
E1
Clase
nombre:String

Imperativo
• Implementación de todas las reglas y algoritmos en forma
procedural
• Expresa cómo se consulta la información en el meta-modelo,
se transforma y se escribe
• Principal ventaja:
• es familiar
• Principal desventaja:
• No reversible => no se puede construir el modelo fuente del
destino

Ejemplo Java
…
foreach (e:Entidad in entidades){
File dir = new File(e.parent.nombre);
dir.mkdirs();
OutputStream os = new FileOutputStream( e.parent.nombre + ”/” +
e.nombre+”.java”);
os.println(“package ”+ e.parent.nombre +”;”);
os.println(“private class ”+e.nombre+” {”);
…
os.println(“}”);
os.close();
}
…
RESULTADO:
El contenido del archivo /PA/PB/E1.java será:
package PA.PB;
private class E1 {
…
}

Basado en arquetipos
• Mezcla el un conjunto de plantillas con código, o reglas para
generar el texto.
• Puede ser implementado con un lenguaje de acceso a datos
que selecciona los elementos apropiados del modelo fuente y
el arquetipo (plantilla) que se usará.
• Luego selecciona cómo hacer la transformación en algo que se
incluye en el modelo destino.
• Principal ventaja:
• Muy bueno para transformar modelos en código

Ejemplo MOF Script
texttransformation gui2java (in mmEntrada:“MMEntrada”) {
mmEntrada.ContenedorEntidades::main () {
self.entidades->forEach(e: mmEntrada.Entidad){
c.mapClase();
}
mmEntrada.Entidad::mapClase () {
file(self.parent.nombre+'/'+self.nombre+'.java');
“package ” self.parent.nombre ”;”
“class “ self.nombre “{“
“}”
}
}
RESULTADO:
El contenido del archivo /PA/PB/E1.java será:
package PA.PB;
class E1 {
…
}

Declarativo
• Especifica los algoritmos como reglas que especifican lo que se
producirá, NO CÓMO SE HARÁ
• Principales ventajas:
• Aunque no se garantiza, puede ser reversible
• Muy bueno para transformaciones entre modelos

Ejemplo ATL
-- @path mmEntrada=/NegocioGUI/MMEntrada.ecore
-- @path mmSalida=/NegocioGUI/Java.ecore
rule Negocio2AUI {
from e : mmEntrada!Entidad
to c : mmSalida!Clase(nombre<-e.nombre)
}

Escenarios de transformaciones
• Verticales
• Refinamiento
• Abstracción
• Horizontales
• Representación
• Migración
• Mezcla

Transformaciones de Refinamiento
• Hemos mostrado una transformación del modelo de análisis al
modelo de diseño que cambia el nivel de abstracción en el cual se
expresan las cosas, ya que el meta-modelo de diseño tiene
elementos adicionales del lenguaje.
• Una función de transformación de refinamiento puede crear todo lo
que se necesita del modelo destino , ya que el modelo fuente es
completo con respecto a la función de mapeo.
• No hay necesidad de examinar el modelo destino antes de
ejecutarlo, o mapearlo al siguiente nivel.
• Hay escenarios donde la función de mapeo es incompleta, y no se
puede construir todo lo que se necesita en el modelo destino.
Existen dos formas de solucionarlo:
• Rellenar los espacios en blanco del modelo destino
• Asociar un modelo adicional de entrada en el modelo fuente de
manera que no lo contamine.

Transformaciones de Abstracción
• Cuando no se puede ver el bosque por culpa de los árboles, es
útil abstraer lo que no agrega comprensión al modelo.
• Para asegurarnos que la vista abstracta está en sincronismo
con el modelo detallado de forma automática utilizamos
transformaciones de abstracción.
• Las vistas abstractas de los modelos son útiles también
cuando se mueve un modelo de una plataforma a otra
• Una transformación abstracta extrae los contenidos de un
modelo detallado en un modelo más abstracto que puede ser
mapeado a otro modelo detallado
• Tanto las transformaciones de refinamiento como de
abstracción son VERTICALES (cambian el nivel de abstracción)

Transformaciones de
Representación
• A veces un meta-modelo no está totalmente soportado por
notaciones disponibles, otras veces se necesitan un conjunto
de meta-modelos que tienen sus propias notaciones.
• Por lo tanto, se puede definir una transformación a un meta-
modelo existente con notaciones y soporte de herramientas
existentes.
• Tales transformaciones permiten crear modelos en un meta-
modelo soportado por otro modelo en otro meta-modelo.
• Son más útiles cuando son reversibles

Transformaciones de Migración
• En algunos casos, portar modelos existentes a otras
plataformas usando una transformación de abstracción y una
de refinamiento no es apropiado, ya que los cambios no son
substanciales.
• Por ejemplo, la migración de una versión de modelo de datos
a otra.
• Estas transformaciones reformatean y reagrupan información
existente para que sea manejable por otras transformaciones.
• De la misma manera que con las transformaciones de
representación, no cambian el nivel de abstracción.
• Tanto la transformación de representación como la de
migración son transformaciones HORIZONTALES.

Transformaciones de Mezcla
• Combina de múltiples modelos fuente para combinarlos en un único
modelo destino.
• Crea enlaces entre elementos de modelos diferentes que no hacen
referencia explícita.
• Este concepto de entrelazado aparece en los lenguajes de programación
como «programación orientada a aspectos»
Modelo de
Seguridad
Modelo de
Banca
Información
de enlace
Transformación
mezcla
Modelo
mezclado

Referencias
1. Stephen J. Mellor, Kendall Scott, Axel Uhl, Dirk Weise. MDA
Distilled: Principles of Model-Driven Architecture. Addison
Wesley. 2004.
2. Object Management Group. Unified Modeling Language:
Superstructure. Version 2.0, ptc/03-07-06, July 2003;
http://www.omg.org/cgi-bin/doc?ptc/2003-08-02.

Transformaciones de modelos

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Transformaciones de modelos

Similar a Transformaciones de modelos (20)

Más de Ricardo Tesoriero

Más de Ricardo Tesoriero (10)

Transformaciones de modelos