Administración de Bases de Conocimiento

 

Elementos básicos. 2

Modularización. 2

Fácil integración de las Bases de Conocimiento. 2

Estándar para Nomenclatura.. 2

Introducción. 2

Nomenclatura sugerida. 3

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

Tipos de Bases de Conocimiento. 4

Carpetas dentro de las Bases de Conocimiento. 4

Administración de las Bases de Conocimiento. 5

 


 

Elementos básicos

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

A tener en cuenta:

·         Modularización

·         Fácil integración de las Bases de conocimiento

Como contemplar en el trabajo con Genexus los temas anteriores

·         Uso de un estándar de nomenclatura

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

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:

·         Cada módulo tiene un fin en sí mismo. Resuelve un problema concreto.

·         La relación con otros módulos es mínima.

·         Pueden ser dos tipos de módulos:

o        Los interactivos: que capturan un conjunto de datos que le son propios y realizan un proceso con ellos.

o        Los de procesamiento: que realiza un proceso con datos capturados por otros módulos.

Relación con las Bases de Conocimiento

·         Cada módulo se desarrolla en una BC propia e independiente.

·         Cada módulo se desarrolla en una BC en un PC.

·         Es necesaria la red para que todo el equipo de desarrollo de un mismo módulo tenga acceso a la misma BC.

 

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:

·         Duplicación de objetos:

o        Objetos iguales se llaman diferente.

o        Atributos iguales tienen diferente nombre.

·         Sobreescritura de objetos:

o        Objetos distintos se llaman de igual forma.

o        Atributos diferentes tienen igual nombre.

·         Visión diferente de las relaciones entre los objetos.

Sugerencias para minimizar los problemas de integración:

·         Uso de una estándar de nomenclatura común a todo el proyecto para nombrar Objetos.

·         Usar una metodología para administrar el conocimiento común.

 

 

Estándar para Nomenclatura

Introducción

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

Razones para usar una nomenclatura predefinida.

·         Atributos: dado que Genexus establece la relación entre los objetos y define la normalización de la Base de Datos basándose en los nombres de los atributos, al consolidar dos BC la forma de nombrar los atributos en las BC que se consolidan es muy importante. Se debe lograr nombrar atributos de forma tal que al consolidar dos BC no haya sobreescritura de atributos, atributos duplicados ni cambio en la normalización de la Base de Datos obteniendo una Base de Datos diferente a la esperada.

·         Objetos (Transacciones, Procedimientos, Work Panels, Menúes, Web Panels, Dataviews): Definir una forma de nombrar estos objetos en forma única en todas las BC del proyecto asegura que al consolidarlos no haya pérdida de objetos por sustitución de otro con igual nombre.

·         Tablas e índices: los nombres de éstos deben ser únicos al momento de la consolidación de las BC.

·         Variables: no es necesario pero ayuda a la lectura y mantenimiento de los objetos que los nombres de variables también cumplan con 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:

·         Base de Conocimiento Núcleo: Contiene los objetos compartidos por los diferentes módulos del sistema. Contiene objetos que representan información corporativa. Se define al comienzo del proyecto y debe tener un responsable.

·         Base de Conocimiento de Aplicación: Contiene los objetos de un módulo o submódulo del sistema. Se debe definir un responsable por cada base de conocimiento de Aplicación.

·         Base de Conocimiento Consolidada: Contiene la información consolidada de todas las demás Bases de Conocimiento del sistema. Se debe definir un responsable de la Base de Conocimiento Consolidada que también es el responsable de la consolidación de la información proveniente de las demás BC. Existirán dos Bases de conocimiento Consolidado, una para Prueba y otra que es la que da origen a la liberación (o puesta en producción) de un producto (un módulo o varios módulos) y que en todo momento es un reflejo de lo que está liberado en el ambiente de los usuarios.

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

·         Para utilizar este mecanismo en cada BC al mismo nivel que el Folder del módulo (nivel superior de Folders) crear un Folder que contenga los objetos a ser borrados de dicha BC.

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:

·         Diseño

·         Prototipo: para probar el funcionamiento de los objetos definidos.

 

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:

·         Todos los objetos del Folder Núcleo Corporativo o General de la BC Núcleo.

·         Todos los objetos de los Folders de subnúcleos de la BC Núcleo que sean necesarios para la aplicación.

 

Modificar o agregar objetos

·         Si surge la necesidad desde una aplicación de modificar un objeto de la BC Núcleo se notifica al responsable de la BC Núcleo dicha necesidad y es éste quien analiza, evalúa y realiza el cambio. Una vez realizado el cambio en la BC Núcleo desde ahí se exporta el cambio y se consolida en todas las Bases de Conocimiento que usan dicho objeto.

·         En cualquier momento se puede modificar un objeto propio de la BC de aplicación.

El momento de enviar el cambio a la BC Consolidada está determinado por los momentos de integración y Control de Versiones.

 

Borrar objetos

·         Si en una BC de Aplicación se borran objetos que pertenecen a la BC Núcleo cuando se consolide una actualización de la BC Núcleo ese objeto vuelve a existir en la BC de Aplicación. Por lo que para borrar un objeto que pertenece a la BC Núcleo se deben seguir los pasos indicados en la sección Borrar objetos bajo el título Administración de la BC Núcleo.

·         Para borrar objetos que pertenecen a la BC de Aplicación que solamente están siendo usados por dicha BC simplemente se borran.

·         Para borrar objetos que pertenecen a la BC de Aplicación que están siendo usados por otras Bases de Conocimiento se deben seguir pasos análogos a los que se explicaron para borrar un objeto de la BC Núcleo. El momento de hacer los cambios está determinado por el momento de integración y Control de Versiones.

Ambientes de trabajo

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

·         Diseño

·         Prototipo

 Administración de la Base de Conocimiento Consolidada

Contenido de la BC Consolidada

·         Contiene los objetos de la BC Núcleo y de las BC de Aplicación.

·         Estos objetos están organizados en carpetas por módulo.

·         En esta BC no se modifican objetos solamente se consolidan los objetos de la BC Núcleo y las Bases de Conocimiento de Aplicación.

·         La única razón por la que se podría trabajar en la BC Consolidada es para hacer consultas corporativas de información que involucra más de un módulo y no pertenecen al Núcleo.

Ambientes de trabajo

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

·         Diseño: para hacer las consultas corporativas antes mencionadas.

·         Prototipo (opcional): para realizar pruebas en la BC Consolidada sin tener dos Bases de Conocimiento Consolidadas.

·         Producción

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