1. MDA
MODEL-DRIVEN ARCHITECTURE
Jefferson Durán Escalante
Ferney Eduardo Cáceres
Guillermo Celis Prada
1

2. Contenido
1. INTRODUCCIÓN
2. MDD
3. MDA
3.1 Historia
3.2 Definición según la OMG
3.3 Importancia del MDA para el desarrollador
3.4 Generalidades
3.5 Modelos MDA
3.6 Tipos de modelos
2

3. 3.7 Desarrollo tradicional vs. Desarrollo con
MDA
3.7.1 Problemas del desarrollo tradicional
3.7.2 Beneficios del MDA
3.7.3 El nuevo proceso de desarrollo
3.8 Implementación
3.9 Mapas de transformación
3.9.1 Definiciones de Transformación
3

4. 3.10 Herramientas MDA
3.10.1 Características
3.10.2 IBM Rational Delivery Platform UML
to Java
4. CONCLUSIONES
5. BIBLIOGRAFIA
4

5. 1. Introducción
5

6. 1. Introducción
Unos de los principios básicos de la ingeniería del software
es la abstracción, para separar lo esencial de lo no
esencial.
En términos del desarrollo de software, lo esencial es la
funcionalidad, y lo no esencial es la plataforma tecnológica.
Estas abstracciones nos las proveen los modelos.
El modelado y la transformación de modelos hasta el nivel
de abstracción requerido, constituye el núcleo del Desarrollo
Dirigido por los Modelos (Model Driven Development
(MDD)).
6

7. 2. Model Driven
Development
7

8. 2. Model Driven Development
 MDD es un estilo de desarrollo de software
donde el artefacto primario son los modelos, a
partir de los cuales se obtiene el código y otros
artefactos.
 Los modelos se usan para pensar en el
dominio del problema y en el dominio de la
solución.
8

9. 2. Model Driven Development
 Además de crear los
modelos, podemos crear
reglas para automatizar la
transformación de los
mismos en otros, este estilo
de MDD es conocido como
Model Driven Architecture
(MDA).
9

10. 2. Model Driven Development
MDD usa los modelos para capturar los
requerimientos, y automatizar parcial o
totalmente la implementación.
Compilamos los modelos para producir
ejecutables, o facilitar el desarrollo manual.
10

11. 2. Model Driven Development
 Con los modelos podemos centrarnos en el
diseño lógico de la aplicación, y liberarnos de los
detalles de la implementación.
 El esfuerzo invertido en el modelado tiene una
continuidad durante el desarrollo, esto modelos
no son meramente parte de la documentación
sino que dirigen de forma automatizada el
desarrollo del código.
11

12. 2. Model Driven Development
12

13. 3. Model Driven
Architecture
13

14. 3.1 Historia
El framework MDA fue establecido en el año 2001 por el OMG como arquitectura para el
desarrollo de aplicaciones.
MDA representa un nuevo paradigma de desarrollo de software en el que los modelos
guían todo el proceso de desarrollo.
Se considera como un nuevo paso en el camino hacia lenguajes de programación más
expresivos y hacia una mayor automatización.
14

15. 3.2 Definición de MDA
Según el OMG, MDA proporciona una solución para los cambios de negocio y de
tecnología, permitiendo construir aplicaciones independientes de la plataforma e
implementarlas en plataformas como CORBA, J2EE o Servicios Web.
15

16. 3.3 Importancia del MDA para el
desarrollador
16

17. 3.3 Importancia del MDA para el
desarrollador
 MDA promueve el uso eficiente de modelos de
sistemas en el proceso de desarrollo de
software.
 Representa para los desarrolladores, una nueva
manera de organizar y administrar arquitecturas
empresariales, basada en la utilización de
herramientas de automatización de etapas en el
ciclo de desarrollo y servicios.
17

18. 3.3 Importancia del MDA para el
desarrollador
 Permite definir los modelos y facilitar
trasformaciones paulatinas entre diferentes
modelos.
 Algunos ejemplos de modelos son: el modelo
