Modelos y niveles meta

Modelos y niveles meta

Abraham Sánchez López

FCC/BUAP

Grupo MOVIS

(C) A. Sánchez L. 2016 2

Introducción

Si MDA está basado en la utilización masiva de los modelos en todas las fases

del ciclo de vida de las aplicaciones, los metamodelos son sus elementos de

estructuración.

Es por este intermediario que MDA garantiza la persistencia de los modelos.

Anteriormente, supimos que MDA requería la utilización de distintos tipos de

modelos (CIM, PIM, PSM, etc.).

Cada tipo de modelo se elaboraba en un formalismo particular.

MDA debe pues definir precisamente los distintos formalismos que permiten

elaborar modelos que sean persistentes y productivos.

Consciente de la dificultad inherente en la definición de formalismos de

modelización, el OMG en primer lugar definió el soporte de definición de los

formalismos de modelización.

A tal efecto, concibió el estándar MOF (Meta Object Facility), que aporta el

soporte de definición de los formalismos de modelización en forma de

metamodelos.


Los metamodelos, I

Según MOF, un metamodelo define la estructura que debe tener todo modelo

conforme a este metamodelo.

Es decir, todo modelo debe respetar la estructura definida por su metamodelo.

Por ejemplo, el metamodelo UML define que los modelos UML contienen

paquetes, sus paquetes de las clases, sus clases de los atributos y de las

operaciones, etc.

La siguiente figura ilustra la relación entre un metamodelo y el conjunto de los

modelos que él estructura.

Los metamodelos proporcionan la definición de las entidades de un modelo, así

como las propiedades de sus conexiones y sus reglas de coherencia.

MOF las representa en forma de diagramas de clases.

Recordemos que los diagramas de clases permiten representar los conceptos de

un ámbito y sus propiedades, que estos conceptos o entidades estén organizados

o no en forma de objetos.


Los metamodelos, II

Esta utilización de los diagramas de clases tiene la doble ventaja de permitir

definir muy precisamente los metamodelos y de volverlos por lo tanto

persistentes y productivos.

Un metamodelo es por lo tanto una clase de diagrama de clases que define la

estructura de un conjunto de modelos.


Metamodelo y semántica de un modelo

Metamodelo y semántica de un modelo son dos cosas diferentes.

Un metamodelo define la estructura de un conjunto de modelos pero

proporciona poca precisión sobre su semántica.

Definir que un modelo UML contiene paquetes, y que, ellos mismos, contienen

clases, no informa de ningún modo sobre el significado de los conceptos de

paquete y de clase.

MDA no da ninguna recomendación para definir la semántica de un modelo.

Esto se hace principalmente por medio del lenguaje natural, en este caso el

inglés para los estándares de MDA.


Ejemplos de metamodelos

Antes de definir precisa y teóricamente lo que son los metamodelos, nos parece

importante presentar dos ejemplos.

Mostraremos así, a quienes sirven los metamodelos y cómo se elaboran

conceptualmente.

Metamodelo del diagrama de caso de uso

El primer metamodelo ejemplo que presentamos es el de una versión reducida

de UML.

Consideraremos inicialmente que esta versión sólo contiene diagramas de caso

de uso.

Nuestro propósito no es explicar cómo hacer diagramas de caso de uso, sino de

presentar el metamodelo de los diagramas de casos de uso.

Nos interesamos solamente por la estructura de estos diagramas.

La siguiente definición de los diagramas de casos de uso no es estándar, pero la

proponemos con el fin de que facilite nuestra presentación:


Metamodelo del diagrama de casos de uso

« Un diagrama de casos de uso contiene actores, un sistema y casos de uso.

Un actor tiene un nombre y está conectado a los casos de uso.

Un actor puede heredar de otro actor.

Un caso de uso tiene un título y puede extender o incluir otro caso de uso.

El sistema tiene también un nombre, e incluye todos los casos de uso. »

La información que representa los conceptos fundamentales de los diagramas

de casos de uso está en negrita y las relaciones existentes entre estos conceptos

en cursiva.

El metamodelo que corresponde a estos diagramas de casos de uso es una clase

de diagrama de clases, en la cual cada concepto fundamental está representado

con la ayuda de una clase y cada relación existente entre conceptos con ayuda

de una asociación.

La siguiente figura ilustra este metamodelo.

