INTRODUCCIN A LA

METODOLOGA GENEXUS

Presentaremos una introduccin a la Metodologa GeneXus.

De estar interesado en profundizar ms en este tema, el alumno podr inscribirse al curso
Gestin de Proyectos GeneXus si as lo desea, y/o recurrir a la documentacin existente.

400

Filosofa de GeneXus

Integrar los sistemas en un gran

sistema corporativo

Sistema de Compras
Sistema de Ventas

Sistema de Sueldos

La filosofa de GeneXus tiende a la integracin de los sistemas en un gran sistema corporativo.

Es decir, el objetivo es implementar para una empresa dada, un gran sistema integrado con
base de datos corporativa, de la cual se pueda obtener informacin de gestin y gerencial para
la toma de decisiones.

401

Con herramientas tradicionales...

Suele resultar muy complejo lograr el desarrollo
de sistemas corporativos...
Generalmente
se
desarrollan
soluciones
independientes para cada rea operativa de la
empresa:
Sistema de
Compras

Sistema de
Ventas

Sistema de
Sueldos

PROBLEMA: no se cuenta en la
empresa
con
informacin
corporativa,
resultando
ser
informacin no confiable

Implementar un sistema corporativo suele resultar una tarea muy compleja cuando se utilizan
herramientas tradicionales, por lo que generalmente no se lleva a cabo.
Esto trae como resultado que se tengan aplicaciones independientes, cada una resolviendo un
problema operativo particular, sin la posibilidad de obtener informacin corporativa.
As encontramos por ejemplo en una empresa comercial: una aplicacin de Ventas, otra de
Compras, otra Contable, etc.
En consecuencia no se cuenta en la empresa con informacin corporativa, resultando por lo tanto
ser informacin no confiable (por la aparicin de informacin redundante).

402

Sistemas Corporativos
La integracin de las Aplicaciones operativas de la
Organizacin es la base para poder construir los sistemas para
el rea de Gestin y Gerencial:

INFORMACION
GERENCIAL

APLICACIONES PARA
EL REA DE GESTION

APLICACIONES PARA EL AREA OPERATIVA

403

Cmo lograr Sistemas Corporativos?

1. Dividir el problema (modularizar)
2. Crear varios frentes de desarrollo
3. Asegurar la integrabilidad
4. Obtener una sola Base de Datos Corporativa

404

1. Dividir el problema (Modularizar)

Por qu modularizar?
Para:

Dividir el problema en partes ms pequeas

Habilitar frentes de desarrollo en paralelo
Reducir los tiempos de desarrollo
Incrementar la calidad de cada solucin

Como resultado de la modularizacin, se obtiene un conjunto de

mdulos a ser desarrollados

La razn principal para modularizar es entonces, dividir el problema en partes ms pequeas y

habilitar varios frentes de desarrollo con el fin de hacer ms eficiente la labor.
Realizar esta divisin (modularizacin) puede que no sea una tarea sencilla y depender de las
caractersticas de cada aplicacin, sin embargo debemos hacerlo cuando el problema adquiere un
determinado tamao tal que deba ser desarrollado por ms de una persona.
No existen procedimientos exactos para esta tarea, pero cuando la realicemos no debemos olvidar
que el principal objetivo es obtener ambientes de desarrollo lo ms independientes posibles,
reconociendo que seguramente los mdulos no sern disjuntos y compartirn cierto
conocimiento. Debemos sin embargo, intentar que el conjunto de los objetos que compartan sea
lo ms pequeo posible para poderlo administrarlo mejor, y realizar posteriormente una ms fcil
integracin en un nico modelo corporativo.

405

2. Crear varios frentes de desarrollo

Luego de asignado cada mdulo a cada persona o equipo de
desarrollo, surge la pregunta es conveniente realizar el desarrollo
en una sola KB o en KBs independientes ?

KB Compras

Desarrollo: KBs independientes

