Model Driven Architecture

Por José García y Juan Fernando Valdés

Objetos y Abstracción de Datos

Guatemala 2009
 Model Driven Architecture

Por José García y Juan Fernando Valdés

Objetos y Abstracción de Datos

Universidad del Valle de Guatemala

Facultad de Ciencias y Humanidades
26 de febrero de 2009
2

ÍNDICE

Página .

Capítulos

I. INTRODUCCIÓN ……………………………………………………….. 3
II.MODERN DRIVEN ARCHITECTURE ………………………………… 4
A. El futuro a largo plazo para los MDA ………………………………. 6
B. Java y MDA ……………………………………………………….….. 6
III.METODOLOGÍA DE RAMBAUGH…….………………………………. 7
IV.METODOLOGÍA DE SHLAER Y MELLOR....................................... 10
V.CONCLUSIONES.............................................................................. 12
VI.BIBLIOGRAFÍA ………………………………………………………….. 13
3

I. INTRODUCCIÓN

Un Model Driven Architecture (MDA) es un sistema que es creado

automáticamente a base de un modelo que pretende describir el sistema usando
un lenguage independiente de plataformas. De esta manera es posible hacer que
el sistema funcional se genere a partir del mismo modelo para que funcione en
diferentes plataformas e incluso para que funcione en ambientes en donde es
vital la cooperación entre equipos que utilizan diferentes plataformas.

La metodología de Rumbaugh usa el concepto de objeto para proponer un

método de desarrollo de software que consta de 4 etapas. También se asiste de
3 tipos de modelos gráficos compuestos por diagramas que se usa para estudiar
diferentes partes del sistema. Los modelos son de objetos, de funcionalidad y
dinámicos, el último refiriemdo al cambio de estados de objetos. La primera
etapa es análsis del sistema, después el diseño de sistema, diseño de objetos y
finalmente implemenración. También estudiaremos la metodología de Rumbaugh,
dónde se separa al sistema en 4, no 3 descripciones ortogonales y se describe
un método aplicable a todas ellas, que consiste en 3 diagramas. Y así se usan
todas para generar el código al combinarse.

En esta investigación se busca estudiar tanto el MDA como la metodología de

Rumbaugh y de Shlaer y Mellor para comprenderlos mejor, sus capacidades,
sus limitaciones y la forma en la que funcionan.
4

II. MODERN DRIVEN ARCHITECTURE

Un MDA es, tal como su nombre lo indica, una forma de crear sistemas que
funcionan a base de un modelo. En otras palabras, en un MDA, a partir de un
modelo que describe al sistema y que está diseñado en un lenguaje
independiente de plataformas (como lo es UML) se establece la funcionalidad del
sistema. El modelo es traducido a un sistema funcional en plataformas
específicas por medio de una función que mapea el modelo independiente de
plataformas a uno que depende de las plataformas en las que se utilizará el
sistema y posteriormente a un código para esas plataformas. (Poole, 2001:2).

Para entender lo anterior es necesario comprender antes a lo que se refiere con

plataformas independientes y por ende a ser dependiente de plataformas. Esto
se hará buscando una analogía con la conocida “independencia de plataformas”
de Java. Se dice que el lenguaje Java es independiente de plataformas ya que
uno escribe código en un lenguaje de programación, este genera un archivo en
“bytecode” es decir, un archivo en código binario y este es posteriormente
ejecutado en cualquier sistema por la máquina virtual de Java (JVM). Notemos
entonces la importancia de la JVM. Esta es necesaria ya que el programa debe
ser corrido sobre ella. Además la llamada “independencia de plataformas” se
consigue por medio de darle a cada plataforma una JVM que pueda correr
adecuadamente en ella. Por lo tanto, el programa creado en Java es dependiente
de la presencia de la JVM ya que en realidad esta es la plataforma sobre la que
el programa debe correrse. Aún si existen diferentes JVM para correr el mismo
programa desde computadores o sistemas con otro tipo de plataformas, el
programa creado es dependiente de un JVM. Por lo tanto no es a lo que se
refiere con la independencia de plataformas del modelo que está en el corazón
de todo sistema MDA.

Con la “independencia de plataformas” de este modelo nos referimos a que el

