Arquitectura basada en modelos

El modelo MDA está relacionado con múltiples estándares, incluyendo el Lenguaje Unificado de Modelado (UML), la Instalación de Metaobjetos (MOF), el Intercambio de Metadatos XML (XMI), la Computación de Objetos Distribuidos Empresariales (EDOC), el Metamodelo de Ingeniería de Procesos de Software (SPEM) y el Metamodelo de Almacén Común (CWM). Cabe destacar que el término "arquitectura" en la Arquitectura Dirigida por Modelos no se refiere a la arquitectura del sistema que se está modelando, sino a la arquitectura de los diversos estándares y formatos de modelo que sirven como base tecnológica para MDA.

El perfil UML ejecutable era el que se utilizaba cuando nació MDA. Ahora, la OMG promueve fUML en su lugar. (El lenguaje de acciones para fUML es ALF).

El Object Management Group posee marcas registradas para el término Model Driven Architecture y su acrónimo MDA, así como marcas registradas para términos como: Model Based Application Development, Model Driven Application Development, Model Based Application Development, Model Based Programming, Model Driven Systems y otros. ^{[ 3 ]}

OMG centra la Arquitectura Dirigida por Modelos® en la ingeniería directa, es decir, la producción de código a partir de diagramas de modelado abstractos elaborados por humanos (por ejemplo, diagramas de clases) . El grupo ADTF (Grupo de Trabajo de Análisis y Diseño) de OMG lidera este esfuerzo. Con cierto humor, el grupo eligió ADM (MDA al revés) para nombrar el estudio de la ingeniería inversa. ADM se decodifica como Modernización Dirigida por la Arquitectura. El objetivo de ADM es producir estándares para la ingeniería inversa basada en modelos de sistemas heredados. ^{[ 4 ]} El Metamodelo de Descubrimiento de Conocimiento (KDM) es el más avanzado de estos esfuerzos y describe los sistemas de información en términos de varios activos (programas, especificaciones, datos, archivos de prueba, esquemas de bases de datos, etc.).

Dado que los conceptos y las tecnologías utilizados para realizar diseños y arquitecturas han evolucionado a ritmos distintos, su separación permite a los desarrolladores de sistemas elegir las mejores y más adecuadas en ambos ámbitos. El diseño aborda los requisitos funcionales ( casos de uso ), mientras que la arquitectura proporciona la infraestructura a través de la cual se materializan los requisitos no funcionales, como la escalabilidad, la fiabilidad y el rendimiento. MDA prevé que el modelo independiente de la plataforma (PIM), que representa un diseño conceptual que materializa los requisitos funcionales, perdurará a pesar de los cambios en las tecnologías de implementación y las arquitecturas de software .

De particular importancia para la arquitectura dirigida por modelos es la noción de transformación de modelos . OMG ha definido un lenguaje estándar específico para la transformación de modelos llamado QVT .

La organización OMG proporciona especificaciones generales en lugar de implementaciones, a menudo como respuesta a solicitudes de propuestas (RFP). OMG documenta todo el proceso en un documento llamado Guía MDA.

Básicamente, una herramienta MDA es una herramienta utilizada para desarrollar, interpretar, comparar, alinear, medir, verificar, transformar, etc., modelos o metamodelos. ^{[ 5 ]} En la siguiente sección, "modelo" se interpreta como cualquier tipo de modelo (por ejemplo, un modelo UML) o metamodelo (por ejemplo, el metamodelo CWM). En cualquier enfoque MDA tenemos esencialmente dos tipos de modelos: los modelos iniciales son creados manualmente por agentes humanos, mientras que los modelos derivados son creados automáticamente por programas. Por ejemplo, un analista puede crear un modelo inicial UML a partir de su observación de alguna situación empresarial general, mientras que un modelo Java puede derivarse automáticamente de este modelo UML mediante una operación de transformación de modelos .

Una herramienta MDA puede ser una herramienta utilizada para comprobar si los modelos están completos, si presentan inconsistencias o si contienen errores o advertencias.

Algunas herramientas realizan más de una de las funciones mencionadas anteriormente. Por ejemplo, algunas herramientas de creación también pueden tener capacidades de transformación y prueba. Existen otras herramientas dedicadas exclusivamente a la creación, a la presentación gráfica, a la transformación, etc.

Las implementaciones de las especificaciones OMG provienen de empresas privadas o grupos de código abierto . Una fuente importante de implementaciones para las especificaciones OMG es la Fundación Eclipse (EF). Muchas implementaciones de los estándares de modelado OMG se pueden encontrar en el Eclipse Modeling Framework (EMF) o el Graphical Modeling Framework (GMF). La Fundación Eclipse también está desarrollando otras herramientas de diversos perfiles, como GMT. El cumplimiento de Eclipse con las especificaciones OMG a menudo no es estricto. Esto se aplica, por ejemplo, al estándar EMOF de OMG, que EMF aproxima con su implementación Ecore. Se pueden encontrar más ejemplos en el proyecto M2M, que implementa el estándar QVT, o en el proyecto M2T, que implementa el estándar MOF2Text.

Es importante no confundir la Lista de Herramientas MDA con la Lista de Herramientas UML , ya que la primera es mucho más amplia. Esta distinción se puede generalizar diferenciando entre «herramientas de metamodelo variable» y «herramientas de metamodelo fijo». Una herramienta UML CASE suele ser una «herramienta de metamodelo fijo», puesto que está diseñada para funcionar únicamente con una versión específica del metamodelo UML (por ejemplo, UML 2.1). Por el contrario, otras herramientas cuentan con capacidades genéricas internas que les permiten adaptarse a metamodelos arbitrarios o a un tipo particular de metamodelo.

