Upload
others
View
7
Download
0
Embed Size (px)
Citation preview
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.
(C) A. Sánchez L. 2016 3
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.
(C) A. Sánchez L. 2016 4
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.
(C) A. Sánchez L. 2016 5
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.
(C) A. Sánchez L. 2016 6
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:
(C) A. Sánchez L. 2016 7
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.
(C) A. Sánchez L. 2016 8
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.
(C) A. Sánchez L. 2016 9
Más detalles del metamodelo, II
(C) A. Sánchez L. 2016 10
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.
(C) A. Sánchez L. 2016 11
Más detalles del metamodelo, IV
(C) A. Sánchez L. 2016 12
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.
(C) A. Sánchez L. 2016 13
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.
(C) A. Sánchez L. 2016 14
Metamodelo
(C) A. Sánchez L. 2016 15
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.
(C) A. Sánchez L. 2016 16
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.
(C) A. Sánchez L. 2016 17
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.
(C) A. Sánchez L. 2016 18
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.
(C) A. Sánchez L. 2016 19
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.
(C) A. Sánchez L. 2016 20
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.
(C) A. Sánchez L. 2016 21
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.
(C) A. Sánchez L. 2016 22
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?
(C) A. Sánchez L. 2016 23
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.
(C) A. Sánchez L. 2016 24
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.
(C) A. Sánchez L. 2016 25
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.
(C) A. Sánchez L. 2016 26
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.
(C) A. Sánchez L. 2016 27
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.
(C) A. Sánchez L. 2016 28
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.
(C) A. Sánchez L. 2016 29
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.
(C) A. Sánchez L. 2016 30
Representación de MOF1.4
(C) A. Sánchez L. 2016 31
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.
(C) A. Sánchez L. 2016 32
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.
(C) A. Sánchez L. 2016 33
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.
(C) A. Sánchez L. 2016 34
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:
(C) A. Sánchez L. 2016 35
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.
(C) A. Sánchez L. 2016 36
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.
(C) A. Sánchez L. 2016 37
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.
(C) A. Sánchez L. 2016 38
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
(C) A. Sánchez L. 2016 39
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
(C) A. Sánchez L. 2016 40
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.
(C) A. Sánchez L. 2016 41
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.
(C) A. Sánchez L. 2016 42
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.
(C) A. Sánchez L. 2016 43
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.
(C) A. Sánchez L. 2016 44
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.).
(C) A. Sánchez L. 2016 45
UML2.0 Superestructura, II
El metamodelo UML2.0 Superestructura es pues mucho más complejo que el
metamodelo UML2.0 Infraestructura.
(C) A. Sánchez L. 2016 46
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.
(C) A. Sánchez L. 2016 47
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.
(C) A. Sánchez L. 2016 48
Representación esquemática de MOF2.0
(C) A. Sánchez L. 2016 49
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.
(C) A. Sánchez L. 2016 50
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.
(C) A. Sánchez L. 2016 51
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.
(C) A. Sánchez L. 2016 52
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.