modelo puede ser utilizado para describir cómo funciona el sistema sin importar
la plataforma en la que se espera que este vaya a correr. Por lo tanto el trabajo
en un MDA recae en funciones que mapean el modelo a sistemas específicos ya
que el mismo modelo puede utilizarse para describir el sistema en cada uno de
estos. Diferentes funciones mapean el modelo en modelos específicos para
diferentes plataformas, dándole así funcionalidad al modelo en todas estas
plataformas simultáneamente. UML es un buen ejemplo de un modelo
independiente de plataforma ya que con él se pueden modelar sistemas
orientados a objetos a casi cualquier plataforma. Hay que notar que aunque
UML cumpla con la independencia necesaria para crear un MDA, no es el único
lenguaje que lo cumple por lo que no es estrictamente necesario para un MDA.
4
4
5

Ahora es necesario estudiar las ventajas que tiene un sistema hecho a base de
MDA. La primera ventaja es evidente: por medio de un modelo se puede
construir programas que funcionen en forma similar sobre diferentes plataformas.
Otra característica importante del MDA es que por medio de este el programador
podrá modificar el modelo para modificar el programa, y sus versiones en cada
plataforma para la que está hecho sin tener que recurrir a revisar el código ya
que este es producido a partir del modelo. En MDA “el programa es el
modelo” (Venners, 2007). Sin embargo, esta no es la única funcionalidad de usar
MDA. Resulta ser más interesante considerar el caso de un sistema de
información en el que actúan diferentes componentes que funcionan con
diferentes plataformas. Propongamos por ejemplo un juego de celular en el que
se almacenan los récords globales del juego en una página de Internet. Este
juego debe ser corrido por celulares con distintas plataformas y, más aún, el
celular deberá interactuar eventualmente con un computador en donde se están
guardando los récords. Las plataformas del celular pueden y suelen ser
totalmente diferentes a las del computador. Además si el juego tiene un modo
celular contra celular, distintos celulares con distintas plataformas deberán
interactuar en el sistema generado por el juego. Por lo tanto si esta interacción es
descrita por un modelo independiente de plataformas, este describirá el rol que
debe de tomar cada actor (en este caso cada plataforma distinta) sin importar de
cómo se realice el trabajo dentro del actor ya que esto lo determinará la función
que transforma el modelo independiente a uno dependiente. Por lo tanto los
sistemas MDA permiten un gran nivel de interacción entre plataformas que sería
difícil de alcanzar sin esta herramienta. A esto se le llama interoperabilidad.

Para entender el funcionamiento de un MDA hay que comprender antes el

concepto de metadatos. Los metadatos son datos que dan información sobre los
datos que se mueven en el sistema. Estos son importantes ya que en diferentes
plataformas, datos que brindan la misma información pueden ser tratados
diferentemente. Debido a esto el sistema debe tener metadatos que le permitan
reconocer el tipo de información que se están enviando y recibiendo. También
son necesarios metadatos que guarden información sobre las definiciones y
capacidades del ambiente y de los componentes que interactúan en él .Por esto
el medio para conseguir interoperabilidad en un ambiente heterogeneo (uno en
donde interactúan plataformas distintas) es a través del manejo de los metadatos
(Poole, 2001:2).

La utilización de metadatos facilita el intercambio de información y posibilita el

mapeao de datos de un tipo a datos de otro a través de sus descripciones.
También facilita la generación de resultados que puedan ser utilizados por otros
elementos del sistema. Los metadatos también se utilizan para permitir que los
componentes del software de diferentes o incluso del mismo elemento del
sistema, puedan interacutar entre ellos una vez los metadatos les permitan
conocer que tipo de información requiere o es enviada por el otro componente de
software. (Poole 2001:4)
6

Para conseguir que los metadatos son entendidos por todos los componentes es
necesario que el sistema MDA tenga verciones estándard del lenguaje formal
que se utiliza para representar los metadatos, el formato de intercambio y
publicación de metadatos, un modelo para acceder a los metadatos existentes o
para crear los metadatos necesarios al realizar una operación (como por ejemplo
al agregar un componente nuevo al sistema) (Poole 2001:5).

A. El futuro a largo plazo de las MDA

Se espera que en un futuro los sitemas basados en un MDA tengan, adamás de

las propiedades y capacidades mencionadas anterirormente, la capacidad de
reconocer características del medio en el que se corre el sistema y que pueda
acoplarse a él, modificando su propio comportamiento si es necesario. Usando la
propiedad reflexiva de algunas plataformas, en la acutalidad es posible conseguir
que un programa se revice su propia ejecución. Se espera que en el futuro esto
se vea acompañado de que el programa modifique su estructura y
comportamiento de acuerdo con estas revisiones.

B. Java y MDA

