Reunión de Generación de Sistemas con AjGenesis

Ya había anunciado que el viernes pasado había desayuno de arquitectura, en el Microsoft User Group de Argentina. Agradezco desde acá a la gente del MUG por haberme dado la oportunidad de presentar este proyecto, y las ideas que me llevaron a implementarlo.

La reunión comenzó a las 9 horas y monedas, y seguimos casi hasta las 12hs, hubo charla informal post reunión, muy interesante.

Material del Desayuno de Arquitectura sobre AjGenesis

Para los que no conozcan sobre AjGenesis, mi “pet project” de generación de código, leer alguno de los “post”:

Generación de aplicaciones con AjGenesis
Generando código: Hello World con AjGenesis

Presentación

Pueden bajarse del material de la reunión, la presentación que usé, ya usada en una reunión del año pasado. Esta vez, usé los primeros puntos de esa presentación, y varios de los puntos ya escritos en

Sobre la generación de código

Así que acá agregaré algunos puntos adicionales, que no había pasado por escrito:

. La adopción de una variante del AjBasic como lenguaje de templates: motivada por la necesidad de tener un lenguaje de programación, no solamente una forma de expandir variables dentro de un template, o ejecutar algún for each sobre una lista de objetos del modelo. Creo que fue una buena elección, y siempre queda abierta la posibilidad de usar otro lenguaje para los templates. Con AjBasic tengo la posibilidad de tratar el modelo como un grafo de objetos (no solo como un árbol, como sería si trabajara con XML solamente), modificable, competable (puedo tomar decisiones y agregar elementos al modelo). Pequeñas cosas como

if not Project.Title then
    Project.Title = Project.Name
end if

o compleciones del modelo como

if Entity.Reference then
    Entity.Reference = GetEntity(Entity.Reference)
end if

(donde Entity.Reference inicialmente tiene solo el NOMBRE de la entidad referida, y luego lo reemplazo por la entidad completa, para armar un grafo de objetos, desde un árbol inicial de objetos).

son posibles al haber elegido ese camino.

- El modelo libre: mostré el ejemplo del Hello World, y cómo desde ese modelo se puede generar código o artefactos de texto, llamada desde consola, la ejecución de pequeñas tareas en AjBasic, y la integración con NAnt.

- Ejemplos de modelos y templates: me basé en lo que ya estaba escrito en AjGenesisExamples3.zip y Generación de aplicaciones con AjGenesis donde se muestra un ejemplo. No es que AjGenesis se base sobre “ese modelo”, sólo son ejemplos de distintos proyectos, sobre el mismo modelo, que se concentra en representar entidades, y templates que generan Java, Java con Hibernate, VB.NET 1/2, CSharp 1/2, business entities, o implementaciones con conceptos de Domain-Driven Desing.

- Uso de XML para describir el modelo: usando un XML libre, no sujeto a un esquema, que no “duela los ojos” leerlo, nos permite ir agregando elementos al modelo, sin tener que modificar una base de datos, o cambiando un esquema con el que hay que cumplir a rajatabla. Creo que ha sido una decisión que ha permitido que cada uno experimente con distintos modelos, rápidamente. Más sobre el tema más adelante en este post.

- Prototipos y semillas: mostré cómo el AjGenesis puede generar sus propios modelos, desde modelos más sencillos. El ejemplo, basado en el modelo de AjGenesisExamples2/3, pasa, de una simple lista de entidades, cada una prototípica de alguna categoría (“kantiana” la llamé ;-) como persona, documento, lugar, empresa, evento, a un modelo más completo, con armado del directorio del proyecto, el archivo que lo describe, los archivos de entidades, los archivos de tecnología, y los scripts del NAnt, listos para usar.

- Caminos a encarar: como una aplicación web que permita exponer los servicios de AjGenesis, el uso de inteligencia artifical, pasar a un modelo ASP (Application Service Provider), integración con IDEs (por ejemplo, un custom tool para Visual Studio 2005, o un plugin para el Eclipse).

- CodePlex: Ahora el proyecto está en Codeplex y ahi tenemos un foro para plantear dudas, discusiones y problemas encontrados.

