Model Driven Architecture

Model Driven Architecture (MDA). Los generadores de código

Como se indica antes, Model Driven Architecture es el estándar propuesto por el Object Management Group, para la construcción de software con el auxilio de herramientas que simplifiquen y automaticen tareas. El propósito de éstas páginas, en una de sus partes, es defender justamente éste modelo de desarrollo de aplicaciones, a partir del uso de un producto inspirado en estos principios.
Tomado de la MDA GUIDE 1.0.1

The Model-Driven Architecture starts with the well-known and long established idea of separating the specification of the operation of a system from the details of the way that system uses the capabilities of its platform. MDA provides an approach for, and enables tools to be provided for:
— specifying a system independently of the platform that supports it,
— specifying platforms,
— choosing a particular platform for the system, and
— transforming the system specification into one for a particular platform.
The three primary goals of MDA are portability, interoperability and reusability through architectural separation of concerns.

Las ventajas de modelar y además hacerlo en forma abstracta una aplicación son innegables. Construír un modelo del problema debiera llevar a una solución más confiable, más probada, más segura al haber explorado los distintos escenarios en que la aplicación actuará. Más aún si el modelado abstracto puede convertirse en código, y si eso se puede hacer para distintas plataformas, o contar con medios de exportar o importar su diseño para interoperar con otras herramientas. Por qué mantenerse en la escritura detallada de código, escribiendo miles y miles de líneas, cuando se puede contar con modeladores potentes capaces de abreviar los tiempos por veinte? Esa debiera ser una de las mayores lecciones aportadas por la falla del año 2000.
Un aspecto importante es el soporte de estas herramientas al manejo ordenado del ciclo de vida de los sistemas de información, ya que el modelado visual en general alimenta un repositorio único, que se despliega luego en un diseño detallado y en directivas de implementación. Esta característica permite soportar un ciclo incremental, facilitando el cambio, con bajo nivel de impacto en el momento en que los cambios sean de importancia. Un buen estudio sobre la relación entre la arquitectura MDA y el manejo del ciclo de vida se puede encontrar en "Understanding the Model Driven Architecture", de Sinan Si Alhir.
Una visión de la actividad y problemas bajo investigación, puede seguirse en el Workshop efectuado en la Universidad de Twente, en junio del 2003, en Holanda. Participaron en él investigadores de Europa, Estados Unidos y Canadá. Pueden estudiarse los papeles del workshop en el mismo sitio. Se pueden encontrar allí no solo casos interesantes líneas de desarrollo, sino también casos prácticos de aplicación.
Sin embargo, existen opiniones que descreen de esta dirección, y algunas de ellas provienen de Agile. Una buena descripción de MDA, de sus fortalezas, y una fundamentación de argumentos en contra, se pueden encontrar en el artículo de Scott Ambler, "Architecture and Architecture Modeling Techniques".
La estandarización de las herramientas de diseño está hoy (y quizá siempre, en nuestras condiciones) bajo fuego. En un contexto en el que la lucha por la preeminencia en el control del mercado es aguda (debiera decirse feroz?), los estándares no son sólo un interés científico, sino un argumento comercial. Así, OMG ha variado a través del tiempo en la composición de sus integrantes, y la evolución a veces pasa por sus elaboraciones, y a veces no. Rational devino en un departamento de IBM, y el UML en una dependencia suya. Java es boicoteado abiertamente por Microsoft, que desea imponer .NET como plataforma base. Sun se niega a participar de Eclipse, el proyecto abierto promovido por IBM. "Si usted no suscribe a estándares, entonces la interoperabilidad deviene limitada" dice un consultor en el artículo de J. Ambrosio sobre Longhorn. Bajo estas condiciones, la interoperabilidad fluctúa entre la conveniencia de establecer estándares de integración, y la protección de la inversión en una marca. Así pasó con CORBA, una de las recomendaciones de la OMG, cuyo uso está lejos de ser generalizado, y con UML mismo, donde no todas las empresas que construyeron herramientas para su uso, han adoptado el estándar 2.0.
Sin embargo, los conceptos de MDA, en abstracto, son más generales que su especificación. Y son sumamente recomendables: usar el modelado visual, convertir este en código, separar el modelo del código, separarlo de la aplicación a una plataforma, disponer de herramientas que "traduzcan" el modelo a un código externo exportable e importable: la separación conceptual del sistema respecto a la plataforma, y el tratamiento de modelos como patrones para relacionar los distintos planos son una idea correcta. Desde sus orígenes en las herramientas CASE, distintos productos crecieron basados conceptualmente en la idea de simplificar el diseño, agilizar la construcción de aplicaciones, cohesionar el código, y aún se mantienen en evolución. Genexus es un ejemplo cercano para Latinoamérica, de ese crecimiento.
OMG reconoce que la construcción de herramientas en esta dirección aún es imperfecta, y está en evolución. MDA requiere de herramientas de modelado, que encaucen de manera integrada el diseño hacia su conversión en código ejecutable. UML es el estándar en el que OMG ha trabajado siempre, y es el estándar para el diseño en MDA. No todas las herramientas reconocen a UML como estándar propio, e incluso es relativizado en su alcance por algunos autores, y aún más sucede esto con CORBA. Scott Ambler, por ejemplo, habla críticamente sobre el alcance del estandar de la OMG, desde el punto de vista de Agile.
Aún más fuerte es la crítica de Chris Date, encarada desde cuestionamientos más básicos, ya que Date manifiesta el conflicto entre el modelo Relacional y los conceptos de Orientación a Objetos. Sus observaciones apuntan a inconsistencias en el alcance del UML, y particularmente de OCL, en definitiva uno de los pilares de las transformaciones requeridas por MDA para pasar un modelo lógico a código.