Produccin: Todas las KBs son
consolidadas en KB Corporativa

KB Sueldos

KB Corporativa

KB Ventas

El desarrollo de un mdulo tiene asociados ciclos de prototipacin y puesta en produccin

propios. Estos ciclos tienen asociados reorganizaciones de la Base de Datos (considerar que
las reorganizaciones son tareas monousuario), as como especificaciones y generaciones de
objetos.
No es recomendable que los ciclos de un mdulo en particular, afecten el desarrollo de los
dems mdulos que estn siendo desarrollados en forma simultnea, como ocurre en el
caso que compartan la Base de Datos. Por esta razn, es conveniente que los mdulos se
implementen en Bases de Conocimiento independientes, para posteriormente integrarlos
(consolidarlos) todos, en otra Base de Conocimiento.

406

3. Desarrollar asegurando la
Integrabilidad de las KBs
Las KBs no son disjuntas, sino que comparten cierto
conocimiento.
La siguiente pregunta que surge es Cmo administrar
el conocimiento en comn, para que al momento de
consolidar todas las KBs el impacto sea mnimo?
Plantearemos el tema suponiendo por un momento, que en
una empresa se realiza la divisin del sistema a desarrollar
en 2 mdulos y 2 equipos comienzan con el desarrollo de
KBs diferentes sin coordinar nada de antemano...

407

Ejemplo
KB 1 COMPRAS

KB 2 VENTAS

Objetos:

Objetos:

Proveedores
Clientes
FacturasCompra
FacturasVta
Productos - - - - - - - - - - - - - - - - - - - -Productos
Bancos - - - - - - - - - - - - - - - - - - - - - -Bancos
Agencias - - - - - - - - - - - - - - - - - - - - -Agencias
Compras
Ventas
OrdenesCompra
NotasCredito

DATOS

PROGRAMAS

DATOS

PROGRAMAS

En el ejemplo tenemos dos mdulos correspondientes a un sistema: el mdulo de compras y el

mdulo de ventas.
Sern desarrollados en forma independiente por dos equipos de desarrollo distintos, que
probarn sus prototipos con sus propios datos, hasta que est todo listo para ponerlo en
produccin.
Ahora bien, observemos que estos dos mdulos no son disjuntos, sino que comparten
informacin comn; entre otras cosas, ambos trabajan con productos, con bancos y con
agencias.
Observemos que pasar a la hora de integrar ambos mdulos en la KB Corporativa (a la cual
solemos llamarla tambin KB Consolidado).
Supongamos que primeramente consolidamos el mdulo de Compras

408

Ejemplo
Consolidacin de KB1 (COMPRAS)
COMPRAS
COMPRAS

KB CONSOLIDADO

Base
de Datos

PROGRAMAS

Ha quedado en la KB Consolidado el conocimiento que aport el mdulo de Compras.

409

Ejemplo
Consolidacin de KB2 (VENTAS)
COMPRAS
COMPRAS

VENTAS
VENTAS

Anlisis de
Impacto

Proceso de
consolidacin

KB CONSOLIDADO

Base
de Datos

PROGRAMAS

Ahora hemos consolidado en la KB Consolidado el mdulo de Ventas.

Como los mdulos no son disjuntos, surgirn alteraciones a lo consolidado anteriormente, y los
cambios a ser efectuados se mostrarn en el reporte de anlisis de impacto.
Con este ejemplo pretendemos despertar la atencin sobre los problemas inherentes a la
integracin de KBs, sin haber coordinado previamente el factor Integrabilidad.

410

Ejemplo
Problemas que surgen en la consolidacin del conocimiento

Objetos diferentes se llaman igual

Objetos iguales se llaman diferente
Atributos diferentes tienen el mismo nombre
Atributos iguales tienen diferente nombre

KB1 COMPRAS

KB2 VENTAS

Objeto: Invoice
Descripcin: Supplier Invoice

Objeto: Invoice
Descripcin: Customer Invoice

