Transformación de modelos
52
Transformación de modelos Abraham Sánchez López FCC/BUAP Grupo MOVIS
Transcript of Transformación de modelos
Transformación de modelos
Abraham Sánchez López
FCC/BUAP
Grupo MOVIS
(C) A. Sánchez L. 2016 2
Introducción
Hacer los modelos productivos consiste en aplicar las transformaciones de
modelos para obtener resultados útiles en el desarrollo, por lo general en forma
de modelos más detallados y próximos de la solución técnica o código.
Por estas razones, las transformaciones de los modelos son omnipresentes en
MDA. Estas permiten convertir un modelo CIM en un modelo PIM u obtener
un modelo PSM de un modelo PIM.
En este parte del curso se define el concepto de transformación modelos, tal
como se define en MDA y se presentan las diferentes tecnologías para lograr
las transformaciones de modelos.
(C) A. Sánchez L. 2016 3
Transformación y MDA, I
Como se explicó al inicio del curso, MDA representa con la ayuda de modelos
toda la información necesaria para construir aplicaciones computacionales.
La aplicación de MDA induce necesariamente la creación de un gran número
de modelos. Cada modelo contiene alguna información útil para la generación
de aplicaciones computacionales.
La parte final de MDA (producción), inicia con la vinculación de estos modelos
y más precisamente por sus respectivas transformaciones.
Es a través de las transformaciones de modelos que es posible, por ejemplo,
obtener la trazabilidad entre los modelos muy abstractos, cercanos de los
requerimientos expresados por los usuarios, y de los modelos muy concretos,
próximos de las plataformas de ejecución .
La siguiente figura muestra las fases de MDA e ilustra las principales
transformaciones de modelos MDA:
Transformaciones de modelos CIM a PIM. Permiten construir los PIM parciales a
partir de la información contenida en los CIM. El objetivo es asegurar que los
requisitos expresados en los CIM se transcriben a los PIM.
(C) A. Sánchez L. 2016 4
Principales transformaciones de MDA
(C) A. Sánchez L. 2016 5
Transformación y MDA, II
Estas transformaciones son esenciales para la persistencia de los modelos. Y es lo
que garantiza los vínculos de trazabilidad entre los modelos y los requisitos
expresados por el cliente.
Transformaciones de modelos PIM a PIM. Permite refinar los PIM para mejorar la
exactitud de la información que estos contienen. En UML, estas transformaciones
pueden ser, por ejemplo, la creación de clases de UML a partir de un conjunto de
diagramas de secuencia o la creación de diagramas de estado a partir de diagramas de
clases. Estas transformaciones son omnipresentes en las herramientas de desarrollo
de modelos PIM. Permiten igualmente acelerar la producción de los PIM y así
acortar el ciclo de desarrollo.
Transformaciones de modelos PIM a PSM. Permiten construir muchos de los
modelos PSM a partir de los modelos PIM. Estas transformaciones son las más
importantes de MDA, ya que garantizan la persistencia de los modelos, así como su
productividad y su relación con las plataformas de ejecución.
Transformaciones de modelos PSM a código. Permiten generar todo el código.
Veremos más adelante en esta parte del curso, que estas transformaciones no se
consideran realmente como transformaciones de modelos.
(C) A. Sánchez L. 2016 6
Transformación y MDA, III
Transformación inversa
Aunque este no es el objetivo principal de MDA, todas estas transformaciones
tienen por supuesto su transformación inversa (código a PSM, PIM a PSM y
PIM a CIM).
Estas transformaciones inversas también son fuertemente discutidas por la
comunidad científica para el futuro estándar ADM (Architecture Driven
Modernization) del OMG, que tiene por objeto definir el enfoque inverso de
MDA, es decir, construir los modelos a partir de aplicaciones existentes.
Acabamos de ver cómo las transformaciones de modelos son esenciales en
MDA. En la medida en que estas transformaciones hacen a los modelos más
productivos, su definición es estratégica para la aplicación de MDA.
(C) A. Sánchez L. 2016 7
Metamodelos y reglas de correspondencia, I
Cualquiera que sea el tipo (PIM a PSM, PIM a PIM, etc.), una transformación
de modelos se parece siempre a una función que toma como entrada un
conjunto de modelos y que da como salida un conjunto de modelos.
Los modelos de entrada y de salida están estructurados por su metamodelo.
Esto es también lo que nos permite discernir en MDA las transformaciones de
los modelos de generación de código.
Para tener en cuenta la generación de código como una transformación de
modelos, debemos ser capaces de construir el metamodelo del código.
Han surgido varios intentos para construir, por ejemplo, el metamodelo de Java
para considerar la generación de código Java como una transformación de
modelos.
Estos intentos no han tenido gran éxito y se tiene en la actualidad, evidencia de
que la realización de un metamodelo de este tipo no es muy realista.
Esto explica en parte la razón por la que el OMG está realizado esfuerzos de
estandarización para crear un lenguaje que permita definir la generación de
código a partir de modelos.
(C) A. Sánchez L. 2016 8
Metamodelos y reglas de correspondencia, II
Veremos con posterioridad, que no consideramos la generación de código
como transformaciones de modelos.
Una transformación de modelos MDA es una función donde los parámetros de
entrada y salida son los modelos estructurados por los metamodelos.
También es posible, en el contexto particular de los modelos UML, que los
modelos de entrada y de salida sean perfiles, es decir, que estén etiquetados por
los estereotipos definidos por los perfiles (ver el documento UML 2.0).
Desde el punto de vista de las transformaciones de modelos, los perfiles se
consideran como metamodelos en el sentido de que estos estructuran un
conjunto de modelos.
Si una transformación de modelos se ejecuta a nivel de los modelos, esta
especifica el nivel de los metamodelos.
Es decir, una transformación expresa las correspondencias estructurales entre
los modelos fuente y destino. Estas correspondencias estructurales se basan en
los metamodelos de los modelos de origen y destino.
(C) A. Sánchez L. 2016 9
Metamodelos y reglas de correspondencia, III
Por ejemplo, una transformación de modelos que permita transformar los
modelos UML a los esquemas de bases de datos relacionales (BD) podría
especificar la siguiente regla: a toda clase UML corresponde una tabla de un
esquema de una base de datos.
Esta misma regla, expresada según los metamodelos, debe decir: a todo
elemento del modelo fuente, instancia de la metaclase Class del metamodelo
UML debe corresponder un elemento del modelo destino, instancia de la
metaclase Table del metamodelo BD (suponiendo que el metamodelo BD
define la metaclase Table).
Esta regla expresa más bien una correspondencia estructural entre los
metamodelos UML y BD y en concreto una correspondencia entre las
metaclases Class y Table.
La siguiente ilustra la relación entre las transformaciones de modelos y los
metamodelos. Si la transformación es aquí binaria, con una única fuente y un
solo destino, es importante destacar que las transformaciones de modelos son
N-arias, es decir, que pueden tener como entrada y salida varios modelos .
(C) A. Sánchez L. 2016 10
Metamodelos y transformación de modelos
(C) A. Sánchez L. 2016 11
Metamodelos y reglas de correspondencia, IV
Acabamos de ver que las transformaciones de modelos fueron transformaciones
estructurales.
Estas se componen de un conjunto de reglas que expresan cada una de las
correspondencias estructurales entre los metamodelos origen y destino.
El rol de los metamodelos en las transformaciones de modelos MDA es definir
las posibles estructuraciones de los modelos origen y destino, y de proporcionar
la base para la definición de las reglas de transformación.
(C) A. Sánchez L. 2016 12
Transformaciones semánticas
Las transformaciones de modelos no son transformaciones semánticas.
Una transformación de modelo no puede preservar inherentemente la semántica
de los modelos de origen y de destino.
De hecho, no es posible definir las relaciones semánticas a partir de las
relaciones estructurales.
En nuestro ejemplo, el hecho de haber definido la transformación de los
modelos UML a los modelos BD no significa que la semántica de los modelos
UML se pueden encontrar transcrita en los modelos BD resultantes de la
transformación.
Garantizar una coherencia semántica durante una transformación de modelo se
puede lograr mediante el uso de otras técnicas, tales como las técnicas
formales.
(C) A. Sánchez L. 2016 13
Especificación de las reglas de transformación, I
Lo que diferencia a los diferentes enfoques para la elaboración de las
transformaciones de modelos es la forma en que se especifican las reglas de
transformaciones.
Actualmente, son tres los enfoques que permiten la especificación de tales
reglas de correspondencia.
Enfoque por programación. Consiste en el uso de lenguajes de programación
orientados a objetos. La idea es programar una transformación de modelos de la
misma manera que se programa cualquier aplicación computacional. Estas
transformaciones son aplicaciones computacionales que tienen la particularidad de
manipular modelos.
Estas aplicaciones utilizan las interfaces de manipulación de modelos que hemos
presentado anteriormente. Este enfoque es el más utilizado, ya que es muy potente y
altamente presente en las aplicaciones comerciales.
Enfoque por plantilla. Consiste en definir el contorno de los modelos destino
deseados, especificando sus parámetros. Estos parámetros serán sustituidos por la
información contenida en las modelos fuente. Se le denomina a estos contornos
«modelos destino parametrizados» o «modelos plantilla».
(C) A. Sánchez L. 2016 14
Especificación de las reglas de transformación, II
La ejecución de una transformación consiste en tomar un modelo plantilla y
reemplazar sus parámetros por los valores de un modelo fuente.
Este enfoque requiere de un lenguaje específico que permita la definición de los
modelos plantilla. Su poder radica principalmente en el lenguaje de definición de
los modelos plantilla.
Tales lenguajes están en desarrollo y aún no tienen la madurez de los lenguajes de
programación orientados a objetos usados en el primer enfoque.
Enfoque por modelización. Consiste en aplicar los conceptos de la ingeniería de los
modelos a las transformaciones de los modelos mismos. El objetivo es modelar las
transformaciones de modelos y hacer que los modelos de transformación sean
persistentes y productivos, y expresar su independencia de frente a las plataformas de
ejecución.
Este enfoque se encuentra actualmente en fase de investigación. El estándar MOF2.0
QVT (Query View, Transformation) que se esta definiendo por el OMG tiene como
objetivo definir el metamodelo que permite la elaboración de los modelos de
transformación de modelos. En la actualidad, sólo unos pocos prototipos de
investigación apoyan este enfoque.
(C) A. Sánchez L. 2016 15
Ejemplo de aplicación, I
Para comprender mejor los diferentes enfoques de transformación de modelos,
vamos a ilustrar con un ejemplo sencillo, como transformar un modelo UML a
un esquema de base de datos (BD).
La siguiente figura (acetato 16) ilustra el metamodelo fuente de esta
transformación. Este metamodelo es una versión muy simplificada de UML.
La metaclase SimpleUMLPackage representa el concepto de paquete de UML.
Esta metaclase se conecta a la metaclase Classifier, que es la metaclase
abstracta que representa tanto el concepto de clase UML como el concepto de
tipo de dato UML.
La metaclase DataType representa el concepto de tipo de dato UML.
La metaclase Class, que hereda de la metaclase Classifier, representa el
concepto de clase UML. Esta metaclase está conectado a la metaclase Property,
que representa el concepto de propiedad UML.
La metaclase Property está conectada a la metaclase Classifier para expresar el
tipo de una propiedad.
(C) A. Sánchez L. 2016 16
Ejemplo de aplicación, II
Este metamodelo estructura los modelo UML simplificados, constituidos por
paquetes que contienen los tipos de datos y de las clases, estos últimos pueden
contener propiedades tipeadas.
(C) A. Sánchez L. 2016 17
Ejemplo de aplicación, III
La figura del acetato 18 ilustra el metamodelo destino de la transformación.
Este metamodelo representa una versión muy simplificada de los esquemas
relacionales de base de datos.
La metaclase Esquema representa el concepto de esquema de base de datos.
Esta metaclase está unida a la metaclase Tabla, que representa el concepto de
tabla en las bases de datos.
La metaclase Tabla está unida a la metaclase Columna, que representa una
columna de una tabla de base datos.
La metaclase Columna está unida a la metaclase Tipo , lo que permite
especificar el tipo de la columna.
La metaclase LlaveForanea, que hereda de la metaclase Columna, representa el
concepto de llave foránea.
Esta metaclase está unida a la metaclase Tabla, lo que permite especificar a
cual tabla la llave foránea hace referencia.
Este metamodelo estructura los modelos que representan los esquemas de la
base de datos.
(C) A. Sánchez L. 2016 18
Metamodelo de un esquema relacional simplificado
(C) A. Sánchez L. 2016 19
Ejemplo de aplicación, IV
Estos esquemas están constituidos de varias tablas, y estas mismas tablas están
constituidas de columnas tipeadas.
Algunas de estas columnas pueden contener llaves foráneas que permiten
expresar las relaciones entre las tablas.
Estos dos metamodelos ejemplo, tienen como único objetivo servir de soporte
en la transformación de modelos que se van a detallar más adelante.
Estos metamodelos están muy simplificados y no deben considerarse como
metamodelos establecidos en el dominio UML y de los esquemas de bases de
datos.
La transformación ejemplo, que consiste en transformar los modelos UML
hacia los esquemas de bases de datos, se puede definir de la siguiente manera:
1. A todo paquete UML corresponde un esquema.
2. A toda clase UML del paquete corresponde una tabla en el esquema.
3. A toda propiedad UML de una clase corresponde una columna en la tabla:
(C) A. Sánchez L. 2016 20
Ejemplo de aplicación, V
Si el tipo de la propiedad es una clase UML, la columna es una llave foránea.
Si el tipo de la propiedad es un tipo de datos UML, la columna es del tipo
correspondiente.
4. A todo tipo de dato UML de un paquete corresponde un tipo de datos en el
esquema.
Las siguientes secciones muestran como estas cuatro reglas se desarrollan
según los enfoques por programación, por plantilla y por modelización.
(C) A. Sánchez L. 2016 21
Reglas de programación, I
Como se explicó anteriormente, el enfoque por programación consiste en
programar las transformaciones de los modelos, utilizando los lenguajes de
programación orientados a objetos y las interfaces de manipulación de
modelos.
Los principios del enfoque por programación son muy simples. Sólo se tiene
que disponer de un lenguaje de programación y una manera de manipular los
modelos.
Algunas herramientas siguen este enfoque, ofreciendo varios asistentes o
frameworks que faciliten la codificación de las transformaciones de modelos.
Estos asistentes y los frameworks son muy fáciles de usar y aportan ganancias
significativas al desarrollo.
A continuación, se detalla un ejemplo práctico.
En este ejemplo, se eligió el leguaje Java con las interfaces de manipulación de
los modelos taylored de EMF (Eclipse Modeling Framework). Esta elección
ilustra ampliamente el enfoque por programación sin necesitan un asistente o
un framework adicional al framework EMF.
(C) A. Sánchez L. 2016 22
Reglas de programación, II
El framework EMF es muy fácil de descargar dado que es Open Source.
Convertimos los metamodelos fuente y destino MOF hacia los metamodelos
Ecore y después aplicamos las reglas de generación de interfaces taylored del
framework EMF.
Gracias al EMF, el metamodelo UML simplificado genera las siguientes
interfaces que permiten la manipulación de los modelos UML:
SimplePackageUML. Obtenido a partir del EClass SimplePackageUML, esta
interface ofrece la operación getElements(), que permite obtener los elementos
contenidos en un paquete.
Classifier. Obtenido a partir del EClass Classifier, esta interface ofrece las
operaciones getName() y setName(), que permiten leer y escribir el nombre del
elemento.
Class. Obtenido a partir del EClass Class, esta interface, que hereda de la
interface Classifier, ofrece la operación getProps(), que permite obtener la lista
de las propiedades de la clase.
(C) A. Sánchez L. 2016 23
Reglas de programación, III
DataType. Obtenido a partir del EClass DataType, esta interface hereda de la
interface Classifier.
Property. Obtenido a partir del EClass Property, esta interface ofrece las
operaciones getType() y setType(), que permiten especificar el tipo de la
propiedad. Esta interface ofrece también las operaciones getName() y
setName(), que permiten leer y escribir el nombre del elemento.
UmlFactory. Obtenido a partir del EClass UML, esta interface ofrece todas las
operaciones que permiten crear instancias de las Eclass del EPackage UML.
Por ejemplo, la operación createClass() permite crear una instancia del EClass
Class.
El metamodelo simplificado del esquema de bases de datos permite en cuanto a
él, generar las siguientes interfaces:
Esquema. Obtenido a partir del EClass Esquema, esta interface ofrece la
operación getTables(), que permite obtener todas las tablas contenidas en el
esquema de base de datos.
(C) A. Sánchez L. 2016 24
Reglas de programación, IV
Tabla. Obtenido a partir del EClass Tabla, esta interface ofrece la operación
getColumnas(), que permite obtener todas las columnas contenidas en una tabla.
Esta interface ofrece también las operaciones getName() y setName(), que
permiten leer y escribir el nombre del elemento.
Columna. Obtenido a partir del EClass Columna, esta interface ofrece las
operaciones getType() y setType(), que permite especificar el tipo de la columna.
Esta interface ofrece también las operaciones getName() y setName(), que
permiten leer y escribir el nombre del elemento.
Tipo. Obtenido a partir del EClass Tipo, esta interface ofrece las operaciones
getName() y setName(), que permiten leer y escribir el nombre del elemento.
LlaveForanea. Obtenido a partir del EClass LlaveForanea, esta interface ofrece
las operaciones getRefTable() y setRefTable(), que permiten especificar la tabla
referenciada por la llave foránea.
BDFactory. Obtenido a partir del EPackage BD, esta interface ofrece todas las
operaciones que permiten crear instancias de las EClass del EPackage BD. Por
ejemplo, la operación createTable() permite crear una instancia del EClass Table.
(C) A. Sánchez L. 2016 25
Reglas de programación, V
Gracias a estas interfaces de manipulación de modelos, es posible escribir en la
forma de programa Java la transformación presentada anteriormente.
Hemos elegido estructurar este programa Java en una sola clase que contenga
un método por regla de transformación.
Las siguientes secciones presentan los diferentes métodos de esta clase.
(C) A. Sánchez L. 2016 26
Métodos de transformación de la clase Java, I
El siguiente método SimpleUMLPackage2Schema corresponde a la primera
regla, que consiste en construir un esquema a partir de un paquete.
La segunda línea de este método permite crear una instancia de la EClass
Esquema. La tercera y cuarta líneas permiten iterar sobre todos los elementos
en el paquete.
La quinta, sexta y séptima líneas permiten llamar a la ejecución de la regla de
transformación relativa a las clases UML para crear tablas en el esquema.
La octava, novena y décima líneas permiten llamar a la ejecución de la regla de
transformación relativa a los tipos de datos UML para crear tipos en el
esquema.
[1] public void simpleUMLPackage2Schema(SimpleUMLPackage pc) {
[2] Schema sh = BdFactoryImpl.eINSTANCE.createSchema();
[3] for (Iterator it = pc.getElements().iterator() ; it.hasNext() ; ) {
[4] Object next = it.next();
[5] if ( next instanceof uml.Class) {
[6] sh.getTables().add(class2Table((uml.Class) next));
[7] }
(C) A. Sánchez L. 2016 27
Métodos de transformación de la clase Java, II
[8] else if (next instanceof DataType) {
[9] dataType2Type((DataType)next);
[10] }
[11] }
[12] }
El método class2Table anterior, corresponde a la segunda regla, que consiste en
crear una tabla a partir de una clase.
La segunda línea de este método permite crear una instancia de la EClass
Tabla.
La tercera línea permite especificar que el nombre de la tabla corresponde al
nombre de la clase.
La cuarta, quinta, sexta y séptima líneas permiten iterar en las propiedades de la
clase y además ejecutan la regla de transformación relativa a las propiedades de
UML.
Las siguientes líneas, bastante complejas, permiten establecer los vínculos
entre las llaves foráneas y las tablas.
(C) A. Sánchez L. 2016 28
Métodos de transformación de la clase Java, III
Es decir, como nuestro algoritmo considera una navegación descendente en el
modelo UML, es posible llamar a la ejecución de la regla de transformación
relativa a una propiedad, entonces el tipo de esta no ha dado lugar a la creación
de un elemento al que le corresponde un esquema.
La siguientes figura presenta un ejemplo en el cual no es aún posible vincular la
llave foránea con la tabla que esta referencia ya que la tabla correspondiente no
se ha creado por el algoritmo.
(C) A. Sánchez L. 2016 29
Métodos de transformación de la clase Java, IV
Para hacer frente a este problema, hemos elegido almacenar los vínculos que
restan por establecerse en las tablas hash. De este modo, estos vínculos se
realizarán cuando se han creado todos los elementos necesarios para su
establecimiento. [1] public Table class2Table(uml.Class clazz) {
[2] Table tab = BdFactoryImpl.eINSTANCE.createTable();
[3] tab.setName(clazz.getName());
[4] for (Iterator it = clazz.getProps().iterator() ; it.hasNext() ; ) {
[5] Property next = (Property) it.next();
[6] tab.getColumnas().add(property2Columna(next));
[7] }
[8] classTable.put(clazz , tab);
[9] if (llaveRef.containsKey(clazz)) {
[10] Vector llaves = (Vector) llaveRef.get(clazz);
[11] for (Iterator it = llaves.iterator() ; it.hasNext() ; ){
[12] LlaveForanea current = (LlaveForanea) it.next();
[13] current.setRefTable(tab);
[14] }
[15] }
[16] return tab;
[17] }
(C) A. Sánchez L. 2016 30
Métodos de transformación de la clase Java, V
El método property2Columna que se muestra enseguida, corresponde a la
tercera regla, y consiste en crear una columna o una llave foránea a partir de
una propiedad de una clase.
La segunda línea de este método permite saber si el tipo de la propiedad es una
clase o un tipo de datos. Si se trata de una clase, crea una llave foránea,
mientras que si se trata de un tipo de datos, crea una sola columna.
La tercera y vigésima primera líneas se utilizan respectivamente para crear
instancias del EClass LLaveForanea y de la Eclass Columna.
Las otras líneas permiten establecer vínculos entre las llaves foráneas y su tabla
o entre las columnas y su tipo.
Preferimos no pensar demasiado en el funcionamiento del mecanismo que
permite establecer los enlaces, ya que no es de gran interés en el contexto de
este curso y podría oscurecer la presentación de las transformaciones de
modelos.
(C) A. Sánchez L. 2016 31
Métodos de transformación de la clase Java, VI
[1] public Columna property2 Columna prop){
[2] if (prop.getType() instanceof uml.Class){
[3] LlaveForanea llave = BdFactoryImpl.eINSTANCE.createLlaveForanea();
[4] llave.setName(prop.getName());
[5] if (classTable.containsKey(prop.getType())) {
[6] llave.setRefTable((Table) classTable.get(prop.getType()));
[7] }
[8] else {
[9] if (llaveRef.containsKey(prop.getType())){
[10] ((Vector)llaveRef.get(prop.getType())).add(llave);
[11] }
[12] else {
[13] Vector vec = new Vector();
[14] vec.add(llave);
[15] llaveRef.put(prop.getType() , vec);
[16] }
[17] }
[18] return llave;
[19] }
[20] else { //DataType
[21] Columna col = BdFactoryImpl.eINSTANCE.createColumna();
[22] col.setName(prop.getName());
(C) A. Sánchez L. 2016 32
Métodos de transformación de la clase Java, VII
[23] if (datatypeType.containsKey(prop.getType())) {
[24] col.setType((Type)datatypeType.get(prop.getType()));
[25] }
[26] else {
[27] if (colType.containsKey(prop.getType())){
[28] ((Vector)llaveRef.get(prop.getType())).add(col);
[29] }
[30] else {
[31] Vector vec = new Vector();
[32] vec.add(col);
[33] colType.put(prop.getType() , vec);
[34] }
[35] }
[36] return col;
[37] }
[38] }
El método dataType2Type siguiente corresponde a la última regla, que consiste en
crear un tipo a partir de un tipo dado.
La segunda línea de este método crea una instancia del EClass Tipo.
(C) A. Sánchez L. 2016 33
Métodos de transformación de la clase Java, VIII
La tercera línea permite especificar que el nombre del tipo corresponde al
nombre del tipo de dato. Las siguientes líneas se utilizan para establecer los
vínculos entre las columnas y su tipo.
[1] public Type dataType2Type(DataType dt) {
[2] Type t = BdFactoryImpl.eINSTANCE.createType();
[3] t.setName(dt.getName());
[4] datatypeType.put(dt , t);
[5] if (colType.containsKey(dt)) {
[6] Vector llaves = (Vector) colType.get(dt);
[7] for (Iterator it = llaves.iterator() ; it.hasNext() ; ){
[8] Columna current = (Columna) it.next();
[9] current.setType(t);
[10] }
[11] }
[12] return t;
[13] }
(C) A. Sánchez L. 2016 34
Reglas mediante plantilla, I
Ya hemos dicho que el enfoque por plantilla consistía en definir el contorno de
los modelos destino deseados, declarando los parámetros.
Estos parámetros serán sustituidos por la información contenida en los modelos
fuentes.
Los modelos objetivos se llaman «modelos destino parametrizados» o «
modelos plantillas».
Plantillas y sitios Web
El enfoque por plantilla es ampliamente utilizado en el desarrollo de sitios web
con tecnologías como PHP o JSP.
La idea es definir los contornos de las páginas web que se mostrarán, indicando
los parámetros. Estos parámetros se definen utilizando un lenguaje de
programación y se calcularán dinámicamente a partir de, por ejemplo, una base
de datos.
La siguiente figura muestra un ejemplo de plantilla para las tablas de los
esquemas de base de datos.
(C) A. Sánchez L. 2016 35
Reglas mediante plantilla, II
Esta plantilla contiene varios parámetros, donde los valores se obtienen a partir
de la información contenida en los modelos fuente.
La plantilla que se presenta aquí, contiene dos parámetros, uno para el nombre
de la tabla y el otro para todas las columnas de la tabla.
Estos parámetros serán respectivamente remplazados por el nombre de la clase
del modelo fuente y por todas sus propiedades.
El ejemplo tiene como única función ilustrar la importancia del lenguaje que
permite la definición de las plantillas.
(C) A. Sánchez L. 2016 36
Reglas mediante plantilla, III
Este lenguaje debe ofrecer un compromiso entre potencia de expresión y
facilidad de uso.
En nuestro ejemplo, hemos utilizado un pseudo lenguaje dedicado a los
esquemas de bases de datos.
Este lenguaje parece fácil de utilizar pero al parecer, de forma evidente se
constata que sus capacidades de expresión están limitadas.
Las herramientas que apoyan al enfoque mediante plantilla proponen, ya sea
lenguajes gráficos específicos de metamodelos destino, o lenguajes textuales
independientes de los metamodelos:
Los lenguajes gráficos específicos de un metamodelo son frecuentemente fáciles de
utilizar pero son por lo regular muy poco expresivos, dada su adherencia a un único
metamodelo. Estos no permiten la transformación más que de un solo tipo de
modelo.
Los lenguajes textuales independientes de los metamodelos son por el contrario muy
expresivos pero muy difíciles de utilizar, dado su carácter genérico. Estos permiten
la transformación de todos los tipos de modelos.
(C) A. Sánchez L. 2016 37
Reglas mediante plantilla, IV
La elección de un lenguaje depende del objetivo del usuario y del tipo de
modelos que este desea transformar.
Un ejemplo de lenguaje de definición de plantilla específico de un metamodelo
sería UML. UML permite definir modelos UML con parámetros.
Los parámetros de estos modelos serán sustituidos por la información
contenida en los modelos fuente.
Las plantillas UML son ampliamente compatibles con las herramientas UML
existentes y además permiten una fácil definición de transformaciones de
modelos UML.
Un ejemplo de lenguaje de definición de plantilla, independiente de los
metamodelos se proporciona a menudo por los lenguajes basados en XMI y en
los lenguajes de programación clásicos, dado que las palabras clave permiten el
procesamiento automatizado.
La idea es que la plantilla sea un documento XMI que corresponda al modelo
de destino.
(C) A. Sánchez L. 2016 38
Reglas mediante plantilla, V
Los parámetros de este documento XMI así como la automatización de ciertos
tratamientos se codifican con un lenguaje de programación directamente en el
documento XMI.
Los caracteres particulares permiten identificar claramente el lenguaje de
programación de las etiquetas XMI.
(C) A. Sánchez L. 2016 39
Ejemplo práctico, I
Proponemos ilustrar el enfoque con plantilla con un lenguaje independiente de
la definición de plantilla independiente de los metamodelos.
Elegimos un lenguaje basado en XMI y Java para las palabras clave que
permiten el procesamiento automatizado.
Este lenguaje utiliza un enfoque similar a JSP (Java Server Pages), que consiste
en agrupar las palabras clave Java con los caracteres <% y %> para
distinguirlas de las etiquetas XMI.
En lugar de detallar toda la transformación, presentamos un modelo plantilla
que permite la generación de una tabla a partir de una clase.
Consideramos que el modelo fuente que permitirá proporcionar los valores a
los parámetros de plantilla, contiene una clase. Esta clase está identificada por
el término clazz en la plantilla. Esta plantilla se presenta a continuación.
La primera línea contiene el elemento XMI que representa una tabla.
Esta línea también contiene un parámetro que será reemplazado por el valor del
nombre de la clase contenida en el modelo fuente.
(C) A. Sánchez L. 2016 40
Ejemplo práctico, II
Aquí, hemos utilizado el lenguaje Java para precisar que el parámetro será
reemplazado por el nombre de la clase (clazz.getName ()).
La segunda y tercera líneas de la plantilla utilizan Java para iterar sobre todas
las propiedades de la clase contenida en el modelo fuente.
La cuarta línea contiene el elemento XMI que representa una columna. Esta
línea también contiene un parámetro que será reemplazado por el valor del
nombre de la propiedad de la clase contenida en el modelo fuente.
La quinta línea contiene el elemento XMI que representa el tipo de la columna.
Esta línea incluye un parámetro que será reemplazado por el valor del nombre
del tipo de la propiedad del modelo fuente.
Esta transformación de modelo producida de acuerdo con el enfoque de
plantilla no es completa. También hay que definir todas las otros modelos
plantilla y explicar las relaciones de orden de ejecución entre ellos.
Esta transformación, incluso incompleta, es sin embargo suficiente para
comprender los principios del funcionamiento de un enfoque por plantilla.
(C) A. Sánchez L. 2016 41
Ejemplo práctico, III
[1] <tables name="<%clazz.getName()%>">
[2] <%for (Iterator it=clazz.getProps().iterator() ; it.hasNext() ; ) {
[3] Property next = (Property) it.next(); %>
[4] <columnas name="<%next.getName()%>">
[5] <type name="<%next.getType().getName()%>">
[6] </columnas>
[7] <%}%>
[8] </tables>
(C) A. Sánchez L. 2016 42
Reglas mediante modelización, I
Hemos constatado que el enfoque por modelización consistía en aplicar los
conceptos de la ingeniería de los modelos a las transformaciones de los
modelos propios.
La idea es por lo tanto, modelar las transformaciones de los modelos.
Para realizar este enfoque, el OMG decidió a principios de 2001, poner en
marcha los trabajos de estandarización para definir un lenguaje que permita
elaborar modelos de transformación de modelos.
Estos trabajos de estandarización tratan de definir el metamodelo MOF2.0
QVT (Query, View, Transformation), que estructura estos modelos de
transformación de modelos. MOF2.0 QVT, la primera versión pública que
salió en 2008.
A pesar de que estos trabajos aún están todavía bajo investigación, parece
interesante presentarlos como el enfoque por modelización, y serán sin duda
muy importantes en los años venideros.
La siguiente figura ilustra este enfoque.
(C) A. Sánchez L. 2016 43
Enfoque por modelización
(C) A. Sánchez L. 2016 44
Reglas mediante modelización, II
La definición de la transformación de modelos es un modelo estructurado
según el metamodelo MOF2.0 QVT.
Los modelos instancias del metamodelo MOF2.0 QVT expresan las reglas de
correspondencia estructurales entre los metamodelos fuente y destino de una
transformación.
Este modelo es un modelo persistente y productivo, que debe ser transformada
para permitir la ejecución de la transformación en una plataforma de ejecución
La siguiente figura proporciona una visión simplificada del futuro metamodelo
MOF2.0 QVT, en el cual hemos representado las metaclases de QVT
necesarias en la comprensión de la filosofía de este estándar.
La metaclase Modulo representa una transformación de modelos. Esta
metaclase esta unida a la metaclase Paquete del metamodelo MOF2.0 por dos
meta asociaciones (fuente y destino).
Estas meta asociaciones permiten especificar cuales son los metamodelos
fuente y destino de la transformación.
(C) A. Sánchez L. 2016 45
Visión simplificada del futuro metamodelo
(C) A. Sánchez L. 2016 46
Reglas mediante modelización, III
Este metaclase está también unida por dos meta asociaciones a las metaclases
Consulta, Relacion y Mapeo.
Estos vínculos permiten especificar el conjunto de consultas, reglas de
correspondencia y reglas de construcción que componen una transformación.
La metaclase Consulta representa las consultas efectuadas en una
transformación de modelos.
Las consultas QVT son principalmente expresiones OCL que permiten navegar
en un modelo con el fin de obtener cierta información.
Las consultas no tienen efecto de borde, es decir que estas no modifican los
modelos sobre los cuales serán ejecutadas.
La metaclase Relación representa las reglas de correspondencia entre la partes
estructurales de los metamodelos fuente y destino. Esta metaclase esta unida a
la metaclase Dominio, que representa una sub parte estructural de un
metamodelo.
Más precisamente, un dominio es un subconjunto de un metamodelo.
(C) A. Sánchez L. 2016 47
Reglas mediante modelización, IV
Un dominio debe estar compuesto de al menos una metaclase del metamodelo y
puede contener todas las metaclases del metamodelo, con las meta asociaciones
que las unen.
Las relaciones no definen la construcción de elementos del modelo. Estas
expresan únicamente las correspondencias estructurales entre los metamodelos
sin definir la manera en como se realizan estas correspondencias.
Se pueden comparar estas relaciones a las reglas de la programación
declarativa, en el sentido donde estas permiten la declaración de
correspondencias estructurales y no en la realización de estas correspondencias.
La metaclase Mapeo representa las reglas de construcción. Esta metaclase esta
unida a la metaclase MatchingExpression, que representa el concepto de acción
de construcción.
Contrariamente a las relaciones, los mapeos especifican las correspondencias
estructurales entre metamodelos explicando, la manera de cómo deben
realizarse estas correspondencias.
(C) A. Sánchez L. 2016 48
Reglas mediante modelización, V
Los mapeos pueden compararse a las instrucciones de la programación
imperativa puestos que estos definen un conjunto de acciones a realizar para
establecer un correspondencia estructural.
Para resumir lo que expresa este metamodelo, se puede decir que una
transformación QVT se escribe en un modulo. Este modulo, que puede
contener consultas escritas en un lenguaje próximo de OCL, puede igualmente
contener reglas de transformación.
Estas últimas son ,ya sean reglas de correspondencia (enfoque declarativo) o
reglas de construcción (enfoque imperativo).
El estándar hace posible la construcción de una transformación mediante un
enfoque híbrido, que contiene a la vez reglas de correspondencia y reglas de
construcción.
(C) A. Sánchez L. 2016 49
Ejemplo de aplicación, I
En este ejemplo se está aplicando parcialmente el enfoque de modelado.
Hemos elegido ilustrar solamente la parte declarativa del metamodelo MOF2.0
QVT y hemos modelado de manera declarativa las reglas de transformación.
El modelo de la transformación simplemente expresa las relaciones
estructurales entre los metamodelos fuente y destino. Estas relaciones deben
ser traducidas o interpretadas por un motor de transformación, lo que permitirá
la ejecución de la transformación.
La figura del acetato 50 muestra una parte del modelo de transformación de
UML a BD.
Se utilizó una notación gráfica, que, sin ser estándar, permite representar con
eficacia los vínculos entre el modelo de transformación, sus metamodelos
origen y destino, y el metamodelo MOF2.0 QVT.
Los vínculos entre los elementos del modelo de transformación y el
metamodelo MOF2.0 QVT están representados por flechas punteadas. El
modulo de la transformación se representa por medio de un cuadrado.
(C) A. Sánchez L. 2016 50
Una parte de la transformación realizada por el
enfoque de modelización
(C) A. Sánchez L. 2016 51
Ejemplo de aplicación, II
Este cuadrado representa una instancia de la metaclase Modulo del
metamodelo MOF2.0 QVT.
Este cuadrado está relacionado con los paquetes UML y BD por dos enlaces
denominados fuente y destino.
Los paquetes UML y BD son también metamodelos instancias de la
metametaclase Paquete de MOF.
Estos enlaces permiten expresar que los modelos fuentes de la transformación
son consistentes con el metamodelo UML y que los modelos destino de la
transformación son consistentes con el metamodelo BD.
El módulo de la transformación contiene sólo una relación, representada
gráficamente por una elipse.
Esta relación, que es una instancia de la metaclase Relacion, representa la regla
de transformación, que consiste en hacer corresponder un tabla a una clase
UML.
Por tanto, esta relación referencia dos dominios representados por los círculos.
(C) A. Sánchez L. 2016 52
Ejemplo de aplicación, III
Estos dominios se referencian respectivamente a las metaclases Class y Table
de los metamodelos UML y BD.
El modelo de la transformación de UML a BD no es completo.
Sería necesario modelar de la misma manera las otras reglas de la
transformación.
Esta parte del modelo, permite sin embargo ilustrar el enfoque por
modelización.
