En los últimos días, se han extendido dos o tres certificados de defunción; rápidamente se ha dado por muerto a SOA, y ahora (bueno, ya hace uno o dos años algunos teóricos darían por muerta alguna variante) también al desarrollo basado en modelos (MDA, MDD, MDE y otros semejantes). En la muy reciente Model Driven Software Network, se ha abierto una discusión sobre este asunto, que tiene la virtud de exponer los puntos débiles del paradigma, o estándar, según cuánto esté cada uno adherido al estándar MDA de OMG. La crisis económica sin duda empuja a la simplificación de costos, y esto alcanza a las "olas" de novedades tecnológicas: sólo lo que tenga verdadero valor quedará, o al menos, rebrotará.
¿Es MDD una ola comercial?. Claramente, no. MDD es la etapa actual (seguramente no la última) de esfuerzos comenzados hace quizá más de veinte años, con la aparición de las herramientas CASE. Puede extinguirse una rama de desarrollo, un punto de vista de cómo lograr el objetivo, pero la meta en sí ha sido reafirmada contínuamente por la industria y la comunidad académica. Puede incluso que se demore o estanque su crecimiento bajo las actuales circunstancias, pero no más.
Repasando la discusión en curso en The Model Driven Software Network, las principales objeciones van encaminadas particularmente al punto de vista MDA (Model Driven Architecture), y dentro de él, a la capacidad de UML de representar la dinámica de un modelo; UML, se afirma, es capaz de generar clases basadas en el modelo estático, pero luego es necesario completar el código generado escribiendo código que describa su conducta (behavioral). Así, Vlad Varnica afirma que el modelo UML suele ser abandonado tras la primera iteración ("The model driven and the iterative approach are not compatible"), porque la regeneración de código elimina el código manual, que debe ser reinsertado. Esta y otras participaciones en la discusión ponen el acento de las dificultades de adopción en este punto. Tiempo atrás, esta fue una objeción de los proponentes del modelo Software Factory (Jack Greenfield, Steve Cook, Keith Short), cuestionando en bloque la capacidad de UML para facilitar el modelado y la generación automática de código (En realidad, SF tampoco promovería simplemente la generación automática de código, sino una combinación de agentes, que no descartaría el código manual).
Creo haber comentado en distintas ocasiones que la herramienta que utilizo (Plex) no requiere centralmente UML; puede interrelacionarse con un modelo estático UML, pero no lo necesita: El modelo construído en su caso puede expresar igualmente su aspecto estático, pero, fundamentalmente, es capaz de expresar su aspecto dinámico dentro del modelo con toda la precisión que se necesite. En ocasiones puede requerirse código manual para acciones muy específicas, pero integrado de tal manera en el modelo, que no es afectado (no es sobreescrito) en una regeneración (una iteración). De tal forma, se logra un objetivo fundamental: que dada una aplicación, ésta sea expresada en el modelo de manera prácticamente completa. Esto tiene dos consecuencias muy importantes: es posible derivar del modelo la aplicación a distintas plataformas, y es posible modificarlo (sin temor a la regeneración del código).
¿Y a qué viene este comentario? A que el punto básico cuestionado a MDA/UML, que es su baja capacidad de describir las acciones, métodos, eventos, puede ser resuelta por alguna vía. En fin, que no se trata de un desarrollo en vía muerta, sino de un desarrollo que todavía debe encontrar el medio de resolver un obstáculo. Podríamos decir que uno de sus cuestionadores más agresivos del último tiempo, Software Factories, hoy está más comprometido que su escarnecido rival (MDA), a tal punto que los grandes críticos hoy vuelven a UML...
2 comentarios:
El articulo dice 'la regeneración de código elimina el código manual', esto no pasa en AndroMDA.
Correcto. Sería adecuado diferenciar los distintos casos que se presentan. También EMF preserva el código, y seguramente otros. Conozco el caso de AndroMda porque lo usan los colegas de I2E. Pero de todas formas persiste una dislocación entre código Java (u otro), y modelo. Uno es opaco respecto al otro. Que se preserve el código no evita que ese código ya no coincida con lo que el modelo expresa luego de un cambio, tampoco asegura que sea totalmente distorsivo del objetivo diseñado en el modelo, ni tampoco asegura coherencia entre declaraciones den uno u otro ambiente. Sin hablar de la posibilidad de introducir errores simples (tipeo, maluso de instrucciones).
Publicar un comentario