de análisis, el de diseño y el de
comportamiento, entre otros. Es decir que, a
partir de uno de ellos, podemos generar otro de
menor abstracción.
18

19. 3.3 Importancia del MDA para el
desarrollador
 Un ejemplo común de generación de modelos,
es la generación de código a partir del modelo de
diseño, mediante el uso de una herramienta de
modelado UML. En este caso usamos una
herramienta para transformar el modelo de
diseño en el “modelo” de código.
19

20. 3.4 Generalidades
¿Qué motivó la creación de MDA?
 La diversidad de plataformas y tecnologías: falta
interoperabilidad entre las diversas estrategias
tecnológicas.
 La acelerada evolución tecnológica: esto ocasiona
que las plataformas muy pronto sean obsoletas.
Surgen, entonces, interrogantes como: ¿Cuál
tecnología va a salir mañana?¿Cuánto va a durar
la última versión de una plataforma?¿Cómo
protejo mi inversión?
20

21. Otras Generalidades
 La aproximación MDA utiliza los estándares abiertos de
modelado establecidos por la OMG’s: Unified Modeling
Language(UML), Meta-Object Facility(MOF), and Common
Warehouse Metamodel(CWM).
 Los PIM pueden ser creados a partir de dichos estándares,
para luego ser transformados sobre plataformas como
CORBA, J2EE, .NET, etc.
21

22. 3.5 Modelos en MDA
Los modelos juegan un rol trascendental en MDA. Como un framework para construir
sistemas, MDA abstrae el sistema a construir en distintas capas de abstracción (layers).
22

23. 3.6 Tipos de Modelos
 CIM (Computation Independent Model).
Modelado del Negocio y requerimientos.
 PIM (Platform Independent Model).
Análisis y diseño independiente de la
plataforma tecnológica.
Un PIM se transforma en uno o más PSM.
23

24. 3.6 Tipos de Modelos
 PSM (Platform Dependent Model).
Diseño dependiente de la plataforma tecnológica.
Cada PSM se transforma en código.
24

25. 3.6 Tipos de Modelos
Code model
El modelo de código representa el código
desplegable (deployable), normalmente en
un lenguaje de programación de alto
nivel, como Java, C#, C++,VB, JSP, etc.
25

26. 3.7 Desarrollo tradicional vs.
Desarrollo con MDA
26

27. 3.7.1 Problemas del desarrollo
tradicional.
•Productividad.
•Portabilidad.
•Interoperatibilidad.
•Mantenimiento y
documentación.
27

28. 3.7.2 Beneficios del MDA
• Una vez implementada la transformación de PIM a PSM, puede
usarse en muchos desarrollos.
Productividad • Aisla problemas específicos de cada plataforma y encaja mucho
mejor con las necesidades de los usuarios finales
• Todo lo definido en un modelo independiente de la plataforma
Portabilidad es totalmente portable.
• Los PSMs generados a partir de un mismo PIM se pueden
Interoperabilidad comunicar a través de “puentes” (relaciones) , por lo cual
pueden pertenecer a diferentes tecnologías.
• El PIM desempeña el papel de la documentación de alto
Mantenimiento y nivel que se necesita para cualquier sistema software
Documentación • Los cambios realizados en el sistema se reflejarán en todos los
niveles, mediante la regeneración de los PSMs y del código.
28

29. Más Beneficios …
 Dinamiza el proceso de integración entre
sistemas “legacy” y sistemas futuros.
 Soporte completo para el ciclo de vida de la
aplicación.
 Escalabilidad y robustez.
 Está predestinado a ser un estándar.
 Interoperatividad entre diferentes tecnologías.
 Permite disminuir costos y mejorar la calidad de
los modelos y procesos.
29

