los modelos en xmlasanchez/mda/modelos_xml.pdf · las etiquetas con nombres muy genéricos como , ,...

Los modelos en XML

Abraham Sánchez López

FCC/BUAP

Grupo MOVIS

(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.


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.


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.


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:


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'>


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.


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):


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.


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.


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.


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.


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.


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)


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.


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>


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>


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.


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.


Alineación entre metamodelo/modelo y

DTD/documento XML


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.


XMI y la estructuración de etiquetas XML


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.


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).


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:


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.


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>


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.


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.


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.


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.


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.


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


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.


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.


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.


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.


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.


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.).


Utilización del estándar SVG en DI


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.


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.


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.


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.


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.


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.


Representación del modelo de la parte

gráfica


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.


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.


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.

los modelos en xmlasanchez/mda/modelos_xml.pdf · las etiquetas con nombres muy genéricos como , ,...

Documents