Modelado específico de Dominio

Moving to English this page is a hard work for me. It will be done, but, in the meantime, use Google for a basic tranlation.

DSM Forums, quizá el principal centro de discusión en su tema.

Steven Kelly sobre DSM

Juha Pekka sobre DSM

DSM 2007, en OOPSLA

Microsoft y herramientas DSL.

El concepto de Modelado Específico de Dominio (DSM, Domain Specific Modeling), así como los Lenguajes Específicos de Dominio (DSL, Domain Specific Languages), han cobrado importancia como respuesta a la utilización de conceptos "genéricos" en la descripción de problemas que implica UML. Si durante la década de los 90 la discusión sobre el modelado estuvo centrada en la definición de un lenguaje unificado, a partir de las metodologías orientadas a objetos existentes, tras el establecimiento del UML como un estándar más o menos de facto, la discusión se transladó a los aspectos que el UML no resolvía adecuadamente. O que así lo pareciera en el punto de vista de algunas corrientes de teóricos que lo califican, como se señaló, de genérico, e insuficiente para explicar dominios específicos. Este es el terreno que DSM y DSL pretenden cubrir. Wikipedia, en su descripción de DSM, destaca dos de sus características: su mayor aptitud para describir problemas específicos de un dominio para el que fueron construídos, y la mayor probabilidad de que el lenguaje de dominio sea elaborado por los propios interesados, asegurando una mayor exactitud en su propósito:

Domain-Specific Modeling (DSM) is a software engineering methodology for designing and developing systems, most often IT systems such as computer software. It involves systematic use of a graphical Domain-specific programming language (DSL) to represent the various facets of a system. DSM languages tend to support higher-level abstractions than General-purpose modeling languages, so they require less effort and fewer low-level details to specify a given system. DSM often also includes the idea of code generation: automating the creation of executable source code directly from the DSM models. Being free from the manual creation and maintenance of source code means DSM can significantly improve developer productivity. The reliability of automatic generation compared to manual coding will also reduce the number of defects in the resulting programs, thus improving quality. DSM differs from earlier code generation attempts in the CASE tools of the 1980s or UML tools of the 1990s. In both of these, the code generators and modeling languages were built by tool vendors. While it is possible for a tool vendor to create a DSM language and generators, it is more normal for DSM to occur within one organization. One or a few expert developers creates the modeling language and generators, and the rest of the developers use them. Having the modeling language and generator built by the organization that will use them allows a tight fit with their exact domain and needs. It also reduces the time needed for developers to learn the modeling language, since it can use familiar terms and concepts. Finally, since only one organization's requirements need be taken into account, it is easier for the modeling language to evolve in response to changes in the domain.

DSL ocupa un papel importante en el proyecto de Software Factories de Microsoft, como parte del paquete de Visual Studio. En su página sobre Lenguajes Específicos de Dominio, se presenta el mecanismo así:

A domain-specific language, unlike a general-purpose language, is designed to be useful for a specific task in a fixed problem domain. By using Domain-Specific Language Tools, you can build customized modeling tools. You can define a modeling language and implement it very simply. For example, you can create a specialized language that describes a user interface, a business process, a database, or the flow of information, and then you can generate code from those descriptions.

En resumen, el modelado específico de dominio se propone atacar el diseño enfocándose en áreas específicas sobre las que es posible entonces describir el problema con elementos adecuados a éste, y, en lo posible, desarrollar código automático a partir de este diseño específico, utilizándo elementos de lenguaje también específicos al área atendida. En buena medida, como se trata en el caso de las herramientas de Microsoft, la importancia se desplaza a la creación de metalenguajes, de tal forma que sea posible crear lenguajes por parte del equipo de diseño, basados en el problema que se intenta resolver.
Este criterio implica complementariedad: DSM no necesariamente contradice otros esquemas, particularmente MDA, sino que lo complementa: una arquitectura de diseño puede componerse de un conjunto de DSLs atacando diferentes dominios.
Esta página se propone comentar y difundir este concepto, y presentar y discutir aquellos papeles que traten el tema

Estudios sobre DSM/DSL

Existen distintas interpretaciones sobre este área de investigación. Es particularmente importante el trabajo de Steven Kelly y Juha Pekka, miembros del equipo de Metacase, y soportes del foro DSM. A ellos hay que agregar también especialmente todo el trabajo de Microsoft, y las investigaciones de Martin Fowler. Algunas referencias que se irán comentando:

De Metacase, una descripción detallada del problema y su particular solución, en un papel corporativo: Diez veces más rápido que con UML

De Martín Fowler, sus elaboraciones en desarrollo sobre el problema, en su bliki:Language Workbenches, y sus comentarios en curso.

También importante, entre los papeles conservados por el foro DSM, el desarrollado por Benoit Langlois, Consuela-Elena Jitia, y Eric Jouenne, sobre una clasificación de DSLs.