Las críticas y oposición a los generadores de código

Como se ha dicho, MDA, CASE, y los generadores de código, son una buena idea, pero tienen opositores.

Comparar con CASE de los 80´s

Una parte de estas críticas parten de asimilar erróneamente la actual generación de herramientas 4GL a las primeras CASE, que no obtuvieron respaldo amplio y fallaron en resolver el problema que era su objetivo. En muchos casos, estas herramientas no entregaban un producto final generado y compilado, sino que se detenían en el paso previo, entregando un marco de referencia que debía ser implementado. Es de hacer notar que Synon 2E, antecedente de Advantage Plex, si lo hacía desde el principio, y aún mantiene una amplia base de usuarios capaces de incluso mover a la web sus aplicaciones RPG. En el caso de estas críticas, entonces, existe un error de conocimiento superficial acerca de las capacidades propias de la actual generación de herramientas.

No deseo usar una herramienta que medie con el código fuente

Otra fuente importante de críticas está originada en una equivocada disyuntiva, difundida entre programadores, y difundida en nuestro medio latinoamericano obligado a manejarse con escasos recursos: Es mejor trabajar directamente sobre el código final, ya que así se optimizan los algoritmos, porque las herramientas 4GL agregan código inutilmente y desarrollan aplicaciones innecesariamente agrandadas. "La programación es un arte", y el programador no debe ceder su código a una "máquina"; no debe ser reemplazado por un modelador automático. En este caso, existe un error conceptual acerca del objetivo de este tipo de herramientas: no se trata de eliminar programadores, sino de reenfocar su modo de enfrentar el diseño. En lugar de prestar atención a miles de pequeñas acciones que finalmente construirán el edificio, se trata de verlo más globalmente, dejando los pequeños detalles en manos de agentes que invariablemente lo harán de manera consistente. La actividad inteligente se translada a un nivel más abstracto de pensar el problema, y construye de forma más consistente, eliminando los cientos de imperceptibles y altamente problemáticos errores que de otra manera se producirían.

El aprendizaje es largo

Una crítica derivada de esta anterior, es la relacionada con la curva de aprendizaje. Es real que la curva de aprendizaje de estas herramientas es mayor que la que un lenguaje requiere, pero el beneficio obtenido recupera el mayor tiempo consumido. Una vez que se domina el concepto, la mejora en la definición del problema, la mayor confianza en la consistencia del código, y especialmente, la gran facilidad comparativa con que se vuelve sobre el código la segunda vez (el impacto de modificar las definiciones del problema), todo esto, justifica la inversión inicial.

