MDD y MDA: La estructuración de la ingeniería de

software como un modelo de dominios.

Miquely Calvopiña, José Zamora y Sebastián Zúñiga

Ingeniería en Tecnologías de la Información, Universidad de las Fuerzas Armadas – ESPE,

Sangolquí, Rumiñahi, Ecuador.
{mcalvopina,jazamora4,sazuniga}@espe.edu.ec

Abstract. El software es uno de los elementos más importantes en la actualidad

y su desarrollo se ha visto marcado, desde sus orígenes, por una falta de estanda-
rización y por consiguiente varias dificultadas que ellos conlleva, mantenibilidad,
eficiencias, etc. Por ello surgen metodologías que permiten mantener un esquema
estructurado de desarrollo y conservar documentación, dentro de este marco apa-
rece MDD y MDA, en el presente ensayo se incluye un análisis de MDD y MDA
que contiene fases, ejemplos, descripciones y herramientas que permiten obtener
una vista general de desarrollo de software como un modelo de dominios.

Keywords: MDA, MDD, AMDD, Modelo de Dominio, Arqui-

tectura de Dominios.

1 Introducción

A lo largo de la historia de la informática, el desarrollo de programas que permitan el

uso del hardware ha sido imperante, iniciando, con quienes consideran a Ada King
condesa de Lovelace, como la primera programadora de ordenadores, quien en el siglo
XIX, esbozo un método para utilizar la máquina analítica, del célebre matemático Char-
les Babbage, con el fin de ejemplificar los números de Bernoulli, utilizando solo tarjetas
perforadas (Charman-Anderson, 2015), hasta nuestro días con dispositivos que rozan
en la ciencia ficción y aplicaciones y programas que aprovechan de la mejor manera
posible las bondades del hardware.
Sin embargo, a pesar del avance exponencial de los dispositivos, como computado-
res, dispositivos inteligentes y elementos relacionados a la industrialización y al IoT, el
software que se desarrolla para dichos dispositivos crece sin el uso de estándares defi-
nidos. En muchos casos se observa el desarrollo ineficiente de software, se realiza sin
tomar en cuenta estándares, metodologías o documentación adecuada.
Cuando se habla de desarrollo de software a nivel de ingeniería, se piensa, equivo-
cadamente, que basta con el proceso de generar código y desprenderse de el en forma
de proyectos o programas para la venta o para su publicación en forma de software de
acceso libre (open source). Esta idea es completamente errada cuando se compara con
los diferentes procesos en todos los demás campos de la ingeniería. Es incongruente
pensar en el exponencial avance de los diferentes campos de la ingeniería, sin modelos,

adfa, p. 1, 2011.
© Springer-Verlag Berlin Heidelberg 2011
sin metodologías y sin planos estructurales de lo que se quiere construir, o en este caso
desarrollar.
Debido a esta falta de desarrollo, surgen los diferentes diseños o modelos sobre los
cuales se recomienda el desarrollo del software, algunos tradicionales otros agiles, cada
uno orientado a un diferente tipo de proyecto y pensadas en momentos diferentes de la
historia de la informática y la computación. Considerando esto, en el presente ensayo
se presenta el Modelo Impulsado por Modelos o MDD por su siglas en Ingles, y de la
Arquitectura Dirigida por Modelos o MDA por su siglas en Ingles, como un subcon-
junto de MDD que permite el desarrollo de software, adecuado y con la capacidad de
mantenibilidad y un desarrollo ágil, además se realizará un breve análisis de los con-
ceptos de dichos temas a tratar y además un análisis en la línea argumentativa de su uso
en la ingeniería de software.

2 Desarrollo

2.1 MDD
Este modelo tiene sus orígenes desde que las personas comenzaron a programar en las
computadoras, a partir de esto los ingenieros de software constantemente han seguido
trabajando para poder obtener un mejor nivel de abstracción por lo cual este modelo
fue uno de los resultados del trabajo de las investigaciones realizadas, el primer com-
pilador FORTRAN fue un hecho importante en la informática ya que con esto por
primera vez se permitió que los programadores pueden especificar a la computadora lo
que debe de hacer en vez de como debe de hacerlo.
El Modelo Impulsado Por Modelos (MDD) se considera como una continuación natural
de esta tendencia ya que en lugar de exigir a los desarrolladores a usar un lenguaje de
programación que especifique como un sistema es implementado, este permite usar
modelos para especificar que funcionalidad del sistema es necesaria y que arquitectura
se va a utilizar.
Esto permite resolver problemas comunes de los problemas considerados como difíci-
les para los estándares actuales como: la asignación de objetos, la búsqueda de métodos,
el control de excepciones, etc. El objetivo de MDD es lograr el mismo grado de auto-
matización para las cuestiones que hoy en día son muy complejas cuando se las quiero
resolver manualmente como lo es la persistencia de un sistema, la interoperabilidad, la
distribución, etc.

