Los Modelos como Foco del Desarrollo

MDD parte de la idea de que se ha dado una evolución en el nivel de abstracción utilizado para desarrollar software, acercándose cada vez más a representaciones familiares para los humanos, o dicho de otra manera utilizando abstracciones de más alto nivel. El objetivo es abstraerse de los detalles técnicos de la plataforma, lo que ayuda a incrementar la productividad de los desarrolladores, por ejemplo: lenguaje de alto nivel vs. lenguaje ensamblador vs. lenguaje máquina. Desde la perspectiva de
MDD, el siguiente paso en este “proceso evolutivo” es generar código a partir de modelos que faciliten la especificación, comprensión, desarrollo y mantenimiento del software. Lo anterior gracias a la utilización de: 1) abstracciones más cercanas al dominio del problema que se quiere resolver y 2) modelos independientes de la tecnología, los cuales son menos susceptibles de ser afectados por cambios en
la tecnología. En MDD la reutilización no ocurre en los componentes de software generados, sino en el conocimiento inmerso en el propio modelo, el cual es compartido entre diferentes equipos de trabajo o productos.

Características de un modelo
Un buen modelo debe cumplir las siguientes características:
• Abstraer para incluir lo esencial y omitir los detalles irrelevantes.
• Ser facil de entender, para que pueda ser una herramienta de comunicación efectiva.
• Ser preciso, representando fielmente el dominio del problema.
• Ser predecible, haciendo posible predecir cómo se comportará.
• No menos importante, un modelo debe ser económico en su creación.

Una vez que un sistema ha sido especificado con un conjunto de modelos, éstos son transformados ya sea en otros modelos intermedios o directamente en código. Dependiendo del tipo de transformación, existen limitantes claras: si sólo se generaron plantillas de código a partir del modelo, lo más probable es que el modelo deje de utilizarse, pues generalmente en un proyecto nunca sobran los recursos para
mantener “documentación”. Si la herramienta utilizada tiene capacidades de ingeniería inversa, es posible que el modelo también termine abandonándose cuando la complejidad del código impida que éste pueda convertirse nuevamente en parte del modelo después de haberse modificado manualmente el código. Por ello, una herramienta MDD moderna debería generar programas completos no sólo fragmentos o plantillas de código. Al llegar a este punto, el lenguaje de modelado se ha convertido efectivamente en un lenguaje de programación.

Diversidad y retos en MDD
Las aproximaciones a MDD no son homogéneas. Por lo que respecta a lenguajes de modelado, hay una escuela de pensamiento que afirma que deberían preferirse lenguajes específicos de dominio o DSL por sus siglas en inglés (Domain Specific Language). En contraparte hay otra corriente que piensa que lo mejor es utilizar un lenguaje de modelado de propósito general con la capacidad de extenderse con abstracciones propias de un dominio, como es el caso de UML.

Igualmente existen soluciones heterogéneas en la búsqueda de una estrategia efectiva para conseguir una adecuada separación de intereses (separation of concerns). Algunos enfoques promueven el uso de un conjunto fijo de perspectivas, en tanto que otros han desarrollado técnicas denominadas “Modelado
Orientado a Aspectos”

La generación de código a partir de modelos, no se da sin sus problemas. Uno muy importante es la rastreabilidad (traceability). Cuando ocurre un problema en el código generado, puede ser muy complicado encontrar qué parte del modelo debe corregirse, y más complicado corregir código generado que no se comprende. Se requiere el equivalente de profilers y debuggers para los modelos,
y éstos deberían poder iniciarse, pausarse, detenerse para observar con detenimiento su ejecución. Otro problema es la eficiencia del código generado, ya sea vista en términos de desempeño, escalabilidad, uso de recursos, etc. por lo que una buena herramienta MDD debería permitir la integración transparente de fragmentos de código escritos manualmente para resolver puntos críticos. Esto es
el equivalente a escribir rutinas en lenguaje C o ensamblador e incorporarlas en programas escritos en otros lenguajes.

MDD en práctica
Dos de las iniciativas MDD con más visibilidad son Model Driven Architecture (MDA) del OMG y Software Factories de Microsoft. Un elemento crucial que las diferencia es que MDA busca la independencia de la plataforma mientras que Software Factories no. Existen herramientas de código abierto y libre que permiten tener un acercamiento
a MDD. Entre ellas KerMeta (http://bit.ly/3HHvuC), ATL (http://bit.ly/fUK79), ModelPro (http://bit.ly/3pQbHs). y AndroMDA (http://bit.ly/4724jn).

Conclusión
Aún si MDD siguiese como hasta ahora, sin adoptarse de manera generalizada, las lecciones
aprendidas durante su desarrollo pueden resultar valiosas para enfrentar la complejidad del software. O tal vez ocurra lo mismo que con otros generadores de código: los compiladores, cuestionados tras su introducción algunas décadas atrás, se han convertido en una tecnología cotidiana.

Referencias