El modelado visual no puede llegar a la flexibilidad que produce crear el código directamente

Quizá una de las críticas más interesantes abiertas sobre MDA, sea la originada por Martin Fowler, especialmente, por dos razones: Fowler ha participado en la construcción y evolución de estas ideas (Es un difusor del UML, ha participado incluso en la actividad de investigación de este tipo de herramientas -Sterling trabajó junto con el cuando Plex era "Cool"). Y justamente por esto, la discusión de sus argumentos ayuda a definir mejor el problema. Quizá a algunos les haga dar un paso atrás, pero probablemente el resultado será una mejora en las herramientas. Centralmente, el argumento de Fowler:

Having an OMG standards stack is certainly something that the 80's CASE tools lacked, but we'll see how well people stick to it. One thing that's struck me is how many MDA fans seem to see UML as the UnwantedModelingLanguage. MDA proponents talk about platform independence, but I've already dismissed this as a PlatformIndependentMalapropism. I've heard about how MDA will simplify development by allowing automatic generation of patterns. But I don't see a difference between what you can do in UML and what can be done with good libraries and frameworks. (As well as the fact that generating pattern implementations is missing at least half the point of patterns.) Much of the boosting of UML seems to be based on the statement that pictures are better than text. In cases this is true, but I see no evidence for that in general - anyone who has compared flow charts to pseudo code can form their own conclusions. In many ways I'd love to be wrong about this. I would really like to see software development raised by a level of abstraction. (Not to mention that the UML's success would be good for me personally.) But I don't see that the UML provides this abstraction jump - and without it the MDA will not succeed.

Puede ver el inicio del punto de vista de Fowler en su página. Entre otros, en The Server Side, existe una discusión abierta sumamente útil, que se puede consultar y servir de hilo conductor de nuevos desarrollos.
Uno de los participantes en esta discusión, Stefan Tilkov, amplía la discusión en su weblog.
Este tema será desarrollado, pero en principio, lo mínimo necesario es despejar dos aspectos de lo dicho: uno, no se debe asimilar el estado actual de comprensión de éste problema, con el manejado por el CASE de hace alrededor de veinte años atrás. Segundo, no se debe circunscribir el problema al soporte gráfico del UML. Tanto el dominio del problema a resolver, como las alternativas reales existentes, van más allá de ese alcance.
Esta discusión será ampliada en las próximas semanas.

El modelo visual es un auxiliar inicial, que una vez que el código se extiende, queda desactualizado.

Eric Newcomer, de IONA, a propósito de la aplicabilidad de MDA a un proyecto basado en servicios web, pero generalizando, dice

My experience with UML-generated code seems to be in line with what Stefan is saying, and with a more practical view of UML and MDA that now seems to be emerging. I was running a COM+ architecture lab program at the time for Compaq services. We started with UML to capture the use cases and create the initial class diagrams, from which we generated the initial VB skeletons. However, once we got into the code we never went back to the diagrams. True round-tripping, as far as I know, remains an unrealistic goal.

El punto de vista de Newcomer, aplicado en el contexto de otra discusión (Web Services) es un argumento frecuente en contra de MDA, extensible a otras variantes de diseño abstracto. Esta irreversibilidad no está justamente en los objetivos buscados por el estándar, y, en el caso en que existiera (de acuerdo al grado de desarrollo de la herramienta que lo aplique), estaría en un contexto de superación progresiva. En el caso de Plex, que podría ser considerado dentro de este marco, (y que seguramente sería acusado de lo mismo por un sostenedor de estos argumentos) el diseño abstracto está sólidamente integrado con la evolución de la aplicación, y de ninguna forma podría considerarse el modelo evolucionando separadamente entre su representación de alto nivel y su código generado: el problema no existe, simplemente.

Una extensión de estas observaciones, estrictamente atinente a MDA, puede verse comentada por Stefan Tilcov, en su artículo de Diciembre de 2002 "MDA from a developer perspective", en The Server Side. Más adelante estas observaciones servirán para analizar puntos fuertes y débiles de MDA en su definición actual, y cómo Plex se acerca o se aleja de este marco.