Por lo general, las herramientas MDA se centran en la especificación rudimentaria de la arquitectura, aunque en algunos casos las herramientas son independientes de la arquitectura (o de la plataforma).

Algunos ejemplos sencillos de especificaciones de arquitectura son:

• Seleccionar una de las arquitecturas de referencia compatibles, como Java EE o Microsoft .NET ,
• Especificar la arquitectura a un nivel más detallado, incluyendo la elección de la tecnología de la capa de presentación, la tecnología de la capa de lógica de negocio, la tecnología de persistencia y la tecnología de mapeo de persistencia (por ejemplo, el mapeador objeto-relacional).
• Metadatos: información sobre los datos.

Algunos conceptos clave que sustentan el enfoque MDA (lanzado en 2001) fueron dilucidados por primera vez por el método Shlaer-Mellor a finales de la década de 1980. De hecho, un estándar técnico clave ausente en el enfoque MDA (la sintaxis de un lenguaje de acción para UML ejecutable ) ha sido superado por algunos proveedores mediante la adaptación del lenguaje de acción Shlaer-Mellor original (modificado para UML) . Sin embargo, durante este período, el enfoque MDA no ha logrado una aceptación generalizada en la industria; el Grupo Gartner aún identifica a MDA como una tecnología "en ascenso" en su " Ciclo de Hype " de 2006, ^{[ 6 ]} y Forrester Research declaró que MDA estaba "muerto al llegar" en 2006. ^{[ 7 ]} Las posibles preocupaciones que se han planteado con el enfoque MDA de OMG incluyen:

• Estándares incompletos: El enfoque MDA se basa en una variedad de estándares técnicos, algunos de los cuales aún no se han especificado (por ejemplo, un lenguaje semántico de acciones para xtUML ) o aún no se han implementado de manera estándar (por ejemplo, un motor de transformación QVT o un PIM con un entorno de ejecución virtual). ^{[ 8 ] [ 9 ]}
• Dependencia del proveedor: Si bien MDA se concibió como un enfoque para lograr la independencia de la plataforma (técnica), los proveedores actuales de MDA se han mostrado reacios a diseñar sus herramientas para que sean interoperables. Esta situación podría generar dependencia del proveedor para quienes adopten un enfoque MDA.
• Idealista: MDA se concibe como un enfoque de ingeniería directa en el que los modelos que incorporan programación en lenguaje de acción se transforman en artefactos de implementación (p. ej., código ejecutable, esquema de base de datos) en una dirección mediante un paso de "generación" total o parcialmente automatizado. Esto se alinea con la visión de OMG de que MDA debería permitir modelar la complejidad total de un dominio de problemas en UML (y estándares relacionados) con la posterior transformación a una aplicación completa (ejecutable). ^{[ 10 ]} Sin embargo, este enfoque implica que no se admiten cambios en los artefactos de implementación (p. ej., ajuste del esquema de base de datos). Esto constituye un problema en situaciones donde se considera necesaria dicha "adaptación" de los artefactos de implementación posterior a la transformación. La evidencia de que el enfoque MDA completo puede ser demasiado idealista para algunas implementaciones del mundo real se ha visto en el auge del llamado "MDA pragmático". ^{[ 11 ]} El MDA pragmático combina los estándares literales del MDA de OMG con enfoques más tradicionales basados ​​en modelos, como la ingeniería de ida y vuelta, que proporciona soporte para adaptar los artefactos de implementación (aunque no sin desventajas sustanciales).
• Habilidades especializadas: Los profesionales de la ingeniería de software basada en MDA (al igual que con otros conjuntos de herramientas) deben poseer un alto nivel de experiencia en su campo. Actualmente, los expertos en MDA (a menudo denominados modeladores/arquitectos) son escasos en comparación con la disponibilidad de desarrolladores tradicionales. ^{[ 12 ]}
• Historial de OMG: El consorcio OMG, que patrocina el enfoque MDA (y posee la marca registrada MDA), también introdujo y patrocinó el estándar CORBA, que no llegó a materializarse como un estándar ampliamente utilizado. ^{[ 13 ]}
• Propuesta de Valor Incierta (PVU): Como se mencionó, la visión de MDA permite especificar un sistema como un modelo abstracto, que puede materializarse como una implementación concreta (programa) para una plataforma informática específica (por ejemplo, .NET). Por lo tanto, una aplicación desarrollada con éxito mediante un enfoque MDA puro podría, en teoría, portarse a una versión más reciente de la plataforma .NET (o incluso a una plataforma Java) de forma determinista , aunque persisten importantes interrogantes sobre las implicaciones prácticas durante la migración (como la implementación de la interfaz de usuario). Si esta capacidad representa una propuesta de valor significativa es una cuestión que debe resolverse para cada usuario. En cualquier caso, quienes adopten MDA y busquen valor a través de una "alternativa a la programación" deben ser muy cautelosos al evaluar este enfoque. La complejidad de cualquier dominio problemático siempre persistirá, y la programación de la lógica de negocio debe realizarse en MDA, al igual que con cualquier otro enfoque. La diferencia con MDA radica en que el lenguaje de programación utilizado (por ejemplo, xtUML) es más abstracto (que, por ejemplo, Java o C#) y se integra con los artefactos UML tradicionales (por ejemplo, diagramas de clases). La cuestión de si programar en un lenguaje más abstracto que los lenguajes 3GL convencionales dará como resultado sistemas de mejor calidad, a menor coste o con una entrega más rápida, es algo que aún no se ha respondido adecuadamente.
• MDA fue reconocida como una posible forma de integrar diversas soluciones estandarizadas desarrolladas de forma independiente. Para la comunidad de simulación, se recomendó como una alternativa empresarial e industrial a otro estándar impuesto por el Departamento de Defensa de EE. UU. ^{[ 14 ]}