La estrategia de Microsoft en modelado vs MDA

Un importante punto de inicio para discutir otros argumentos. Se trata de un documento de Microsoft de octubre de 2005, que aunque no sea muy reciente, es más constructivo que otros documentos posteriores.

Imagínese Software Factories como MDA incorporado y ampliado, donde MDA se define con un sentido más amplio que la definición oficial basada en PIM y PSM. Software Factories van más allá de la independencia genérica de la plataforma y los modelos específicos. (...)
MDA, según lo define OMG, sólo trata una pequeña parte de lo que creemos que son problemas reales que deben solucionarse para permitir un desarrollo eficaz controlado por modelos.

Incluso resulta de mucho interés la descripción de algunos objetivos deseables en el marco de una mayor rigurosidad en la construcción de software:

¿Qué se debería modelar para un tipo de sistema determinado? Puesto que distintos sistemas pueden tener arquitecturas diferentes, ni un sólo conjunto de modelos puede describir todos los sistemas posibles de forma efectiva. La respuesta a esta pregunta variará entonces según los diferentes tipos de sistemas. En nuestra opinión, un único PIM y un solo PSM por plataforma de destino, desarrollados todos con un lenguaje de modelado de finalidad general, como prescribía MDA, no son suficientes para admitir los niveles considerablemente superiores de automatización que promete el desarrollo controlado por modelos. La automatización enriquecida del ciclo de vida del software requiere numerosos tipos de modelos adicionales como, por ejemplo, modelos que:
• Capturan, analizan y administran los requisitos; identifican las relaciones de seguimiento entre los requisitos, diseño arquitectónico y construcciones de implementación, permiten la validación de que se implementan los requisitos y permiten el análisis del impacto cuando cambian los requisitos.
• Definen la arquitectura del software de modo que admita la seguridad, el análisis del rendimiento y la confiabilidad, así como otras formas de evaluación, de manera que permita un ensamblado de sistemas predecible a partir de componentes y transformaciones paso a paso eficientes y reversibles de requisitos e implementación.
• Definen cómo se empaquetan los componentes ejecutables del sistema, identificando los tipos de recursos del entorno de desarrollo que necesita cada componente y enlazando los componentes a instancias específicas de dichos tipos de recursos.
• Definen casos de pruebas, realizan pruebas en los conjuntos de datos, en el sistema de seguridad y en otros artefactos, de forma que facilitan el proceso de evaluación de la calidad del software desarrollado mediante modelos y la administración y visualización de los resultados de las pruebas.
• Identifican las relaciones de seguimiento entre los modelos y los demás artefactos, de modo que facilitan el análisis del impacto empresarial cuando los sistemas dejan de funcionar, configuran los sistemas para satisfacer los requisitos y aplican limitaciones durante la configuración del sistema.
• Define configuraciones de artefactos de origen utilizados para crear ejecutables, facilitar la creación de versiones de dichas configuraciones y asociar informes de defectos y solicitudes de cambios de características asociados con versiones específicas.

Invariablemente, estos requisitos son vistos como elementos que invalidan el esquema sugerido por OMG, y remiten a la solución de Software Factories como camino acertado, afirmación que a más de un año de este documento sigue siendo una promesa, y una visualización de futuro.
Por eso mismo, insisto en que estas puntualizaciones deben ser tomadas como parte de una lista de tareas para discutir, en un camino convergente de soluciones, donde las realidades de múltiples herramientas practicando sobre las lineas sugeridas por el estándar de Desarrollo Orientado por Modelos de OMG, compitan con las virtualidades de Software Factory, y aún otras propuestas existentes.
Contrariamente a las afirmaciones actuales de los sostenedores de SF, en 2005 el enfoque era más abierto:

Algunas organizaciones que buscan un desarrollo controlado por modelos aceptan una interpretación más amplia del término MDA que la que prescribe OMG; de hecho, como hemos descrito, deben hacerlo para poder lograr el éxito. El uso de cualquiera de las especificaciones de OMG en el desarrollo controlado por modelos se marca normalmente como MDA, incluya o no PIM y PSM. Algunas organizaciones, por ejemplo, consideran la especificación MOF de OMG clave para MDA. Esta consideración se basa en los nuevos lenguajes de modelado definidos con MOF, no los predefinidos en UML, y son similares en efectividad a nuestro enfoque. (...)
Imagínese Software Factories como MDA incorporado y ampliado, donde MDA se define con un sentido más amplio que la definición oficial basada en PIM y PSM. Software Factories van más allá de la independencia genérica de la plataforma y los modelos específicos para tratar los problemas descritos en la sección anterior.

En cuanto a uno de los pilares de MDA, como ya es sabido, la posición era y es la misma:

En resumen, recomendamos el uso de UML y las herramientas basadas en UML para:
• Realizar bocetos.
• Escribir en pizarras blancas.
• Documentación.
• Dibujos conceptuales que no están directamente relacionados con el código.

Recomendamos DSL y herramientas basadas en DSL definidas de forma precisa para:
• Abstracciones precisas con las que generar código
• Abstracciones precisas que asignan puntos de variación en los marcos y componentes.
• Asignaciones precisas entre lenguajes DSL.
• Dibujos conceptuales que tengan asignaciones que se puedan especificar de forma precisa en otros lenguajes DSL o en artefactos de código.

No recomendamos nada de lo anterior en el caso de programación visual de lógica detallada de programas (o por lo menos no hasta dentro de varios años).

Este también es uno de los puntos donde disiento particularmente: No es más ni menos riguroso el mapeo que se ejecute entre un diagrama UML y el código, que el que pueda hacerse entre una herramienta DSL y el código. Esto sin hablar del hecho de que reemplazar el ahora odioso diagrama "genérico" UML por un lenguaje específico de dominio no será una tarea trivial, capaz de poner en manos de un desarrollador medio. Estamos hablando aquí de: o comprar n herramientas "de dominio" para cubrir la articulación de la arquitectura elegida (y resolver su integración), o dedicar un(os) equipo(s) de desarrollo a la forja de los DSL requeridos para el problema específico.
Que el UML como lenguaje no sea suficiente para generar lógica detallada, y que tampoco lo sea un DSL ("No recomendamos nada de lo anterior en el caso de programación visual de lógica detallada de programas -o por lo menos no hasta dentro de varios años-"), es algo que pone la escritura de código "a mano" como parte principal del desarrollo, con lo que no difiere mucho una SF de un marco para la administración de configuración. Sinceramente, los intentos tipo MDA se proponen mayores logros.