Administrar la Base de Conocimiento MGx

Elementos básicos

Modularización

Fácil integración de las Bases de Conocimiento

Estándar para Nomenclatura

Introducción

Nomenclatura sugerida

Administración del conocimiento común y tipos de Bases de Conocimiento

Tipos de Bases de Conocimiento

Carpetas dentro de las Bases de Conocimiento

Administración de las Bases de Conocimiento

 

Elementos básicos

A continuación se presentan algunos elementos básicos para administrar las Bases de Conocimiento.

A tener en cuenta:

Como contemplar en el trabajo con GeneXus los temas anteriores

Modularización

Necesidad

La necesidad de dividir el sistema en módulos surge del tamaño del problema y de poder habilitar varios frentes de desarrollo paralelos.

Objetivo

Se deben lograr ambientes de desarrollo lo más cerrados posibles con el fin de maximizar la productividad, no afectar el desarrollo de otros módulos y permitir liberar productos al usuario en forma incremental.

Criterios

Los criterios para modularizar son los siguientes:

Relación con las Bases de Conocimiento

 

Fácil integración de las Bases de Conocimiento

Problemas

Los problemas surgen en el momento que se integran dos Bases de Conocimiento que comparten cierta información. Al proceso de integrar dos o más Bases de Conocimiento le denominaremos de aquí en adelante como Consolidación.

Entonces al consolidar Bases de Conocimiento pueden surgir errores como:

Sugerencias para minimizar los problemas de integración:

 

Estándar para Nomenclatura

Introducción

Se establece nomenclatura para Objetos, Atributos, Tablas e índices, variables.

Razones para usar una nomenclatura predefinida.

Nomenclatura sugerida

A continuación se sugiere un estándar para nomenclatura, en el estándar no se indican longitudes para los nombres ya que esta característica depende de la versión de GeneXus con que trabaje.

Objetos:

Identificador_módulo +(Identificador_submódulo)+ Identificador_objeto

 

Identificador_módulo

Es un identificador del módulo al que pertenece el objeto. Se sugiere un nombre mnemotécnico que identifique únicamente al módulo en el sistema.

Identificador_submódulo

Es opcional y surge si existen submódulos. Se sugiere un nombre mnemotécnico que identifique únicamente al submódulo dentro del módulo al que pertenece.

Identificador_objeto

Es el identificador del objeto dentro del módulo o submódulo si existiera este último.

Según la cantidad de objetos por módulo o submódulo se sugieren dos alternativas:

Pocos objetos: el Identificador_objeto puede ser un nombre mnemotécnico o numérico.

Muchos objetos: el Identificador_de_objeto se sugiere numérico.

Ejemplo:

El objeto Productos del módulo Facturación

En el caso de nombre mnemotécnico: FAPR ó FAPROD

En el caso de nombre numérico: FA01 ó  FA0001

 

Si existieran los submódulos Facturación interna, Facturación externa

FAINPR  o  FAINPROD,  FAEXPR o  FAEXPROD

FAIN01   o  FAIN0001,    FAEX01  o   FAEX0001

Atributos:

Identificador_objeto_mnem + Categoría + Calificador + Calificador + Texto_libre

 

Identificador_objeto_mnem

Identificador mnemotécnico del objeto (aunque el objeto en sí se haya nombrado con números).

Categoría

Sustantivo que identifica al atributo.

Calificador

Calificador para el atributo.

Texto_libre

Un texto cualquiera.

 

Ejemplo:

La fecha de vencimiento del producto definido en el objeto FA01 (objeto producto), se nombraría:

PrdFchVto    

Prd – Identificador del objeto

Fch – Categoría

Vto – Calificador

 

Uso de dos calificadores:

PrdPrcMaxCmp – Precio máximo de compra del producto (Max y Cmp)

PrdPrcMinVta - Precio mínimo de venta del producto (Min y Vta)

Tablas e índices (file views):

Identificador_objeto_mnem + Calificador1 + Calificador2

 

Identificador_de_objeto_mnem

Identificador mnemotécnico del objeto (aunque el objeto en sí se haya nombrado con números).

Calificador1

Calificador para la tabla, índice o file view.

Calificador2

Calificador para la tabla, índice o file view.

 

Administración del conocimiento común y tipos de Bases de Conocimiento

Tipos de Bases de Conocimiento

