CASE: su evolución en dos décadas

Antecedentes y evolución de CASE

Un antecedente fundamental del concepto es el originado en las ideas de Information Engineering, desarrolladas por James Martin, y Clive Finkelstein. Martin particularmente inspiró varios de los proyectos posteriores, entre ellos Plex, que le debe varios aspectos, tales como la idea de los diagramas de acción. Una historia de la idea de Information Engineering, en palabras de Finkelstein, en SQL Summit. Otro papel de Finkelstein sobre IE, en IES (Information Engineering Services). Hoy son escasas las referencias a Martin, aunque el eco nos acompaña, como diríamos en Astronomía. Una referencia a Martin de Yourdon, en su sitio. En cuanto al CASE inicial, el artículo del SEI mencionado antes da un marco general de su alcance. Dave Hay en su sitio, dedica una página a los conceptos de IE, y su bibliografía, mas otro artículo con referencias comparativas entre distintos métodos de modelado, incluyendo IE. De la primera época provienen herramientas que construyen un repositorio capaz de constituír un modelo amplio (Synon 2, Platinum, Lansa), y otras enfocadas más bien en el desarrollo rápido de aplicaciones, lo que se denominó RAD (Rapid Application Development): Clarion, Genexus.

La consolidación del modelo de desarrollo orientado a objetos, y la posterior simplificación y unificación de métodos y notaciones, reenfocó a esa generación de productos, o dió lugar a otros nuevos. El Object Management Group aglutinó, a través de su evolución, a los principales actores interesados en establecer una notación estándar, y una interpretación coherente del paradigma: IBM, Microsoft, Oracle, HP, Sun, junto a Rational, Synon, Cayenne, Trireme, todos actores propietarios de ideas que fueron en general absorbidos por los participantes mayores de esta iniciativa. El trabajo de la OMG está, por su propia conformación, destinado a sufrir un desarrollo irregular, ya que el objetivo de mejorar la construcción del software coexiste con la competencia comercial entre algunos de sus participantes. Así, sus miembros varían en su adhesión a través del tiempo, y nuevos participantes reemplazan a otros. No obstante, la asociación sigue constituyendo una de las instituciones que más fuertemente contribuyeron a la consolidación de una base común para la construcción de software en forma racional, habiendo sido capaz de definir un grupo de estándares tanto en la notación y lenguaje de modelado, como en el esquema de construcción de aplicaciones.

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".