Contiene tres clases, actor, sistema y caso de uso. La clase actor posee un

atributo denominado nombre, cuyo tipo es una cadena de caracteres.


Más detalles del metamodelo, I

La clase caso de uso posee un atributo denominado titulo, donde el tipo es una

cadena de caracteres.

La clase sistema posee un atributo denominado nombre, cuyo tipo es una

cadena de caracteres.

Este metamodelo contiene a una asociación denominada hereda, que tiene la

clase actor como fuente y como objetivo.

Contiene también dos asociaciones, extiende e incluye, que tienen como fuente

y como objetivo la clase caso de uso.

Contiene finalmente una relación de agregación entre la clase sistema y la clase

caso de uso.

Este metamodelo define que los modelos en conformidad con él no pueden

contener más que actores, sistemas y casos de uso.

Un actor tiene un nombre, un caso de uso tiene un título y un sistema tiene un

nombre.


Más detalles del metamodelo, II


Más detalles del metamodelo, III

Este metamodelo define también que los modelos conformes pueden evidenciar

las relaciones de herencia entre los actores y quienes pueden por otro lado

evidenciar relaciones de extensión o de inclusión entre casos de uso.

Los casos de uso de estos modelos deben por otro lado, estar contenidos en un

sistema.

Este metamodelo define muy bien la estructura de los diagramas de casos de

uso tal como lo enunciamos anteriormente en lenguaje natural.

La siguiente figura ilustra la relación que existe entre este metamodelo y un

ejemplo de diagrama de casos de uso.

Las flechas punteadas representan las relaciones existentes entre los elementos

del metamodelo y los elementos del diagrama de casos de uso.

Estas relaciones pueden considerarse como relaciones de instanciación. Se dice

entonces que un modelo es la instancia de su metamodelo.


Más detalles del metamodelo, IV


Más detalles del metamodelo, V

Como lo vemos, el diagrama de casos de uso contiene a un actor (instancia de

la clase actor del metamodelo), dos casos de uso (instancias de la clase caso de

uso del metamodelo) y un sistema (instancia de la clase sistema del

metamodelo).

El nombre del actor es cliente.

Los títulos de los casos de uso son Solicitar artículo y validar carrito.

El actor de este diagrama está conectado a los dos casos de uso, de acuerdo con

la asociación presente en el metamodelo entre las clases actor y caso de uso.

El sistema denominado PetStore incluye los dos casos de uso, de acuerdo con

la asociación presente en el metamodelo entre las clases sistema y caso de uso.


Metamodelo del diagrama de clases, I

Vamos a desarrollar nuestro ejemplo añadiendo a nuestra versión reducida de

UML los diagramas de clases simplificados (paquete, clases, atributos).

La información que nos interesa es la siguiente:

Un diagrama de clases contiene paquetes. Un paquete tiene un nombre y

contiene clases. Un paquete puede importar otro paquete.

Una clase tiene un nombre y puede contener atributos. Una clase puede

también heredar de otra clase.

Un atributo tiene un nombre y una visibilidad que puede ser ya sea pública o

privada. Un atributo tiene un tipo que puede ser ya sea un tipo de base (string,

integer, boolean), o una clase del diagrama.>>

La siguiente figura ilustra el metamodelo de los diagramas de clases. Está

formado por ocho clases.

La clase paquete contiene un atributo denominado nombre, cuyo tipo es una

cadena de caracteres. La clase clase contiene un atributo denominado nombre,

cuyo tipo es una cadena de caracteres.


Metamodelo


Metamodelo del diagrama de clases, II

La clase clase hereda de la clase tipo. La clase atributo contiene un atributo

denominado nombre, cuyo tipo es una cadena de caracteres, y un atributo

denominado visibilidad, cuyo tipo es una enumeración (pública o privada).

Las clases string, integer y boolean heredan de la clase Tipo basico, que hereda

de la clase tipo.

Existe una asociación denominada importa, que tiene como origen y como

destino la clase paquete, así como una asociación denominada super, que tiene

como origen y como destino la clase clase, una asociación denominada tipo,

entre las clases atributo y tipo, y dos asociaciones de agregación entre las

clases paquete y clase y entre las clases clase y atributo.

Este metamodelo define que los modelos conformes no pueden contener más

que paquetes que contienen clases con atributos. Paquetes, clases y atributos

tienen nombres.

