Modularizando una Knowledge Base
En los días anteriores me tocó participar con Ruben, Alejandro y Gustavo en las instalación de un sistema en el exterior.
Cuando uno está con amigos en el exterior, las noches se convierten en ámbitos de discusión de temas variados. Iba a decir tertulia, pero no me gusta esa palabra.
Uno de los temas que discutimos, era la de como forzar el tener aplicaciones GeneXus, mas modularizadas. La idea era poder definir un conjunto de funcionalidades dentro de un módulo y que la funcionalidades de dicho modulo solo pueda ser accedido a ella a través de interfaces conocidas y dominadas.
A mi me gustaría contar con :
Una forma de agrupar objetos en módulos.
Por defecto, debería ser el nombre de la carpeta raíz. También se deben poder incluir las TABLAS como objetos del modulo.
Marcar APIS/Objetos publicos.
Poder indicar que algunos objetos pueden ser invocados desde fuera de mi modulo. Por ejemplo si tengo un modulo de desposito/stock, debo habilitar que la funcion que da el saldo de de un producto, como que es invocable desde fuera de dicho modulo.
Si quiero que una tabla pueda ser accedida por objetos externos al modulo, debo marcarla como publica.
Avisar cuando se violan las interfaces.
Hacer una consulta que permita identificar todos los objetos que invoquen a objetos fuera de su modulo, que no sean publicos.
Tambien deberian verse aquellos objetos que hacen for each/new/delete sobre tablas que no son de su modulo y que las tablas no sean publicas.
Si esta validación se pudiera hacer en el momento de la especificación estaría muy bueno. **
Diagrama de llamadas entre modulos.
Se pueden mostrar las llamadas entre los modulos, pintando de rojo las llamadas invalidas (o sea las llamadas a objetos no publicos desde afuera del modulo).
Estas funcionalidades podrían implementarse en una GeneXus Extension. Tengo ganas de hacerla pues no es muy compleja y puede ayudar bastante a mejorar nuestras aplicaciones.
** Alejandro también proponía que si alguien especificaba un objeto con un for each sobre una tabla que no estaba en el modelo le diera un choque eléctrico, pero no creo que sea una feature para la primera versión.
Cuando uno está con amigos en el exterior, las noches se convierten en ámbitos de discusión de temas variados. Iba a decir tertulia, pero no me gusta esa palabra.
Uno de los temas que discutimos, era la de como forzar el tener aplicaciones GeneXus, mas modularizadas. La idea era poder definir un conjunto de funcionalidades dentro de un módulo y que la funcionalidades de dicho modulo solo pueda ser accedido a ella a través de interfaces conocidas y dominadas.
A mi me gustaría contar con :
Una forma de agrupar objetos en módulos.
Por defecto, debería ser el nombre de la carpeta raíz. También se deben poder incluir las TABLAS como objetos del modulo.
Marcar APIS/Objetos publicos.
Poder indicar que algunos objetos pueden ser invocados desde fuera de mi modulo. Por ejemplo si tengo un modulo de desposito/stock, debo habilitar que la funcion que da el saldo de de un producto, como que es invocable desde fuera de dicho modulo.
Si quiero que una tabla pueda ser accedida por objetos externos al modulo, debo marcarla como publica.
Avisar cuando se violan las interfaces.
Hacer una consulta que permita identificar todos los objetos que invoquen a objetos fuera de su modulo, que no sean publicos.
Tambien deberian verse aquellos objetos que hacen for each/new/delete sobre tablas que no son de su modulo y que las tablas no sean publicas.
Si esta validación se pudiera hacer en el momento de la especificación estaría muy bueno. **
Diagrama de llamadas entre modulos.
Se pueden mostrar las llamadas entre los modulos, pintando de rojo las llamadas invalidas (o sea las llamadas a objetos no publicos desde afuera del modulo).
Estas funcionalidades podrían implementarse en una GeneXus Extension. Tengo ganas de hacerla pues no es muy compleja y puede ayudar bastante a mejorar nuestras aplicaciones.
** Alejandro también proponía que si alguien especificaba un objeto con un for each sobre una tabla que no estaba en el modelo le diera un choque eléctrico, pero no creo que sea una feature para la primera versión.
Creo que la extension debería incluir de partida el choque eléctrico ya que sería la feature más frecuentemente usada.
ResponderBorrarSi necesitan de mi ayuda les hago la interfaz para implentar el choque eléctrico. De cuánto estaríamos hablando 220 o 380? ^_^
Muy buena idea.
Sauron:
ResponderBorrarTe tomo la palabra.
La spec dice:
for each sin update -> 110
for each con update -> 220
new/delete -> 330
Estamos considerando que en vez de un choque electrico de 330 V, se podria emitir una cancion de Natalia Oreiro a todo volumen.
Se evaluara en los test de usabilidad cual de los dos metodos brinda mejores resultados.