A falta de módulos, buenos son los folders.

En el post Modularizando una KB, planteo el problema de tener una KB dividida lógicamente en módulos, donde los cuales pueden interactuar entre ellos a traves de interfaces conocidas (y controladas) y poder evitar (o al menos informar) la utilización de objetos "privados" de mis módulos.

Que ventajas tiene este enfoque?.
El tener bien definidos los módulos dentro de una KB y sus interfaces (objetos públicos) permite independizar el desarrollo de cada uno de estos módulos, haciendo posible que cada uno de ellos se desarrolle/testee por separado, aumentando asi mucho la productividad.
También se van a necesitar menos horas en la integración en el armado de la solución, pues deberían existir menos problemas.

Si soy el desarrollador de un modulo, y tengo definido todos los objetos que alguien puede invocar desde afuera de mi módulo, voy a poder cambiar la implementación de todos los objetos de mi modulo, siempre y cuando no cambie el comportamiento de los objetos interfaz (objetos públicos).

Que se necesitaría para poder implementarlo?.
Se necesita tener una forma de definir los módulos. Como en GeneXus, aun no existe el concepto de módulo (sistema, paquete o como le queramos llamar), en Concepto hemos decidido usar los folders que están en la raíz de la KB para dicho fin. Si tengo un folder llamado Contabilidad, en la raíz de la KB, todos los objetos que están bajo dicha carpeta o sus sub-carpetas son considerados del modulo Contabilidad.

También se necesita poder definir cuales son los objetos públicos de dicho modulo y esto se logra con un archivo XML que se guarda en el directorio de la KB.

Poco digno y primitivo, pero nuestro y efectivo.

De esta forma, a traves de un programa llamado KBModule, se pueden detectar determinadas inconsistencias en este enfoque. Va a servir para GeneXus 8.0 y GeneXus 9.0 y lo estoy terminando de desarrollar.

Ahora, surge otra pregunta:
Como se determina las interfaces de un sistema?.
Hay objetos que no ofrecen mayores dudas, pues por ejemplo queda claro cuando un procedimiento, transacción, webpanel, workpanel puedan ser invocados desde otros módulos.

Ahora, la ausencia de un objeto modulo, hace difícil la determinación de la pertenencia a los mismos a todos los objetos que no tienen folders, por ejemplo: Tablas, SDT, programas externos , web services, styles, themes, dominios y atributos (pueden faltar algunos).

• Con las tablas, estoy usando una heurística donde defino la tabla con el mismo Modulo que tiene la primer transacción que la define. Puede dar cualquier cosa, pero es una aproximación razonable.
• Con los SDT, estoy viendo que objetos los referencias y si todos son del mismo modulo, puedo decir que son de ese modulo, sino quedaran con un modulo genérico. NO ME GUSTA ESTA SOLUCION, pero es lo mejor que encontre hasta el momento.
• Con los programas externos, los dejo como objetos de un módulo genérico.. siempre se considerarán públicos. Lo mejoraré en el futuro, porque se pueden negociar.
• Con la invocación a web services, tengo un problema, pues no quedan registrados en la Cross Reference y además en las variables quedan marcados como que son del tipo 255 (no ésta documentado) y no puedo saber que Web services es el invocado.
• Atributos y dominios por el momento quedaran como públicos. En el futuro se pueden incorporar para un análisis mas fino.

Y todo esto, para que sirve?
Con esta herramienta vamos a poder modularizar mejor nuestras KB, pudiendo cambiar sin temor los objetos internos de mi módulo y conociendo los servicios que mi modulo brinda a los demás.

Preparación de un KB para SOA.
Esto puede ayudar para mostrar/administrar cuales son los servicios que mi modulo brinda.

Detectar dependencias no deseadas.
Puedo listar todas las invocaciones realizadas desde otro modulo a objetos privados de mi modulo. Por ejemplo si alguien esta alterando los datos de una tabla, que está marcada como privada, seria un error. Esto debería realizarse a través de un procedimiento o bussines component de mi módulo.

Grants
Como requerimiento secundario, puedo generar un script con los grants necesarios para la ejecución de un determinado main, pues tengo todas las tablas leídas/actualizadas/borradas por el programa y todos los invocados por el.

El tema de para un poco mas, pero ya es un post demasiado largo.

PD: Se dice LAS folders o LOS folders?. Siempre saqué baja nota en las clases de spanglish.