Los paquetes pueden importar otros paquetes y las clases heredan de otras

clases, mientras que el tipo de un atributo puede ser ya sea un tipo de base, o

una clase.


Metamodelo del diagrama de clases, III

Este metamodelo define por lo tanto la estructura de los diagramas de clases tal

como lo enunciamos anteriormente en lenguaje natural.

Estos dos ejemplos nos permitieron eliminar el misticismo de los metamodelos.

Sabemos que dado que un metamodelo era una clase de diagrama de clases que

permitía representar los conceptos fundamentales de un lenguaje de

modelización en forma de clases y de representar las relaciones existentes entre

estos conceptos en forma de asociaciones.


Metamodelo MOF1.4, I

Después de constatar que un metamodelo era una clase de diagrama de clases y

haber presentado dos ejemplos, es momento de explicar precisamente lo que es

un metamodelo.

Dado que existe varias maneras de construir metamodelos (MOF1.3, MOF1.4,

MOF2.0, EMF, etc.) y que no podemos presentarlos todos, discutiremos

aspectos de MOF versión 1.4.

Todos los metamodelos públicos del OMG se realizan con esta versión,

bastante simple de utilizar, contrariamente a la 1.3, que requiere un

conocimiento de CORBA, o la versión 2.0, que es muy compleja.

Presentaremos la versión 2.0 del MOF al final de esta parte ya que es esta nos

permitirá elaborar los futuros metamodelos.

Para MOF1.4, un metamodelo define la estructura de un conjunto de modelos.

Esta estructuración es similar a la estructuración orientada a objetos. Los

metamodelos MOF1.4 se definen pues en forma de clases.

Los modelos conformes a los metamodelos se consideran como instancias de

estas clases.


Metamodelo MOF1.4, II

Con el fin de distinguir las clases constitutivas de un metamodelo de las otras

clases, como las clases Java, MOF1.4 propone utilizar el término metaclase.

Un metamodelo entonces está constituido por un conjunto de metaclases. Del

mismo modo, con el fin de distinguir los objetos instancias de las metaclases de

los otros objetos, MOF1.4 propone utilizar el término meta-objeto.

Así pues, un modelo está constituido por un conjunto de meta-objetos, es decir

instancias de metaclases.

Una metaclase tiene un nombre y contiene atributos y operaciones, también

llamados meta-atributos y meta-operaciones.

Un meta-atributo representa una propiedad de un elemento del modelo. Una

meta-operación representa un tratamiento aplicable a un elemento del modelo.

Para caracterizar (establecer los tipos) los atributos y los parámetros de las

operaciones, MOF1.4 propone el concepto de tipo de dato (dataType).

Un tipo de dato permite especificar un tipo que no es un tipo de objeto. Los

tipos como los booleanos, las cadenas de caracteres, las tablas y las estructuras

son tipos de datos.


Metamodelo MOF1.4, III

Con respecto a la expresión de las relaciones entre metaclases, MOF1.4

propone el concepto de meta-asociación. Una meta-asociación es una

asociación binaria entre dos metaclases. Una meta-asociación tiene un nombre,

y en cada una de sus extremidades puede llevar un nombre de rol y una

multiplicidad.

Para agruparlos entre ellos, a los distintos elementos de un metamodelo,

MOF1.4 propone el concepto de paquete. Un paquete, también llamado meta-

paquete, es un espacio de nombrado que sirve para identificar por nombres los

distintos elementos que lo constituyen.

Para resumir, se puede decir que los conceptos de base de MOF1.4 son los

siguientes (usamos sus nombres en inglés):

Class. Una meta-clase permite definir la estructura de meta-objetos. Un conjunto de

meta-objetos constituye un modelo. Una meta-clase contiene meta-atributos y meta-

operaciones.

DataType. Un tipo de dato permite especificar el tipo no objeto de un meta-atributo

o de un parámetro de una meta-operación.


Metamodelo MOF1.4, IV

Association. Una meta-asociación permite especificar una relación binaria entre dos

metaclases.

Package. Un meta-paquete permite agrupar bajo un mismo espacio de nombrado

diferentes elementos de un metamodelo.


Los niveles meta

Acabamos de definir lo que era un metamodelo y describimos la relación que

existía entre un modelo y su metamodelo.

Dado que un metamodelo era una clase de diagrama de clases cuyas reglas de

