Upload
others
View
19
Download
0
Embed Size (px)
Citation preview
(C) A. Sánchez L. 2016 2
Introducción, I
En los temas anteriores, los modelos nos fueron presentados por medio de
metamodelos.
Así definidos, estos siguen siendo entidades teóricas abstractas altamente
volátiles y no se pueden almacenar o intercambiar en un soporte de datos.
Es difícil en estas condiciones hablar de persistencia.
Con esta parte se concluye la primera parte del curso MDA, el tratamiento de la
persistencia de los modelos con la introducción del estándar XMI (XML
Metadata Interchange) y DI (Diagram Interchange) del OMG, que permiten el
soporte computacional de los modelos para el almacenamiento y el
intercambio.
Para estos estándares, el OMG ha optado por confiar en el formato XML de
W3C, con un éxito indiscutible y que como sabemos está considerado como el
formato internacional de intercambio de datos.
También es posible utilizar XML como formato de tratamiento de los modelos ,
con el fin de desarrollar operaciones tales como la transformación de modelos.
(C) A. Sánchez L. 2016 3
Introducción, II
Queremos, por lo tanto insertar XMI en temas más avanzados, que se dedican
al estudio de la productividad de los modelos.
Sin embargo, consideramos que estos tratamientos son más idealmente
realizados, utilizando lenguajes orientados a objetos.
(C) A. Sánchez L. 2016 4
El formato XML
Esta sección no pretende presentar XML en detalle, sino más bien sirve como
recordatorio de los los conceptos importantes de este estándar que se
implementan en los estándares del OMG.
El lector ya está familiarizado con XML y domina los conceptos de espacio de
nombres, esquemas XML y el documento SVG, y entonces se podría saltar
esta parte e ir directamente a la sección sobre XMI.
Documentos bien formados
Un documento XML bien formado es un documento de texto estructurado por
un conjunto de etiquetas abiertas y cerradas.
Las etiquetas XML son fácilmente identificables porque comienzan con el
carácter < y terminan con el carácter >.
Entre estos dos caracteres, una cadena de caracteres alfanuméricos comienza
obligatoriamente por una letra y no contiene espacios, y representa el nombre
de la etiqueta.
(C) A. Sánchez L. 2016 5
Documentos bien formados, I
Un par de etiquetas de apertura y cierre debe tener el mismo nombre. La
etiqueta de cierre debe contener el carácter / justo después del carácter <.
Veamos un ejemplo de etiquetas XML:
<Libro> </Libro>
<MiEtiquetaNumero1> </MiEtiquetaNumero1>
Además de su nombre, una etiqueta de inicio puede contener un conjunto de
atributos.
Un atributo se caracteriza por un nombre y un valor.
En una etiqueta de inicio, los atributos aparecen después del nombre de la
etiqueta y están separados por el carácter de espacio.
El nombre de un atributo debe ser una cadena alfanumérica que no contiene
ningún espacio.
Su valor es una cadena entre comillas o apóstrofes. El nombre y el valor de un
atributo están separados por el carácter =.
A continuación se muestra un ejemplo de etiquetas XML con atributos:
(C) A. Sánchez L. 2016 6
Documentos bien formados, II
<Libro numero=‘1’> </Libro>
<MiEtiquetaNumero1 id=“a1”> </MiEtiquetaNumero1>
Entre un par de etiquetas de apertura y cierre, un documento XML bien
formado puede contener otras etiquetas, o cualquier cadena de caracteres.
Los caracteres < y > no deben entonces utilizarse, al menos deben protegerse.
Un documento XML debe comenzar obligatoriamente con una etiqueta de
apertura.
No es posible anidar de manera cruzada las etiquetas de apertura y cierre. Por
ejemplo, no es posible abrir la etiqueta A y la etiqueta B y cerrar la etiqueta A
antes de cerrar la etiqueta B.
Es perfectamente válido, en contraste anidar las etiquetas.
Veamos a modo de ejemplo, un documento XML bien formado:
<Libro titulo = "MDA">
<Autor Nombre = ‘Javier' Apellido = ‘Rojas'> </ Autor>
<Capítulo numero ='4' titulo = 'Modelos XML'>
(C) A. Sánchez L. 2016 7
Documentos bien formados, III
En los temas anteriores se ha insistido en la importancia de la persistencia en los
modelos MDA ...
</ Capítulo>
</ Libro>
El estándar XML define otras restricciones sintácticas en los documentos XML
bien formados, pero la presentación anterior es suficiente para nuestra
demostración.
Documentos válidos
Si un documento bien formado debe respetar una serie de restricciones
sintácticas, un documento válido debe respetar una estructura preestablecida de
un conjunto de etiquetas.
Tal estructura predeterminada puede, en el ejemplo anterior, especificar que la
etiqueta Capítulo debe estar incluida en la etiqueta libro.
Cualquier documento que respete la estructura preestablecida sería considerado
como válido.
(C) A. Sánchez L. 2016 8
Documentos válidos, I
El estándar XML proporciona los medios para definir estas estructuraciones de
las etiquetas, en particular a través del DTD y el XML Esquema.
DTD (Document Type Definition)
Históricamente, el primer medio propuesto para definir una estructura de
etiquetas era la construcción de un DTD.
Un DTD es un documento de texto que especifica una estructuración de un
conjunto de etiquetas mediante la definición de sus relaciones de inclusión.
La palabra clave ELEMENT se utiliza para definir una etiqueta. Debe ser
seguida por el nombre de la etiqueta y del conjunto de las etiquetas contenidas.
La palabra clave ATTLIST define un conjunto de atributos asociados a una
etiqueta. Esta palabra clave debe ser seguida por el nombre de la etiqueta que
contendrá los atributos y la lista de atributos.
El siguiente ejemplo especifica que la etiqueta Libro debe contener la etiqueta
Capítulo y esta debe tener un atributo nombrado título (la palabra clave
CDATA permite especificar que el valor del atributo titulo es una cadena de
caracteres):
(C) A. Sánchez L. 2016 9
Documentos válidos, II
<! ELEMENT Libro (Capítulo)>
<! ATTLIST Libro titulo CDATA>
Para completar este ejemplo, obviamente se deben especificar otras etiquetas,
como Capítulo, Autor, etc.
Los DTD proporcionan una manera sencilla de definir la estructura de un
conjunto de etiquetas.
Hoy en día hay varias propuestas de estructuración de las etiquetas XML
realizadas a través de los DTD. Sin embargo, esta definición adolece de varias
deficiencias.
Un DTD debe realizarse utilizando un formato de texto que no es XML. Por lo
tanto, no es posible manipular el DTD como manipulamos los documentos
XML.
Además, la expresión de los DTD es bastante limitada. No es posible reutilizar
fácilmente una estructura existente con el fin de enriquecer o de definir órdenes
particulares de inclusión de la secuencia.
(C) A. Sánchez L. 2016 10
Documentos válidos, III
Por todas estas razones, el W3C ha desarrollado el estándar XML esquema, que
permite definir la estructuración de etiquetas XML ofreciendo más
posibilidades.
XML Schema
Los esquemas XML se han estandarizado por el W3C para reemplazar los DTD
debido a su flexibilidad para definir las estructuraciones de las etiquetas XML.
A diferencia de los DTD, los esquemas XML están definidos por los
documentos XML. Por lo tanto, es posible manipular cualquier documento
XML.
Los esquemas XML también permiten definir los tipos de estructuración. Es
posible volver a utilizar estos tipos para ampliarlos o restringirlos.
Estos se basan en un sistema de tipeado mucho más completo que el de los
DTD (compuesto solamente del tipo String). Es posible, por ejemplo, decir que
el valor de un atributo debe ser un número entero o un booleano.
El siguiente ejemplo muestra la definición de la etiqueta Libro en XML
Schema.
(C) A. Sánchez L. 2016 11
Documentos válidos, IV
Este esquema XML especifica que la etiqueta Libro tiene un tipo complejo
(complexType) y que este tipo complejo es un secuencia de Capitulo
(sequence, element):
<element name = 'Libro'>
<complexType>
<sequence>
<element ref = 'Capítulo'> </ element>
</ sequence>
</ complexType>
</ element>
Para completar este ejemplo, obviamente se debe proporcionar la definición de
otras etiquetas (Capítulo, Autor, etc.).
La definición de una estructuración de etiquetas en XML esquema es sin
embargo mucho más complejo de lo que es con un DTD. Esto explica en parte
por qué actualmente hay poca estructuración de las etiquetas XML realizadas
en XML esquema.
(C) A. Sánchez L. 2016 12
Otras técnicas XML, I
Dado que XML permite definir fácilmente conjuntos de etiquetas, no es raro
ver a las etiquetas con los mismos nombres como fueron definidas por
diferentes usuarios con diferentes significados.
Podríamos, por ejemplo, imaginar que la etiqueta <direccion> significaría ya
sea una dirección postal, dirección de correo electrónico, o por qué no, una
dirección de memoria.
Las etiquetas con nombres muy genéricos como <contenido>, <extension>,
<lista> o <elemento>, a menudo tienen diferentes significados.
Esta incertidumbre en los significados es obviamente problemática si queremos
usar estas etiquetas en un mismo documento XML.
Así podríamos imaginar un documento XML utilizando varias veces las
etiquetas <lista> y <contenido> pero con diferentes significados.
Entonces sería imposible encontrar el verdadero significado asociado a cada
etiqueta.
Este problema es muy importante para el uso de XML en MDA.
(C) A. Sánchez L. 2016 13
Otras técnicas XML, II
De hecho, las etiquetas definidas como <Clase> y <Paquete> tienen diferentes
significados dependiendo de si están asociadas con MOF o UML o según las
diferentes versiones de estos estándares.
Para abordar este problema de conflicto de nombrado, el W3C ha definido el
concepto de espacio de nombres (namespace).
Namespace XML
Un espacio de nombres se utiliza para agrupar un conjunto de etiquetas y de
precisar en un documento XML a que espacio de nombres pertenecen las
etiquetas.
El espacio de nombres por lo tanto se utiliza para agrupar diferentes etiquetas
con un significado común.
Un espacio de nombres se define simplemente por una URL. Es posible asociar
a esta URL una lista de etiquetas, un DTD o un XML esquema.
Por ejemplo, el OMG definió la URL en su página
http://www.omg.org/spec/UML/1.3/, para el espacio de nombres de las
etiquetas de UML1.3.
(C) A. Sánchez L. 2016 14
Otras técnicas XML, III
Para precisar a que espacio de nombres pertenece una etiqueta, simplemente se
procede de la siguiente manera:
1. Asociar un alias al espacio de nombres. Esto se hace mediante el atributo
xmlns, que podemos asociar con cualquier etiqueta de apertura.
2. Prefijar las etiquetas que pertenecen a este espacio de nombres con el alias del
espacio de nombres.
El siguiente ejemplo asocia el alias uml13 al espacio de nombres de las
etiquetas UML1.3 y muestra cómo utilizar este alias para identificar claramente
las etiquetas utilizadas:
<document xmlns: uml13 = "http://www.omg.org/spec/UML/1.3/ ">
<uml13: Class>
</ Uml13: Class>
</ document>
XSLT (eXtensible Stylesheet Language Transformations)
(C) A. Sánchez L. 2016 15
Otras técnicas XML, IV
XML permite representar de una manera estructurada cualquier tipo de
información, es necesario poder transformar los documentos XML con el fin de
beneficiarse de la información que contienen.
El W3C propuso el estándar XSLT (eXtensible Stylesheet Language
Transformations) para elaborar transformaciones de documentos XML.
El enfoque definido en este estándar permite especificar transformaciones de
documentos XML utilizando plantillas (templates).
Una plantilla se compone de una cláusula de aplicación (cláusula match) y un
conjunto de instrucciones.
El principio de funcionamiento de XSLT consiste en recorrer un documento
XML dado como entrada de una transformación para detectar cuales plantillas
se pueden aplicar.
Una vez que se detecta una plantilla que sea aplicable, se ejecuta el conjunto de
instrucciones que se definen. Este conjunto de instrucciones que tiene como
objetivo la construcción de un nuevo documento, en este caso el documento de
salida de la transformación.
(C) A. Sánchez L. 2016 16
Otras técnicas XML, V
Se utiliza el estándar XSLT, por ejemplo, para transformar los documentos
XML en documentos HTML para que sean documentos XML presentables en
los navegadores web.
Aquí, por ejemplo, una parte de la transformación XSLT permite generar un
documento HTML a partir de un documento XML que representa un libro.
Este ejemplo muestra una plantilla aplicable a las etiquetas <Libro>. La
secuencia de instrucciones de esta plantilla permite construir las etiquetas
<HTML> y <HEAD>, basta con insertar un texto que precise el titulo del libro
gracias a la instrucción <value-of>):
<template match = "/Libro">
<HTML>
<HEAD>
Pagina correspondiente al libro <value-of select = "@titre" />
</ HEAD>
</ template>
(C) A. Sánchez L. 2016 17
Otras técnicas XML, VI
SVG (Scalable Vector Graphics)
SVG (Scalable Vector Graphics) es un lenguaje XML estandarizado por el
W3C para representar figuras gráficas vectoriales bajo la forma de documentos
XML. Una de las ventajas de SVG es poder utilizarlo con XSLT para
transformar documentos XML en figuras gráficas.
Veremos que esto tiene un gran interés para MDA, ya que permite representar
los diagramas gráficos de los modelos como documentos XML y así facilitar su
intercambio y su persistencia.
El siguiente ejemplo es un documento SVG que representa tres círculos
(etiqueta círculo) de color (ver la figura del acetato 18):
<?xml version="1.0"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN"
"http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">
<svg xmlns="http://www.w3.org/2000/svg">
<style type="text/css">
circle:hover {fill-opacity:0.9;}
</style>
(C) A. Sánchez L. 2016 18
Otras técnicas XML, VII
<g style="fill-opacity:0.7;">
<circle cx="6.5cm" cy="2cm" r="100" style="fill:red; stroke:black;
stroke-width:0.1cm" transform="translate(0,50)" />
<circle cx="6.5cm" cy="2cm" r="100" style="fill:blue; stroke:black;
stroke-width:0.1cm" transform="translate(70,150)" />
<circle cx="6.5cm" cy="2cm" r="100" style="fill:green; stroke:black;
stroke-width:0.1cm" transform="translate(-70,150)"/>
</g>
</svg>
Veremos más adelante, que SVG se utiliza para representar las partes gráficas,
diagramas, o modelos UML.
(C) A. Sánchez L. 2016 19
XMI (XML Metadata Interchange), I
Dado que los modelos eran entidades abstractas, los cuales no disponen de una
representación intrínsecamente computacional.
El OMG decidió estandarizar XMI, que ofrece una representación concreta de
los modelos en forma de documentos XML.
El principal objetivo de XMI es definir una forma de representar un modelo
como un documento XML.
Para precisar cómo realizar esta representación, el OMG utiliza los mecanismos
de definición de la estructura de las etiquetas XML DTD y XML Schema.
XMI permite de hecho definir las estructuraciones de las etiquetas necesarias y
suficientes para la representación de los modelos en formato XML.
Para definir estas estructuraciones de etiquetas, XMI se basa en la alineación
existente entre los modelos y su metamodelo, por un lado, y de los documentos
XML y su estructuración, por otro lado.
Los metamodelos y las estructuraciones de etiquetas son similares en que estas
definen las estructuras de los modelos y los documentos XML respectivamente.
La siguiente figura ilustra esta alineación.
(C) A. Sánchez L. 2016 21
XMI (XML Metadata Interchange), II
La estructuración de las etiquetas XML que permiten la representación de
modelos como documento XML se basa en los metamodelo de los modelos.
Por ejemplo, la estructuración de etiquetas XML que permite representar
modelos UML como documento XML se basa en el metamodelo UML.
A continuación se detallan las reglas de generación de etiquetas XML.
La alineación de los metamodelos y de las estructuraciones de etiquetas XML
permite a XMI definir un conjunto de reglas para la generación automática de
estructuración de etiquetas XML a partir de un metamodelo.
Este proceso se indica con (1) en la figura del acetato 22.
Con esta estructuración de etiquetas XML, es posible representar los modelos
en forma de documentos XML.
Esta operación se denomina serialización del modelo en el formato XML.
La parte indicada como (2) en la figura, se beneficia del mecanismo de
validación propuesto por XML y proporciona una representación en el formato
XML de mejor calidad.
(C) A. Sánchez L. 2016 23
Reglas de generación de etiquetas XML, I
Estas reglas de generación de la estructuración de etiquetas XML a partir de un
metamodelo son bastante naturales.
Presentamos las siguientes reglas, aunque muy simplificadas, permiten captar
la filosofía de XMI.
Estas reglas aceptan como entrada un metamodelo MOF1.4. Numeramos estas
reglas para identificarlas más adelante en estas notas.
Reglas XMI de generación de DTD a partir de un metamodelo MOF1.4:
1. Toda metaclase proporciona la definición de una etiqueta que tiene como
nombre, el nombre de la metaclase. Esta etiqueta debe tener un atributo XML
llamado id que permite identificar la instancia de la metaclase con la finalidad
de referenciarla cuando sea necesario.
2. Todo meta-atributo de una metaclase proporciona la definición de una etiqueta
que tiene como nombre, el nombre del meta-atributo meta. El contenido de la
etiqueta representará el valor del meta-atributo. Esta etiqueta debe estar
contenida en la etiqueta correspondiente a la metaclase que contiene el
atributo.
(C) A. Sánchez L. 2016 24
Reglas de generación de etiquetas XML, II
3. Toda meta-referencia de una metaclase proporciona la definición de una
etiqueta que tiene como nombre, el nombre de la meta-referencia. El
contenido de la etiqueta representará un id que identifica la instancia
referenciada. Esta etiqueta debe estar contenida en la etiqueta que corresponde
a la metaclase que contiene la referencia.
4. Toda meta-asociación entre dos metaclases proporciona la definición de una
etiqueta que tiene como nombre, el nombre de la meta-asociación. El
contenido de la etiqueta contendrá las instancias conectadas o los id que las
identifica. Si la meta-asociación es navegable, la etiqueta de la meta-
asociación debe estar contenida en la etiqueta que corresponde a la metaclase
fuente de la asociación.
Ejemplo de aplicación en un metamodelo sencillo
Hemos elegido aplicar las reglas XMI al ejemplo de metamodelo presentado
anteriormente.
Recordemos que este metamodelo consta de tres metaclases y que permite
modelar procesos simples (ver la figura del acetato 25).
(C) A. Sánchez L. 2016 25
Ejemplo de aplicación de las reglas , I
Las meta-clases de este metamodelo se incluyen en un meta-paquete llamado
MMProceso.
Si aplicamos las cuatro reglas presentadas anteriormente, obtenemos el
siguiente DTD:
(C) A. Sánchez L. 2016 26
Ejemplo de aplicación de las reglas , II
<!ELEMENT Proceso (ProcesoATransicion , ProcesoAEtapa) >
<!ATTLIST Proceso id ID> /* regla 1 y regla 4*/
<!ELEMENT Etapa (nombre) >
<!ATTLIST Etapa id ID> /* regla 1 */
<!ELEMENT Transicion (in, out) >
<!ATTLIST Transicion id ID> /* regla 1 y regla 4*/
<!ELEMENT ProcesoATransicion #PCDATA> /* regla 4*/
<!ELEMENT ProcesoAEtapa #PCDATA> /* regla 4*/
<!ELEMENT nombre #PCDATA> /* regla 2 */
<!ELEMENT in #PCDATA> /* regla 4 */
<!ELEMENT out #PCDATA> /* regla 4 */
La regla 1 proporciona la definición de las etiquetas Proceso, Etapa y
Transicion. La regla 2 proporciona la definición de la etiqueta nombre. La regla
2 no se utiliza.
La regla 4 proporciona la definición de las etiquetas ProcesoATransicion y
ProcesoAEtapa, donde los nombres se han generado a partir de los nombres de
las metaclases, y la definición de las etiquetas in y out.
(C) A. Sánchez L. 2016 27
Ejemplo de aplicación de las reglas , III
Gracias a este DTD, es posible representar los modelos del proceso de acuerdo a
este metamodelo bajo la forma de documentos XML. Por ejemplo, el modelo de
proceso compuesto únicamente de dos etapas denominadas inicio y fin conectadas
por una transición se representa por un documento XML de la siguiente manera:
<Proceso id=’p1’>
<ProcesoAEtapa>
<Etapa id=’e1’>
<nombre>inicio</nombre>
</Etapa>
<Etapa id=’e2’>
<nombre>fin</nombre>
</Etapa>
</ProcesoAEtapa>
<ProcesoATransicion>
<Transicion>
<in idref=’e1’/>
<out idref=’e2’/>
</Transicion>
</ProcesoATransicion>
</Proceso>
(C) A. Sánchez L. 2016 28
Estado actual de XMI, I
Las secciones anteriores han presentado el principio de funcionamiento de
XMI, que consiste en permitir la generación automática de la definición de
estructuración de etiquetas XML a partir de un metamodelo.
Hemos mostrado que este mecanismo permite representar cualquier modelo en
el formato XML.
Cada nueva versión de XMI mejora el conjunto de estas reglas con el fin de
generar las definiciones de estructuración de etiquetas, siempre más adecuadas
a la representación de los modelos como documento XML.
La primera versión de XMI, XMI1.0 permitía sólo generaciones relativamente
resumidas de los DTD a partir de metamodelos MOF1.3.
Esta versión sufría inevitablemente de deficiencias de los DTD. Estos sólo
disponían de un sistema de tipeado resumido (únicamente cadenas de
caracteres), no era posible sacar el máximo provecho de los documentos XML
de los tipos de metamodelos (sistema de tipeado completo).
El DTD generado también carecía de flexibilidad en cuanto a las posibilidades
de organización de las etiquetas XML.
(C) A. Sánchez L. 2016 29
Estado actual de XMI, II
Es por lo tanto necesario seguir un orden preestablecido completamente
arbitrario, que no fue impuesto por el metamodelo.
Era necesario, por ejemplo, para los modelos UML, que los casos de uso
aparecieran antes de las clases en los documentos XML.
Además, el nombre asociado con la etiqueta XML correspondiente a cada
metaclase de un metamodelo debe integrar plenamente los nombres de la
jerarquía de paquetes que contienen la metaclase.
La etiqueta correspondiente a la metaclase caso de uso (UseCase) se llamaba
entonces Behavioral_Elements.Use_Cases.UseCase y es la que corresponde al
nombre del caso de uso llamado Foundation.Core.ModelElement.name ya que
el nombre de un caso de uso fue heredado de la metaclase ModelElement.
Por lo tanto, los documentos XML que representan los modelos eran
particularmente detallados (“verbosos”) y sólo contenían poca información útil.
Basado en los metamodelos MOF1.4, la segunda versión de XMI, XMI1.1
mejora dramáticamente todas las reglas XMI1.0.
(C) A. Sánchez L. 2016 30
Estado actual de XMI, III
También la ganancia notable de flexibilidad que aporta a la organización de las
etiquetas XMI, y se beneficia de la estandarización del mecanismo de espacio
de nombres XML, lo que reduce significativamente el tamaño de los nombres
de las etiquetas asociándolos a un mismo espacio de nombres.
XMI1.1 define un mecanismo que permite representar sub partes de los
modelos como documentos XML.
Este mecanismo es muy útil para realizar, por ejemplo, actualizaciones de los
modelos y transmitir solamente las sub partes de los modelos que han
cambiado.
A pesar de todos estos avances, esta versión sufre inevitablemente de lagunas
en los DTD en lo referente al tipeado de los datos.
La tercera versión de XMI, XMI 1.2, no ofrece ningún avance, pero corrige
todos los pequeños errores de la versión 1.1.
Notablemente más estable, esta versión está siendo normalizado por la ISO
(International Standardization Organization) .
Una extensión de XMI1.2 puede beneficiarse de los esquemas XML.
(C) A. Sánchez L. 2016 31
Estado actual de XMI, IV
El propósito de esta extensión es generar ya sea DTDs, o esquemas XML a
partir de los metamodelos.
La adición del esquema XML a XMI es importante ya que proporciona los
mecanismos de tipeado de forma más interesante.
Con esta extensión, XMI no tiene que sufrir las deficiencias de los DTD.
La versión XMI2.0 no se basa en los metamodelos MOF2.0, al contrario de lo
que sugiere su nombre, pero si en los de MOF1.4.
Esta versión utiliza las reglas de la extensión a XMI1.2 que permiten generar
los esquemas XML y los mejora.
Este estándar también propone construir automáticamente un metamodelo a
partir de un esquema XML.
Este enfoque es sin embargo, aplicable para el momento en que los esquemas
XML respetan las restricciones fuertes.
Será necesario esperar la versión XMI2.1, en fase de desarrollo, para encontrar
los metamodelos MOF2.0 y permitir la generación de esquemas XML.
(C) A. Sánchez L. 2016 32
El problema del intercambio de modelos, I
Cuando se publicó la primera versión de XMI, se suponía que este estándar
permitía que todas las herramientas existentes pudieran intercambiar modelos
UML.
Esto es al menos lo que había anunciado el OMG y no parece presentar
ninguna dificultad importante.
Más de cinco años después de la publicación de este estándar, está claro que no
siempre es posible intercambiar los modelos UML entre las herramientas del
mercado que utilizan XMI.
La primera razón de este fracaso proviene de la multitud de versiones de los
estándares que participan en la forma de intercambio de modelos UML entre
las diferentes herramientas.
La serialización de un modelo UML como un documento XML depende de
hecho en las versiones de XMI, de MOF y de UML.
Ahora hay cuatro versiones de XMI, cuatro de UML y tres de MOF.
Dado que cada versión de XMI está fuertemente vinculada a una única versión
de MOF.
(C) A. Sánchez L. 2016 33
El problema del intercambio de modelos, II
Sólo las versiones de XMI y de UML entran en consideración para el
intercambio de los modelos UML.
La siguiente tabla muestra las diferentes combinaciones para representar los
modelos UML como documento XML.
Es posible intercambiar los modelos UML1.3, UML1.4 y UML1.5 según las
cuatro versiones diferentes de XMI.
Como no existe ninguna recomendación oficial del OMG que promueva una
combinación más que otra, cada herramienta elige una o varias posibilidades.
XMI1.0 DTD XMI1.1 DTD XMI1.2 DTD XMI1.2 Schema XMI2.0 Schema XMI2.1 Schema
UML 1.3 X X X X
UML 1.4 X X X X X
UML 1.5 X X X X X
UML 2.0 X
(C) A. Sánchez L. 2016 34
El problema del intercambio de modelos, III
De este hecho, la posibilidad de intercambio de modelos UML entre
herramientas es todo menos evidente.
La tabla anterior también muestra que será posible intercambiar los modelos
UML2.0 en una única versión de XMI.
El intercambio de modelos UML 2.0 deberá facilitarse en gran medida.
La segunda razón del fracaso tiene relación del como funciona XMI con
respecto a la flexibilidad de la organización de las etiquetas XML.
Cada nueva versión de XMI ofrece más flexibilidad en la organización de las
etiquetas XML. Esta flexibilidad es interesante ya que ofrece más opciones de
representación de los modelos UML como documentos XML.
A cambio, esto tiene el gran inconveniente de aumentar significativamente la
complejidad de la lectura de los documentos XML que representan los modelos
UML.
Para leer correctamente un documento XML que representa un modelo UML,
se debe ser capaz de leer todas las posibilidades de organización.
(C) A. Sánchez L. 2016 35
El problema del intercambio de modelos, IV
Este conjunto de organizaciones es muy importante en el caso de UML.
Esto explica por qué algunas herramientas no son aún capaces de importar los
modelos UML por si solos y que todavía exportan como documentos XML.
Esta segunda razón es aún válida con UML2.0.
Parece que las herramientas de manipulación de los documentos XML son más
fáciles de usar y más potentes y que estas contribuyen a mejorar la gestión de
esta complejidad.
Desafortunadamente, no podemos verificar cuando estarán disponibles en el
mercado una gran cantidad de herramientas que soporten UML 2.0.
(C) A. Sánchez L. 2016 36
DI (Diagram Interchange), I
No es del todo exacto decir que el estándar XMI permite representar los
modelos como un documento XML.
XMI solo permite representar la información del documento XML cuya
estructura se define en un metamodelo.
En otras palabras, la información cuya estructura no está definida en un
metamodelo no puede representarse como un documento XML bajo las reglas
del estándar estructura XMI.
Vimos que en UML, la parte gráfica de los modelos, es decir, los diagramas, no
estaban definidos en el metamodelo UML. Por lo tanto, no es posible
representar los diagramas UML en los documentos XML.
Esto no deja de ser un problema. Aunque es posible rediseñar un diagrama de
clases, es mucho más problemático rediseñar los diagramas de estados o de
secuencia, por ejemplo.
Además, un modelo UML obtenido a partir de un documento XML no sabe
cuántos diagramas se deben diseñar.
(C) A. Sánchez L. 2016 37
DI (Diagram Interchange), II
Decir que necesitamos un paquete es demasiado simplista y demasiado
arbitrario.
El número de diagramas y su contenido son, sin embargo de suma importancia
para el intercambio de información.
Para hacer frente a esta dificultad, el OMG ha definido un estándar específico
bajo el nombre de DI (Diagrama Interchange).
Este estándar tiene como objetivo permitir la representación en el formato
XML de las partes gráficas de los modelos UML.
Principio de funcionamiento de DI
El enfoque definido por DI para permitir la representación en el formato XML
de las partes gráficas de los modelos UML se apoya fuertemente en XMI.
La idea es definir un nuevo metamodelo, vinculado al metamodelo UML, que
representa bajo la forma de metaclases los lenguajes gráficos necesarios y
suficientes en la representación de todas las partes gráficas de UML.
(C) A. Sánchez L. 2016 38
Principio de funcionamiento de DI, I
El objetivo es aplicar XMI a este metamodelo con el fin de obtener la
especificación de estructuración de las etiquetas XML que permiten representar
estas partes gráficas en XML. Veamos a continuación este principio.
(C) A. Sánchez L. 2016 39
Principio de funcionamiento de DI, II
Además de este principio de funcionamiento, DI define una transformación
XML que permite generar automáticamente los documentos SVG a partir de
documentos XML que representan los modelos UML y sus partes gráficas.
Esta generación permite visualizar los modelos UML en cualquier herramienta
que soporte SVG.
Dado que esta generación es un estándar, es además posible intercambiar
completamente los modelos UML, y también partes gráficas.
La figura del acetato 40 ilustra el uso de SVG en el estándar DI.
Podemos representar al DI, por un lado, como la aplicación del estándar XMI a
un nuevo metamodelo que representa la parte gráfica de UML, y por otro lado,
como la generación automática de un documento SVG que se muestra
gráficamente en las herramientas existentes.
El metamodelo que representa la parte gráfica es de muy bajo nivel.
Mas bien que definir las metaclases relativas a los diferentes diagramas UML
(diagramas de clases, de secuencias, de componentes, de despliegue, etc.).
(C) A. Sánchez L. 2016 41
Principio de funcionamiento de DI, III
Este define las metaclases que permiten representar cualquier elemento gráfico
en forma vectorial, es decir esencialmente en la forma de nodos conectados por
arcos.
Este metamodelo es relativamente simple. Las metaclases principales que este
define son las metaclases GraphNode y GraphEdge.
Gracias a estas dos metaclases, es posible representar cualquier elemento
gráfico.
Estas dos metaclases heredan de la metaclase GraphElement, que permite
representar cualquier elemento gráfico.
Esta metaclase tiene también un meta-atributo llamado Position que permite
localizar el elemento en una cuadrícula (rejilla) 2D.
Esta metaclase hereda de la metaclase DiagramElement y está conectada por
una meta-asociación de agregación.
Esto permite expresar que un elemento gráfico puede ser un elemento
complejo, si este está definido por la composición de varios elementos gráficos.
(C) A. Sánchez L. 2016 42
Principio de funcionamiento de DI, IV
El metamodelo define la metaclase Diagram, que hereda de la metaclase
GraphNode y representa un diagrama gráfico.
La siguiente figura ilustra estas diferentes metaclases.
(C) A. Sánchez L. 2016 43
Principio de funcionamiento de DI, V
La dependencia entre el metamodelo DI y el meta modelo UML se efectúa a
través de las metaclases GraphElement y SemanticModelBridge.
La metaclase GraphElement está conectada a la metaclase
SemanticModelBridge por una meta-asociación de agregación.
Esto permite expresar una dependencia semántica entre un elemento gráfico y
un elemento de un modelo.
La metaclase SemanticModelBridge se hereda por la metaclase
Uml1SemanticModelBridge, que está conectada a la metaclase Core::Element
del metamodelo UML1.4 que representa cualquier elemento del modelo UML.
Gracias a estos enlaces, es posible especificar que un elemento gráfico
(GraphElement) es el representante gráfico de un elemento semántico de un
modelo UML (Core::Element).
En la versión actual del DI, esta relación sólo es posible entre los elementos
gráficos y los elementos de los modelos UML1.4.
Por lo tanto, no es posible usar DI para los modelos UML 2.0.
(C) A. Sánchez L. 2016 44
Principio de funcionamiento de DI, VI
Sin embargo, dado que el metamodelo UML2.0 define el mismo la metaclase
Element, habrá pocas mejoras al DI por que este soporte a UML 2.0.
La siguiente figura ilustra las diferentes metaclases que permiten una
asociación semántica entre un elemento gráfico y un elemento de un modelo
UML1.4.
(C) A. Sánchez L. 2016 45
Ejemplo del uso de DI, I
Para concluir esta presentación del estándar DI, vamos a ilustrar su aplicación a
través del ejemplo de la figura.
Este ejemplo, relativamente sencillo, se compone sólo de un diagrama de clases
que contiene una sola clase.
Diagrama UML para serializar en el formato XML utilizando XMI y DI.
La figura del acetato 47 muestra el modelo conforme al metamodelo DI que
representa la parte gráfica del modelo UML de esta figura anterior.
Dado que este modelo es relativamente complejo, hemos optado por
presentarlo utilizando una notación similar a la de los diagramas de instancias
UML (objetos).
Cada instancia de una metaclase está representada por un cuadrado.
(C) A. Sánchez L. 2016 46
Ejemplo del uso de DI, II
El texto asociado con el cuadrado está constituido del nombre de la instancia
seguido por el nombre de su metaclase, ambos nombres separados están
separados por el carácter dos puntos.
Los vínculos entre los cuadrados representan los vínculos entre instancias.
Este modelo consiste de ocho instancias. La instancia diag1 de la metaclase
Diagram representa el diagrama gráfico.
La instancia class de la metaclase GraphNode representa la parte gráfica de la
clase UnaClase.
Las instancias operationCompartment, attributeCompartment y
nameCompartment representan respectivamente las partes gráficas de la clase
UnaClase que corresponde a las operaciones, a los atributos y al nombre (su
metaclase es la metaclase CompartmentGraphNode).
Es por ello que estas instancias están relacionadas con la instancia class. La
instancia attributeCompartment se une a una instancia atrribute, que es una
instancia de la metaclase GraphNode. Este ejemplo se orienta a la
representación gráfica del atributo.
(C) A. Sánchez L. 2016 48
Ejemplo del uso de DI, III
En esta etapa del modelo, es necesario agregar las instancias que permitan
realizar el vínculo semántico con el modelo UML.
Se establecerán dos enlaces en este ejemplo, uno hacia la clase UML y el otro
hacia el atributo, ya que sólo estos dos elementos tienen una existencia en el
metamodelo de UML.
La figura del acetato 49 muestra el vínculo semántico entre la clase UML y su
parte gráfica.
Constatamos que la instancia de la metaclase class, que representa la semántica
de la clase UML se relaciona con la instancia bridge de la metaclase
Uml1SemanticModelBridge, esta misma vinculada a la instancia class ilustrada
en la figura del acetato 47.
Estas instancias representan la modelación del vínculo entre la parte gráfica del
modelo UML y su parte semántica.
Hemos voluntariamente ocultado una gran parte de este modelo, que es en
realidad mucho más complejo.
(C) A. Sánchez L. 2016 49
Vínculos semánticos entre DI y UML
Conviene por lo tanto agregar todas las instancias que permitan modelar los
cuatro rasgos que forman el cuadrado gráfico de la clase, así como las
instancias que permiten representar todas las cadenas de caracteres, etc.
Tal y como se representa aquí, este ejemplo es sin embargo suficiente para
comprender el enfoque DI.
El modelo ilustrado en parte en las figuras del acetato 49 y del acetato 47
pueden por lo tanto serializarse en un documento XMI.
(C) A. Sánchez L. 2016 50
Ejemplo del uso de DI, IV
Como la representación gráfica y la semántica de un modelo de UML, este
documento XMI garantiza una completa persistencia del modelo UML.
Además, es posible aplicar la generación de un documento SVG, con el fin de
visualizar la parte gráfica del modelo en una herramienta que soporte el
estándar SVG.