SupplierInvoiceId*
SupplierId*
SupplierName
InvoiceDate
(ProductId*
......)

CustomerInvoiceId*
CustomerId
CustomerName
InvoiceDate
(ProductNum*
.......)

Qu problemas encontramos en el ejemplo que venimos viendo?

1. Objetos diferentes que se llaman igual
Las Transacciones Supplier Invoice y Customer Invoice se llaman igual: Invoice
Al integrar ambos modelos solo quedar la ltima consolidada.

2. Atributos diferentes tienen el mismo nombre

En este caso tenemos dos atributos que son conceptualmente diferentes y tienen el mismo nombre:
InvoiceDate
Al momento de efectuar la segunda consolidacin, GeneXus asumir que se refieren al mismo
concepto y tratar de normalizar encontrando un problema: "Existe un atributo secundario en dos
tablas", por lo que informar el error y la Base de Datos no podr ser creada ni reorganizada.

3. Atributos iguales tienen diferente nombre

Tambin encontramos el caso de que el atributo que identifica al Producto, debera llamarse igual
en ambos objetos por tratarse del mismo concepto, pero fue llamado diferente : ProductId y
ProductNum.
As GeneXus no puede reconocer que se est haciendo referencia al mismo elemento y no establece
ninguna relacin para el concepto de Producto.

411

Ejemplo
Problemas que surgen en la consolidacin del conocimiento
Visiones diferentes de las relaciones
Por ejemplo:
KB 2

KB 1
Transaccin
Bank
BankId*
BankName

Transaccin
Agency
AgencyId*
AgencyName
BankId
BankName

Transaccin
Bancos
BankId*
BankName
(AgencyId*
AgencyName)

Otro problema que puede ocurrir es que los desarrolladores definan visiones diferentes de la
relacin entre los objetos.
Supongamos que tenemos 2 equipos desarrollando aplicaciones en un ambiente bancario.
Ambas aplicaciones, hacen referencia a las entidades Banco y Agencia.
Los 2 equipos de desarrollo tienen clara que la relacin que existe entre Bancos y Agencias es
una relacin de 1 a N : BANCO ---->> AGENCIAS
Sin embargo definen visiones diferentes, como se muestra arriba en la KB1 y KB2.
En la KB1 el atributo AgencyId identifica unvocamente una agencia. Y en la KB2 la agencia
queda identificada por la dupla BankId, AgencyId.
En este caso, no tenemos problema de nomenclatura, pero al integrar, solo quedar definida la
primer relacin , o sea:
AgencyId*
BankId
y no:
BankId*
AgencyId*
Dado que los identificadores en las transacciones juegan un papel fundamental, esto puede
dejar invlidos objetos definidos en la segunda aplicacin.
Concluimos entonces, que las relaciones entre atributos y los identificadores de las diferentes
entidades, juegan tambin un papel fundamental en el momento de integrar diferentes
aplicaciones.

412

Cmo trabajar para minimizar

los problemas de integracin?
Definir y seguir un padrn de nomenclatura
para los objetos
para los atributos (Nomenclatura GIK)

Disear y seguir una Metodologa para administrar

el conocimiento comn
a continuacin...

