A falta de módulos, buenos son los folders. (KBModule 1.0)

Después de algunos dias entretenido con la performance de un SQLServer que decidió empezar a consumir mas memoria y disco que lo habitual, volvi a dedicarme un poco al KBModule, para poder modularizar una KB.

La idea es poder ayudar a quien desarrolla a tener modulos mas independientes dentro de la KB y tener interfases bien definidas entre ellos. Que ganaré con esto?. El poder cambiar sin miedo los objetos internos de un modulo, sin afectar el comportamiento de los otros objetos de mi KB.

Nos pasa bastante seguido que al realizar un cambio en un determinado módulo, el comportamiento de otros objetos del sistema funcionan diferentes o dan error, sin haberlos cambiado directamente.

Bueno, pero bajando un poco a tierra la idea:

Que es el KBModule?.
Es un programa que toma una KB y las especificaciones (archivos SP0, para poder saber que objetos hacen select/update/insert/delete sobre una tabla) y carga esa información en una base de datos. Además permite clasificar de una forma particular y determinada los objetos en "Modulos", siendo un Modulo un conjunto de objetos que tienen una determinada funcionalidad. La forma de agrupar objetos que estamos usando ahora, es usar las carpetas (folders) en la raíz de la KB de GeneXus. En la imagen tendríamos tres módulos (SC, SK y TD)

Todos los objetos tiene pertenecen a un Modulo?
Si bien no todos los objetos no tienen folders, quiero que si pertenezcan a un modulo.
Los objetos que hoy no podemos (en 9.0 y anteriores) poner en carpetas son:

• Tablas
• Atributos
• Dominios
• SDT (en GX X, ya se pueden tener en carpetas)
  
• Grupos de Subtipos (en GX X, ya se pueden tener en carpetas)

En esta primera etapa defini que las tablas van a pertenecer al modulo de la transacción que la define y si hay mas de uno, toma la ultima.

Que es un objeto publico?
Son los objetos que pueden llamarse desde otro modulo. Son las interfaces o servicios que un modulo publica.

Como se indica que un objeto es publico?
Para saber cuales son los objetos públicos, desistí a usar un archivo de configuración para decir que objetos son públicos, y estoy usando carpetas con un texto en particular (es configurable) para definirlos. Cualquier folder que tenga el string "_PUBLICO", va a contener los objetos públicos del modulo al que pertenezca. Se pueden tener varios carpetas de objetos públicos por modulo.

Para definir tablas con publicas (o sea que puedan grabar, leer, actualizar y borrar de ellas desde varios módulos) hay que ponerle en la descripción de la misma el mismo texto.

Si defino una tabla como no publica, solo se podra acceder/modificar desde el modulo al que pertenece. Una excepcion a esta regla, son los accesos que se realizan en las transacciones por integridad referencial, que no va a ser tomada en cuenta para algunos reportes.

Que consultas se pueden hacer?.
Se pueden sacar consultas que indiquen cuales son las dependencias inadecuadas, por ejemplo:

• Objeto de un modulo, que llama a un objeto no publico de otro modulo (error)
• Objeto publico de un modulo, no llamado por nadie del exterior (warning)
• Objeto mal ubicados, si solo son llamados por objetos de un modulo (warning)
• Objetos publicos de un modulo (si mantengo el funcionamiento de estos objetos, se que no afecto en nada los demas objetos de la KB).
  
• Objetos que modifican (o borran, o insertan) una determinada tabla
• Dado un rango de fechas, ver que objetos públicos cambiaron y cuales son los modulos que pueden verse afectados por dicho cambio.
  

Y todo esto para que sirve?
Utilizando esta herramienta y su metodologia asociada, se pueden lograr mayor independencia entre los modulos y se puede hacer mas facil la instalacion de nuevas versiones de modulos, con mayor tranquilidad de no tener efectos secundarios no deseados.

Que falta?
Falta un montonazo, porque tengo que probar que esto mejora la mantenibilidad de sistemas, lo cual no es algo que pueda demostrarse en un corto plazo.
También hay que ver si es práctica y mantenible la metodología de definicion de modulos y si la herramienta es lo suficientemente agil como para ser usada en el desarrollo diario.

También falta tomar en cuenta otro tipo de dependencias/referencias, que hoy no tomo en cuenta, como son la que se produce cuando alguien define una variable basada en un atributo.
Se puede considerar que un atributo es privado y entonces no permitir que me definan variables desde otros modulos basadas en ese atributo.

Otra cosa que se puede hacer es graficar la relacion entre modulos. Este es un ejemplo de una KB real, que me gustaria poder simplificar bastante, para lograr que el diagrama no quede tan complejo. Ya voy a ver que tanto logro.


El futuro.
Todo lo anterior es valido para GeneXus 9.0 (y 8.0 tambien). Para la version Genexus X, la cosa esta un poco mas avanzada y fuentes generalmente muy bien informadas me comentaron que vamos a tener novedades de temas relacionados con esto, en la versión Cardal, lo cual me pone muy contento, pues creo que va a ayudar a que todos tengamos mejores sistemas. Supongo que en el Encuentro Internacional de Usuario GeneXus, tendremos alguna charla que hable de algun tema relacionado con esto.

Los modulos (o como quieran llamarlos) van a poder usarse para varias cosas mas, como ayudar al deployment, testeo, capacitación y otras etapas del ciclo de vida de la aplicación.

Por si alguien le interesa, cuando este terminado, va a poder ser bajado/usado/probado. Lo migré hace 2 dias a la version U2 de la GeneXus X y estoy teniendo algunos problemillas que espero solucionar pronto.