MDA: Arquitectura Dirigida por Modelos

María Consuelo Franky

lfranky@javeriana.edu.co
Dpto. Ingeniería de Sistemas
Universidad Javeriana
Bogotá - 2010
http://sophia.javeriana.edu.co/~lfranky/
1
 Temario
• Objetivos de MDA (Model Driven Architecture)
• Términos y Conceptos base MDA
• Construyendo Modelos
• Construyendo Meta-modelos
• Construyendo Transformaciones
• Construyendo modelos de Marcas
• Construyendo Lenguajes de modelado
• Elaborando Modelos
• Construyendo modelos Ejecutables
Referencia: “MDA Distilled, Principles of Model Driven Architecture”,
Stephen Mellor, Kendall Scott, Axel Uhl, Dirk Weise, Addison-Wesley
Professional, 2004

Referencia OMG : “Model Driven Architecture (MDA)”,

Document number ormsc/2001-07-01 - Architecture Board ORMSC1, 2001
2
 Objetivos de MDA
(Model Driven Architecture)

3
MDA es el estándar OMG que busca resolver los
problemas de integración de sistemas

Misión de OMG (Open Management Group)
 Ayudar a los usuarios de computadores a resolver problemas de
integración, mediante especificaciones abiertas y neutrales respecto a
proveedores
 Estándares definidos por la OMG desde 1990:
 1991: CORBA: (Common Object Request Broker Architecture)
 1997: Unified Modeling Language™ (UML™)
 1997: Meta Object Facility™ (MOF™)
 1997: XML Metadata interchange (XMI™)
 1997:Common Warehouse Metamodel (CWM™).
 2001: MDA
 2006: BPMN

MDA (Model Driven Architecture) - 2001

 objetivo principal: soportar interoperabilidad mediante estándares de
integración para las distintas etapas del ciclo de vida de los sistemas:
 del modelaje de negocio al diseño del sistema
 construcción de componentes
 ensamblaje de componentes
 integración, publicación, administración y evolución 4

MDA propone una estrategia (que debe ser soportada por
herramientas) para:
 especificar un sistema independiente de la plataforma tecnológica
 especificar plataformas
 escoger una plataforma para un sistema
 transformar la especificación del sistema para una plataforma
particular

Tres objetivos de MDA: portabilidad, interoperabilidad, y

reutilización

MDA es dirigido por modelos (model-driven)

 usa modelos para todas las etapas del ciclo de vida de un sistema

5
 MDA busca mayor abstracción, reutilización e
integración en el desarrollo de sistemas

Elevando el nivel de abstracción hay mayores posibilidades
de reutilización
 El desarrollo basado en modelos construye modelos que son
independientes de plataformas de software
 Los modelos se reutilizan para generar sistemas para múltiples
plataformas

tomado de: “MDA Distilled, Principles of Model Driven Architecture”

Es más fácil resolver la interoperabilidad de sistemas a un

nivel de diseño y no de implementación 6
 Los estándares OMG se enmarcan en MDA
Estándares para expresar modelos: UML, MOF y CWM (tecnologías
usadas para describir PIMs: modelos independientes de plataforma).

Plataformas tecnológicas

Servicios generales para toda aplicación

(definidos como modelos PIM en UML para
permitir integración entre sistemas)

Especificación de mercados
verticales a través de DTFs
(Domain Task Forces)