Como hemos visto, los problemas de integracin se reducen a problemas de nomenclatura y de definicin
de relaciones e identificadores. Veremos posibles soluciones para minimizar estos problemas:
1. Definir y seguir un padrn de nomenclatura
Como sabemos GeneXus establece la relacin entre los objetos y define la normalizacin de la Base de
Datos, basndose en los nombres de los atributos.
Es por eso que al momento de consolidar, la nomenclatura utilizada para los atributos juega un papel
primordial.
Sin embargo, no son menos importantes los nombres de los objetos (transacciones, procedimientos, etc.)
pues el Knowledge Manager reemplaza en la consolidacin, los objetos con igual nombre.
Los nombres dados a las Tablas, ndices y Data Views sern tambin controlados en el momento de la
consolidacin y debern ser nicos en el Modelo consolidado, por lo que debemos intentar reducir
conflictos tambin en este sentido.
En cuanto a los nombres de las variables, a pesar de que no son relevantes para la consolidacin, ya que
son definiciones locales, igual se sugiere tener una nomenclatura para las mismas con el fin de tener
uniformidad en el desarrollo y mejorar as la comprensin de las aplicaciones.
2. Disear y seguir una Metodologa para administrar el conocimiento comn
Una vez definidos los mdulos y establecida la padronizacin para los objetos del sistema, es el momento
de disear una metodologa para administrar el conocimiento de forma tal de mantener ambientes
independientes de desarrollo y asegurar su integracin en un Modelo Corporativo que tenga asociada una
sola Base de Datos corporativa.
Hemos solucionado parcialmente los problemas de integracin definiendo una nomenclatura standard
para objetos, pero queda an potenciarla y asegurar la integracin desde el punto de vista de
relaciones, es decir asegurar que los objetos compartidos por ms de un mdulo guarden la misma
relacin con el resto de los objetos. Para ello, expondremos a continuacin un esquema basado en tres
tipos de Modelos, que cumplen funciones diferentes en la tarea de administrar el conocimiento.

413

Metodologa basada en 3 tipos

de Bases de Conocimiento
Base de Conocimiento NCLEO: Contiene los objetos
corporativos, compartidos por las diferentes aplicaciones.
Base de Conocimiento asociada a una APLICACIN:
Contiene el conocimiento de uno de los Mdulos, resultado
de la modularizacin.
Base de Conocimiento CORPORATIVA: Contiene la
consolidacin de todas las bases de conocimiento
asociadas a las aplicaciones y el Ncleo.

414

Metodologa basada en 3 tipos

de Bases de Conocimiento
KB
KB
NUCLEO
NUCLEO

KB
KB
COMPRAS
COMPRAS

KB
KB
SUELDOS
SUELDOS

KB
KB
VENTAS
VENTAS

KB CORPORATIVA

BASE DE
DATOS

PROGRAMAS

415

Metodologa basada en 3 tipos

de Bases de Conocimiento
KB Ncleo
Ser posible identificar los elementos comunes a varios
mdulos antes de su desarrollo, e incluir stos en una KB
Ncleo?
S. En poco tiempo es posible definir un conjunto de
transacciones que definan cuales son las entidades y/u
objetos bsicos de la organizacin que a priori sabemos van
a ser compartidos por los mdulos.

416

Metodologa basada en 3 tipos

de Bases de Conocimiento
Objetivo KB Ncleo
Administrar en forma centralizada el conocimiento
compartido para tener un marco de referencia nico. La
Base de Conocimiento Ncleo es el ambiente que habilita la
administracin de este conocimiento.
Darle nombre a lo que conocemos es de esencia corporativa,
evitando as mltiples nominaciones para un mismo objeto y
para sus atributos.

417

Metodologa basada en 3 tipos

de Bases de Conocimiento
KB Ncleo = Interseccin de KBs Aplicaciones

KB
COMPRAS
KB
NUCLEO

KB
VENTAS

KB
SUELDOS
KB
CORPORATIVA

418

Metodologa basada en 3 tipos

de Bases de Conocimiento
FOLDER
NUCLEO

FOLDER
NUCLEO

FOLDER
COMPRAS

FOLDER
NUCLEO

KB
KB
COMPRAS
COMPRAS

FOLDER
COMPRAS

KB
KB
NUCLEO
NUCLEO
FOLDER
VENTAS

KB
KB
VENTAS
VENTAS

FOLDER
NUCLEO

FOLDER
NUCLEO

FOLDER
SUELDOS

KB
KB
SUELDOS
SUELDOS

FOLDER
VENTAS

FOLDER
SUELDOS

KB CORPORATIVA

BASE DE
DATOS

PROGRAMAS

