Uno de los argumentos de los opositores a la generación de código a partir de un modelo del problema, es que no es posible representar mediante diagramas visuales todos sus aspectos, como lo dicen Scott Ambler o Martin Fowler. En el estado actual, y en base a la variedad de artefactos disponibles con UML, es posible que ese argumento sea bastante débil, ya que cualquiera de ellos pudiera mapearse a código ejecutable, más tarde o más temprano, con la ventaja adicicional de que remodelar produciría un efecto inmediato de doble vía entre la representación visual y el código.
Sin embargo, puede irse aún más allá. Basándome en Allfusion Plex (o Plex a secas, considerando su historia de cambios de nombre), se puede decir que no sólo es posible tener un diseño conceptual, abstracto, basado en UML, sino que el modelo puede ser representado por otros medios. Plex basa su descripción del problema en "triples", verbos que describen atributos de objetos, que forman un repositorio único que explica el modelo en todas sus partes, y en este repositorio, el modelo gráfico es una parte.
Plex y MDA crecieron conociéndose, y con cierto grado de intercambio. En el pasado, Synon primero, y Sterling después, participaron en la OMG de los esfuerzos destinados a la construcción de conceptos más sólidos en la elaboración de Software. Quizá hubiera que hacer en algún momento una breve historia de esta evolución. Pero baste recordar que Synon fue participante del proyecto San Francisco (dónde quedó?), y que Synon y Sterling fueron parte de los esfuerzos por elaborar estándares en el manejo de un repositorio, el UML, CORBA y los componentes en general, y aún se encontraron en alguna ocasión con Fowler en esfuerzos comunes en la definición de tecnología para construír patrones de diseño. Debiera revisar materiales de congresos de la década del 90 (especialmente el de 1999) para encontrar estas coincidencias pasadas.
Si lo viéramos desde el enfoque de Plex, el modelo es expresado en forma visual, pero no es dependiente de los diagramas de ningún tipo, sino de una descripción casi narrativa, conservada en un repositorio que puede ser exportada como XML. Podríamos decir que las visiones PIM (Platform Independent Model) y PSM (Platform Specific Model) son representados en Plex a través del modelo en su versión Base, y sus variantes. Las transformaciones entre una visión y otra no requieren otra actividad que la configuración del modelo en una variante, y esto es una acción simple, a condición de haber construído el modelo con una política de configuración premeditada. Se podría decir aún más, ya que la arquitectura que construye al modelo basado en una visión de cuatro dimensiones (Versión, Variante, Nivel, y Lenguaje), permite solucionar en el interior del modelo algunos problemas que todavía no ví bien expresados en MDA: el manejo de la versión como un complejo evolutivo histórico. Qué significa esto: que en el momento en que Plex finalmente integre una herramienta de diagramación, un diagrama determinado (de clases, de actividad), se crearía en una dimensión dada de la configuración (aunque fuera en la base), y aún podría explotar las ventajas de la configuración en una variante o una versión.
En lo que a mí respecta, quisiera tener la libertad de usar un diagramador para representar lo que hiciera falta. Sin embargo, los diagramas UML pueden usarse solo limitadamente hasta ahora importándolos a la IDE de Plex, y básicamente para ERD. En algún momento, con Sterling, existió planificado integrar varias herramientas de tal forma que hubieramos sido "MDA compliant". Sterling planeaba vincular Spex, Biz, Plex, Joe, como un solo conjunto capaz de iniciar un modelo desde el proceso de negocios, hasta el código ejecutable (Biz => Spex => Joe => Plex). El paso a Computer Associates implicó la reubicación de herramientas, y sólo ahora, uno o dos años después, es posible ver una vinculación entre Erwin => Joe => Plex.
Sin embargo, es UML la única vía de pasar de un modelo conceptual a código ejecutable?. Plex a vivido perfectamente usando un repositorio basado en otra forma de describir el modelo, sin perder la opción de usar UML u otro lenguaje de representacion visual como parte del conjunto de recursos, y agregando a partir de la versión 5.1 la posibilidad de exportar o importar un modelo a XML. Es razonable propugnar un estándar común, y UML tiene un camino recorrido como tal, pero quizá sea XML el verdadero medio de intercambio.
Es necesario agregar que UML encuentra resistencias también desde un punto de vista comercial, especialmente desde el momento en que Rational devino en una dependencia de IBM, y creo que Microsoft es uno de ellos.
En fin, esta nota requiere volver sobre ella una y otra vez, en la medida en que algunas tendencias de definan algo más. Digamos que la idea yacente en MDA es fundamentalmente aceptable, y que puede ser alcanzada por más de un camino, entre ellos, el que Plex adopta.
No hay comentarios.:
Publicar un comentario