De pronto, UML, II

El 8 de junio, Dr Dobbs Code Talk publicó una entrada de Christopher Diggins, que reconoce tres elementos que en el último tiempo han sido oscurecidos o cuestionados: que en programación hacen falta modelos, que UML tiene un papel que cumplir, y que existe un intento de crear un modelado que se convierta intrínsicamente en código, basado en UML (xUML, UML ejecutable). Diggins propone una sintaxis para no diagramar, sino escribir los modelos, que luego se ejecutarán (Heron).
Más allá del futuro de su iniciativa, lo motivan algunas objeciones comunmente formuladas a estándar:

Modeling is frequently used in certain software development domains to help verify the design of software, both formally and informally, before implementation starts.

One of the reasons that this approach hasn't caught on in the programming community at large is that it slows down development and increases the overall cost significantly. You have to maintain separate artifacts that contain largely the same information: the source code and the model. Finally models are often ignored after implementation starts.

Diggins reconoce que esta objeción no vale para el "UML ejecutable", que genera código a partir del modelo:

There is however a better solution that already exists: make the code and models synonymous with each other. In other words: make the model the code. This approach is the holy grail of the model-driven architecture (MDA) movement, and only one technology actually offers it today: executable UML (xUML).

Una objeción es acerca del carácter gráfico del modelo:

The problem with xUML is that it is primarily a diagram based formalism (with some unspecfied syntax thrown in). Most of us programmers hate diagrams. They are slow and cumbersome to develop and manipulate. My view, which I am sure is shared by many of you out there, is this: I wish everyone else in the world could supply me with up to date UML models with their source code, but I don't want to be obliged to do so myself.

Otra importante es acerca de la real posibilidad de traducir todos los diagramas a código. O mejor al revés: que todo el código requerido sea manejable con diagramas:

So a question one might ask is: why can't we simply generate models from code? Well the problem is that code is too low-level. Just like you can't generate pretty and elegant source code with meaningful symbol information from assembly code, the same is true of models.

En fin, estas objeciones serían objetables...En OMG existen estándares para manejar información de los modelos por medio de directivas que completen los diagramas. Tampoco es mi experiencia: el modelador que uso (Plex/no UML/si MDD) también es capaz de completar la información con un metalenguaje capaz de expresar lo que haga falta, y lo suficientemente abstracto como para que pueda generar código para distintas plataformas y arquitecturas, basadas en las mismas directivas, configuradas para distintos contextos.
La iniciativa de Diggins va en esa dirección. Nótese que Diggins, ante los puntos no satisfactorios de UML, va por más, no hacia atrás.