Otro ejemplo del compromiso europeo con MDA

El ESI (European Software Institute) con sede en Zamudio, España, junto al
Fraunhofer-Gesellschaft de Munich y el IKV++ Technologies AG, de Alemania, y Thales ATM, con sede en varios países, trabajan en común en un proyecto de evaluación temprana de los conceptos de MDA:

The objective of MASTER project (IST-2001-34600) is to perform an early validation of the concept of MDA (Model Driven Architecture) which is currently being promoted by the OMG (Object Management Group). The validation consists in an experimental approach. MDA concepts are to be applied in the Air Traffic Management (ATM) domain and is focused on achieving the following more detailed objectives:

• Develop a variability specification language and apply it to the ATM domain to improve customising requirements according to the final user needs, and map variability (open decisions) on to the architecture.
  
  

• Provide the mechanisms to derive and analyse the development process activities and project management parameters (such as cost, effort, time, etc.) since the very early stages in contract negotiation and project definition, by using the architecture as the basis for reasoning about this.
  
  

• Implement the MDA concepts of separation of concerns to achieve independence from specific platform technologies and therefore enable the specialisation of resources (business knowledge separate from technological knowledge)
  

Additionally, the project aims at providing tool support for these activities. Tool support will allow for the modelling of variability among ATM systems using a variability specification language, automate the project management based analysis on the architecture and support the transformation mappings among different levels of abstraction of an MDA approach.

Finally, one very important aim of the project is to contribute to the development of the MDA standard and the consolidation of ATM domain. The project plans to achieve this through active participation in the standardisation groups of OMG.

Vea su esquema de implementación de MDA aquí

Microsoft y MDA-MDD - Domain Specific Languages

Uno de los pilares de la visión de Microsoft sobre el uso de modelos, señalado en su documento "Visual Studio 2005 Team System Modeling Strategy and FAQ" es el uso, recomendación y soporte de lenguajes específicos de dominio. Los DSL son propuestos como un diferencial respecto al estándar MDA de OMG, sobre el que se señala que

Microsoft has learned from past industry experiences, and plans to avoid the pitfalls of CASE by adopting an approach to model-driven development based on the following ideas:

• A model should be a first-class artifact in a project—not just a piece of documentation waiting to become outdated. Models have a precise syntax, are often best edited and viewed using a graphical tool, and embody semantics that determine how domain-specific concepts in models map to other implementation artifacts, such as code, project structures, and configuration files. In this way, a model is a lot like a source code file, and the mechanisms that synchronize it with other implementation artifacts are a lot like compilers.
• A model represents a set of abstractions that support a developer in a well-defined aspect of development. (...)
• Since models can abstract and aggregate information from a number of artifacts, they can more readily support consistency checks and other forms of analysis. For example, an application connectivity model might support contract protocol validation, security analysis, or performance analysis.
• Models can be implemented by a process similar to compilation, where the code, configuration files, and other implementation artifacts generated by the compiler are never edited by hand. More often, however, they are implemented by a combination of generated and hand-edited artifacts. In such cases, it is critically important to carefully manage the way the generated and hand-edited artifacts fit together. As mentioned above, the failure to do this effectively was one of the primary shortcomings of CASE products. We have been using several techniques to ensure that generated and hand-edited artifacts are kept separate, and that code added by a developer is never disturbed when boilerplate code required by a tool is generated. These techniques include the use of class delegation and inheritance, and particularly the use of "partial classes," a new feature of the .NET languages in Visual Studio 2005, which has been specifically defined with this task in mind.

We call modeling languages defined in these ways Domain Specific Languages or DSLs. Think of a DSL as a small, highly focused language for solving some clearly identifiable problem that an analyst, architect, developer, tester, or system administrator must wrestle with. Developers are already familiar with examples of DSLs; SQL for data manipulation, XSD for XML document structure definition, and so on. Another example from Visual Studio Team Edition for Software Architects is a DSL for modeling the logical structure of datacenter hardware and host software configurations. This DSL and its related graphical designer can be used to validate during design time that applications are configured to match their intended deployment targets, alerting the developer to problems when they can be fixed more cheaply.