construcción se definían por MOF.

Vamos a continuación a presentar la arquitectura de cuatro niveles tal como se

definen por MDA.

Esta arquitectura pone las bases de las relaciones que existen entre las entidades

que deben modelarse, los modelos, los metamodelos y los metametamodelos.


Entidades que deben modelarse, I

Es importante no olvidar que el objetivo más importante de MDA consiste en

facilitar la construcción y la evolución de las aplicaciones computacionales.

Las entidades que deben modelarse en el contexto MDA son por lo tanto

aplicaciones esencialmente computacionales.

Dado que las calidades esperadas de MDA son la persistencia, la productividad

y la consideración de las plataformas, metodologías de desarrollo, los

mecanismos de producción y también las distintas plataformas de ejecución

existentes son también entidades que deben modelarse.

El problema es que estas entidades (aplicaciones, metodologías, etc.) son

abstractas y que no es fácil distinguir el modelo de la entidad que debe

modelarse.

Por ejemplo, es el código y solamente el código lo que constituye la aplicación

computacional o el código es el modelo de la aplicación?

En el primer caso, el código sería la entidad que debe modelarse.

En el segundo caso, a que correspondería la aplicación computacional?


Entidades que deben modelarse, II

Realmente, se trata de un falso problema.

En el contexto de MDA, solamente los modelos cuentan, y sirven más o menos

para facilitar la producción de las aplicaciones computacionales.

Actualmente, es cierto que la producción de una aplicación se reduce a la

generación de su código, así como a la de los archivos de despliegue.

Consideramos en el contexto de este curso que las entidades que deben

modelarse son las aplicaciones computacionales y que los modelos de estas

aplicaciones contienen toda la información necesaria para la generación del

código.

Esto significa que incluimos tanto los modelos técnicos que describen el diseño

de las aplicaciones como los modelos conceptuales que describen la semántica

del problema dirigido por las aplicaciones.


Los modelos, I

Según los diccionarios existentes en línea, podemos leer diferentes definiciones

de modelo según el contexto a tratar.

Artes y negocios: representación en pequeña escala de un objeto destinado a ser

reproducido en dimensiones normales.

Epistemología: sistema físico, matemático o lógico que representa las

estructuras esenciales de una realidad y capaz en su nivel, de explicar o de

reproducir dinámicamente el funcionamiento.

Cibernética: sistema artificial donde algunas propiedades presentan analogías

con las propiedades, observadas o inferidas, de un sistema estudiado y cuyo

comportamiento, revela comportamientos del original, susceptibles de ser el

objeto de nuevas investigaciones o bien de probar en qué medida las

propiedades atribuidas al original pueden considerar su comportamiento

manifiesto.


Los modelos, II

Al sintetizar estas definiciones y adaptarlas al contexto MDA, podemos

considerar que los modelos MDA son representaciones, a distintos niveles de

abstracción, de la información necesaria para la producción y para la evolución

de aplicaciones computacionales.

Los modelos realizados en MDA contribuyen más o menos según su nivel de

abstracción en la producción o en la evolución de aplicaciones

computacionales.

Como todo modelo, los modelos MDA deben estar fuertemente conectados con

la realidad, en la ocurrencia con las aplicaciones computacionales.


Los metamodelos

Sabemos que los modelos MDA son representaciones de la información

necesaria para la producción y para la evolución de las aplicaciones

computacionales.

El objetivo principal de MDA es procurar que estos modelos sean persistentes,

productivos y que tomen en cuenta las plataformas de ejecución.

Estas cualidades sólo pueden obtenerse definiendo de forma muy precisa la

estructura de los modelos. Sabemos también que estas definiciones de

estructura de los modelos se hacían gracias a los metamodelos.

Los metamodelos son el corazón de MDA. Permiten persistir la estructura de

los modelos ya que ellos mismos están representados en forma de modelos

(diagramas de clases).

Además permiten asociar tratamientos a los modelos gracias, en particular, a

las meta-operaciones de las metaclases. Los vínculos entre metamodelos

permiten separar correctamente los aspectos de negocio de los aspectos

técnicos y en consecuencia de tener en cuenta las plataformas de ejecución.


MOF1.4 Sabemos que los metamodelos son diagramas de clases elaborados según las

reglas del estándar MOF1.4.

La gran ventaja aportada por MOF es que, gracias a él, todos los metamodelos