La portabilidad que permite Java gracias a la “independencia de plataformas” de

Java discutida anteriormente ha facilitado el desarrollo de mapeos de estándares
del Object Management Group (OMG) MDA hacia modelos de tecnología de
Java. Estos son el Java Metadata Interface (JMI), Java OLAP Interface (JOLAP)
y el Java Data Mining API (JDM).
7

III. METODOLOGÍA DE RAMBAUGH

Object Oriented Methodology (OMT)

Orientado a objetos significa organizar sofwtare como un conjunto de objetos

discretos orientados que incorporan una estructura de datos y un
comportamiento. Aunque es discutible se pueden caracterizar por:

Identidad, clasificación, polimorfismo, y herencia.

La metodologia trata de usar estos conceptos en el desarrrollo de software,

recordando, análisis, diseño e implementación. Esta consiste en los siguientes
estados:

1. Anásisis: Abstracción de que se desea del sistema, posibilidad de ser critica

do por expertos no programadores, se usa el modelo funcional.

2. Diseño del sistema: Organización del sistema en subsistemas, para identificar

y optimizar las características deseadas.

3. Diseño de objetos: Modelo que espexífica parte de los detalles de

implementación, contenido y relaciones de clases.

4. Implemtenación: Se traduce diagramas a un lenguaje de programación.

Se usan tres modelos en la metodología, el modelo de objeto. el modelo

dinámico y el modelo funcional. Estos son ortogonales y forman la descripcion de
un sistema completo, siendo el principal el modelo de objetos.

Logramos reemplazar las estructuras de datos y de procedimiento por una

jerarquía de clases, se logra una combinación sinérgica de los conceptos, y un
énfasis en la estructura También se promueve el reuso de la estructura a través
de herencia.

Los objetos promueven una base para la implementación. La clase del objeto
describe al grupo de objetos con los mismos atributos. estos se representan en
diagramas. Aquí damos uso al principio de encapsulación. Ademas de los
atributos tenemos las operaciones y métodos. Los métodos implementan las
operaciones y llamamos firma del método a sus argumentos y tipo de valor
regresado.
8

Las relaciones entre clases son las asociaciones, de las que tenemos como caso
especial, las agregaciones. Las agregaciones refieren a asociaciones completas.
Las asociaciones puede ser también indican multiplicidad. se puede modelar
asociaciones como clases.

Los diagramas dinámicos modelan eventos y estados. Los valores de atributos

constituyen el estado y los eventos son los estimulos entre objetos, cambian
estados. Entendemos por escenario una secuencia de eventos. el diagram a de
estados relaciona los eventos yestados. el cambio de estado se llama transición.
El diagrama incluye condiones para el desarrollo de las secuencias, una vuelta e
el diagrama es la secuencia completa de un evento. Los diagramas así
representan únicamente losestados de un objeto. Para una clase todos los
objetos comparten el mismo diagrama. El modelo dinámico es la colección de
diagramas que interactuan con eventos conpartidos.

Ahora los modelos funcionales, los últimos, muestran los resultados de

computaciones sin específicar como se calculan. Consisten de diagramas de
flujo dde datos que especifican el sinificado de operaciones y sus limitaciones.
Enseñan la relación funcional de los valores calculados, conteniendo los actores
que producen y consumen los datos, y los que los guardan(el patrón de entradas
y salidas).

Figura 1.
9

Figura 2

Figura 3

Figura 4
10

IV. METODOLOGÍA DE SHLAER Y MELLOR

Los dos son investigadores de Project Technologies. Se desarrolló para el proyecto de

renovar el sotware que controlaba el sistema de metro en Berkeley. Transformaron un
software de 70,000 a uno de 2,000 por medio de aplicar una metodología estructurada.
Se puede usar en EDraw Max.

En esta metodología se aplic ael método a cad auno de los dominios que forman el
sistema. Un dominio es un “mundo real, hipotético, o abstracto que esta compuesto de
objetos que se comportan de acuerdo a las características de ese mundo.” Los dominios
son:

1. Aplicación: Es el dominio que identifica el próposito del sistema. Este tiene que ver
con la utilidad que se quiere tener a disposición del cliente o usuario. Este dominio
dice qué servicio da el sistema.

2. Servicios: Formado por las funciones de utilidad que dicen como es que el próposito
es realizado, de for a general, el dominio de servicios que contiene el como prestar la
aplicación deseada por el usuario.