- Version 0.5: En desarrollo, apenas comienza su ciclo, pueden encontrarla en AjGenesis-0.5.zip, está armada para .NET 2.x. Todavía tengo que incluir los créditos, a Marcelo Fassi y su compañero Fabián, por el código para soportar comentarios en el modelo XML, soporte de acentos en los templates. De mi parte, el mayor cambio ha sido recompilarlo a .NET 2.x, pero este fin de semana, agregué el soporte de respetar código manual (escrito por el programador) entre una y otra generación del artefacto de texto. Espero bloguear en estos días, sobre estas novedades.

Discusión

Durante la charla, se plantearon varios temas, entre los asistentes. Tuve la alegría de conocer en persona a Fabio Maulo, activo colaborador del proyecto NHibernate, al que conocía de la lista nhibernate-hispano, administrada por él y Darío Quintana. Ya estámoslo convenciendo para que dé una charla magistral sobre NHibernate en el MUG.

- Manual: fue un tema pedido, la necesidad de tener un manual. Hasta ahora, están los artículos mencionados al principio de este post, para ir entendiendo algunos puntos. Pero es necesario tener un manual, por ejemplo, del lenguaje AjBasic, o que explique algunos usos de las tareas de los ejemplos. Tengo un sistema de documentación en HTML, inspirado en el DocBook (dado un formato inicial, generar la documentación), pero sólo escritas cinco páginas. Tácticamente, para suplir esta falta, voy escribiendo artículos sobre el uso del sistema. Carlos Peix sugirió usar la implementación de la gente de Velocity: parece una interesante implementación sobre DocBook.

- Lista de Generación de Código: Me alegró ver a Luis Petek, Carlos Santos, y Alejandro Nelis, munidos de sus respectivas notebooks, trabajando con templates y generando código con AjGenesis, y estudiando el tema. Armaron una lista donde se discuten estos temas, no sólo de AjGenesis, en Google Groups:

http://groups.google.com/group/codegeneration?hl=es

Tienen armado un template para SQL Server 2005, y otro con persistencia usando Enterprise Library. Notable, muchas gracias!

Ellos plantearon el tema de tener un repositorio de templates. Siempre pienso en ese, en especial viendo a otros generadores de código. Pero no pensé que hiciera falta todavía. Pero voy viendo que puede ser la hora de exponer algo. Otro tema a meditar, para elegir un camino.

- Esquema en modelo: Fabio Maulo dejó un comentario muy amable en el post Desayuno de Arquitectura con AjGenesis. Reproduzco su tema planteado acá:

XSD?

Me parece que el tema de “XSD o no” entra poco en los objetivos de AjG. Como mucho, AjG puede tener un servicio mas que es lo de aceptar unos XSD (o el nombre del folder donde estan disponible) y chekear los XMLs ante de empezar a aplicarle los templates. Mas que eso a AjG no le veo.

Despues de la Genesis sea los animales que los hombres se organizaron en sociedades que conviven dandose algunas reglas. Los XSD lo veo como las “reglas” que se da una determinadad comunidad de utilizadores de AjG para compartir  XML de un determinado dominio o de una determinada forma de definir el dominio.

Distintas comunidades podrán eleguir distintos XSD. Por lo menos creo que eso es lo que va a pasar…

Despues es probable que la evolución sea similar a la que hubo con los lenguajes y los IDE. Yo tambien he trabajado con el “vi” pero no es que este muy entusiasmado con eso.

Usando XSD tendriamos un control “temprano” mientras escribimos el domain y hasta se podría  hacer un plug-ins para varios IDE para escribir los templates… quiero decir que si existe el XSD podríamos usar el IDE para chequear que exista un determinado tag y sobre todo que siga funcionando el intellisense para el lenguaje por el cual estamos escribiendo el template.

Ciertamente, el tema XSD o algún otro esquema, es un tema a meditar. Tengo un “spike” de un esquema expresado en… chan chan… un modelo de AjGenesis… :-). Esto permitiría expresar el esquema del modelo, y además, generar, por ejemplo, páginas web de actualización del modelo. Pero es por ahora sólo una idea.

