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.