Angel López, a quien leo habitualmente con mi Google Reader, está desarrollando varios artículos sobre su emprendimiento
AJGenesis, al que tipifica como generador de aplicaciones. Su idea es muy familiar para el universo de desarrollo basado en modelos, en términos generales. Ángel establece estas premisas para crear un generador de código:
¿Qué le pediríamos entonces, a un generador de código? Gran pregunta, intentemos algunas respuestas:
- Que genere código que hubiéramos generado nosotros: si genera código inentendible, estamos en mal camino. Ese es el problema de varios wizards y demás herramientas: hacen lo que ellas quieren, no lo que nosotros queremos.
- Que genere cualquier texto que nos imaginemos que necesitamos: no basta que genere lo que el generador de código decida. Debe ser lo bastante flexible, para que podamos generar lo que querramos: desde una simple entidad, a un mapeo de Hibernate, desde una página web, hasta un mensaje de Windows Communication Foundation, desde el archivo de configuración de Struts, hasta el interminable ejb-jar.xml que nos pide el JBoss versión 17.84 que tengamos el año que viene.
- Que parta de un modelo simple, o compuesto, pero libre: no que parta de una base de datos, y sólo genere entidades y mapeadores. Necesitamos más flexibilidad. Ya vimos los que nos pasa en la vida real: todo cambia, necesitamos multitud de artefactos. Cualquier inversión en un generador de código que no permita incluir un modelo libre, me parece riesgosa. Creo que como prueba ácida, le pediría a un generador, que permita, desde un modelo libre, generar todo programa "Hello, World" que se nos ocurra. Si una herramienta no puede obtener ese resultado, estamos en el horno.
- Que permita escribir los templates, plantillas que querramos, y generarlas en grupo, en serie, en paralelo, o como querramos. Tanto el orden y enumeración de artefactos a generar, como las plantillas, como la toma de decisiones (generar de tal forma o no), debe estar bajo control del utilitario, y bajo control nuestro.
- Que permita generar desde un modelo, al cambiarlo, de forma fácil: si para generar los artefactos, por un cambio en el modelo, hay que dar cuarenta pasos, de nuevo estamos en problema. Compilar hoy es una tecla. Lo mismo debe ser la generación de código.
AJGenesis no tiene por ahora documentación, pero sí se puede tener una idea de su alcance a través de los ejemplos de uso en construcción, y los comentarios a éstos:
Quisiera en este artículo, comentar cómo funciona y se construye, uno de esos ejemplos. Permítanme primero repasar algo sobre el proyecto.
Está escrito en Visual Basic .NET 1.x, y es código abierto, pues viene con una licencia tipo BSD, que permite utilizarlo en cualquier proyecto que quieran. Se puede usar como librería, invocado desde nuestro proyecto, se puede invocar desde la línea de comando, o puede ser utilizado desde el poderoso NAnt (esto último me permitió organizar mejor las tareas que realiza el generador de código).
En la página del proyecto (y en el proyecto mismo) hay varios ejemplos, que generan código desde un modelo, usando plantillas. Los ejemplos generan código PHP, Java, JSP, VB.NET, C#, ASP.NET, y hasta scripts de base de datos y procedimientos almacenados. Quisiera destacar dos puntos:
- El modelo del que parte es totalmente definible por el usuario
- Las tareas y plantillas a aplicar son totalmente programables y controlables
Esto lo diferencia de otros generadores. Podemos construirnos nuestro propio modelo, y sus propias plantillas, para generar los artefactos de texto que prefiera. Otros sistemas parten de la base de datos, y sólo generan un grupo de artefactos de textos predefinidos (por ejemplo, POJOs, plain old java objects, o DAOs, Data Access Objects). Pero con AjGenesis puede generar el artefacto de texto que se nos ocurra.
[AJGenesis]Se basa en:
- Tener un modelo totalmente libre, que hoy está serializado en archivos XML.
- Plantillas que generan artefactos de texto
- Tareas programables, que cargan los modelos, ejecutan lo que uno quiera, y son invocables desde programas nuestros, desde la línea de comando, o desde un utilitario como el NAnt.
Entonces, se arma uno o varios modelos, que expresan lo que Uds quieran de su sistema, de forma independiente de la plataforma, y luego, adosándole modelos (uno o varios, de nuevo libres), que indican la tecnología a usar, y escribiendo las plantillas que Uds. quieran, generan lo que se les ocurra.
Ángel también explica su concepto a través de lo que No desea de un generador:
Primero: el generador sólo genera lo que él quiere. Típico de generadores "profesionales", que sólo producen lo que los creadores del generador imaginaron. Es difícil, y en algunos casos, imposible, extenderlo más allá de lo que hacen actualmente. Variante de esto: sólo genera código para entidades, o sólo para una tecnología, o sólo para EJB, o sólo para.... y puedo seguir. Claro, la herramienta soluciona el problema, y al comienzo estamos chochos de haberla encontrado. Pero advertiría desde ahora, que encontrarán limitaciones.
Segundo: el generador sólo parte de un modelo predeterminado (típicamente de una estructura de tablas de base de datos). Creo haberlos convencido que hay más bajo el sol que generar entidades y mapeadores. Hay colecciones inmensas de artefactos que tenemos que generar en cualquier sistema no trivial. Y seguirán apareciendo, por lo menos, en el futuro cercano. Si el generador sólo está pensado para partir de un modelo determinado, nos limita en lo que podemos pedirle. La historia nos ha mostrado, que siempre necesitamos algo más.
Tercero: el generador es cerrado, no se puede aprovechar e integrar en sistemas nuestros, o no entrega el código de base, o no permite armar plantillas y demás auxiliares.
Puedo seguir enumerando problemas. Mencionemos uno más: hay quien menciona que utilizó generadores de código, pero sólo lo usa para generar el código inicial de un sistema, y luego ya modifica el código generado, y no puede regenerar sin perder los cambios que hizo. Sugerencia: pongan en claro qué artefactos se generan automáticamente, y cuáles son los generados manualmente. Cuando Uds compilan un ejecutable, y necesitan cambiar un algoritmo, no van y cambian los bits del .exe. No: van al modelo, al lenguaje de programación, lo cambian y compilan de nuevo. Lo mismo deberíamos conseguir algún día, con generación de código. Como no podemos generar todo, debemos tener la disciplina de decidir cuáles artefactos son generados por el utilitario, y cuáles son los artefactos nuestros. En algunos casos, en los repositorios de código, en un CVS, cuando se trabaja en grupo, NO SE GUARDA lo generado automáticamente: solamente se guarda el modelo, y lo generado manualmente. Esto refuerza la responsabilidad de no tocar ese código automático: cualquier cambio manual que hagamos sobre ellos, no se guardará en el repositorio común.
(...) De alguna forma, un generador de código ideal no estará atado a una tecnología. Siempre habrá alguna "better mousetrap", siempre alguien inventará alguna nueva forma de hacer algo, siempre habrá un ruso con insomnio, o un hindú sin novia, que no tiene otra cosa que hacer que crear algo nuevo, ya sea en forma de librería, framework, patrón, o estilo arquitectónico. Un generador de código debe ser agnóstico de la tecnología, de las modas, de las soluciones actuales y futuras.
El generador de código que adoptemos, debe poder adaptarse a lo que querramos hoy y mañana y pasado mañana. La estrategia es: no importa la tecnología, el patrón o el framework que aparezca, nuestro generador deberá aprovecharse de lo que surja.
Estas premisas son familiares. Ángel propone una vía de trabajo que es la preocupación de la actual generación de creadores e investigadores de herramientas para el desarrollo de software "industrial". (Otra vez habrá que explicar qué significa esto?). Me interesa, y aunque mi disponibilidad de tiempo es menor que cero, trataré de seguirlo. Me interesa en la medida que escucho "plantillas", "scripts", "modelos"...
Diría que es importante no perder de vista que cuando hablamos de generadores hoy, no debe pensarse en las herramientas de la década del 80, rígidas y de alcance limitado. Tanto en el propósito como en la existencia real de las múltiples herramientas existentes, es posible ser expresivo, tener control, y soportar un ciclo de desarrollo más o menos completo.
Construír una herramienta es tarea de un equipo de desarrollo, probablemente más o menos numeroso. Seguiré con interés su propuesta.
Con Ángel hemos hablado, en cierta forma. Esta es mi primera nota sobre su trabajo, porque, si bien hace varios días
me dedicó dos palabras, esta mañana de sábado es mi primera disponible (esto no le importa a nadie excepto a Ángel en todo caso). Le escribiré este fin de semana, porque debo agradecerle su elogio, y porque quiero conocer más su proyecto.
Quisiera decir que un aspecto importante de su trabajo, como es el caso de
otros que trato de seguir, es el interés en progresar en la elaboración de herramientas de mayor flexibilidad y alcance en la generación de código.
En uno de sus artículos, Emilio, un desarrollador español, le apunta que le falta a Ángel referirse a MDA como sustento de su elaboración. El apunte es pertinente en términos generales, si queremos hablar de fundamentación de las condiciones de desarrollo de un generador. Pero muy en parte, porque MDA implica un estándar más o menos determinado (UML, OCL, un esquema definido de transformaciones). AJGenesis no parece estar en este marco. Y por lo demás, el estándar de la OMG está abierto y en evolución, y tiene sus puntos débiles: la expresividad de UML para desarrollar el detalle del comportamiento de un modelo quizá alcance, pero quizá también requiera un trabajo excesivo. En este sentido, siempre me pareció mejor la vieja solución de James Martin (diagramas de acción), que es la que empleo con Plex: un metalenguaje que describa en términos abstractos las acciones, suficientemente flexible y suficientemente detallable como para expresar en un párrafo lo que de otra manera puede significar trabajar duro en diagramas de actividad y de estados. Otro aspecto que no veo todavía manejado, y que es un desafío en muchos casos, es el versionamiento. MDA trata bien la variación por plataforma, pero no veo muy bien expresado el manejo de versión, salvo que no sea el abrir un nuevo modelo para cada versión requerida. Y otro aspecto, puntualizado correctamente por Greenfield con su Software Factory, es el seguimiento y mantenimiento del conjunto de dependencias de un proyecto.
En fin, el problema está abierto, y muchos, como Ángel, lo atacan con nuevas y mejoradas ideas y herramientas. Quiero mencionar de nuevo a Emilio, miembro desconocido para mí de una
empresa española (que tampoco conocía) que trabaja con MDA: es interesante seguir el laboratorio que existe en algunas universidades españolas sobre este tipo de proyectos, tanto en Málaga, como en Alicante, como en Valencia, para mencionar a quienes sigo más de cerca.