3. Arquitectura: Dominio que tiene una cualidad muy interesante. El qué y cómo estan
establezidos en un lenguaje que habla de objetos y como funcionan y se relacionan
sus propiedades(sus métodos y atributos). Este dominio esta constituido por
mecanismos, arquetipos, y reglas de traducción. Estos sirven como formatos
predefinidos, que son llenados por mecanismos e implementados al código ya con
las reglas de traducción.

4. Implementación: Formado de las librerias, lenguajes, y sistemas operativos.

La metodolgía usa cuatro diagramas para los dominios que consisten en los siguietes
modelos:

1. Información: Este tiene los objetos, y existe uno para cada subsistema. Para cada
objeto de un subtipo hay un supertipo y vice versa.

2. Estado: Modela el ciclo de un “objeto activo”. Se usa el formalismo de Moore, una

accion es realizada unicamente cuando cambia un estado. se describen las
transiciones, accioners que ocurren cuando cambian, y una descripción escrita. Las
acciones son atómicas y pueden ocurrir mulyiples máquinas de cambio de estado en
una ejecución simultánea.

3. Proceso: Pueden ser de 5 tipos, accesos, generadores de estados,

transformaciones, tests, y puentes a otros dominios.Ilustran el flujo de datos.

El método tiene modelos derivados de los descritos anteriormente para describir

jerarquía y comunicación de substisemas y ellos mísmos
11

1. Relación de subsistemas.

2. Comunicación de subsitemas: comunicación de eventos.

3. Acceso de subsistemas: acceso a atributos de objetos.

4. Nivel subsistema:

A. Comunicación de objetos

B. Acceso objetos

La implementación de lmétodo se puede ver en la figura abajo y es dotado de un

proceso recursivo que consiste en la aplicación iterada del proceso a cada dominio.
Cabe mencionar que los dominios promueven una concepción ortogonal del sistema, y
así son desarrollados de manera disjunta y su relación descrita en la relación
desarrollada en los modelos explícitamente y únicamente.

Figura 5.

Este método se usa por los investigadores del Laboratorio de los Alamos para
desarrollar software para un colisionador de iones llamado PHENIX. Existe
documentación de desarrolladores que quisieron modificar el método y
terminaron desarrollándolo de nuevo.
12

V. CONCLUSIONES

Conclusiones sobre MDA

1. MDA tiene un gran potencial para facilitar el desarrollo de sistemas en

independencia a plataformas y es LA alternativa para hacerlo.
2. MDA tiene una abstracción del sistema suficientemente general como para no
caer problemas de implementación de ningún tipo al diseñar un sistema.
3. La metadata provee una descripción suficientemente detallada como para
generar implementaciones a partir del modelo y es íntinseca a la operabilidad
del método.

Conclusiones sobre las Metodologías

1. La metodología de Rumbaugh hace un énfasis en el diseño de objetos y la

estructura del sistema y subsistemas.

2. La metodología de Rumbaugh no tiene como gran consideración el

procedimiento a la implementación de código, sino a la optimización de los
modelos.

3. La metodología de Shlaer y Mellor tiene aplicaciones en sistemas muy

grandes, y permite la generalidad del sistema de lenguages y plataformas,
dando la herramienta para incluirlos en el proceso.

4. La metodología de Shlaer y Mellor provee de un método muy completo tanto

en el enfoque de diseño y próposito del sistema, funcionalidad e
implementaciones.
13

VI. BIBLIOGRAFÍA

1. John D. Poole, Model-Driven Architecture: Vision, standards, and emerging

technologies. ECOOP. 2001. Consultado en [28-2-2009].

<http://www.omg.org/mda/mda_files/Model-Driven_Architecture.pdf>

2. James Rumbaugh, Object oriented design. Prentice Hall New Jersey. 1991.
Capítulos 1, 3, 4, y 5.

Imágenes: págs. 32, 60, 91 128, 129.

3. Venners, The real meaning of Model-Driven Architecture, An Interview with

Frank Sommers. 2007. Consultado en [28-2-2009].

<http://www.artima.com/lejava/articles/javaone_2007_no_magic.html>

4. Thomas Kolowski, Thomas Carey(Los Alamos Physics Division), David

Whitehead(Brookhaven National Laboratory), Charlie Maguire(Vanderbitt
University), et all. Shlaer and Mellor oriented objetct analysis and recursive
design, an effective modern software development method for developing
computing systems for a large physics detector. US DEPARTMENT OF ENERGY
para RHIC PHENIX Detector.

Figura 2 página 8, Traducción de modelos de OOA.