30. 3.7.3 El nuevo proceso de
desarrollo
Análisis:
Desarrollo del PIM con base en las necesidades del negocio y la
funcionalidad requerida.
Diseño:
Transformación del PIM a uno o más PSMs. Implica conocimiento sobre
arquitecturas, plataformas y transformaciones disponibles.
Codificación:
Generación del código. Los programadores únicamente tendrán que
añadir la funcionalidad que no puede reflejarse en los modelos
30

31. Proceso de desarrollo con MDA
31

32. 3.8 Implementación
32

33. 3.9 Mapas de
Transformación
33

34. 3.9 Mapas de Transformación
Mediante mapas, MDA especifica las reglas de transformación de un PIM a un PSM para una
plataforma en concreto.
Mapeo de Metamodelo
34

35. 3.9 Mapas de Transformación
Mapeo por Marcas
Marcado de un modelo
35

36. 3.9 Mapas de Transformación
Mapeo por Patrones
Uso de información adicional y patrones en la transformación
36

37. 3.9.1 Definiciones
de Transformación
Transformaciones de tipos (Model Type Mapping)
Un mapping de tipos especifica un mapping para
transformar cualquier modelo construido con tipos del
PIM a otro modelo expresado con tipos del PSM.
Para cada atributo del PIM con valor “public” en la visibilidad,
transformarlo en el PSM a un atributo con visibilidad “private” y
añadir dos métodos de consulta y actualización (get y set) a la
clase a la que pertenezca.
37

38. Transformaciones de instancias
Identifica elementos específicos del PIM que deben ser
transformados de una manera particular, dada una
plataforma determinada. Esto se puede conseguir
mediante marcas. El desarrollador marca el PIM para
dirigir o controlar la transformación a una plataforma
determinada.
Para la plataforma EJB (Enterprise JavaBeans), podríamos
tener la marca Entity aplicable a clases de un PIM; si está
activa, esta marca indicará que la clase será transformada a un
EJB Entity en el PSM.
38

39. 3.10 Herramientas MDA
 Herramientas de transformación de PIM a PSM
Permiten transformar un PIM de alto nivel en uno o varios PSMs. Pocas
herramientas ofrecen esta funcionalidad.
 Herramientas de transformación de PSM a código
Poseen una definición de transformación integrada que toman un tipo
predefinido de modelo de entrada (PSM) y producen otro tipo predefinido
como salida (modelo de código).
 Herramientas de transformación de PIM a código
Soporta las dos transformaciones anteriores. En ocasiones el usuario
simplemente verá una transformación directa de PIM a código, quedando
implícito el PSM.
39

40.  Herramientas de definición de transformaciones
Permiten crear y modificar transformaciones sobre modelos,
imprescindibles si necesitamos usar transformaciones distintas a las
disponibles en las herramientas.
Otras herramientas
 Editor de código
 Ficheros de código (analizador gramatical y generador de ficheros de
texto)
 Repositorio de modelos
 Editor de modelos
 Verificador de modelos
 Editor de definiciones de transformaciones
 Repositorio de definiciones de transformaciones
40

41. 3.10.1 Características de
las Herramientas MDA
Modelos de datos E/R partiendo del modelo CIM:
Claves primarias y claves externas, multiplicidad de las relaciones.
Generación y modelado de PIM desde modelos E/R:
Soporte para Modelos de clases y diversos lenguajes de modelado.
Generación de PSM:
Elección de la plataforma para la que generar el PSM (EJB/JDO,
.NET, Corba…) y elección de la tecnología de cliente (Struts, JSP,
XMLC, Swing, SWT, …).
41

42. 3.10.1 Características de las
Herramientas MDA
Adaptación del PSM:
Poder introducir código suplementario al generado que permita
completar la aplicación.
Generación de la aplicación:
Generación del esquema de base de datos y del código.
Producción de ficheros de configuración y producción de
documentación.
42

43. 3.10.1 Características de las Herramientas MDA
Algunas herramientas MDA:
 ATL ATLAS Transformation Language
 OptimalJ is a MDA tool for J2EE.
 ArcStyler is a MDA tool for J2EE and .NET.
 UMT UML Model Transformation
 ArgoUML
 Codagen
 Rational Architect
 MDA Transf
 Enterprise Architect
 GReAT
 AndroMDA
 IBM Rational Software Delivery Platform