se estructuran de la misma manera.

También sabemos que un metamodelo es un conjunto de metaclases con meta-

asociaciones, etc.

Esta estructuración común de todos los metamodelos permite proponer

mecanismos genéricos que funcionan sobre todos los metamodelos.

Todo el interés de MOF es definir mecanismos genéricos sobre los

metamodelos gracias a una estructuración común.

Entre estos mecanismos genéricos, veremos posteriormente en la consagrada a

la persistencia que el mecanismo XMI (XML Metadata Interchange) permite

construir gramáticas XML a partir de cualquier metamodelo con el fin de

almacenar los modelos instancias en el formato XML.

MOF es de un interés estratégico para MDA, ya que permite crear mecanismos

genéricos, que pueden ser mecanismos de producción o persistencia.


Metamodelo de los metamodelos, I

Al observar de más cerca, podemos remarcar que la relación que existe entre el

estándar MOF y los metamodelos es exactamente la misma que aquélla que

existe entre un metamodelo y sus modelos instancias.

MOF define la estructura que debe tener todo metamodelo, es natural querer

representarlo en forma de diagrama de clases.

Para representar MOF en forma de diagrama de clases, sería necesario

representar todos sus conceptos en forma de clases y representar las relaciones

entre sus conceptos bajo forma de asociaciones.

La siguiente figura ilustra una parte de lo que podría ser un diagrama de clases

que representa MOF1.4.

Es decir, se muestra la representación de MOF1.4 bajo la forma de diagrama de

clases.

Los conceptos de metaclase, de meta-atributo, meta-operación, tipo de dato y

paquete están representados por clases.

Las relaciones entre estos conceptos están representadas por asociaciones.


Metamodelo de los metamodelos, II

Este diagrama de clases no está completo y sólo se proporciona como ejemplo

para poner de manifiesto que es perfectamente posible representar MOF en

forma de diagrama de clases.

El diagrama de clases de MOF define la estructura que debe tener todo

metamodelo.

Dicho de otra forma, se trata del metamodelo de los metamodelos, es decir del

metametamodelo.

En realidad, el estándar MOF1.4 se define realmente como un diagrama de

clases.

Este diagrama de clases se llama tanto metametamodelo como modelo MOF.


Representación de MOF1.4


Metametametamodelo

El descubrimiento del nivel metametamodelo plantea inevitablemente la

cuestión de la posible existencia de un nivel metametametamodelo, o incluso el

de saber si esta sucesión de niveles tiene un fin y un sentido.

La respuesta a estas cuestiones es bastante simple.

Si debemos proponer el diagrama de clases que describe la estructura del

metametamodelo, llegaríamos al diagrama de la figura del acetato 30.

La razón a esto, es que el metametamodelo autodefine y es de sí mismo su

propio metamodelo.

Por lo tanto, no existe más que los niveles modelo, metamodelo y

metametamodelo, también llamado modelo MOF.


La arquitectura de 4 niveles de MDA

A partir de estas definiciones, podemos representar la famosa arquitectura de

cuatro niveles de MDA. La siguiente figura ilustra esta arquitectura.

Observamos el nivel M0, que contiene las entidades que deben modelarse, aquí

las aplicaciones computacionales, el nivel M1, contiene los distintos modelos

de la aplicación computacional, el nivel M2, contiene los distintos

metamodelos que se utilizaron y el nivel M3, contiene el metametamodelo que

permitió definir uniformemente los metamodelos.

Las relaciones existentes entre los niveles M1-M2 y M2-M3 son equivalentes.

M2 define la estructura de M1 al igual que M3 define la estructura de M2.

Recordemos que el modelo MOF define su propia estructura.

Las relaciones entre los niveles M1 y M0 no son fáciles de definir.

En efecto, los modelos del nivel M1 representan la información necesaria para

la construcción y para la evolución de las aplicaciones computacionales y

permiten generar las aplicaciones.


Representación gráfica

Podemos considerar que los archivos fuente de una aplicación son también

modelos y que ellos también pueden pertenecer al nivel M1.

MDA considera que, cualesquiera que sean los niveles M1, M2 y M3, todos los

elementos son modelos. Es decir, el metametamodelo y los metamodelos son

también modelos.


Metamodelos y tipado de los modelos, I

Acabamos de ver que un metamodelo definía la estructura de un conjunto de

