MDA | SG Buzz

Published 16 years ago (updated 12 years ago)

Este artículo fue originalmente publicado en la base de conocimiento de Epidata Consulting (www.epidataconsulting.com) y se publica en SG con el consentimiento del autor.

En los últimos 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 nosotros, 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. 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.

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.

¿Qué es MDA?
MDA es el acrónimo de Model Driven Architecture (Arquitectura Dirigida por Modelos), 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, enumeremos rápidamente que no es MDA.

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 (layers). 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. En la figura 1 se muestran las diferentes capas de abstracción (layers). El gráfico se hace más abstracto hacia la izquierda y se vuelve más concreto hacia la derecha.

Figura 1: Un ejemplo de modelo MDA y sus relaciones.

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 en 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)
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. CMI 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”

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étera.

Figura 2: Los PIMs se transforman en PSMs

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 deberíamos 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 seguiremos 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
Hemos visto cómo, de manera automática y paulatina, 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 tomamos cuando, por ejemplo, tenemos 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? Nos es dado a pensar que esto degradaría la calidad final percibida de la aplicación. Para corregir este problema, MDA promueve el uso de Marks (marcas), 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.

Figura 3: Utilización de marcas y mapeos

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 3. 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, modelaremos los PIMs, que representan los modelos de nuestro 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 quisiéramos, 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 con:

¿Cómo evaluar una herramienta MDA? Con el advenimiento de las palabras de moda (buzzwords), utilizadas en exceso y en muchos casos de manera inapropiada, llegan a la puerta de nuestros gerentes los vendedores de sueños y espejitos de colores comentando que, con la nueva herramienta MDA, podremos resolver todos nuestros problemas haciendo clic en el botón derecho del mouse. Como todo el mundo sabe, ese tipo de expectativas suele ser exagerada. En mi opinión personal, la forma de probar una herramienta es usarla para resolver nuestra problemática y, si hay vendedores involucrados, pedirles gentilmente que nos ayuden a resolver la problemática de nuestro negocio con un caso “testigo” elegido por nosotros. Si la herramienta realmente funciona, podrá resolverse el caso testigo y nosotros seremos unos clientes felices.

Más allá del caso práctico sugerido, debemos tener en cuenta varios factores al momento de la evaluación. Estos factores tienen que ver con: El mantenimiento de la aplicación: ¿Cuánto me va a costar agregar o mantener código una vez que haya pasado por el proceso de generación? Impacto del cambio: ¿Cómo se administra un cambio en el proceso de negocio? ¿Qué costo tiene? Manejo de excepciones: ¿Cómo se administran los casos excepcionales, como por ejemplo las transacciones que hacen uso intensivo del procesador? Curva de aprendizaje: ¿Cuál es la curva de aprendizaje? ¿Tengo que aprender todo un nuevo meta-lenguaje? ¿Basta con el uso intuitivo de herramientas “visuales”? Madurez: ¿Qué tan madura es la herramienta y los frameworks involucrados? ¿Cuántos y cuáles casos de éxito existen?

Como éstas, hay muchas preguntas que debemos hacernos antes de elegir una herramienta, con la cual tendremos que convivir un tiempo determinado y la cual podría llegar a transformarse en un gasto, para dejar de ser la inversión esperada.

Conclusión
MDA data del año 2000, cuando la OMG publicó un white-paper titulado “Model Driven Architecture”, en el que describía la visión del desarrollo de software a través de modelos de objetos relacionados entre sí, para la generación de sistemas completos.

Si bien transcurrieron casi seis años desde esa fecha, MDA no es, ni será, una bala de plata capaz de aniquilar a todas las problemáticas inherentes al desarrollo de software. Hoy día, a pesar de todo, 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, repetitiva en muchos casos y, sobre todo, un proceso caro en recursos (y dinero, claro). Además, una vez que el trabajo interesante y de mayor abstracción fue realizado, sólo la transformación desde el código al ejecutable es automatizable.

MDA también es el resultado de reconocer que la interoperatibilidad es algo bueno y que el modelado también lo es. Bien utilizado y teniendo en cuenta los principios de diseño subyacentes, nos puede ahorrar la escritura y generación de muchas tediosas líneas de código, ayuda siempre bien recibida. Incluso es probable que, analizando las tecnologías utilizadas hoy en nuestra organización, encontremos que algunas de ellas están fuertemente relacionadas con el concepto MDA. En ese caso, es posible organizarlas de manera que reflejen y hagan evidente el uso de MDA como concepto subyacente, más allá de las herramientas utilizadas.

Acerca del autor
Valerio Adrián Anacleto es socio fundador de Epidata Consulting, empresa especializada en Arquitectura de Software con oficinas en Argentina y Chile. Adicionalmente, Valerio es docente de la facultad de ciencias exactas y naturales de la UBA y dicta clases tambiÃ©n en CEIS - Carrera de especialización de Ingeniería de Software - en la UCA.