tomado de: “Model Driven Architecture (MDA” 7

Términos y Conceptos de MDA

8
 Conceptos básicos de MDA

Modelos
 un Modelo consiste de un conjunto de elementos que describen
alguna realidad física o hipotética (siendo una simplificación de esa
realidad)
 MDA trata de crear diferentes modelos a diferentes niveles de
abstracción y luego los integra para formar una implementación
 típicamente un modelo se presenta combinando gráficos y texto
 ejs de modelos: código fuente, interfaces IDL, diagramas UML

Abstracción
 ignorar información que no es de interés en un contexto particular

Clasificación
 agrupar información en base a propiedades comunes

Lenguajes de modelado:
 Sintaxis (gráfica o textual) y semántica (significado) de los
elementos usados para expresar un modelo
 por ejemplo: UML y DSLs (lenguajes de dominios específicos)
9
 Metamodelos y plataformas

Metamodelo
 es un modelo de un lenguaje de modelado: define la estructura,
semántica y restricciones de una familia de modelos

 ejemplo: UML tiene un metamodelo que describe aspectos de

estructura y de comportamiento de cualquier modelo UML
 NOTA: el metamodelo de UML se expresa en MOF

Plataforma
 especificación de un ambiente de ejecución para un conjunto de
modelos (ej: CORBA, .NET, JEE)

 relación entre modelos, metamodelos y plataformas:

tomado de: “MDA Distilled, Principles of Model Driven Architecture”

10
 Mapping: Transformación entre modelos

Un mapping o transformación toma uno o más modelos de
entrada y produce un modelo de salida
 ej: transformar un modelo UML de una aplicación a su correspondiente
modelo de código Java

Las reglas de transformación (mapping rules) describen

cómo hacer la transformación
 la transformación completa se considera una función de transformación con
muchas reglas de transformación (ej: una clase en UML se convierte en una
clase Java con el mismo nombre)

 las reglas se especifican a nivel del metamodelo para que puedan aplicarse a
cualquier modelo asociado

tomado de: “MDA

Distilled, Principles
of Model Driven
Architecture” 11
Construyendo Modelos

12
 Características de un buen Modelo

Un buen modelo omite información
 para facilitar la comprensión del objeto modelado

Un buen modelo refleja correctamente una realidad real o

hipotética

Un buen modelo debe ser más económico de construir que la

realidad modelada

Un buen modelo sirve como medio de comunicación entre

los observadores del modelo: humanos o máquinas

13
 Abstracción, Clasificación y Generalización

Un modelador típicamente combina las acciones de
clasificación, abstracción y generalización

tomado de: “MDA Distilled, Principles of Model Driven Architecture” 14


“Zooming in y zooming out”
 MDA permite hacer modelos a un mayor
o menor nivel de detalle

 ”Zooming out” de los objetos de un

modelo: agrupa muchos objetos en
pocos objetos de granularidad más
gruesa (zooming in: ver los detalles de
un objeto grueso)

 ”Zooming out” de las interacciones de

los objetos de un modelo : reúne las
interacciones en una sola interacción
abstracta

tomado de: “Model Driven Architecture (MDA” 15

Modelos para diferentes temas de un mismo sistema

Un dominio de problema es un
tema que puede entenderse
independiente de otros temas

Ejemplo: modelos de un sistema

bancario
 diagrama de clases del
dominio del negocio bancario

 diagrama de clases del

dominio de seguridad (general
para cualquier sistema)

Se necesitan múltiples
proyecciones del sistema para
que al mezclarlas formen el
modelo del sistema completo

16

A medida que se progresa del análisis hacia el diseño de un
sistema, el dominio del problema y el lenguaje de modelaje
se vuelven menos abstractos:

tomado de: “MDA Distilled, Principles of Model Driven Architecture” 17

 Modelos y plataformas

Dos clases de modelos en
relación a la independencia
de plataformas

 PIM (Platform Independent

Model): es un modelo
centrado en un dominio de
problema, independiente de
cualquier plataforma en que
se vaya a implantar

 PSM (Platform Specific

Model): es un modelo de
menor nivel de abstracción
con detalles de la plataforma
en que se va a implantar
(persistencia, seguridad, red,
etc.), por ej:
18

Beneficios de la separación entre modelos PIM y PSM
 Facilita validar correctitud del sistema en el modelo PIM al estar
desligado de aspectos de plataforma tecnológica

 Facilita producir implementaciones del mismo sistema en diferentes

plataformas tecnológicas, cumpliendo los objetivos de negocio
planteados en el modelo PIM

 La integración e interoperabilidad entre varios sistemas se puede

definir de manera más clara en los modelos PIM, y luego se puede
transformar a mecanismos específicos de plataforma (modelos PSM)
Modelo CIM: es modelo del
dominio que no muestra
estructura del sistema

tomado de: “Model Driven

Architecture (MDA”
19
Construyendo Metamodelos

20
 Qué es un metamodelo y para qué sirve?

Un metamodelo es un modelo de un lenguaje de modelado.
 Especifica los conceptos del lenguaje de modelado

Especifica exactamente qué significa un modelo

Simplifica la comunicación entre los interesados en un
modelo
 ejemplo: en lugar de explicar “En el modelo un Cliente es algo que
tiene atributos y operaciones y que persiste tanto como el sistema
viva”, se puede decir “En el modelo un Cliente en una Entidad”
siempre y cuando el concepto Entidad esté definido en el
Metamodelo.

En base a conceptos de metamodelos se puede establecer de

forma concreta las funciones de transformación de un
modelo a otro.
 ejemplo: cada Class de un modelo 1 se transformará a un Entidad del
modelo 2
21
 Ejemplo de un metamodelo

Subconjunto del metamodelo del lenguaje UML:
 indica el concepto Class que tiene múltiples Property y Operation
y que es subclase de Classifier (Interface es otra subclase)

tomado de: “MDA Distilled, Principles of Model Driven Architecture” 22

 Un metamodelo constituye un mayor grado de
abstracción respecto a los modelos de un sistema

tomado de: “MDA

Distilled, Principles of
Model Driven
Architecture”

23
 Los elementos de un modelo son instancias de los
conceptos del metamodelo

tomado de: “MDA Distilled, Principles of Model Driven Architecture” 24

 Arquitectura MDA de 4 niveles

M0: datos de la aplicación

modelo de modelo de
clases objetos

M1: modelo(s) de la
aplicación

ej: modelo de clases UML

M2: metamodelo asociado al

modelo de la aplicación

ej: metamodelo de UML

M3: metamodelo del

metamodelo

ej: MOF como metamodelo del
metamodelo de UML

indica propiedades del
metamodelo M2, que son
requeridas por las herramientas
tomado de: “MDA Distilled, Principles of Model Driven Architecture” de intercambio 25

Papel que juega XMI (XML Metadata Interchange)

 XMI es un mecanismo estándar de intercambio entre varias

herramientas o repositorios

 XMI puede ser usuado para producir automáticamente XML DTDs

de modelos UML y MOF, con el fin de lograr una representación
serializada

26
Construyendo Transformaciones

27
 Qué es una transformación entre modelos

Una transformación (mapping) entre modelos está definida
por una función de transformación compuesta de muchas
reglas de transformación

Objetivo: transformación automática de un modelo (más

abstracto) a otro (más concreto)
 mayor portabilidad
 mayor eficiencia de desarrollo
 mayor calidad del software
 menor tiempo de desarrollo
 menor costo

Los detalles de transformación se separan de los modelos

fuente y destino
 la transformación debería ser repetible para regenerar el modelo
destino cuando cambia el modelo fuente
 el modelo destino por definición está sincronizado con el modelo
fuente
28
 Ejemplo informal de transformación
Analysis Model Information

An Account
- knows its account number
- knows its balance
- can withdraw an amount of money from its balance
- can deposit an amount of money to its balance

A Transfer
- knows the amount of money to transfer
- knows its source and target Accounts
- executes by withdrawing the specified amount of money from its source
Account and depositing it to its target Account

With regard to the lifetime of Accounts, and Transfers, the analysis model
states the following:
 An Account exists from the moment it has been opened until the moment it
has been closed.
 A Transfer exists from the moment it has been commanded by a Customer
until the moment it has been executed.

tomado de: “MDA Distilled, Principles of Model Driven Architecture” 29

 Design Model Information

An Account
- is an entity bean with persistent attributes holding its account number and
balance
- has operations for withdrawing and depositing amounts of money

A Transfer
- is a stateful session bean with transient attributes holding the amount of
money and pointing to the source and target Accounts
- has an operation for executing the transfer

Mapping rules

A class whose instances need to persist over the lifetime of the software system
shall be represented as an entity bean.

A class whose instances exist only for a relatively brief period of time, and that
carry information relating to entity beans, shall be represented as a stateful
session bean.

Every entity bean and stateful session bean shall have attributes that reflect
necessary information about associations in the analysis model.

Las reglas de transformación se definen en términos del metamodelo pero operan sobre modelos 30
Esquema general de transformaciones entre modelos

tomado de: “Model Driven Architecture (MDA”

31

Transformaciones entre modelos PIM y PSM:
 PIM => PIM : refinar un modelo PIM generando otro modelo PIM
 el refinamiento no requiere información de plataforma (ej: transformar
un modelo de análisis en un modelo de diseño)

 PIM => PSM : cuando un modelo PIM es suficientemente refinado

se proyecta a un modelo PSM en términos de la infraestructura de
ejecución
 es relativamente sencillo transformar los elementos estructurales pero
no lo es para los aspectos de comportamiento (operaciones)
 ej: transformar de un modelo lógico de componentes a un modelo de
components EJB o DCOM

 PSM => PSM : refinar un modelo PSM para añadir detalles de

implantación
 ej: detalles de configuración y publicación en un tipo de servidor

 PSM => PIM : abstraer un modelo relativo a una plataforma

específica en otro modelo independiente de cualquier plataforma
 Es difícil lograrlo totalmente de manera automática
 idealmente después de una transformación PIM=>PSM, la
transformación reversa debería regresar al modelo PIM de partida 32
.

Cómo se refinan típicamente los modelos:

tomado de: “Model Driven Architecture (MDA” 33

 Alternativas para expresar una
función de transformación

Imperativo: las reglas de transformación se expresan
mediante algoritmos en un lenguaje de programación
 la tranformación no es reversible (no se puede construir el modelo
fuente a partir del modelo destino, por ejemplo para entender este
último)

Arquetipo: conjunto de plantillas que mezclan código y

reglas para generar texto destino a partir de metamodelos
 tampoco es reversible

Declarativo: reglas que indican qué se quiere producir pero

no cómo hacerlo
 facilita reversibilidad

Enfoque dirigido por modelos: la transformación se

especifica en un modelo respaldado por un metamodelo
 asegura reversibilidad 34
 Escenarios de transformación de modelos

Transformación de refinamiento
 transforma un modelo hacia otro de menor nivel de abstracción (por
ej; pasar del modelo de análisis al modelo de diseño)
 el modelo generado podría requerir ser completado

Transformación de abstracción
 transforma un modelo detallado hacia otro de mayor nivel de
abstracción
 permite portar un modelo detallado para una plataforma a otra
plataforma (transformando inicialmente hacia el modelo abstracto)

Transformación de representación
 transforma cambios en un modelo en cambios en su representación y
viceversa (ej: cambiar nombre de una clase en un modelo de clases
UML implica cambio en el repositorio del modelo, lo cual implica
cambio en el modelo de secuencia, etc.)

35

Transformación de migración
 transforma un modelo directamente a otro del mismo nivel de
abstracción (transformación horizontal)
 ej: para cambiar la versión de modelo de datos, para optimizar, para
hacer refactory, etc.

Transformación de combinación
 toma varios modelos fuentes y los combina en un solo modelo
destino

tomado de: “MDA Distilled, Principles of Model

Driven Architecture”

36
Enumeraciones en una función de transformación

Son adicionales a las reglas de transformación

Indican cómo transformar uno a uno elementos del modelo

fuente en elementos del modelo destino
 ejemplo:

La asociación se expresa en elementos de cada metamodelo

 ej: cada Atrribute (metamodelo de UML) es transformado en un
Column (metamodelo del modelo Entidad-Relación)

37
Construyendo modelos de Marcas

38
 Qué son las marcas y su modelo

Las marcas son extensiones a un modelo fuente que permiten
que una transformación genere un modelo destino más
completo

 como las transformaciones, las marcas están separadas tanto del

modelo fuente como del modelo destino

 permiten probar múltiples posibles transformaciones de un mismo

modelo fuente (por ejemplo las marcas pueden indicar características
de distribución entre múltiples procesadores)

Un modelo de marcas indica nombre, tipo y valor por defecto

para cada marca

Una función de transformación podría generar marcas para el

modelo destino con el fin de que sean usadas para una nueva
trasnformación a partir del modelo destino
39
 Marcas comunes

Tipo de acceso de cada elemento del modelo fuente
 ejemplo de declaración de la marca:
enum AccessorType [ isRemote, isLocal] = isLocal

dependiendo del valor de esta marca para un elemento, la función de

transformación genera un componente habilitado para acceso
remoto o local

Cardinalidad de un elemento
 ejemplo de declaración de la marca :
InstanceQuantity: Int = 50000;

dependiendo del valor de la marca para un elemento , la función de

transformación genera una tabla con un tamaño adecuado

Otros ejemplos de marcas

 para indicar si un elemento es
 stateful o stateless,
 transiente o persistente
 de acceso remoto o local
40
Construyendo lenguajes de modelado

41
 Por qué construir un lenguaje de modelado

No siempre se construye explícitamente un lenguaje de
modelado
 al utilizar un subconjunto de UML para expresar un modelo de análisis
y otro de diseño, implícitamente se están definiendo 2 nuevos lenguajes
 al extender UML (con nuevos artefactos) implícitamente se está
definiendo un nuevo lenguaje

Razones para definir (explícita o implícitamente) un nuevo

lenguaje de modelado
 comunicación entre los miembros del equipo :
 ej: que todos usen una misma anotación {persistent} en los elementos
persistentes y que todos entiendan el mismo significado)
 comunicación con las máquinas:
 permitir transformación automática entre modelos expresados en
lenguajes de modelado

Definición de un lenguaje de modelado:

 sintaxis abstracta que describe estructura del lenguaje independiente
de sus símbolos de notación
 ej: metamodelo de UML define sintaxis de elementos sin indicar
representación gráfica o representación como texto (sintaxis concretas)42
 Construyendo un lenguaje a partir de MOF

MOF es un metamodelo con un conjunto de conceptos simples
pero suficientes para expresar estructura estática de un modelo
 tipos, generalización, atributos, asociaciones, operaciones
 también define interfaces programáticas para manipular modelos

Sobre MOF se puede defnir la sintaxis abstracta de cualquier

lenguaje de modelado
 metamodelo UML es un superconjunto del metamodelo MOF 2.0

Se pueden construir lenguajes para dominios específicos

soportados por herramientas que provee notación del dominio

43

Extensión o restricción mediante perfiles: adaptar
un metamodelo existente a un dominio particular
 mediante estereotipos: extienden el vocabulario de
UML (ejemplo: añadir el estereotipo <<persistent>>
para indicar si una Clase es persistente)
 mediante restricciones: definen cuáles elementos del
metamodelo pueden ir juntos o que condiciones deben
cumplir
 OCL (Object Constraint Language) : indica
precondiciones, invariantes y postcondiciones que deben
cumplir los elementos del sistema

Los perfiles (profiles) de UML permiten definir el

lenguaje de un modelo PSM, el cual debe indicar
elementos de una plataforma específica
 ej: un estereotipo UML puede indicar si una Clase
representa una interfaz CORBA y adicionalmente se
pueden indicar invariantes en OCL
tomado de: “Model Driven Architecture (MDA” 44
Elaborando Modelos

45
 Qué es "elaboración de un modelo"

La elaboración de un modelo se refiere a la posibilidad de
modificar un modelo después de haber sido generado

 por ej. añadir código, editar o hacer refactory del modelo generado
 requiere entender el metamodelo y la función de transformación

Por qué se requiere la elaboración de un modelo?

 para completar la implementación del modelo generado proveniente de

una transformación de un modelo fuente incompleto
 por ej: el modelo fuente solo indica signaturas de métodos, por lo que en
el modelo destino debe completarse su implementación

 para mejorar y sintonizar la interfaz usuario generada

46
 Problema de la regeneración cuando hay
elaboración del modelo destino

Cómo preservar los cambios introducidos por la elaboración
cuando se modifica el modelo fuente y se vuelve a regenerar el
modelo destino?

 una solución es definir áreas protegidas en el modelo fuente para que

la función de transformación preserve la versión del área protegida
asociada en el modelo destino (ej: implementación de un método)

 otra solución es marcar elementos añadidos al modelo destino que no

tienem relación con elementos del modelo fuente, para preservarlos en
caso de regeneración

 una mejor solución es encontrar las diferencias entre el modelo

regenerado y el modelo modificado previo y resolver los conflictos
(solución "diff-and-merge")

47
Problema de la reversibilidad de la transformación

Utilidad de reversar para ir de un modelo destino hacia su
modelo fuente

 en sistemas de legado es importante poder partir de un modelo y

reversarlo para encontrar un modelo más abstracto que ayude a
entender el sistema

 la reversibilidad también permite mover un modelo asociado a una

plataforma hacia otra plataforma, pasando por un modelo abstracto
intermedio

tomado de: “MDA Distilled, Principles of Model Driven Architecture” 48


Cómo asegurar la sincronización bidireccional entre un
modelos fuente y destino (más cuando hay modificaciones en
el modelo destino) ?

 problema: múltiples elementos en el modelo destino están asociados a

un mismo elemento en el modelo fuente

 ejemplo: el tipo de un atributo en el modelo fuente puede derivarse de su

declaración en la clase implementadora en el modelo destino, o también
de la columna de una tabla, o de un descriptor, etc.

 solución: enriquecer con información adicional la función de

transformación para que sea reversible

49
Construyendo modelos Ejecutables

50
 Qué es un modelo ejecutable ?

Es un modelo completo respecto a la funcionalidad deseada en
por lo menos un dominio de problema
 ejemplo: un modelo ejecutable de un banco tiene la funcionalidad
mínima para poder hacer transferencias así no tenga interfaz de usuario
ni seguridad ni persistencia (que serían otros dominios)

Beneficios de trabajar con modelos ejecutables

 Permiten hacer entregas incrementales (y verificación temprana) del
sistema
 en cada incremento se agrega al modelo ejecutable funcionalidad de más
dominios de problemas (mediante funciones de transformación que
mezclan los modelos de varios dominios de problema)
 es la base para definir "proceso MDA ágil"
 el modelo ejecutable es independiente de plataformas por lo cual
facilita la comunicación con el cliente
 para su ejecución requiere transformación ("compilador del modelo
ejecutable) a modelo de plataforma (código)
 permiten integración de sistemas o componentes implantados en
diferentes tecnologías (reversándolos a modelos ejecutables)
51
 UML ejecutable

Es un subconjunto de UML computacionalmente completo

permite definir modelos ejecutables (independientes de plataforma)
• diagrama de máquina de estados para cada Clase
(conjunto de procedimientos)
• las máquinas son concurrentes y se sincronizan por
eventos
c/ procedimiento tiene conjunto de acciones
asociadas (con sintaxis exacta)

tomado de: “MDA Distilled, Principles of Model Driven Architecture” 52