modelos.

Un conjunto de metamodelos puede por lo tanto verse como un sistema de

clasificación de los modelos.

Al tomar como referencia un conjunto de metamodelos, podemos caracterizar

los modelos según su metamodelo.

MDA utiliza mucho los metamodelos como sistema de clasificación de los

modelos.

El objetivo es precisar qué modelos deben elaborarse en las distintas fases del

enfoque MDA (CIM, PIM, PSM y código).

Es importante comprender que no es la arquitectura de cuatro niveles quien

estructura MDA sino más bien el conjunto de los metamodelos definidos por

MDA.

Varios metamodelos estándares definen ya este sistema de tipado de los

modelos:


Metamodelos y tipado de los modelos, II

Tal como introducimos en la primera parte del curso, MDA propone utilizar el

metamodelo UML para elaborar los PIM.

Este mismo metamodelo con sus perfiles también se utiliza para elaborar los PSM.

El metamodelo MOF2.0 QVT se utiliza para elaborar las transformaciones de

modelos.

Este metamodelo permite modelar los pasos automáticos entre las diferentes fases de

MDA.

Los metamodelos OCL (Object Constraint Language) y AS (Acción Semantics)

están también muy presentes en MDA para especificar los comportamientos de las

aplicaciones, como lo veremos posteriormente. OCL y AS se utilizan principalmente

para la elaboración de los PIM.

No podríamos demasiado hacer hincapié en el hecho de que estos son los

metamodelos que estructuran el enfoque MDA.

Este conjunto de metamodelos no está obviamente completo.

MDA sólo es un enfoque, y es perfectamente posible para una empresa definir

sus propios metamodelos con el fin de adaptar este enfoque a su contexto.


Metamodelos y tipado de los modelos, III

Los metamodelos que constituyen el sistema de tipeado MDA no son

independientes sino vinculados.

Es gracias a estos vínculos que podemos mantener la coherencia entre los

modelos elaborados en las distintas etapas MDA.

Esta coherencia es garante de la calidad de MDA.

Es gracias ella que las aplicaciones construidas respetan las exigencias de los

clientes.


Vínculos entre metamodelos, I

Técnicamente, para poder ligar (vincular) dos modelos, instancias de dos

metamodelos diferentes y para procurar que el vínculo esté modelado, es

necesario que una meta-asociación exista en los metamodelos.

Esta meta-asociación puede ser creada ya sea directamente entre las metaclases

concernientes (vínculo interno) o ya sea por otra metaclase, llamada metaclase

de vínculo (vínculo externo).

La primera solución (vínculo interno) tiene la ventaja de ser muy simple pero

presenta el inconveniente de modificar las metaclases existentes, añadiendo una

asociación y referencias si se quiere navegar mediante el vínculo.

La segunda solución (vínculo externo) tiene la ventaja de no modificar las

metaclases existentes pero presenta el inconveniente de crear una nueva

metaclase y en consecuencia un nuevo metamodelo.

Tomemos como ejemplos los dos metamodelos del diagrama de clases y el

diagrama de casos de uso.


Vínculos entre metamodelos, II

Queremos establecer un vínculo entre un caso de uso y un conjunto de clases,

para por ejemplo, precisar que un caso de uso se realiza por un conjunto de

clases.

Podemos ya sea crear a una meta-asociación directamente entre la metaclase

clase y la metaclase caso de uso y agregar las referencias necesarias (ver la

siguiente figura), o ya sea crear una meta-asociación por medio de una nueva

metaclase, que llamaremos realización (ver figura del acetato 39).

Estos vínculos son omnipresentes en MDA.

Vinculo interno entre metaclases


Vínculos entre metamodelos, III

Por ejemplo, se especifican algunos vínculos internos entre los metamodelos

UML, OCL y AS, y se utilizan algunos vínculos externos en el estándar

MOF2.0 QVT para establecer las transformaciones de los modelos.

Recordemos que es siempre posible que una empresa adapte MDA a su

contexto añadiendo, por ejemplo, sus propios vínculos.

Vinculo externo entre metaclases


La arquitectura MOF2.0 del OMG

Conceptualmente, la arquitectura de MOF2.0 sólo difiere muy poco de la

MOF1.4.

MOF2.0 es todavía el único metametamodelo, y UML2.0 es el metamodelo