Good ways to find candidate DSLs are to identify the patterns used by developers, and then to encapsulate them into a modeling language, or to surface the concepts in a software framework as abstractions in a modeling language that can then generate small amounts of code that extend the framework. These techniques allow us to control the amount and complexity of generated code, offering real value to the developers, without the hassles that characterized CASE products.

Microsoft recently announced the DSL Tools, which will enable customers and partners to build DSLs using the same technology in Visual Studio 2005 that we used to build the modeling tools that will ship with Visual Studio Team Edition for Software Architects. This technology, which can be thought of as "tools to build tools," simplifies the task of defining DSLs and reduces the effort and skills required to build graphical editors and compilers for them.

La idea de usar lenguajes específicos para problemas específicos es contrapuesta a la idea de los modelos específicos de plataforma (PSM), suponiendo que para una plataforma corresponde un solo modelo de plataforma. Independientemente de que sea corrientemente así o no, no parece esta una razón para oponerlos. Sí es correcto en todos caso que un DSL puede ser el soporte de generación de un modelo dado.
La idea de crear código combinando generación automática y trabajo manual, mantiene al producto dentro del marco que MS cuestiona para los modelos desarrollados desde UML. No hay ninguna diferencia: (Models can be implemented by a process similar to compilation, where the code, configuration files, and other implementation artifacts generated by the compiler are never edited by hand. More often, however, they are implemented by a combination of generated and hand-edited artifacts. In such cases, it is critically important to carefully manage the way the generated and hand-edited artifacts fit together)
El código manual siempre será opaco para el modelo, por lo que fácilmente devendrá desincronizado, y exige seguimiento del desarrollador acerca de la coordinación entre ambos mundos.
Los DSL son productos orientados a la solución de problemas determinados, bien definidos para cada caso, bien probados, y con la solución más adecuada al caso. Así lo indica el artículo, así lo conocemos de otras definiciones. La novedad que ofrece MS es ofrecer una herramienta para la construcción de DSLs. Esto es coherente con ofrecer como contraposición a un PSM (Platform Specific Model) los DSLs en general: es decir, si se va a decir que los DSL son la solución frente al mapeo que se produce entre un PIM y un PSM, debe ser posible construír un DSL para cada problema vinculado a una plataforma que se presente. Es eso posible? Sin duda que se puede construír un generador o mapeador a un problema que tenga reglas que ya se aplicaban manualmente. Pero es viable?. Seguramente, dependiendo de la magnitud del proyecto, o de la continuidad con que el mismo problema deba ser resuelto. Si se dispone de un equipo que pueda dedicar la cantidad de horas hombre necesarias, y el conocimiento correspondiente, para crear todas los algoritmos que interpreten un dominio, y que testeen todos los escenarios posibles, seguramente se logrará crear un DSL que cumpla con todos los requisitos propuestos. Seguramente dedicarse a este objetivo no está en el ámbito de la productividad y reducción de costos que se proponen los desarrollos basados en modelo y generadores. Salvo que estemos hablando de empresas de primer orden mundial. En el resto del prosaico mundo, la exigencia por resolver problemas con el menor costo implica que la búsqueda de herramientas de desarrollo rápido trate de conseguir eso: desarrollo rápido.
Así, el toolbox para crear DSLs, es seguramente una herramienta para empresas de software dedicadas a nichos de software que trabajen con .NET y Visual Studio.
Poco, estrecho alcance para el nivel de la crítica presentada por la visión de Microsoft a la OMG.

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

Microsoft explica su posición sobre MDA-MDD

El 1 de junio Paul Ballard publica una breve nota en The Server Side presentando el documento oficial de Microsoft donde se explicita en mayor detalle su posición sobre el desarrollo basado en modelos. Quince páginas (ver el artículo en el enlace del título de esta nota) para describir el concepto de Software Factory, los puntos de contacto y las diferencias con UML y MDA:

Customers and partners are keen to understand Microsoft's strategy for model-driven development and its support in Visual Studio Team System. When we explain our strategy to them, they frequently express interest in some of the same topics, and raise some of the same concerns. In this document we set out our strategy for model-driven development as a series of questions and responses that address these topics and concerns. The first five questions deal with the main pillars of our strategy, which we have described with detailed answers and explanations.

En los próximos días trataré de sacar lo mejor del documento...