43

44. 3.10.1 Características de las Herramientas MDA
Símbolos:
• La “√” significa que cumple la característica al 100%.
• El “*” significa que cumple la característica pero indirectamente .
44

45. 3.10.2 IBM Rational Software
Architect
45

46. 3.10.2 IBM Rational
Software Architect
 Rational Software Architect da soporte a UML Versión 2
(UML 2), incluyendo clases y mejoras estructuradas para
los diagramas de máquinas de secuencia, actividad y
estado.
 Éstas y otras revisiones del estándar permiten que los
usuarios expresen su arquitectura con más claridad y
control que nunca.
46

47. 3.10.2 IBM Rational
Software Architect
 El Object Management Group (OMG) ha
llevado esta expresividad al próximo nivel
en la guía de procesos con su iniciativa
Model Driven Architecture (MDA).
47

48. 3.10.2 IBM Rational
Software Architect
 Rational Software Architect da soporte a MDA
permitiendo que el usuario pueda definir múltiples niveles
de modelos junto con las transformaciones definidas por
los usuarios entre esos modelos y el código, dando como
resultado una separación más clara de los asuntos
relacionados con el ciclo de vida.
48

49. 3.10.2 IBM Rational
Software Architect
Nota: Video sobre el uso de la herramienta
http://www.youtube.com/watch?v=N9cPJCiJh7I&feature=player_embedded
49

50. 3.10.2 IBM Rational
Software Architect
50

51. 4. Conclusiones
51

52. 4.Conclusiones
 Actualmente los modelos son costosos de
construir y, una vez construido el modelo, éste
debe ser transformado manualmente en código.
Esta tarea es tediosa, propensa a errores y
repetitiva en muchos casos, por ello MDA
contribuye a disminuir las cargas en estas tareas.
 MDA no ofrece solución a todas las problemáticas
inherentes al desarrollo de software.
52

53. 4.Conclusiones
MDA también es el resultado de reconocer que
la interoperatibilidad es algo bueno y que el
modelado también lo es.
Mediante mapas, MDA especifica las reglas de transformación de un PIM a un
PSM para una plataforma en concreto. Estos mapas incluyen la transformación
MDA Bien utilizado y teniendo en cuenta los
principios de diseño subyacentes, nos puede
ahorrar la escritura y generación de muchas
líneas de código.
53

54. 5. Bibliografía
54

55. 5. Bibliografía
 Corredera de Colsa, Luis Enrique: “Arquitectura dirigida por
modelos para J2ME”. Universidad Pontificia de Salamanca en
Madrid.
 Quintero, Juan Bernardo. Anaya, Raquel: “Mda y el papel de los
modelos en el proceso de desarrollo de software” Revista EIA
(Escuela de Ingeniería de Antioquia) Número 8, p.131-146;
Diciembre 2007.
 López L., Edna D. González G., Moisés : “Proceso de Desarrollo de
Software Mediante Herramientas MDA” Centro Nacional de
Investigación y Desarrollo Tecnológico (CENIDET) , México.
55

56. 5. Bibliografía
 Ramírez Terry, José Luis. Bravo García, Emilio : “Model Driven Architecture”
 Rodríguez Vicente, Jesús: “Ingeniería de Modelos con MDA”. Facultad de
Informática de la Universidad de Murcia.
Recursos electrónicos
 Anacleto, Valerio Adrián. (2006, Octubre 5). “MDA: Reusabilidad Orientada
al Negocio”. Recuperado el 7 de Noviembre de 2009, de:
http://www.epidataconsulting.com/tikiwiki/tiki-read_article.php?articleId=55#
 www.omg.org. (2009, Junio 18). “OMG Model Driven Architecture”.
Recuperado el 7 de Noviembre de 2009, de:
http://www.omg.org/mda/
56

57. 57