dedicado a la modelización de las aplicaciones orientadas a objetos.

Técnicamente, en cambio, esta versión es bastante diferente.

Uno de los objetivos de MOF2.0 es capitalizar los puntos comunes existentes

entre UML y MOF al nivel de los diagramas de clases y de aclarar las

diferencias.

Para realizar este objetivo, los medios aplicados son de tal complejidad que no

facilitan la comprensión de esta versión.


UML2.0 Infraestructura, I

Uno de los objetivos de las versiones 2.0 de MOF y UML era alinear estos

estándares a nivel de los diagramas de clases.

Sabemos que un metamodelo MOF se asemeja mucho a los diagramas de clases

UML. Es por otra parte imposible observar un diagrama de clases y decir

intrínsecamente si representa un metamodelo MOF o un modelo UML.

Esto depende solamente del sentido que le da su diseñador. Es por lo tanto

natural intentar acercar a estos dos conceptos.

Para ello, el OMG construyó un metamodelo común entre UML y MOF. Este

metamodelo contiene todas las metaclases compartidas por UML y MOF a

nivel de los diagramas de clases. Contiene pues las metaclases paquete, clase,

etc. Este metamodelo común lleva el nombre de UML2.0 Infraestructura.

El metamodelo UML2.0 Infraestructura tiene por único objeto ser reutilizado

por los metamodelos MOF2.0 y UML2.0 Superestructura. Por lo tanto se

concibe UML2.0 Infraestructura de una manera modular. Es posible no

reutilizar más que algunas partes de la infraestructura, por ejemplo, los tipos

básicos o los paquetes.


UML2.0 Infraestructura, II

Técnicamente, para volver un metamodelo modular, es necesario recortarlo en

paquetes.

El metamodelo UML2.0 Infraestructura está constituido por una treintena de

paquetes. Mencionamos entre ellos el paquete Basic, que contiene todas las

metaclases necesarias en la elaboración de diagramas de clases sin asociación,

y el paquete Constructs, que contiene todas las metaclases necesarios para la

elaboración de diagramas de clases con asociaciones (ver la figura del acetato

43).

El paquete Constructs se asemeja mucho a MOF1.4. La única gran diferencia es

que se consideran a las asociaciones y a las referencias de MOF1.4 aquí

indiferentemente como propiedades de clase (metaclase property).

Para facilitar la reutilización de sus paquetes, UML2.0 Infraestructura define el

concepto de merge (mezcla) entre dos paquetes. Una mezcla entre paquetes es

una especie de copiar-pegar elementos del paquete mezclado hacia el paquete

mezclador. La mezcla permite integrar más fácilmente en un nuevo

metamodelo los paquetes propuestos no UML2.0 Infraestructura.


UML2.0 Infraestructura, III

Tengamos en cuenta que UML2.0 Infraestructura utiliza la mezcla también él

mismo entre algunos de sus paquetes.

La semántica del merge es realmente mucho más compleja. Establece una

transformación entre los paquetes y las metaclases de los paquetes. La

presentamos más en detalle en la siguiente parte del curso.


UML2.0 Superestructura, I

En su versión 2.0, el estándar UML que permite modelar las aplicaciones

orientadas a objetos se llama UML2.0 Superestructura. Este nuevo nombre

permite distinguirlo del metamodelo UML2.0 Infraestructura.

El metamodelo UML2.0 Superestructura reutiliza algunas partes del

metamodelo UML2.0 Infraestructura.

Esto permite, como lo vimos, acercar a UML y a MOF a nivel de los diagramas

de clases.

La reutilización del metamodelo UML2.0 Infraestructura por el metamodelo

UML2.0 Superestructura se hace gracias al merge.

Se puede considerar que el metamodelo UML2.0 Superestructura hace un

copiar-pegar del metamodelo UML2.0 Infraestructura pero sin integrar la

totalidad de la treintena de paquetes propuestos por UML2.0 Infraestructura.

Además de esta integración, el metamodelo UML2.0 Superestructura define los

otros conceptos necesarios para la elaboración de todos los diagramas UML

(casos de uso, secuencia, despliegue, etc.).


UML2.0 Superestructura, II

El metamodelo UML2.0 Superestructura es pues mucho más complejo que el

metamodelo UML2.0 Infraestructura.


MOF2.0

Desde un punto de vista conceptual, MOF2.0 siempre se considera como el

