Arquitectura dirigida por modelos

Arquitectura Dirigida por Modelos(MDA)

Arquitectura MDA. Producto de las mejores prácticas en Ingeniería de Software surge la Arquitectura dirigida por modelos (MDA – Model Driven Architecture).

¿Qué es MDA?

MDA es un concepto promovido (pero no creado) por la OMG, que propone basar el desarrollo de software en modelos especificados utilizando UML, para que, a partir de esos modelos, se realicen trasformaciones que generen código u otro modelo, con características de una tecnología particular (o con menor nivel de abstracción). MDA define un framework para procesar y relacionar modelos. Suele escucharse que MDA es la evolución natural de UML, ya que tiende a incrementar la cantidad de código generado, a partir de especificaciones detalladas en UML.

¿Qué no es MDA?

Hoy MDA es uno de los tantos acrónimos de moda y, como ocurre algunas veces con las modas, el concepto puede tender a malinterpretarse. Por lo tanto, se debe conocer que:

• MDA no es un proceso de desarrollo.
• MDA no es una especificación.
• MDA no es una implementación.
• MDA no es una implementación de referencia de ningún estándar particular.
• MDA no es un concepto maduro aún.
• MDA no es simplemente generar código.
• MDA no tiene, aún, una visión unificada en la industria.

Modelos 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. Tradicionalmente, el OOAD (Object Oriented Analysis and Design) contiene, entre otros, una vista de análisis, una vista de diseño detallado y código -representando la vista de negocios de un sistema-, la vista de arquitectura y la vista de implementación. MDA agrega una capa de abstracción más, que representa el contexto de negocio del sistema.

Los modelos concretos exceden en número a los modelos abstractos. A medida que avanzamos en las transformaciones, los modelos se vuelven más concretos, transformando al modelo abstracto en uno compatible con una tecnología o plataforma. La situación inversa de llevar el código hacia un modelo concreto -también conocido como ingeniería reversa- rara vez ocurre, excepto cuando el punto de partida es el código mismo. Esto se produce debido a que MDA promueve la fuerte separación entre las responsabilidades de requerimientos del negocio y las responsabilidades tecnológicas. La ventaja de esta “separación de responsabilidades” es que ambos aspectos pueden evolucionar individualmente sin generar dependencias entre sí. De está manera, la lógica de negocio responderá a las necesidades del negocio y no dependerá de vicisitudes técnicas.

CIM (Computational-Independent Model)

CIM debe su nombre a este foco en el negocio por sobre la tecnología, que en español se traduce como: “Modelo Independiente de la Computación”. El CIM se centra en los requerimientos y representa el nivel más alto del modelo de negocios. Usa un lenguaje para modelar procesos de negocios que no es UML, aunque este lenguaje puede ser derivado perfectamente utilizando MOF (meta-object facility). El CIM transciende a los sistemas; cada proceso de negocio interactúa con trabajadores humanos y/o componente de máquina. El CIM describe solamente aquellas interacciones que tienen lugar entre los procesos y las responsabilidades de cada trabajador, sea o no humano. Un objetivo fundamental del CIM, es que cualquiera que pueda entender el negocio y los procesos del mismo puede comprenderlo, ya que éste evita todo tipo de conocimiento especializado o de sistemas.

PIM (Platform-Independent Model)

El PIM, que se traduce al castellano como “Modelo Independiente de la Plataforma”, representa el modelo de procesos de negocio a ser implementado. Comúnmente se usa UML o un derivado de UML para describir el PIM. El PIM modela los procesos y estructuras del sistema, sin hacer ninguna referencia a la plataforma en la (o las) que será desplegada la aplicación. A su vez, ignora los sistemas operativos, los lenguajes de programación, el hardware y la topología de red. Suele ser el punto de entrada de todas las herramientas para MDA e incluso de muchos artículos que hablan de MDA, dejando de lado el CIM.

PSM (Platform-Specific Model)

El PSM, que se traduce al castellano como “Modelo Específico de la Plataforma”, representa la proyección de los PIMs en una plataforma específica. Un PIM puede generar múltiples PSMs, cada uno para una tecnología distinta. Generalmente, los PSMs deben colaborar entre sí para una solución completa y consistente. Normalmente, esto se realiza en UML, creando distintos profiles que definen un PSM para cada tecnología requerida. Los PSMs tienen que lidiar explícitamente con los sistemas operativos, los lenguajes de programación, las plataformas (CORBA, .Net, J2EE, ETC), etc.

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. Idealmente, el modelo de código está listo para compilar y no debería requerir la intervención humana; el despliegue de la aplicación podría ser automatizado. Según los puristas y algunos fanáticos de MDA, en un ambiente MDA maduro no se debería pensar en el código más que como simples archivos, o como un mero objeto intermedio para generar el ejecutable final. Pero debido a que MDA no está maduro, y difícilmente se llegue alguna vez a la utopía de no tener que tocar ningún código, los desarrolladores seguirán necesitando conocer la tecnología para complementar la generación de código, debuguear la aplicación y, sobre todo, lidiar con muchos y variados errores inesperados, extraños y divertidos.

