La arquitectura MDA - Benemérita Universidad Autónoma de...
45
La arquitectura MDA Abraham Sánchez López FCC/BUAP Grupo MOVIS
Transcript of La arquitectura MDA - Benemérita Universidad Autónoma de...
La arquitectura MDA
Abraham Sánchez López
FCC/BUAP
Grupo MOVIS
(C) A. Sánchez L. 2016 2
Introducción
Este capítulo presenta globalmente la arquitectura MDA (Model Driven
Architecture) como se ha definido por el OMG (Object Management Group).
A lo largo del curso se detallaran más los aspectos que se introducen a
continuación.
Recordemos que la ingeniería de software guiada por modelos es el futuro de
las aplicaciones según Bill Gates, “Modelar es el futuro, y pienso que las
sociedades que trabajan en este ámbito tienen razón”.
Igualmente Richard Soley, director del OMG y los pioneros de UML (Graddy
Booch, Jim Rumbaugh e Ivar Jacobson), afirman que es momento de elaborar
las aplicaciones a partir de modelos y, sobre todo, procurar que estos modelos
sean el centro del ciclo de vida de estas aplicaciones, en pocas palabras que
estos sean productivos.
(C) A. Sánchez L. 2016 3
Los modelos, I
Los modelos ofrecen numerosas ventajas. Los que practican UML o cualquier
otro lenguaje de modelado los conocen bien.
La ventaja más importante que se obtiene es la de especificar distintos niveles
de abstracción, facilitando la gestión de la complejidad inherente de las
aplicaciones.
Los modelos muy abstractos se utilizan para presentar la arquitectura general
de una aplicación o su lugar en una organización, mientras que los modelos
muy concretos permiten especificar precisamente protocolos de comunicación
en red o algoritmos de sincronización.
Aunque los modelos se sitúan a diferentes niveles de abstracción, es posible
expresar relaciones de refinamiento entre ellos. Son en realidad verdaderos
vínculos de rastreabilidad, estas relaciones son garantes de la coherencia de un
conjunto de modelos que representan una misma aplicación
La diversidad de las posibilidades de modelización, así como la posibilidad de
expresar vínculos de trazabilidad son puntos decisivos para administrar la
complejidad.
(C) A. Sánchez L. 2016 4
Los modelos, II
Otra ventaja innegable de los modelos es que pueden presentarse bajo formato
gráfico, facilitando la comunicación entre los actores de los proyectos
computacionales.
Entre los modelos gráficos más utilizados, se encuentran los modelos
relacionales; que permiten especificar la estructura de las bases de datos.
La representación gráfica de estos modelos ofrece una ganancia significativa de
productividad.
“Las malas lenguas afirman” que modelar es la mejor manera de perder el
tiempo puesto que, in fine, es necesario en cualquier caso escribir el código.
Del mismo modo, al famoso proverbio que enuncia que un buen esquema es
mejor que un largo discurso, se entiende como el hecho de que a veces replicar
un esquema puede corresponder a más de mil discursos, según la forma en que
se intérprete.
(C) A. Sánchez L. 2016 5
Los modelos, III
Estas críticas contemplan exactamente en caso de ausencia de control de las
buenas prácticas de modelización, es decir, de la ingeniería de los modelos.
Esta es la razón por la que es esencial adquirir buenas prácticas de
modelización con el fin de determinar cómo, cuándo, que y porqué modelar y
explotar plenamente las ventajas de los modelos.
El OMG definió MDA (Model Driven Architecture) en 2000 con este objetivo.
El enfoque MDA preconiza la utilización masiva de los modelos y ofrece las
primeras respuestas al cómo, cuándo, que y porqué modelar.
Sin pretender ser una biblia de la modelización, categorizando todas las buenas
prácticas; tiene como objetivo valorizar las calidades intrínsecas de los
modelos, como persistencia, productividad y consideración de las plataformas
de ejecución.
MDA incluye la definición de varias normas, en particular, UML, MOF y XMI.
(C) A. Sánchez L. 2016 6
Los modelos, IV
El OMG (Object Management Group) es un consorcio sin fines de lucro de
industriales e investigadores, cuyo objetivo consiste en establecer normas que
permitan solucionar los problemas de interoperabilidad de los sistemas de
información (http://www.omg.org).
El principio clave de MDA consiste en la utilización de modelos en las distintas
fases del ciclo de desarrollo de una aplicación.
Más concretamente, MDA preconiza la elaboración de modelos de requisitos
(CIM), análisis y diseño (PIM) y código (PSM).
El objetivo principal de MDA es la elaboración de modelos persistentes,
independientes de los detalles técnicos de las plataformas de ejecución (J2EE,
,Net, PHP u otros), con el fin de permitir la generación automática de la
totalidad del código de las aplicaciones y obtener una ganancia significativa de
productividad.
Otros modelos, como los modelos de supervisión, verificación u organización
de la empresa, aún no se integran en el enfoque MDA pero lo estarán
rápidamente sin dificultad, dada su apertura.
(C) A. Sánchez L. 2016 7
El modelo de requisitos, I
CIM (Computation Independent Model)
La primera cosa a realizar en la construcción de una nueva aplicación es por
supuesto especificar los requerimientos del cliente.
Aunque muy hacia atrás, esta etapa debe mucho beneficiarse de los modelos.
El objetivo consiste en crear un modelo de requisitos de la futura aplicación.
Tal modelo debe representar la aplicación en su ambiente con el fin de definir
cuáles son los servicios ofrecidos por la aplicación y cuáles son las otras
entidades con las cuales interacciona.
La creación de un modelo de requisitos es de una importancia capital.
Esto permite expresar claramente los vínculos de rastreabilidad (trazabilidad)
con los modelos que se construirán en las otras fases del ciclo de desarrollo de
la aplicación, como los modelos de análisis y diseño.
Se crea así un vínculo duradero con las necesidades del cliente de la aplicación.
(C) A. Sánchez L. 2016 8
El modelo de requisitos, II
Por lo tanto, los modelos de requisitos pueden considerarse como elementos
contractuales, destinados a servir de referencia cuando se quiera garantizar que
una aplicación se ajusta a las solicitudes del cliente.
Es importante tener en cuenta que un modelo de requisitos no contiene
información sobre la realización de la aplicación ni sobre los tratamientos.
Esta es la razón por la que, en el vocabulario MDA, el modelo de requisitos se
llama el CIM (Computation Independent Model), literalmente “modelo
independiente de la programación”. Con UML, un modelo de requisitos puede
resumirse en un diagrama de casos de uso.
Estos últimos contienen en efecto las funcionalidades proporcionadas por la
aplicación (caso de uso) así como las distintas entidades que interactúan con
ella (actores) sin aportar información sobre el funcionamiento de la aplicación.
En una óptica más amplia, se considera un modelo de requisitos como una
entidad compleja, constituida entre otras cosas por un glosario, definiciones de
los procesos de negocio, requerimientos y casos de uso así como de una vista
sistémica de la aplicación.
(C) A. Sánchez L. 2016 9
El modelo de requisitos, III
Si MDA no emite ninguna recomendación en cuanto a la elaboración de los
modelos de requisitos, hay trabajos que están en curso de realización para
añadir a UML los conceptos necesarios para cubrir esta fase preliminar.
El rol de los modelos de requisitos en un enfoque MDA, es ser los primeros
modelos persistentes.
Una vez modeladas los requisitos, estos son consensuados con el afán de
proporcionar una base contractual que varía poco, ya que está validada por el
cliente de la aplicación.
Gracias a los vínculos de trazabilidad con los otros modelos, se puede crear un
vínculo desde los requisitos hacia el código de la aplicación.
(C) A. Sánchez L. 2016 10
Modelo de análisis y diseño abstracto, I
PIM (Platform Independent Model)
Una vez realizado el modelo de requisitos, el trabajo de análisis y diseño puede
comenzar. En el enfoque MDA, esta fase utiliza también un modelo.
El análisis y el diseño son desde hace más de treinta años, las etapas donde la
modelización es lo más representativo, en sus inicios con los métodos Merise y
Coad/Yourdon luego con los métodos orientados a objetos Schlear y Mellor,
OMT, OOSE y Booch.
Estos métodos proponen sus propios modelos.
En la actualidad, el lenguaje UML se ha impuesto como la referencia para
realizar todos los modelos de análisis y diseño.
Por diseño, conviene entender la etapa que consiste en estructurar la aplicación
en módulos y sub-módulos.
La aplicación de los patrones de diseño, o Design Patterns, del GoF (Gang of
Four) forma parte de esta etapa de diseño.
(C) A. Sánchez L. 2016 11
Modelo de análisis y diseño abstracto, II
Por el contrario, la aplicación de los patrones técnicos, propios a ciertas
plataformas, corresponde a otra etapa.
No consideramos aquí más que el diseño abstracto, es decir, aquello que es
realizable sin conocimiento de ninguna de las técnicas de implementación.
MDA considera que los modelos de análisis y diseño deben ser independientes
de toda plataforma de implementación, ya sea J2EE. .Net, PHP, etc.
Los detalles de implementación no se integran sino hasta la parte más tardía del
ciclo de desarrollo, es posible maximizar la separación de las preocupaciones
entre la lógica de la aplicación y las técnicas de implementación.
UML es preconizado por el enfoque MDA como el lenguaje a utilizar para
realizar modelos de análisis y diseño independientes de las plataformas de
implementación.
Esta es la razón por la que en el vocabulario MDA estos modelos se llaman los
PIM (Platform Independent Model).
(C) A. Sánchez L. 2016 12
Modelo de análisis y diseño abstracto, III
Precisemos que MDA no hace más que preconizar la utilización de UML y que
no excluye que otros lenguajes se puedan utilizar.
Además, MDA no da ninguna indicación en torno a los modelos que deben
elaborarse ni en que método deben utilizarse para elaborar estos PIM.
Cualesquiera que sean el o los lenguaje(s) utilizadas, el rol de los modelos de
análisis y diseño es ser persistentes y hacer el vínculo entre el modelo de
requisitos y el código de la aplicación.
Estos modelos deben por otra parte ser productivos puesto que constituyen el
aglomerado de todo el proceso de generación de código definido por MDA.
La productividad de los PIM significa que estos deben ser suficientemente
precisos y contener suficientemente información para que sea posible una
generación automática de código.
(C) A. Sánchez L. 2016 13
Modelo de código o diseño concreto, I
PSM (Platform Specific Model)
Una vez que se han realizado los modelos de análisis y diseño, el trabajo de
generación de código puede comenzar. Esta fase, la más delicada del MDA,
debe también utilizar modelos. Incluye la aplicación de los patrones de diseño
técnicos.
MDA considera que el código de una aplicación puede obtenerse fácilmente a
partir de los modelos de código.
La diferencia principal entre un modelo de código y un modelo de análisis o de
diseño reside en el hecho de que el modelo de código está vinculado a una
plataforma de ejecución.
En el vocabulario MDA, estos modelos de código se llaman los PSM (Platform
Specific Model).
Los modelos de código sirven esencialmente para facilitar la generación de
código a partir de un modelo de análisis y diseño.
(C) A. Sánchez L. 2016 14
Modelo de código o diseño concreto, II
Contienen toda la información necesaria para la explotación de una plataforma
de ejecución, como la información que permite manipular los sistemas de
archivos o los sistemas de autenticación.
Es a veces difícil diferenciar el código de las aplicaciones de los modelos de
código.
Para MDA, el código de una aplicación se resume a una secuencia de líneas
textuales, como un archivo Java por ejemplo, mientras que un modelo de
código es más bien una representación estructurada que incluye, por ejemplo,
los conceptos de ciclo, condición, instrucción, componente, evento, etc.
La escritura de código a partir de un modelo de código es por lo tanto una
operación bastante ordinaria.
Para elaborar los modelos de código, MDA propone, entre otras cosas, la
utilización de perfiles UML.
Un perfil UML es una adaptación del lenguaje UML a un ámbito particular.
Por ejemplo, el perfil UML para EJB es una adaptación de UML al ámbito de
los EJB.
(C) A. Sánchez L. 2016 15
Modelo de código o diseño concreto, III
Gracias a este perfil, es posible elaborar modelos de código para el desarrollo
de EJB (Enterprise JavaBeans).
El rol de los modelos de código es principalmente facilitar la generación de
código.
Son por lo tanto esencialmente productivos pero no son forzosamente
persistentes.
La otra característica importante de los modelos de código es que hacen posible
el vínculo con las plataformas de ejecución.
Este concepto de plataforma de ejecución es muy importante en MDA ya que
es lo que delimita la famosa separación de las preocupaciones.
(C) A. Sánchez L. 2016 16
Transformación de modelos, I
Acabamos de examinar los tres tipos de modelos más importantes para MDA
que son los CIM, PIM y PSM.
También vimos que es importante establecer correctamente los vínculos de
trazabilidad entre estos modelos.
En realidad, MDA establece estos vínculos automáticamente gracias a la
ejecución de transformaciones de los modelos.
Las transformaciones de modelos preconizadas por MDA son esencialmente las
transformaciones CIM hacia PIM y PIM hacia PSM.
La generación de código a partir de los PSM no es por su parte considerada
como una transformación de modelos.
MDA prevé también las transformaciones opuestas:
código hacia PSM, PSM hacia PIM y PIM hacia CIM.
No podríamos destacar demasiado la importancia de las transformaciones de
modelos.
(C) A. Sánchez L. 2016 17
Transformación de modelos, II
Son estas las que aportan la inteligencia del proceso metodológico de la
construcción de una aplicación.
Son estratégicas y forman parte de los conocimientos técnicos de la empresa o
la organización que las ejecuta, ya que contemplan las reglas de calidad de
desarrollo de las aplicaciones.
Consciente de esto, MDA preconiza modelar las transformaciones de los
mismos modelos.
Después de todo, una transformación de modelos puede considerarse como una
aplicación.
Es natural por lo tanto modelar sus requisitos, su análisis y su diseño y sus
modelos de código con el fin de generar automáticamente el código de la
transformación.
(C) A. Sánchez L. 2016 18
Arquitectura general de MDA, I
La siguiente figura proporciona una vista general del enfoque MDA.
Constatamos que la construcción de una nueva aplicación comienza por la
elaboración de uno o de varios modelos de requisitos (CIM).
Se continúa con la elaboración de los modelos de análisis y diseño abstracto de
la aplicación (PIM).
Éstos deben en teoría parcialmente generarse a partir de los CIM para que en
algunos se establezcan los vínculos de trazabilidad.
Los modelos PIM son modelos persistentes, que no contienen ninguna
información sobre las plataformas de ejecución.
Para realizar concretamente la aplicación, es necesario a continuación construir
los modelos específicos de las plataformas de ejecución.
Estos modelos se obtienen por una transformación de PIM añadiendo la
información técnica relativa a las plataformas.
Los PSM no tienen por vocación ser persistentes. Su principal función es
facilitar la generación de código.
(C) A. Sánchez L. 2016 19
Arquitectura general de MDA, II
MDA no considera la generación de
código a partir de los modelos PSM
por otra parte realmente. Ésta se
vinculó más bien con una traducción
de los PSM en un formalismo textual.
Si la primera vocación del enfoque
MDA es facilitar la creación de
nuevas aplicaciones, este procura por
otro lado numerosas ventajas para el
retro-diseño de aplicaciones
existentes.
Esta es la razón por la que las
transformaciones opuestas también se
definen, PSM hacia PIM y PIM hacia
CIM.
Estas transformaciones no están
presentes aún, se encuentran en fase
de investigación
(C) A. Sánchez L. 2016 20
Tecnologías de modelización
Acabamos de ver la primicia de los modelos en el enfoque MDA.
Es esto que lo diferencia principalmente de los enfoques clásicos de ingeniería
de software como OMT (Object Management Technique), OOSE (Object
Oriented Software Engineering) o BCF (Business Component Factory), que
colocan los objetos o los componentes en un primer plano.
Vimos también que MDA preconizaba la elaboración de distintos modelos,
modelo de requisitos CIM, modelo de análisis y diseño abstracto PIM y modelo
de código y de diseño concreto PSM.
Realmente, MDA es mucho más general y preconiza modelar cualquier
información necesaria para el ciclo de desarrollo de las aplicaciones.
Podemos pues encontrar modelos de prueba, despliegue, plataforma, etc.
Con el fin de estructurar este conjunto de modelos, MDA define el concepto de
formalismo de modelización.
(C) A. Sánchez L. 2016 21
Formalismo de modelización MOF, I
El formalismo de modelización MOF (Meta Object Facility).
Un formalismo de modelización es un lenguaje que permite expresar modelos.
Cada modelo se expresa por lo tanto en un determinado formalismo de
modelización.
Los modelos de requisitos tienen su propio formalismo, que es diferente del
formalismo que permite la expresión de los modelos de análisis y diseño
abstracto.
Recordemos por otra parte que el formalismo preconizado para la expresión de
los modelos de análisis y diseño es UML.
Un formalismo define los conceptos, así como las relaciones entre conceptos
necesarios para la expresión de modelos.
El formalismo UML de expresión de los modelos de análisis y de diseño
define, entre otros, los conceptos de clase y objeto así como la relación que
precisa que un objeto es la instancia de una clase.
(C) A. Sánchez L. 2016 22
Formalismo de modelización MOF, II
Los conceptos de modelos y formalismo de modelización no son suficientes
para aplicar MDA.
Hemos visto que era también muy importante poder expresar vínculos de
trazabilidad, así como transformaciones entre modelos.
Para poder efectuar esto, es indispensable trabajar no solamente con los
modelos, sino que además a nivel de los formalismos de modelización.
Es necesario expresar vínculos entre los conceptos de los distintos formalismos.
Por ejemplo, es necesario poder expresar que el concepto de clase UML debe
transformarse en el concepto de clase Java.
Para esto, MDA preconiza modelar los propios formalismos de modelización.
El objetivo consiste en disponer de un formalismo que permita la expresión de
modelos de formalismos de modelización.
En la jerga de MDA, se llama a tal formalismo un metaformalismo, y se llama a
los modelos que permiten expresar los metamodelos. Podemos pues hacer una
analogía entre metamodelos y formalismos de modelización.
(C) A. Sánchez L. 2016 23
Formalismo de modelización MOF, III
La pregunta que se plantea entonces, consiste en saber si es posible construir un
metametaformalismo permitiendo expresar metaformalismos, o incluso un
metametameta -formalismo, y así sucesivamente.
MDA responde que solo son necesarios tres niveles: el modelo, el formalismo
de modelización, también llamado metamodelo, y el metaformalismo.
Para frenar el agregado de más niveles meta, MDA procura que el
metaformalismo sea así mismo su propio formalismo. Un metametaformalismo
no es por lo tanto ya necesario.
En MDA, no existe más que un único metaformalismo, el MOF (Meta Object
Facility).
También llamado metametamodelo, el MOF permite expresar formalismos de
modelización, o metamodelos, permitiendo a ellos mismos expresar modelos.
La siguiente figura ilustra estos conceptos de modelo, de formalismo de
modelización (metamodelo) y de metaformalismo (metametamodelo). Más
adelante, utilizaremos más bien el vocabulario MDA, es decir, modelo,
metamodelo y metametamodelo.
(C) A. Sánchez L. 2016 24
Modelo, metamodelo y metametamodelo
(C) A. Sánchez L. 2016 25
Metaformalismo
La idea de un metaformalismo no es nueva en sí para quien está habituado a
manipular gramáticas de lenguaje.
En el mundo XML, un formalismo está representado en forma de esquema
XML.
Un esquema XML define los conceptos así como las relaciones entre conceptos
que permiten la expresión de documentos XML, y los esquemas XML sean
ellos mismos documentos XML.
Esto no es posible porque existe un esquema de los esquemas XML, es decir un
metaformalismo.
En el mundo XML, el esquema de los esquemas XML es también el último
nivel ya que es así mismo su propio esquema.
La misma analogía puede hacerse entre los lenguajes de programación y la
BNF (Bachus Naur Form), el lenguaje utilizada para expresar la sintaxis de los
lenguajes. En prácticamente todos los manuales de referencia de los lenguajes
(Java, ADA, C++, etc.), se encuentra una definición de la BNF.
(C) A. Sánchez L. 2016 26
El metamodelo UML
Introducimos los conceptos de modelo, metamodelo y metametamodelo.
Hemos también visto que MDA preconizaba la utilización de distintos modelos
y que cada uno de estos modelos se ajustaba a un metamodelo, él mismo
conforma al metametamodelo MOF.
El universo de MDA está particionado (dividido) en un conjunto de
metamodelos.
Cada uno de estos metamodelos se dedica a una etapa particular de MDA
(requisitos, análisis y diseño, código).
Desde un punto de vista puramente teórico, MDA no impone ninguna
dificultad en cuanto a la utilización de tal o cual metamodelo para cada una de
estas etapas.
No es lo mismo para la realización, puesto que MDA preconiza actualmente la
utilización del metamodelo UML para la etapa de análisis y diseño abstracto y
aconseja recurrir a los perfiles UML para elaborar los modelos de código y
diseño concreto a partir de modelos UML.
(C) A. Sánchez L. 2016 27
UML para los PIM, I
El metamodelo UML es el metamodelo más conocido del enfoque MDA.
El tema central de estas notas no será UML, nos limitaremos a precisar
solamente su papel en MDA.
El metamodelo UML define la estructura que debe tener todo modelo UML.
Precisa, por ejemplo, que una clase UML puede tener atributos y operaciones.
Más adelante se presentara con más detalle el metamodelo UML.
Desde un punto de vista más conceptual, el metamodelo UML permite elaborar
modelos que describen las aplicaciones orientadas a objetos.
UML define varios diagramas que permiten describir las distintas partes de una
aplicación orientada a objetos.
Por ejemplo, los diagramas de clases permiten describir la parte estática de las
aplicaciones mientras que los diagramas de secuencia o de actividades permiten
definir la parte dinámica.
Los modelos UML son independientes de las plataformas de ejecución.
(C) A. Sánchez L. 2016 28
UML para los PIM, II
Se utilizan para describir tanto las aplicaciones Java como las aplicaciones C# o
PHP.
Varias herramientas del mercado proponen generadores de código para estos
distintos lenguajes de programación.
Por todas estas razones, está claro que el metamodelo UML constituye el
metamodelo ideal para la elaboración de los PIM (Platform Independent
Model).
Recordemos que un PIM es un modelo de análisis y diseño de una aplicación y
que este debe ser independiente de una plataforma de ejecución.
(C) A. Sánchez L. 2016 29
UML para los PSM, I
El metamodelo UML define el concepto de perfil UML.
Un perfil UML permite adaptar UML a un ámbito particular.
Por ejemplo, el perfil UML para EJB permite adaptar UML al ámbito de los
EJB.
Los modelos UML realizados según este perfil no son ya verdaderamente
modelos UML pero más bien los modelos de la aplicación EJB.
Los perfiles UML dirigidos a plataformas de ejecución permiten, por
definición, adaptar UML a las plataformas de ejecución.
El punto interesante a destacar en un contexto MDA es que los modelos
realizados según estos perfiles no son más modelos independientes de las
plataformas de ejecución pero, por el contrario, modelos dependientes de estas
plataformas.
Estos modelos no son pues más PIM sino PSM (Platform Specific Model).
Gracias a los perfiles dirigidos a las plataformas de ejecución, es posible
utilizar UML para elaborar PSM.
(C) A. Sánchez L. 2016 30
UML para los PSM, II
Estos PSM son más bien modelos de código y no pueden ser confundidos con
el código.
Por el contrario, dado que están vinculados a las plataformas de ejecución,
facilitan en gran parte la última etapa del MDA, que es la generación del
código.
MDA aconseja la utilización de perfiles UML para la elaboración de PSM ya
que esto tiene el mérito de facilitar las transformaciones PIM hacia PSM puesto
que PIM y PSM son ambos modelos UML.
El otro enfoque posible, que también es aconsejado por MDA, es definir los
metamodelos propios a las plataformas.
Este otro enfoque presenta el inconveniente de no facilitar las transformaciones
PIM hacia PSM pero tiene la ventaja de ofrecer una mayor libertad en la
expresión de las plataformas.
El OMG estandarizó los perfiles UML para EJB y UML para CORBA.
(C) A. Sánchez L. 2016 31
UML para los PSM, III
Otros perfiles, como UML para Java o UML para C#, no se estandarizan sino
que están disponibles en productos como Rational Software Modeler o Softeam
MDA Modeler.
(C) A. Sánchez L. 2016 32
UML y CIM
La elaboración del CIM con UML es de hecho un debate.
Recordemos que un CIM es un modelo de requisitos de una aplicación. Los que
conocen UML podrían discutir que los diagramas de casos de uso UML pueden
considerarse como parte del CIM.
Estos diagramas permiten en efecto describir las funcionalidades que ofrece
una aplicación a su ambiente.
Existen sin embargo otros enfoques de expresión de requerimientos, como las
soportadas por DOORS o Rational Requisite Pro.
Por esta razón MDA no hecho ninguna recomendación en cuanto a la
utilización o no de UML para expresar el CIM.
(C) A. Sánchez L. 2016 33
Transformación de modelos con QVT, I Ya mencionamos el hecho de que las transformaciones de modelos estaban en
el corazón de MDA y que era importante modelarlas.
Para ello, el OMG elaboró el estándar MOF2.0 QVT (Query, View,
Transformation).
Este estándar define el metamodelo que permite la elaboración de modelos de
transformación.
La transformación de UML hacia la plataforma Java, por ejemplo, se elabora en
forma de un modelo de transformación conforme al metamodelo MOF2.0
QVT.
El estándar MOF2.0 QVT orienta las transformaciones modelo hacia modelo.
Para simplificar, decimos que un modelo de transformación se considera como
una función que toma un modelo en la entrada y devuelve un modelo en la
salida.
Dado que los modelos de entrada y salida disponen cada uno de su
metamodelo, se habla también de metamodelo de entrada y metamodelo de
salida del modelo de transformación.
(C) A. Sánchez L. 2016 34
Transformación de modelos con QVT, II
La siguiente figura ilustra las relaciones existentes entre el metamodelo
MOF2.0 QVT, uno modelo de transformación (UML2Java), su metamodelo de
entrada (UML) y salida (Java) y una ejecución del modelo de transformación.
(C) A. Sánchez L. 2016 35
Transformación de modelos con QVT, III
Los metamodelos de entrada y salida de un modelo de transformación pueden
ser idénticos.
Un modelo de transformación puede obviamente transformar modelos UML
en… modelos UML.
Los perfiles UML que pueden utilizarse para elaborar los modelos PSM se
consideran como metamodelos completos. Por ejemplo, un modelo de
transformación puede tener el metamodelo UML como metamodelo de entrada
y el perfil UML para EJB como metamodelo de salida.
Tal modelo de transformación puede especificar una transformación UML
hacia EJB.
No hay de verdad consensos sobre el estatuto de la generación de código.
Esto se considera como una transformación modelo hacia modelo por algunos,
esto de hecho no es unánime.
Es a menudo más práctico expresarse bajo forma textual para manipular el
código que en forma de metamodelo.
(C) A. Sánchez L. 2016 36
Transformación de modelos con QVT, IV
Un estándar en construcción actualmente por parte de la OMG permitirá por
otra parte definir un lenguaje específicamente dedicado a la generación de
código a partir de modelos.
Más adelante se enumerarán las transformaciones de modelos en MDA y se
presentaran más concretamente los distintos enfoques posibles para realizar una
transformación de modelo y se ilustrarán a partir de un mismo ejemplo.
(C) A. Sánchez L. 2016 37
Vínculos hacia XML y Java, I
Los modelos son entidades abstractas que no necesitan representación
computacional para existir.
MDA utiliza los modelos con fines de productividad, es sin embargo necesario
que estos dispongan de representaciones concretas con el fin de ser
manipulados computacionalmente.
MDA define dos maneras diferentes de representar los modelos: ya sea en
forma de documentos textuales, o ya sea en forma de objetos de programación.
La representación textual se adapta más al almacenamiento de los modelos en
disco duro o a los intercambios de modelos entre aplicaciones mientras que la
representación objeto se adapta más a la manipulación computacional
(transformación, ejecución, validación, etc.).
Los estándares y frameworks MDA que definen la manera de representar
computacionalmente los modelos son XMI, JMI y EMF.
El estándar XMI (XML Metadata Interchange) define la manera de representar
los modelos en forma de documento XML.
(C) A. Sánchez L. 2016 38
Vínculos hacia XML y Java, II
El estándar JMI (Java Metadata Interface) y el framework EMF (Eclipse
Modeling Framework) definen la manera de representar los modelos en forma
de objetos Java.
EMF, por ejemplo, permite la manipulación de los modelos en la plataforma
Eclipse.
XMI, JMI y EMF funcionan según el mismo principio.
Tanto en XML como en Java, un formato de representación se define por su
estructura.
Definir un formato de representación XML se hace construyendo un DTD o un
esquema XML.
Definir un formato de representación objeto se hace construyendo un conjunto
de clases Java.
El principio de funcionamiento de XMI, JMI y EMF es generar
automáticamente la estructura de los formatos de representación de los modelos
a partir de su metamodelo.
(C) A. Sánchez L. 2016 39
Vínculos hacia XML y Java, III
La idea es sacar partido de la analogía que existe entre la relación entre un
modelo y su metamodelo y la relación que existe entre un documento XML y
su DTD o entre objetos y su clase.
La siguiente figura ilustra este principio de funcionamiento. Constatamos que
XMI, JMI y EMF definen reglas que permiten generar automáticamente las
estructuras de los formatos de representación de modelos a partir de su
metamodelo.
Por ejemplo, XMI aplicado a UML permite la generación automática de un
DTD que permite representar los modelos UML en forma de documentos
XML.
De la misma manera, JMI y EMF permiten la generación automática de clases
Java que permiten representar los modelos UML en forma de objetos Java.
Gracias a los estándares XMI y JMI y al framework EMF, es posible
representar computacionalmente todo modelo.
(C) A. Sánchez L. 2016 40
Principio de funcionamiento de los estándares
XMI y JMI
(C) A. Sánchez L. 2016 41
Vínculos hacia XML y Java, IV
XMI concreta la persistencia de los modelos dado que ofrece un formato de
representación XML. JMI y EMF son las propuestas operativas de MDA dado
que permiten la construcción de operaciones de productividad sobre los
modelos.
Precisemos que existen pasarelas entre estos dos estándares y que es posible
pasar de una representación a otra sin dificultad.
Más adelante se presenta con todo detalle los principios de funcionamiento del
estándar XMI ilustrados por un ejemplo, mientras que también se examinaran
JMI y EMF e igualmente se explicaran a partir de un ejemplo de cómo
manipular un modelo con ayuda de un programa Java.
(C) A. Sánchez L. 2016 42
Ventajas esperadas de MDA, I
Ahora que introducimos el enfoque MDA y que hemos descrito brevemente la
forma en que lo ilustraremos en un caso de estudio, toman un poco de retroceso
con el fin de medir plenamente las ventajas esperadas de este enfoque.
Comencemos por recordar brevemente lo que ha pasado estos últimos años en
el ámbito de la construcción de las aplicaciones distribuidas.
Los primeros trabajos efectuados por la OMG para facilitar la construcción y el
mantenimiento de aplicaciones distribuidas se refirieron a la elaboración de la
especificación CORBA.
El objetivo de CORBA era proporcionar un ambiente estándar y abierto que
permitía a todo tipo de aplicación ser interoperable.
En la época (1990), era necesario solucionar todos los problemas de
interoperabilidad estandarizando las comunicaciones distribuidas y las
interfaces de distintas entidades que componen la aplicación distribuida.
Por distintas razones, CORBA no fue un franco éxito.
(C) A. Sánchez L. 2016 43
Ventajas esperadas de MDA, II
Otros middleware tienen su oportunidad de solucionar el problema de la
interoperabilidad ofreciendo siempre más de los servicios a los diseñadores de
aplicaciones (EJB, DCOM, Servicios Web).
De esta sucesión de middlewares nació la paradoja de los middleware.
Es decir, los middleware se concibieron inicialmente para hacer frente a la
complejidad de las aplicaciones distribuidas y finalmente aportaron mucha más
complejidad que no eliminaron.
El problema no es tanto su propia complejidad, que es inevitable, más bien es el
hecho de que las aplicaciones que los utilizan dependen mucho de los servicios
ofrecidos por estos middleware.
Por lo tanto, cambiar de middleware se convierte en una pesadilla dado que la
aplicación se atrapa en el middleware.
Algunos llegan hasta llamar spaghettiware las aplicaciones distribuidas que
utilizan los middleware.
(C) A. Sánchez L. 2016 44
Ventajas esperadas de MDA, III
La evolución de una aplicación tiene un costo prohibitivo, ya que es necesario
inevitablemente sumergirse en el mismo para cortar todos los vínculos con los
middleware que se quieren cambiar
Para solucionar este problema, la solución considerada consistió en aplicar todo
para garantizar de manera industrial la famosa separación de las
preocupaciones entre el negocio de las aplicaciones y la técnica de los
middleware. De allí nació MDA.
Las tres ventajas buscadas eran entonces las siguientes:
La persistencia de los conocimientos técnicos, con el fin de permitir a las empresas
capitalizar sobre su negocio sin tener que preocuparse de la técnica.
Las ganancias de productividad, con el fin de permitir a las empresas reducir los
costos de desarrollo de las aplicaciones computacionales necesarias para su negocio.
La consideración de las plataformas de ejecución, con el fin de permitir a las
empresas beneficiarse de las ventajas de las plataformas sin sufrir de los efectos
secundarios.
(C) A. Sánchez L. 2016 45
Conclusión
Esta primera parte presentó MDA a grandes rasgos.
Sabemos que MDA utilizaba mucho los modelos e indicamos los distintos tipos
de modelos empleados por MDA, es decir CIM, PIM y PSM.
Presentamos también brevemente las distintas tecnologías que permiten aplicar
MDA.
Dejamos para terminar las principales ventajas de MDA, que son la
persistencia, la productividad y la consideración de las plataformas.
En la consecuencia del curso, detallaremos cada uno de los puntos planteados
en esta parte introductoria del curso.