Para administrar el conocimiento común y la integración de Bases de Conocimiento se sugiere la creación de tres tipos de Bases de Conocimiento, que son los siguientes:

Carpetas dentro de las Bases de Conocimiento

Organización

Dentro de cada BC se crea una carpeta con el nombre del módulo (Folder en los términos de GeneXus), y submódulo si existiera, con el fin de que al consolidar esa BC  en la BC Consolidada se genere un Folder por cada BC, que se corresponde con un módulo o submódulo.

Si un módulo se divide en dos submódulos y éstos se desarrollan en Bases de Conocimiento diferentes, en cada BC debe existir un Folder con el nombre del módulo (debe llamarse de idéntica forma en ambas Bases de Conocimiento) y bajo él un Folder con el nombre de submódulo que corresponda en cada BC.

Debajo de la última carpeta, de módulo o submódulo, se pueden generar más Folders con el objetivo de organizar los objetos dentro del módulo o submódulo.

Ejemplos:

Crear dentro del módulo o submódulo un Folder por funcionalidad y bajo él crear Folders por tipo de objetos, uno para transacciones, otro para procedimientos, otro para workpanels, etc.

Para aclarar éstos conceptos:

En la Base de Conocimiento Núcleo debe existir un Folder llamado Núcleo y bajo él todos los objetos de dicha BC organizados como se crea conveniente.

En la Base de Conocimiento de Aplicación “Módulo 1” debe existir un Folder llamado Módulo 1 y bajo él los objetos de dicha BC organizados como se crea conveniente.

De esta forma al consolidar la BC Núcleo y la BC “Módulo 1” en la BC Consolidada en ésta última se crean dos Folder uno llamado Núcleo con todo el contenido de la BC Núcleo y otro llamado Módulo 1 con todo el contenido de la BC de Aplicación Módulo 1.

Ventajas

Ventajas de esta organización:

·         Al consolidar varias BC quedan organizadas en carpetas diferentes en la BC donde se consolidan.

·         Se conoce a que BC pertenece cada objeto.

 

Administración de las Bases de Conocimiento

La primera BC que surge en el proyecto es la BC Núcleo conteniendo objetos que describen el conocimiento común a todos los módulos del sistema.

Todas las demás BC de Aplicación y BC Consolidada deben contener la información de la BC Núcleo. Esa información en dichas BC es solamente para lectura. La información de la BC Núcleo no se modifica desde dichas Bases de Conocimiento.

Administración de la BC Núcleo

Contenido de la BC Núcleo

En la BC Núcleo se incluyen transacciones que definen estructuras de uso común entre todos los módulos del sistema, objetos de uso común que operan sobre las estructuras de uso común como son: procedimientos comunes, work panels que permiten seleccionar datos de las estructuras de uso común, data views sobre tablas externas que se deban definir en un lugar único, reportes sobre las estructuras comunes.

Si hay objetos que se comparten solamente entre algunos módulos, y no entre todos, pueden dar origen a subnúcleos.

En este caso bajo el Folder Núcleo de la BC Núcleo se creará un Folder para el Núcleo Corporativo o General, que es el compartido por todos, y un Folder por cada subnúcleo que surja.

Generalmente los objetos que se comparten entre algunos módulos definen las interfases entre dichos módulos. A diferencia de los que se comparten entre todos los módulos que son objetos que definen las estructuras generales a todo sistema.

Modificar o agregar objetos

Si es necesario modificar un objeto que pertenece a la BC Núcleo o agregar un objeto a dicha BC, es el responsable de la BC Núcleo quien lo modifica o agrega en la BC Núcleo y luego se exporta y consolida en todas las demás BC que lo usan.

Un objeto que pertenece a la BC Núcleo no se modifica desde las Bases de Conocimiento que lo contienen.

Renombrar objetos

Si es necesario renombrar un objeto que pertenece a la BC Núcleo se debe notificar el cambio de nombre a los responsables de todas las Bases de Conocimiento que contienen a la BC Núcleo, para que se renombre el objeto de dichas Bases de Conocimiento.

Esto se aplica para el borrado de un objeto de cualquier BC que está contenida en otra.

Borrar objetos