único metametamodelo.

Sin embargo, por razones de eficacia, se convino que un metamodelo instancia

de MOF2.0 podía o no contener meta-asociaciones.

Para hacer la diferencia entre estos dos tipos de metamodelos, MOF2.0 ha sido

dividido en dos partes: EMOF (Essential MOF), para la elaboración de

metamodelos sin asociación, y CMOF (complete MOF), para la de los

metamodelos con asociación.

MOF2.0 integra también el metamodelo UML2.0 Infraestructura. EMOF

integra el paquete Basic de la infraestructura y CMOF el paquete Constructs.

En realidad, el paquete EMOF integra el paquete Basic y el paquete CMOF

integra el paquete Constructs utilizando el merge (ver la siguiente figura).

Por lo tanto, las relaciones de integración entre MOF2.0 y UML2.0

Infraestructura son bastante complejas.


EMOF

EMOF tiene por fuente principal el framework de metamodelización EMF

(Eclipse Modeling Framework) propuesto por Eclipse:

(http://www.eclipse.org/modeling/emf/).

Este framework, se presentara con todo detalle más adelante, permite generar

automáticamente interfaces Java a partir de metamodelos Ecore.

La particularidad de los metamodelos Ecore es que no contienen meta-

asociaciones entre sus metaclases.

Para expresar una relación entre dos metaclases, es necesario utilizar meta-

atributos y caracterizarlos por metaclases.

EMF impone esta dificultad para facilitar la generación de las interfaces Java.

El concepto de asociación que no existe en Java, sería necesario en efecto

definir una transcripción particular.


Representación esquemática de MOF2.0


Arquitectura y niveles, I

Se podría pensar que las versiones 2.0 de MOF y UML revolucionan muy

radicalmente la bonita arquitectura de cuatro niveles que presentamos.

Con todo, a nivel conceptual, esta arquitectura sigue siendo válida y facilita la

comprensión de los niveles meta.

MOF2.0 continua el metametamodelo (nivel M3), UML2.0 Superestructura

sigue siendo un metamodelo (nivel M2), y los modelos UML (nivel M1)

representan siempre la información necesaria para la construcción y en la

evolución de las aplicaciones computacionales (nivel M0).

La dificultad viene principalmente de UML2.0 Infraestructura ya que se trata

de un metamodelo sin nivel fijo.

Puede pertenecer a M3 o M2, o incluso a M1 según el buen juicio del usuario.

Cuando se integra a MOF2.0, pertenece al nivel M3.

Cuando se integra a UML2.0 Superestructura, pertenece al nivel M2.

Básicamente, no es contrastando estos detalles, ya que UML2.0 Infraestructura

representa la estructuración de un diagrama de clases.


Arquitectura y niveles, II

No basta que sepamos que no es posible decir intrínsecamente a qué nivel

pertenece un diagrama de clases, esto es muy dependiente del sentido que se da

a este último.


Conclusión, I

Vimos en esta parte del curso que los metamodelos definían la estructura de un

conjunto de modelos y no la semántica de los modelos.

Aprendimos a construir metamodelos según el estándar MOF1.4 y sabemos

también que un metamodelo está constituido por uno o varios paquetes que

contienen metaclases conectadas por meta-asociaciones.

Vimos igualmente que la arquitectura de cuatro niveles de MDA permitía hacer

la diferencia entre las entidades que deben modelarse, los modelos, los

metamodelos y los metametamodelos.

Esta arquitectura nos permitió destacar que las entidades que deben modelarse

en el contexto MDA eran las aplicaciones esencialmente computacionales.

También constatamos que eran los metamodelos y sus interrelaciones que

estructuraban MDA.

Sabemos entre otras cosas que el metamodelo UML permite la elaboración de

PIM y que este mismo metamodelo asociado a los perfiles que veremos durante

los capítulos siguientes permiten la elaboración de los PSM.


Conclusión, II

Vimos brevemente otros metamodelos que permiten estructurar MDA.

Para terminar, introducimos las versiones 2.0 de UML y MOF y sabemos que

estas no añadían nuevos conceptos conceptuales porque serían técnicamente

complejos.

Este conocimiento adquirido sobre los metamodelos va a permitirnos entrar en

detalle de los metamodelos que hacen MDA.

Modelos y niveles meta

Documents

Transcript of Modelos y niveles meta