Microsoft y MDA-MDD - Segunda aproximación

Yendo adelante con la nota anterior, quisiera entrar un poco más en la visión de Microsoft.
Debo aclarar que tengo un prejuicio, y es que la insistencia de MS en desechar, desvalorar o desacreditar los dos estándares de OMG relacionados (MDA y UML) tiene una simple razón comercial. El mejor resultado de desentrañar su iniciativa, sería determinar los valores positivos que la estrategia de modelado de MS pueda aportar.
También debo decir que yo mismo, por mi experiencia personal con Plex, puedo coincidir en que no necesariamente se debe construír un producto por medio de transformaciones de un modelo generado a partir de un esquema UML. Aunque creo que entre los propios constructores del estándar, aceptan que pueden existir otras vías de pasar desde un modelo hacia una aplicación.
Salvado esto, quisiera enfocar el punto más valioso de la estrategia MS:

In our opinion, a single PIM and a single PSM per target platform, all developed using a general purpose modeling language, as prescribed by MDA, are insufficient to support the significantly greater levels of automation promised by model-driven development.

De acuerdo. Tratar de elevar el diseño orientado por modelos a un esquema que soporte en forma amplia el ciclo de vida completo de una aplicación, es una consecuencia natural de la construcción evolutiva de un modelo.
Cómo se ejemplifica en el documento de MS:

Rich automation of the software life cycle requires many additional types of models, such as models that:

• Capture, analyze, and manage requirements; identifying trace relationships between requirements, architectural design and implementation constructs, enabling validation that requirements have been implemented, and supporting impact analysis when requirements change.
• Define software architecture in a way that supports security, performance and reliability analysis, and other forms of evaluation; and in a way that enables predictable assembly of systems from components, and efficient and reversible step-by-step transformations from requirements and deployment,
• Define how the executable components of a system are packaged, identifying the types of resources in the deployment environment required by each component, and binding the components to specific instances of those resource types,
• Define test cases, test data sets, test harnesses, and other artifacts, making it easier to evaluate the quality of software developed using models, and to manage and display the test results
• Identify traceability relationships between models and other artifacts, making it easier to support business impact analysis when systems go down, configure systems to satisfy requirements, and enforce constraints during system configuration,
• Define configurations of source artifacts used to build executables, making it easier to version those configurations, and to associate defect reports and feature change requests with specific versions.

Dejando de lado que algunos de estos casos debieran ser contemplados hoy día por un esquema UML (seguramente el ítem 3), hay aquí un conjunto de escenarios que requerirían conducción, trazabilidad, interconexión o integración, automatización, y que cubren un paso más que lo que hoy una transformación PIM => PSM puede alcanzar. Muchos de ellos pudieran ser encarados encauzando el uso de un modelo dentro de una herramienta de manejo de configuración, que hoy cubren casi todos los ítems, al menos en una forma secuencial histórica. Pero mucho mejor sería que el mismo modelo articulara todos estos aspectos.
MS habla de "many additional types of models" para referirse al modo en que estos aspectos serían expresados, planteando el problema como una colección de modelos. Me conforma más la idea de OMG que habla de visiones encaradas por distintos diagramas. La idea de colección de modelos me hace pensar que la integración de ellos se lograría por medio de la IDE en la que se describieran y recolectaran, con lo que deja un grado de subjetivismo en cómo serán interpretados o aplicados. Más aún, cuando la IDE en que están incluídos es una parte del Visual Studio mismo, en donde la construcción de código tiene de automático aquello que pueda ser derivado de un wizard, una clase heredada, un header, o un patrón aplicado. Sobre esta característica retornaré en otro momento.
En resumen, la idea de extender, y las áreas propuestas de extensión, son de real interés, y creo que son valiosos generadores de ideas. El cuánto sea esto logrado en esta iniciativa, es algo que debe verse bajando más cerca de cada una de las herramientas concretas con las que se lo intenta. En cambio, el hecho de manejar estos recursos como una colección, sugiere que la idea no está acabada, y que en estos términos puede ser incluso peligrosa, excepto que se tenga una buena disciplina para su utilización. El desarrollo basado en modelos justamente se propuso atacar la complejidad del diseño, facilitando la visión arquitectónica, yendo hacia la abstracción, y poniendo bajo control la complejidad de las decisiones de detalle. De un modo en que la cascada de consecuencias que se derivan de las definiciones en el modelo abstracto, estén bajo control. No veo en el esquema propuesto por MS facilidades amplias de este tipo. Pudiera convertirse en lo contrario.
Volveremos sobre esto avanzando un poco...