Si es necesario borrar un objeto que pertenece a la BC Núcleo se debe notificar su borrado a los responsables de todas las Bases de Conocimiento que contienen a la BC Núcleo, para que se borre el objeto de dichas Bases de Conocimiento y luego borrarlo de la BC Núcleo. De esta forma se asegura que en las Bases de Conocimiento que contienen a la BC Núcleo no queden objetos que ya no están en la BC Núcleo.

Esto se aplica para el borrado de un objeto de cualquier BC que está contenida en otra.

Un mecanismo sugerido

Un mecanismo para transmitir a los responsables de cada BC cuales objetos se deben borrar es el siguiente:

  1. Cuando se quiere borrar un objeto de la BC Núcleo se mueve dicho objeto al Folder que contiene los objetos a ser borrados, en lugar de borrarlo.

  2. Cada vez que se exportan objetos de la BC Núcleo a las demás BC se exporta también el Folder que contiene los objetos a ser borrados.

  3. El responsable de cada BC consolida los objetos enviados de la BC Núcleo, entre los cuales se encuentra el Folder que contiene los objetos a ser borrados. Borra dichos objetos y notifica de su borrado al responsable de la BC Núcleo.

  4. El responsable de la BC Núcleo luego de obtener todas las notificaciones de borrado de las BC que contengan a la BC Núcleo, borra los objetos del Folder que contiene los objetos a ser borrados.

Ambientes de trabajo

La BC Núcleo debe tener dos ambientes de trabajo:

 

Administración de las Bases de Conocimiento de Aplicación

Contenido de la BC de Aplicación

Es una BC que contiene todos los objetos de un módulo o submódulo y permite desarrollar y probar una aplicación determinada en un ambiente ágil y realizar ciclos de prototipación muy dinámicos.

En esta BC se consolidan:

Modificar o agregar objetos

Borrar objetos

Ambientes de trabajo

La BC de Aplicación debe tener dos ambientes de trabajo:

 Administración de la Base de Conocimiento Consolidada

Contenido de la BC Consolidada

Ambientes de trabajo

La BC Núcleo puede tener tres ambientes de trabajo:

A continuación se muestra gráficamente la metodología de administración de las Bases de conocimiento.

Fig. 1 Administración de Bases de Conocimiento

 

BC Consolidada para pruebas

Para realizar pruebas sobre la BC Consolidada se sugiere tener dos Bases de Conocimiento Consolidadas una para pruebas (llamémosle BC Consolidada Prueba) y otra la de producción (llamémosle BC Consolidada Producción).

Integración

Cuando un módulo está listo para ser integrado a los demás se sigue el procedimiento detallado a continuación:

  1. Se exportan los objetos desde la BC de Aplicación del módulo.

  2. Se consolida dicha exportación en la BC Consolidada Prueba.

  3. En la BC Consolidada Prueba se realiza el siguiente ciclo, hasta que no se encuentren más errores significativos:

3.1    Se realizan las pruebas del Software Integrado.

3.2    Los errores detectados se devuelven al responsable del módulo que corresponda.

3.3    Se corrigen los errores en la BC de Aplicación, se exportan los objetos modificados.

3.4    Se consolida la exportación en la BC Consolidada Prueba.

3.5    Una vez que el Software Integrado cumple con los criterios de aceptación establecidos (menos de tantos errores, no contiene errores de un determinado tipo, etc.) el módulo integrado se puede pasar a la BC Consolidada Producción.

  1. Se exporta el módulo desde la BC de Aplicación.

  2. Se consolida dicha exportación en la BC Consolidada Producción.

  3. Se arma la versión del producto de software para llevar al entorno del usuario.

  4. Se instala el producto en el entorno del usuario para realizar pruebas por parte del usuario o comenzar a usarlo.

Resultado de la integración

La BC resultante de una consolidación debe ser completa en tres sentidos, a saber:

No se cumple la completitud en este sentido cuando no se exportan los objetos en base a los cuales está definida una fórmula, un subtipo, un índice, etc.

La solución es asegurase que cuando se exporta un objeto se exporten todos los objetos que el primero usa para su definición.

No se cumple la completitud en este sentido cuando se exportan transacciones y no se exportan las transacciones de las cuales depende la primera.

No se cumple la completitud en este sentido cuando se exportan objetos y no se exportan objetos a los cuales llama el primero.

Para evitar este inconveniente, al momento de exportar además de los objetos que se quieren exportar se deben incluir todos los objetos llamados por los anteriores.