MDA: Arquitectura Dirigida por Modelos
1
María Consuelo Franky
lfranky@javeriana.edu.co
Dpto. Ingeniería de Sistemas Universidad Javeriana
Bogotá - 2010
Temario
•
Objetivos de MDA (Model Driven Architecture)
•
Términos y Conceptos base MDA
•
Construyendo Modelos
•
Construyendo Meta-modelos
•
Construyendo Transformaciones
•
Construyendo modelos de Marcas
2
•
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)”,
Objetivos de MDA
(Model Driven Architecture)
3 3
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™)
MDA es el estándar OMG que busca resolver los
problemas de integración de sistemas
4
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
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
5
Tres objetivos de MDA: portabilidad, interoperabilidad, y
reutilización
MDA es dirigido por modelos (model-driven)
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
MDA busca mayor abstracción, reutilización e
integración en el desarrollo de sistemas
6
Es más fácil resolver la interoperabilidad de sistemas a un
nivel de diseño y no de implementación
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
7
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)
Términos y Conceptos de MDA
8 8
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
Conceptos básicos de MDA
9
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
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
Metamodelos y plataformas
10
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:
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
Mapping: Transformación entre modelos
11
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”
Construyendo Modelos
12 12
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
Características de un buen Modelo
13
realidad modelada
Un buen modelo sirve como medio de comunicación entre
Un modelador típicamente combina las acciones de
clasificación, abstracción y generalización
Abstracción, Clasificación y Generalización
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
15
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
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
Modelos para diferentes temas de un mismo sistema
16
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
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:
17
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
Modelos y plataformas
18
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:
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
19
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)
tomado de: “Model Driven Architecture (MDA”
Modelo CIM: es modelo del dominio que no muestra estructura del sistema
Construyendo Metamodelos
20 20
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
Qué es un metamodelo y para qué sirve?
21
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
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)
Ejemplo de un metamodelo
22
Un metamodelo constituye un mayor grado de
abstracción respecto a los modelos de un sistema
23
tomado de: “MDA Distilled, Principles of Model Driven Architecture”
Los elementos de un modelo son instancias de los
conceptos del metamodelo
24
Arquitectura MDA de 4 niveles
M0: datos de la aplicación
M1: modelo(s) de la
aplicación
ej: modelo de clases UML modelo de
clases
modelo de objetos
25
tomado de: “MDA Distilled, Principles of Model Driven Architecture”
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 de intercambio
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
Construyendo Transformaciones
27 27
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
Qué es una transformación entre modelos
28
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
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
Ejemplo informal de transformación
29
- 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.
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
30
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.
Esquema general de transformaciones entre modelos
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
32
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 .
Cómo se refinan típicamente los modelos:
33
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
Alternativas para expresar una
función de transformación
34
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
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
Escenarios de transformación de modelos
35
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.)
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
36
destino
tomado de: “MDA Distilled, Principles of Model Driven Architecture”
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:
Enumeraciones en una función de transformación
37
La asociación se expresa en elementos de cada metamodelo
ej: cada Atrribute (metamodelo de UML) es transformado en un
Construyendo modelos de Marcas
38 38
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
Qué son las marcas y su modelo
39
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
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
Marcas comunes
40
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
Construyendo lenguajes de modelado
41 41
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
Por qué construir un lenguaje de modelado
42
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
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
Construyendo un lenguaje a partir de MOF
43
metamodelo UML es un superconjunto del metamodelo MOF 2.0
Se pueden construir lenguajes para dominios específicos
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
44
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
Elaborando Modelos
45 45
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?
Qué es "elaboración de un modelo"
46
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
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)
Problema de la regeneración cuando hay
elaboración del modelo destino
47
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")
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
Problema de la reversibilidad de la transformación
48
plataforma hacia otra plataforma, pasando por un modelo abstracto intermedio
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
49
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
Construyendo modelos Ejecutables
50 50
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
Qué es un modelo ejecutable ?
51
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
Es un subconjunto de UML computacionalmente completo
permite definir modelos ejecutables
(independientes de plataforma)UML ejecutable
• 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)
52