En mi experiencia, en los últimos cerca de diez años he aplicado y he visto a otros aplicar Plex en toda clase de problemas, y encontré que nuestros modelos, a pesar de todos los augurios, no solo han resistido toda clase de desafíos, sino que han crecido y adoptado nuevas tecnologías, y han podido expresar la lógica en los ambientes más diversos. Eso, a mi juicio, es irrebatible. No veo cómo volvería atrás a un estilo de construcción de software que no explotara las facilidades de la abstracción y automatización de tareas, o que me obligara a seguir la pista de mis cambios "a mano".

Plex y MDA

En este contexto podemos ver a Plex en general como una herramienta basada en esta visión. En mi experiencia, su transición al cambiar de propietarios, (donde se ve que la evolución de la teoría se parece al curso accidentado de la evolución de las especies), significó que la evolución planeada hacia el soporte de UML tropezara al pasar de Sterling a Computer Associates (Todavía hoy Plex puede iniciarse con un modelo de alto nivel en Cool:Biz, bajar a un modelo de entidades y exportarlo a su entorno propio; o partir de un diseño UML en Cool:Spex, y pasar a un diseño en Joe, que sirva para una implementación J2EE). Esa demora de tiempo que parece estar llegando a su fin. Desde la incorporación de Plex al grupo de herramientas de Allfusion, la integración de Plex en un conjunto articulado de herramientas capaces de sostener un proceso de construcción de software, es un hecho. Junto a ERwin, Harvest, Joe y algunos plug-ins, constituye la línea principal de productos dedicados al desarrollo de aplicaciones en CA. Esto planea ser incrementado, estando el soporte de UML y el estándar MDA, como releases futuros, en un marco de dos años adelante.
Más aún, Synobsys, una empresa holandesa dedicada a Plex desde hace años, adelantó el soporte de UML, desarrollando un puente desde y hacia UML, que ya permite ahora mismo elaborar un ciclo de vida que integre el trabajo desde el análisis hasta la implementación, haciéndolo recursivamente, como lo requiere el desarrollo actual. Ahora entonces es posible iniciar el modelo recurriendo a Casos de Uso, Clases, Diagramas de Estado, Diagramas de Secuencia, Diagramas de Colaboración, Packages, intercambiando información por medio del importador y exportador en XML, ya en uso para intercambiar modelos o partes de él.
Es que la base "MDA oriented" de facto de Plex es fuerte por su capacidad de importar y exportar un esquema o un modelo, y fundamentalmente, por su capacidad de crear patrones abstractos aplicables solo con un cambio de configuración, a distintas plataformas, e integrarlas.

Gartner publicó en enero de 2003 un estudio donde destaca las herramientas basadas en ARAD (Architected RAD), como combinación de desarrollo rápido con soporte en el modelado de la arquitectura. Incluye a Plex como una herramienta ARAD, y analiza brevemente justamente estas características aquí discutidas, pesando y comparando tres tipos de herramientas: NeoRAD (Neo Rapid Aplication Development) , ARAD, y AMD (Architected Model Driven). Gartner analiza favorablemente el enfoque de la combinación de una arquitectura modelada, con el desarrollo rápido de aplicaciones. Es destacable la observación acerca de la viabilidad de AMD, puntualizando que un tercio abandona los proyectos AMD antes de dos años, y otro tercio congela los desarrollos a aquellos donde fue aplicado.

Una buena discusión de requisitos a verificar en una herramienta de modelado, aplicables en principio al UML, pero que no podemos limitar a él, está en Objects By Design

Nuevamente, Scott Ambler, como Martin Fowler, dan un enfoque crítico sobre Model Driven Architecture, que debe ser tenido en cuenta, aunque usted (o yo) no cambiemos nuestro interés por MDA. Lea su análisis en un estudio de distintas arquitecturas.

Más información sobre MDA puede encontrar en Cover Pages, con una lista de reportes y direcciones sobre el tema, incluyendo artículos de OMG, Ambrosio y otros. También la introducción y lista de referencias de la Universidad de Nantes, conducida por Jean Bézivin. Ahora, en su página, un conjunto bien organizado de referencias.