Características.
• Es una metodología de desarrollo que se enfoca en el desarrollo de modelos
y simplifica los sistemas deseados permitiendo a los usuarios comprender de
una manera más sencilla los sistemas y facilita el trabajo a los desarrolladores.
• Se puede dividir simplemente en negocios, procesos, dominio, datos y fabri-
cación de información del sistema.
 • Utilizan lenguajes con lo cual los usuarios y técnicos de TI pueden comuni-
carse con respecto a los diferentes sistemas, los lenguajes de modelado bási-
cos utilizados son UML (Lenguaje Unificado de Modelado), SQL (Lenguaje
de consulta estructurado), BPMN (Modelo y notación de procesos de nego-
cio), DSL (Lenguaje especifico de dominio).
• El desarrollo de software se define como modelos que no dependen de la pla-
taforma de desarrollo y se subdividen en arquitecturas de software.
• Está compuesto de modelos abstractos y tecnología de conversión entre mo-
delos, esta característica abstracta permite simplificar y estandarizar los siste-
mas y automatizar la creación de código fuente, la creación de documentos y
las pruebas.
• Divide la tecnología de TI y la cantidad de trabajo a través de modelos sim-
plificados y permite una mejor comunicación entre expertos en dominios y
técnicos de TI al momento de desarrollar software.

Requerimientos.
La principal motivación para el desarrollo dirigido por modelos es mejorar la producti-
vidad, para poder aumentar los rendimientos que una determinada institución se deriva
a través de la dedicación de la misma para desarrollar software. A través de dos mane-
ras:
1. Mediante la mejora de la productividad a corto plazo de desarrolladores, al
aumentar el valor de los principales artefactos de software en términos de
cantidad funcional que se ofrece.
2. Mediante la mejora de la productividad a largo plazo de desarrolladores, me-
diante la disminución de la velocidad a la que los artefactos de software se
vuelven inservibles.
El Modelo Impulsado Por Modelos debe definir:
1. Los conceptos que están disponibles para la creación de modelos y las reglas
que rigen su uso.
2. La notación que se utilizara en la representación de los respectivos modelos.
3. Como se relacionan los elementos de un modelo.
4. Conceptos para facilitar las extensiones de usuarios dinámicas haciendo refe-
rencia al enunciado 1 y 2, y modelos creados a partir de ellos.
5. Conceptos para facilitar el intercambio haciendo referencia al enunciado 1 y
2, y modelos creados a partir de ellos.
6. Conceptos para facilitar las asignaciones referenciadas por el usuario de mo-
delos a otros artefactos.

Herramientas.
Algunas empresas o instituciones utilizan BridgePoint como herramienta MDD. Pero
el problema es que para crear un modelo usando BridgePoint, se necesita mucho tiempo
para aprender el lenguaje de acción que se requiere para definir las acciones de estado.
Entonces para poder resolver este problema se desarrolló un lenguaje de Modelado Es-
pecifico del Dominio (DSM) para modelar la educación utilizando la plataforma social
DSL.
Esta plataforma lo que permite es realizar diagramas de clases y diagramas de máquinas
de estado. Un diagrama de clase consta de clases y relaciones, mientras que los diagra-
mas de máquina de estado consisten en estados, eventos y acciones. Para recopilar el
historial de cambios del modelo, se crea un repositorio de modelos. Al almacenar mo-
delos en su repositorio existe la posibilidad que las personas que utilizan la aplicación
pueden ver las versiones anteriores de los modelos que han sido modificados. El repo-
sitorio de modelos es una función adicional de la herramienta MDD.

Fig. 1. Plataforma social DSL (Rikard, 2016)

Infraestructura tradicional .

Fig. 2. Infraestructura de Modelado Tradicional (Atkinson & Kuhne, 2003)

M0: Contiene los datos de usuario, los cuales consisten en datos reales que el soft-
ware está diseñado para manipular. Aquí se ejecuta el sistema que se ha creado a par-
tir de su ejecución. Se utiliza: Objeto UML e instancias de Java
M1: Contiene un modelo de los datos del usuario de la capa M0, en este nivel se en-
cuentran los modelos de usuario. Aquí se realiza una definición del modelo de la apli-
cación. Se utiliza: Modelo UML y modelo de clases en Java.
M2: Contiene un modelo de la información del nivel M1, se lo conoce como un meta-
modelo. Aquí se encuentra los elementos del lenguaje del modelado. Se utiliza: UML
y Java
M3: Contiene un modelo de la información del nivel M2, se caracteriza a menudo
como el meta-metamodelo, también está definido como un metalenguaje MOF (Meta
Objeto de Instalación).