Mantener código manual: Se discutió la necesidad de mantener código manual, dentro de una solución, o incluso, dentro del mismo artefacto de texto. En este último caso, ya pude aportar un intento de solución el fin de semana, en la versión 0.5 que mencioné arriba. También se mencionó de mantener lo manual por subclase, o en clases parciales, en el caso de .NET. Claudio Meschini comentó sus ideas sobre generar desde el código mismo, y este fin de semana, posteó sobre templates compilados. Creo que puedo implementar algo así en AjGenesis directamente, pero me parece que se complica incrustrar ciclos en esos textos. Por lo que entendí, Claudio plantea tener un código, compilable, y de ahí obtener el template. Se discutió el tema al terminar la charla, y es interesante. Me recordó lo que hacía en los 80, con mi sistema de generación de código C: a un código que compilaba, le pasaba una macros de editor, para cambiar, por ejemplo “AltaCliente(Cliente c)” por “Alta${Entity}(${Entity} c)” (me confunde el término template compilado, no sé si entendí bien a Claudio: lo que estoy describiendo, es un código que compila, que luego puede usarse para generar el template genérico). Vean también el proyecto de Claudio Quetzal: si lo tuviera que hacer en Java, apelaría al proyecto Anaxia, dentro de Velocity.

Lógica de negocio: ¿cómo expresarla en el modelo? Gran tema, discutido en parte en la charla, y en la reunión post charla. Yo creo que hay dos caminos, uno más cercano que otro:

1- Colocar código para un lenguaje, en el propio modelo (algo como

<Method… >
  <CodeImplementations>
   <CodeImplementation Language=”VBNET”>
… codigo VBNET…

   </CodeImplementation>
   <CodeImplementation Language=”Java”>
… codigo Java …
   </CodeImplementation>
  </CodeImplementations>
</Method>

2- Definir más abstractamente la lógica, mediante:

2a)- Seudo lenguaje, podría ser un AjBasic, y trasladores de ese lenguaje al lenguaje destino

2b)- Modelo en XML, como en los sistemas de Rule Engines, que luego se vuelca al sistema (no sólo lenguaje) destino

Creo que el camino 1, es el más fácil, y pragmático. Y más aplicable en el caso de tener varios sistemas, pero con un solo lenguaje de implementación, con distintas lógicas de negocio para distintas versiones. Las distintas versiones de lógica, se podrían mantener como una parte variable del modelo: hoy generamos con la lógica A1, y mañana cargamos el modelo con la lógica A2, de manera similar a como se carga hoy en los ejemplos a la tecnología.

El camino 2a, es interesante. Pero tenemos que discutir qué es “la lógica de negocio”. No necesariamente la lógica va a un método, puede ser que influya en el esquema de definición de un workflow, en un XML de definición de ese workflow, y demás. Pero si es código a incrustar, se puede pensar en el 1, y el 2a.

El camino 2b, es más abstracto. Pero hay que tener claro exactamente que le pedimos como capacidad a la implementación de la lógica de negocio.

Claudio Meschini mencionó LOP Lenguajes orientados a programación. Puede estudiar:

http://www.onboard.jetbrains.com/is1/articles/04/10/lop/index.html
Language-Oriented Programming talk with Neal Ford

Generando el modelo: Recordé en algún momento, un trabajo del bueno de Darío Quintana:

Reflexión + Generación de Código = Modelo para AjGenesis

Esa es la idea: generar el modelo pragmáticamente, desde donde sea. Fabio sugirió levantar los .hbm de un NHibernate, y usarlo como parte de modelo. No se me había ocurrido, pero es posible e interesante: debería cargar un XML cualquiera como objeto y permitirlo vivir en el modelo (eso implica una nueva forma de cargar un XML en memoria para AjGenesis: al contrario de lo que hace ahora, deberá distinguir entre atributo y elemento hijo de un nodo, pero es un cambio que puedo hacer sin afectar la forma actual de carga de modelo).

Conclusión

Excelente que la gente se haya enganchado en el tema! Creo que, de las ideas y discusiones planteadas, las prioridades serán:

- Manual: indispensable para poder explicar el uso del sistema

- Mantenimiento de código manual: algo avancé en la nueva versión 0.5

- Comunidad: ya se va formando. Creo que no hay que forzar las cosas, e ir viendo de alimentar el grupo de generación de código, y seguir paso a paso.

- Modelado de lógica de negocio: interesantísimo tema, con varios caminos a seguir.

De nuevo, gracias a la gente del MUG por haberme permitido hacer esta reunión. Y a todos los que vinieron, gracias! Espero que les haya servido, para ver alguna alternativa más sobre el fascinante tema de creación de software.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com/

This entry was posted in 1389, 1390, 1392, 2643, 6145. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>