Decisiones de diseño

MDA promueve la transformación de modelos que representan lógicas de negocios complejas (CIM), hasta llegar al código ejecutable y desplegable (Code Model). Pero, ¿qué pasa con las decisiones de diseño, aquellas decisiones que se toman cuando, por ejemplo, se tiene que desarrollar un sistema donde la mayoría de las transacciones sólo leen datos, pero diez de ellas hacen uso intensivo del procesador? ¿Qué pasaría si todos los mapeos se hicieran de igual manera? Se pudiera pensar que esto degradaría la calidad final percibida de la aplicación. Para corregir este problema, MDA promueve el uso de marcas (Marks), las cuales indican aspectos específicos para tener en cuenta en cada transformación. Un PIM generado a partir de un PIM y Marcas se denomina PIM Marcado o Marked PIM. La utilización de las marcas establece que las decisiones respecto a aspectos tecnológicos queden fuera de los modelos principales. Ahora bien, para realizar el mapeo entre un PIM marcado y, por ejemplo, un PSM, es necesario detallar cómo se mapean esas marcas; para eso se definen los Mappers (mapeadores). Puede verse la relación entre los mapeadores, las marcas y los PSM en la figura anterior. Los mapeos se hacen utilizando un QVT: Query, Views, and Transformations.

Ventajas de MDA

La ventaja principal de MDA radica en la clara y estricta separación de responsabilidades. Por un lado, modelar los PIMs, que representan los modelos del negocio, y por otro lado, los PSMs con las preocupaciones tecnológicas. Esto permitirá que ambos modelos puedan evolucionar por separado. De esta manera, si se quisiera, por ejemplo, modificar un aspecto técnico, bastará con modificar el PSM sin que estos tengan impacto en la lógica de negocios. Esta idea viene de un concepto que, en Ingeniería de Software, se llama “Guías de Diseño”. Particularmente, una de esas guías dice que el modelado de la solución debe ser dirigido por el negocio. Esta guía se basa en la afirmación de que un cambio en el negocio seguramente produzca un cambio en el código, pero no lo inverso: los cambios en el código no deberían impactar en el negocio. MDA también permite: lidiar con la complejidad del negocio, modelando a éste por separado y permitiendo su análisis y mejora; disminuir costos, si se cuenta con una herramienta MDA adecuada a nuestras necesidades; mejorar la calidad de nuestros modelos y procesos, mediante su análisis y la separación de responsabilidades.

Estándares involucrados en MDA

Las tecnologías más importantes involucradas, para poder llevar a la práctica los conceptos subyacentes en MDA son:

• Meta Object Facility (MOF).
• Unified Modeling Language (UML).
• XML Model Interchange (XMI).
• Common Warehouse Meta-model (CWM).
• Software Process Engineering Meta-model (SPEM).
• Action Semantics Language (ASL).
• Query-View-Transformation (QVT).
• UML profiles.

Herramientas MDA

Las herramientas MDA deberían proveer la capacidad de transformar modelos de negocios puro (CIMs) en aplicaciones completas, desplegables y capaces de ejecutar con un mínimo de decisiones técnicas. Lamentablemente, nos encontramos muy lejos de que MDA o alguna herramienta MDA provea todas estas facilidades para cualquier negocio y problemática a desarrollar. Tampoco existe un líder en herramientas MDA, debido a que son muy sofisticadas. Algunas de las herramientas más conocidas son:

1. ATL ATLAS Transformation Language
2. OptimalJ is a MDA tool for J2EE.
3. ArcStyler is a MDA tool for J2EE and .NET.
4. UMT UML Model Transformation
5. ArgoUML
6. Codagen
7. Rational Architect
8. MDA Transf
9. Enterprise Architect
10. GReAT
11. AndroMDA

Importancia de MDA para el desarrollador

Actualmente, MDA es importante para el desarrollador promedio. Quienes son bendecidos con la capacidad de utilizar la creatividad para transformar ceros y unos en aplicaciones útiles para nuestros clientes. En los últimos dos años, muchas organizaciones han comenzado a prestar atención a MDA, ya que promueve el uso eficiente de modelos de sistemas en el proceso de desarrollo de software. MDA 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. De esta forma, permite definir los modelos y facilitar trasformaciones paulatinas entre diferentes modelos. Es decir que, a partir de un modelo, se puede generar otro de menor abstracción.

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 se usa una herramienta para transformar el modelo de diseño en el “modelo” de código.

Enlaces Relacionados

• Modelo de desarrollo rápido de aplicaciones
• Ingeniería de Software

Fuentes

• Anacleto V. A. Corredera, L. E. MDA: Reusabilidad Orientada al Negocio 2006.
• Corredera, L. E. Arquitectura dirigida por modelos, 2006.