2.2 MDA
A medida que la tecnología avanza, así también lo hacen los estándares para la in-
terconexión. La Arquitectura Dirigida por Modelos (MDA) es una propuesta promo-
vida por el Grupo de Gestión de Objetos (OMG) como una forma de unificar lo cons-
truido con lo que se va a construir y que es capaz de manejar esta evolución basándose
en modelos específicos implementando UML a partir de los cuales se genere código.
Su desarrollo se basa prácticamente en tres fases, la primera es el desarrollo de un
modelo independiente de la plataforma (PIM) y a partir de la cual se realiza la transfor-
mación a varios modelos específicos de plataforma (PSM) en la segunda fase haciendo
uso de alguna tecnología que permita su implementación. Como última fase, se realiza
la obtención de código de cada PSM, todos estos pasos se realizan con la ayuda de
herramientas de transformación para evitar cualquier proceso manual.
En la figura 1 podemos ver que el MOF (Meta Objeto de Instalación) se constituye
como el lenguaje predeterminado por un estándar en la capa M3 y cuyo objetivo es
lograr la adición de nuevos lenguajes de modelación, también se puede observar el in-
tercambio de metadatos XML (XMI) para posibilitar un intercambio entre modelos.

Fig. 3. Esquema de la Arquitectura Dirigida por Modelos (Loor, 2014)

Características.
• Promueve la importancia de tener modelos específicos que al unificarse pro-
pongan una solución.
• Sus pilares son la abstracción, la automatización y el uso de estándares ade-
cuados para la interconexión.
• Su arquitectura tiene como objetivo obtener un producto final con una óptima
productividad e interoperabilidad y que sea portable.
• Trata de promover la implementación de MDD de una manera correcta a tra-
vés de la preparación previa de una estructura tecnológica y conceptual.
• Los requerimientos son levantados haciendo uso de modelos UML que hacen
que sean más fácil de interpretar.
• Permiten disminuir la complejidad de desarrollo de software.

Principios de MDA.
Según (Loor, 2014) el modelo MDA se rige por cuatro principios, los cuales son:
1. La notación es fundamental al momento de entender los sistemas, debido a
que son de gran tamaño.
2. Los sistemas se construyen en torno a varios modelos organizados en las dife-
rentes capas y con sus respectivas transformaciones.
3. Al tener diferentes modelos, es necesario contar con documentación que los
describa para que así sea más fácil la integración entre ellos.
4. El uso de estándares es necesario y cumplir todas las normas que la OMG
propone para que sea entendible para los clientes.

Desafíos del MDA.

Fig. 4. Desafíos de la Arquitectura Manejada por Modelos (Noureen, Amjad, & Azam, 2016)

El desarrollo de software se encuentra con diferentes desafíos a medida que la tecnolo-

gía avanza y las expectativas de un cliente crecen, es por ello que el MDA se encuentra
con diferentes desafíos.
En cuanto al tiempo, el MDA se propuso como una arquitectura de software rentable,
por lo que reduce costos, pero con el uso de herramientas varias para la transformación
de modelos aún sigue siendo un aspecto débil de esta arquitectura. Y como se debía
esperar, debido a los diferentes modelos existentes al momento de crear relaciones entre
estos, la consistencia de datos es un reto.

2.3 AMDD
En las subsecciones anteriores se hablo de MDD y MDA como elementos innova-
dores dentro del desarrollo del software, y en verdad, el MDD como un marco sobre el
cual basar un estándar específico como el MDA, ambos explicados con la mayor clari-
dad posible. Sin embargo, con el pasar de los años, se han presentado una serie de
modelos que permiten agilizar el proceso del desarrollo de software, estos son conoci-
dos como metodologías ágiles, existen muchas de ellas, y es la misma generalización
que con MDD y MDA, MDD es el marco o paradigma y MDA es la visión o imple-
mentación de un estándar por parte de una organización («Clarifying concepts», s. f.).
De igual forma AMDD es un marco o paradigma que se basa en los dos anterior-
mente mencionados, Ágil y MDD, para crear un paradigma que permita aprovechar la
consistencia y fiabilidad de MDD con la rapidez de desarrollo que proponen las meto-
dologías ágiles (Matinnejad, 2011).
Según (Matinnejad, 2011), AMDD supone una seria contradicción entre sus compo-
nentes, MDD implica una extensa documentación lo que permite una mayor confianza
a la hora de desarrollar y mantener el productos, por otro lado las metodologías ágiles
parecen tenerle una especie de fobia a la documentación, al punto que algunas de ellas
sacrifican esto en post de un desarrollo más rápido. Unificar las dos posturas que com-
ponen AMDD es descrito en (Ambler, 2007), como un modelo de “son los suficiente-
mente buenos”, documentos que satisfaces una tarea específica, de este modo se incor-
poran en AMDD la rapidez de ágil y la confianza de MDD.
MDD no es un estándar como tal, a diferencia de MDA, es el mismo caso de AMDD,
esta representa únicamente al compromiso o a la forma en que los estándares deberían
estar construidos, dentro de AMDD desde el año 2004 (Matinnejad, 2011) se han ge-
nerado varios procesos basados en AMDD, para no alargar el presente ensayo se in-
cluirá uno de ellos, que a juicio de los autores del presente, es uno de los más signifi-
cativos.