En cada KB (Ncleo y Mdulos) se deber crear un folder, y los objetos propios de dicha KB, debern
ubicarse dentro de ese folder.
Es decir, en la KB Ncleo habr que crear un folder llamado Ncleo, en la KB Compras ser necesario
crear un folder llamado Compras, en la KB Ventas un folder llamado Ventas, y en la KB Sueldos un folder
llamado Sueldos.
La primer KB a ser definida ser la KB Ncleo. Para ello habr que identificar los objetos comunes a todos
los mdulos (por ejemplo, las transacciones Banks, Agencies, Products, Customers) y definirlos dentro del
folder Ncleo de la KB Ncleo.
Una vez definido el Ncleo, este deber distribuirse y consolidarse en cada una de las KBs asociadas a cada
aplicacin, para asegurarse el compartir todas los mismos objetos comunes, exactamente.
De modo que lo que se distribuir ser el folder Ncleo de la KB Ncleo, y se consolidar en cada una de
las KBs asociadas a una aplicacin (KB Compras, KB Ventas y KB Sueldos) as como en la KB
Corporativa.
Recin luego de esto, cada desarrollador responsable de un mdulo podr comenzar a trabajar, debiendo
crear todos los objetos propios de su mdulo, en el folder correspondiente a ese mdulo en particular. As,
la KB Compras tendr 2 folders: el folder Nucleo con los objetos comunes a todos los mdulos, y el
folder Compras con los objetos propios que implementen ese mdulo. Anlogamente, las KBs Ventas y
Sueldos tendrn el folder Nucleo y su folder propio.
Cada KB asociada a una aplicacin tendr un ambiente de Prototipacin, y un ambiente de Test en la
plataforma de Produccin. Estos modelos permitirn tener un diseo completo de la aplicacin, minimizando
los tiempos de desarrollo pues:
1. Se estar trabajando con KBs pequeas, asegurando la integrabilidad con el resto de las aplicaciones
2. Se estarn realizando los primeros niveles de test de funcionalidad para el mdulo en forma
independiente asegurando un ciclo de prototipacin dinmico
3. No se afectar al resto del desarrollo
En la medida que cada desarrollador de por finalizado su mdulo, distribuir el folder propio de su KB (por
ejemplo el folder Sueldos de la KB Sueldos) y este se consolidar en la KB Corporativa. No distribuir el
folder Nucleo de la KB Sueldos, ya que este folder solo se distribuye de la KB Nucleo).

419

Metodologa basada en 3 tipos

de Bases de Conocimiento
Administracin de las KBs correspondientes a mdulos
1. Se consolida el Ncleo
2. Se crea un folder propio, es decir que identifique a la aplicacin,
y en el mismo se crean los objetos de la aplicacin
3. Una vez finalizado el desarrollo y test del mdulo, se distribuir
el folder propio para consolidarlo en la KB Corporativa.
Cambios en objetos del Ncleo se deben realizar en la KB
Ncleo y luego deben ser redistribuidos a todas las KBs.
Incorporar objetos de esencia corporativa en el Ncleo

Cmo se procede si uno de los mdulos requiere modificar un objeto del Ncleo? Es decir,
supongamos que el desarrollador de un mdulo se da cuenta que le resulta necesario para su
aplicacin, agregar un atributo en una transaccin del Ncleo.
Esto tendr un impacto en todas las KBs de aplicacin, y por tanto deber administrarse con
cuidado.
La forma de proceder es realizar el cambio en la KB Ncleo, y luego redistribuir el Ncleo (folder
Ncleo de la KB Ncleo) a todas las KBs.

420

Metodologa basada en 3 tipos

de Bases de Conocimiento
Caractersticas de la KB Corporativa
Contiene el Ncleo y las Aplicaciones
Ventajas:
Integridad total de la Base de Datos
Minimiza la redundancia de Datos
Base para construir la Informacin Corporativa de la
Organizacin

421