AMDD High-Level Life Cycle

El AMDD HLLC es de los primeros estándares que se tiene conocimiento, basados
en AMDD, el modelo es apenas considerado una metodología, sin embargo, es sufi-
ciente para poder iniciar el proceso del desarrollo de software.
 Fig. 5. AMDD HLLC tomado de (Matinnejad, 2011) como aparece en (Ambler, 2007)

3 Conclusiones

En este corto ensayo se han descrito dos importantes partes del desarrollo de soft-
ware, MDD y MDA, ambos elementos relacionados entre sí, además se ha incluido un
elemento extra el AMDD como una metodología que incluye al paradigma ágil a la
hora de desarrollar software.
MDD permite centrar los esfuerzos de los desarrolladores en resolver los problemas
que actualmente plagan el desarrollo de software, persistencia de un sistema, la inter-
operabilidad, la distribución, etc. Considerando estas ideas MDD se caracteriza princi-
palmente por la simplificación de los problemas considerados difíciles, además de rea-
lizar una documentación intensiva de cada fase, por ello MDD permite tener confianza
en el desarrollo de los programas desarrollados.
A diferencia de MDD, MDA comparte las características antes mencionadas con la
diferencia que MDA es una especialización de MDD, pues pertenece a una organiza-
ción.
Su desarrollo se basa prácticamente en tres fases, la primera es el desarrollo de un
modelo independiente de la plataforma (PIM) y a partir de la cual se realiza la transfor-
mación a varios modelos específicos de plataforma (PSM) en la segunda fase haciendo
uso de alguna tecnología que permita su implementación. Como última fase, se realiza
la obtención de código de cada PSM, todos estos pasos se realizan con la ayuda de
herramientas de transformación para evitar cualquier proceso manual.
Finalmente se ha propuesto una metodología mucho más actual y basada principal-
mente en el paradigma ágil, esta supera uno de los problemas principales de MDD que
es el tiempo que toma realizar el desarrollo de software, pues incorpora la necesidad de
las metodologías ágiles de desprenderse de la documentación, sin embargo se realiza
una documentación denominada por un autor como “justo lo necesario”, de este modo
cada tarea lleva su documentación, pero esta documentación no representa una perdida
de tiempo, esto es especialmente útil a la hora de desarrollar proyectos pequeños.
4 Referencias
1. Ambler, S. W. (2007). Agile Model Driven Development (AMDD): The Key to Scaling
Agile Software Development. Recuperado 14 de octubre de 2019, de Agile Modeling web-
site: http://www.agilemodeling.com/essays/amdd.htm
2. Atkinson, C., & Kuhne, T. (2003). Model-driven development: A metamodeling foundation.
IEEE Software, 20(5), 36-41. https://doi.org/10.1109/MS.2003.1231149
3. Selic, B. (2013). The Pragmatics of Model-Driven Development. 20-22.
4. Charman-Anderson, S. (2015). Ada lovelace: Victorian computing visionary. 36, 35-41.
5. Clarifying concepts: MBE vs MDE vs MDD vs MDA. (s. f.). Recuperado 14 de octubre de
2019, de Modeling Languages website: https://modeling-languages.com/clarifying-con-
cepts-mbe-vs-mde-vs-mdd-vs-mda/
6. Loor, L. V. (2014). Arquitectura Manejada por Modelos. Revista San Gregorio, 2(Junio-
Diciembre), 64-73.
7. Matinnejad, R. (2011). Agile Model Driven Development: An Intelligent Compromise. 2011
Ninth International Conference on Software Engineering Research, Management and Ap-
plications, 197-202. https://doi.org/10.1109/SERA.2011.17
8. Noureen, A., Amjad, A., & Azam, F. (2016). Model Driven Architecture—Issues, Chal-
lenges and Future Directions. Journal of Software, 11(9), 924-933.
https://doi.org/10.17706/jsw.11.9.924-933