INTRODUCCIÓN A LA METODOLOGÍA GENEXUS
Presentaremos Presentaremos una introducción a la Metodología GeneXus. De estar interesado interesado en profundizar más en este tema, el alumno podrá inscribirse al curso curso recurrir a la documentación existente. existente. Gestión de Proyectos GeneXus si así lo desea, y/o recurrir
400
Filosofía de GeneXus
Integrar los sistemas en un gran g ran sistema corporativo Sistema Sistema de Compras Compras Sistema Sistema de Ventas Ventas
Sistema Sistema de Sueldos Sueldos
La filosofía de GeneXus tiende a la integración de los sistemas en un gran sistema corporativo. Es decir, el objetivo es implementar implementar para una empresa empresa dada, un gran sistema integrado con base de datos corporativa, corporativa , de la cual se pueda obtener información de gestión y gerencial para la toma de decisiones.
401
Con herramientas tradicionales... • Suele Suele resultar resultar muy muy complejo complejo lograr lograr el desar desarrollo rollo de sistemas corporativos... • Generalm Generalmente ente se desarro desarrollan llan soluci soluciones ones independientes para cada área operativa de la empresa: Sist Sistem ema a de Compras
Sistem Sistema a de Ventas
Sistem Sistema a de Sueldos
PROBLEMA: no se cuenta en la empresa con información corp corpor orat ativ iva, a, resu result ltan ando do ser ser información no confiable
Implement Implementar ar un sistema sistema corporativo corporativo suele resultar resultar una tarea tarea muy compleja compleja cuando cuando se utilizan herramientas tradicionales, 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 información corporativa. Así encontramos por ejemplo ejemplo en una empresa empresa comercial: comercial: una aplicación de Ventas, otra de de Compras, otra Contable, etc. En consecuencia no se cuenta cuenta en la empresa con con información corporativa, corporativa, resultando por lo tanto ser información no confiable (por la aparición de información redundante).
402
Sistemas Corporativos La integración de las Aplicaciones operativas de la Organización es la base para poder construir los sistemas para el área de Gestión y Gerencial:
INFORMACION GERENCIAL APLICACIONES PARA EL ÁREA DE GESTION
APLICACIONES PARA EL AREA OPERATIVA
403
¿Cómo lograr Sistemas Corporativos? 1. Dividir el problema problema (modulariz (modularizar) ar) 2. Crear varios varios frentes frentes de desarrollo desarrollo 3. Asegurar Asegurar la integrabilid integrabilidad ad 4. Obtener Obtener una una sola sola Base de Datos Corporativa
404
1. Dividir el problema (Modularizar) ( Modularizar) ¿Por qué modularizar? modularizar? Para: • Dividir el problema problema en partes partes más pequeñas pequeñas • Habilitar Habilitar frentes de desarrol desarrollo lo en paralelo paralelo • Reducir los los tiempos tiempos de desarrollo desarrollo • Incrementar Incrementar la calidad calidad de cada solución solución Como resultado de la modularización, se obtiene un conjunto de módulos módulos a ser desarro desarrollados llados
La razón principal para modularizar modularizar es entonces, dividir el problema en en partes más pequeñas pequeñas y habilitar varios frentes de desarrollo con el fin de hacer más eficiente la labor. Realizar esta división (modularización) (modularización) puede que no sea una una tarea sencilla y dependerá dependerá de las características de cada aplicación, sin embargo debemos hacerlo cuando el problema adquiere un determinado tamaño tal que deba ser desarrollado por más 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 más independientes posibles, reconociendo que seguramente los módulos no serán disjuntos y compartirán cierto conocimiento. Debemos sin embargo, intentar que el conjunto de los objetos que compartan sea lo más pequeño posible para poderlo administrarlo mejor, y realizar posteriormente una más fácil integración en un único modelo corporativo.
405
2. Crear varios frentes de desarrollo Luego de asignado cada módulo a cada persona o equipo de desarrollo, surge la pregunta ¿es conveniente realizar el desarrollo en una sola sola KB o en KB’s independientes independientes ?
KB Compras
KB Sueldos
• Desarrollo: KBs independ independien ientes tes • Producción: Todas Todas las las KBs son consolidadas en KB Corporativa KB Corporativa
KB Ventas
El desarrollo de un módulo tiene asociados ciclos de prototipación y puesta en producción propios. Estos ciclos tienen asociados reorganizaciones de la Base de Datos (considerar que las reorganizaciones son tareas tareas monousuario), así como especificaciones y generaciones generaciones de objetos. No es recomendable que los ciclos de un módulo en particular, afecten el desarrollo de los demás módulos que estén siendo desarrollados en forma simultánea, como ocurre en el caso que compartan la Base de Datos. Por esta razón, es conveniente que los módulos se implementen en Bases de Conocimiento independientes, para posteriormente integrarlos (consolida (consolidarlos) rlos) todos, todos, en otra Base de Conocimie Conocimiento. nto.
406
3. Des Desarr arrol olla larr asegu aseguran rando do la Inte Integr grab abililid idad ad de las las KBs KBs • Las KBs no son disjuntas, disjuntas, sino que comparten cierto conocimiento. • La sigu siguien iente te preg pregunt untaa que que surge surge es ¿Cómo administrar el conocimiento conocimiento en común, común, para que que al momento momento de consolidar consolidar todas las las KBs el impacto sea mínimo? • Plantearemos Plantearemos el tema tema suponiend suponiendo o por un momento, momento, que en en una empresa se realiza la división del sistema a desarrollar en 2 módulos módulos y 2 equipos equipos comienzan comienzan con el desarro desarrollo llo de KBs diferentes diferentes sin coordinar coordinar nada de antemano... antemano...
407
Ejemplo KB 1 COMPRAS Objetos:
KB 2 VENTAS Objetos:
Proveedores Clientes FacturasCompra FacturasVta Productos - - - - - - - - - - - - - - - - - - - -Productos Bancos----------------------Bancos Agencias---------------------Agencias Compras Ventas OrdenesCompra NotasCredito
DATOS
PROGRAMAS
DATOS
PROGRAMAS
En el ejemplo ejemplo tenemos dos módulos correspondientes a un sistema: sistema: el módulo de compras y el módulo de ventas. Serán desarrollados en forma independiente por dos equipos de desarrollo distintos, que probarán sus prototipos con sus sus propios datos, hasta que esté todo listo para ponerlo ponerlo en producción. Ahora bien, observemos que estos dos módulos no son disjuntos, sino que comparten información común; entre otras cosas, ambos ambos trabajan trabajan con productos, productos, con bancos bancos y con agencias. Observemos que pasará a la hora de integrar ambos módulos módulos en la KB Corporativa (a la cual solemos llamarla también KB “Consolidado”). Supongamos que primeramente consolidamos el módulo de Compras…
408
Ejemplo Consolidación Consolidación de KB1 (COMPRAS) (COMPRAS) COMPRAS COMPRAS
KB “CONSOLIDADO”
Base de Datos
PROGRAMAS
Ha quedado quedado en la KB “Consolidado” el conocimiento que aportó el módulo de de Compras.
409
Ejemplo Consolida Consolidación ción de KB2 (VENTA (VENTAS) S) COMPRAS COMPRAS
VENTAS VENTAS
Análisis de Impacto
Proces Proceso o de consolidación
KB “CONSOLIDADO”
Base de Datos
PROGRAMAS
Ahora hemos hemos consolidado consolidado en la KB “Consolidado” “Consolidado” el módulo módulo de Ventas. Como los módulos no son disjuntos, surgirán alteraciones a lo consolidado anteriormente, y los cambios a ser efectuados efectuados se mostrarán en el reporte de análisis de impacto. Con este ejemplo pretendemos despertar la atención sobre los problemas inherentes a la integración de KBs, sin haber coordinado previamente el factor Integrabilidad. Integrabilidad.
410
Ejemplo Proble Problemas mas que surgen surgen en la consol consolida idació ción n del conoci conocimie mient nto o • • • •
Objetos diferentes diferentes se llaman llaman igual igual Objetos iguales iguales se llaman llaman diferente diferente Atributos Atributos diferentes diferentes tienen tienen el mismo mismo nombre nombre Atributos Atributos iguales iguales tienen diferente diferente nombre nombre
KB1
COMPRAS
KB2
VENTAS
Objeto: Invoice Descripción: Supplier Invoice
Objeto: Invoice Descripción: Customer Invoice
SupplierInvoiceId* SupplierId* SupplierName InvoiceDate (ProductId* ......)
CustomerInvoiceId* CustomerId CustomerName InvoiceDate (ProductNum*
.......)
¿Qué problemas encontramos encontramos en el ejemplo que que venimos viendo? 1. Objetos diferentes diferentes que se llaman igual Las Transacciones Transacciones Supplier Supplier Invoice Invoice y Customer Customer Invoice se llaman igual: Invoice Al integrar ambos 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: I n voic eDa t e
Al momento de efectuar efectuar la segunda consolidación, GeneXus GeneXus asumirá que se refieren al mismo concepto y tratará de normalizar encontrando encontrando un problema: "Existe un atributo 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 También encontramos el caso de que el atributo que identifica al Producto, debería llamarse igual en ambos objetos por tratarse del mismo concepto, pero fue llamado diferente : P r o d u c t I d y Pr o d u ct N u m . Así GeneXus no puede reconocer reconocer que se está haciendo referencia referencia al mismo elemento elemento y no establece ninguna relación para el concepto de Producto.
411
Ejemplo Proble Problemas mas que surgen surgen en la consol consolida idació ción n del conoci conocimie mient nto o • Vision Visiones es difere diferente ntess de las relacion relaciones es Por ejemplo: KB 2
KB 1 Transacción “Bank” BankId* BankName
Transacción “Agency”
Transacción “Bancos”
AgencyId* AgencyName BankId BankName
BankId* BankName (AgencyId* AgencyName)
Otro problema que puede ocurrir es que los desarrolladores definan visiones diferentes de la relación 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 relación que existe entre Bancos y Agencias es una relación 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 unívocamente una agencia. Y en la KB2 la agencia queda identificada por la dupla BankId, AgencyId . En este caso, no tenemos tenemos problema de nomenclatura, nomenclatura, pero al integrar, solo quedará definida la primer relación , o sea: AgencyId * BankId
y no: BankId * AgencyId *
Dado que los identificadores en las transacciones juegan un papel fundamental, esto puede dejar inválidos objetos definidos en la segunda aplicación. Concluimos entonces, que las relaciones entre atributos y los identificadores de las diferentes entidades, juegan también un papel fundamental en el momento de integrar diferentes aplicaciones.
412
¿Cómo trabajar para minimizar los problemas de integración? • Definir Definir y seguir seguir un padr padrón ón de nomenc nomenclat latura ura • para para los los obje objeto toss • para los atributos atributos (Nomenclatura (Nomenclatura GIK)
• Diseñar y seguir seguir una una Metodolog Metodología ía para para administ administrar rar el conocimiento común • a contin continua uaci ción ón.. ....
Como hemos visto, los problemas de integración se reducen a problemas de nomenclatura y de definición de relaciones e identificadores. Veremos posibles soluciones para minimizar estos problemas: 1. Definir y seguir un padrón de nomenclatura Como sabemos 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. Es por eso que al momento de consolidar, la nomenclatura utilizada para los atributos juega un papel primordial. Sin embargo, no son menos importantes importantes los nombres de los objetos (transacciones, (transacciones, procedimientos, etc.) pues el Knowledge Manager reemplaza en la consolidación, los objetos con igual nombre. Los nombres dados a las Tablas, Índices y Data Views serán también controlados en el momento de la consolidación y deberán ser únicos en el Modelo consolidado, por lo que debemos intentar reducir conflictos también en este sentido. En cuanto a los nombres de las variables, a pesar de que no son relevantes para la consolidación, 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 mejorar así la comprensión de las aplicaciones. aplicaciones. 2. Diseñar y seguir una Metodología para administrar el conocimiento común Una vez definidos los módulos y establecida la padronización para los objetos del sistema, es el momento de diseñar una metodología para administrar el conocimiento de forma tal de mantener ambientes independientes de desarrollo y asegurar su integración en un Modelo Corporativo que tenga asociada una sola Base de Datos corporativa. Hemos solucionado parcialmente los problemas de integración definiendo una nomenclatura standard para objetos, pero queda aún potenciarla y asegurar la integración desde el punto de vista de “relaciones”, es decir asegurar que los objetos compartidos por más de un módulo guarden la misma relación con el resto de los objetos. Para ello, expondremos a continuación un esquema basado en tres tipos de Modelos, que cumplen funciones diferentes en la tarea de administrar el conocimiento.
413
Metodolog Metodología ía basada basada en 3 tipos tipos de Bases de Conocimiento • Base de Conocimiento NÚCLEO: Contiene los objetos corporativos, compartidos por las diferentes aplicaciones. • Base de Conocimiento asociada a una APLICACIÓN: Contiene el conocimiento de uno de los Módulos, resultado de la modularización. • Base de Conocimiento CORPORATIVA: Contiene la consolidación de todas las bases de conocimiento asociadas a las aplicaciones y el Núcleo.
414
Metodolog Metodología ía basada basada en 3 tipos tipos de Bases de Conocimiento KB KB NUCLEO NUCLEO
KB KB COMPRAS COMPRAS
KB KB SUELDOS SUELDOS
KB KB VENTAS VENTAS
KB CORPOR CORPORATI ATIVA VA
BASE DE DATOS
PROGRAMAS
415
Metodolog Metodología ía basada basada en 3 tipos tipos de Bases de Conocimiento KB Núcleo • ¿Será ¿Será posibl posiblee ident identifi ificar car los elemen elementos tos comune comuness a varios varios módulos antes de su desarrollo, e incluir éstos en una KB Núcleo? Núcleo? • Sí. En En poco tiempo es posible posible definir definir un conjunto conjunto de transacciones que definan cuales son las entidades y/u objetos básicos de la organización que a priori sabemos van a ser compartidos por los módulos.
416
Metodolog Metodología ía basada basada en 3 tipos tipos de Bases de Conocimiento Objetivo KB Núcleo • Administrar Administrar en forma forma centralizada centralizada el conocim conocimiento iento compartido para tener un marco de referencia único. La Base de Conocimiento Núcleo es el ambiente que habilita la administración de este conocimiento. • Darle nombre nombre a lo que que conocemos conocemos es de esencia esencia corporativa, corporativa, evitando evitando así múltiples múltiples nominaciones nominaciones para un mismo objeto objeto y para sus atributos.
417
Metodolog Metodología ía basada basada en 3 tipos de Bases de Conocimiento KB Núcleo = Intersección de KBs Aplicaciones KB COMPRAS KB NUCLEO
KB VENTAS
KB SUELDOS KB CORPORATIVA
418
Metodologí Metodologíaa basada basada en 3 tipos tipos de Bases de Conocimiento FOLDER NUCLEO
KB KB NUCLEO NUCLEO
FOLDER NUCLEO
FOLDER COMPRAS
FOLDER NUCLEO
KB KB COMPRAS COMPRAS FOLDER COMPRAS
FOLDER VENTAS
KB KB VENTAS VENTAS FOLDER NUCLEO
FOLDER NUCLEO
FOLDER SUELDOS
KB KB SUELDOS SUELDOS
FOLDER VENTAS
FOLDER SUELDOS
KB CORPORA CORPORATIV TIVA A
BASE DE DATOS
PROGRAMAS
En cada KB (Núcleo y Módulos) se deberá deberá crear un folder, y los objetos propios propios de dicha KB, deberán deberán ubicarse dentro de ese folder. Es decir, en la KB Núcleo habrá que crear crear un folder folder llamado Núcleo, Núcleo, en la KB Compras será será neces necesari ario o crear un folder llamado Compras, en la KB Ventas un folder llamado Ventas, y en la l a KB Sueldos un folder llamado Sueldos. La primer primer KB a ser definida definida será la KB Núcleo. Núcleo. Para ello habrá habrá que identificar los objetos comunes comunes a todos los módulos (por ejemplo, las transacciones transacciones Banks, Agencies, Products, Products, Customers) y definirlos definirlos dentro del folder Núcleo de la KB Núcleo. Núcleo. Una vez definido el Núcleo, Núcleo, este deberá distribuirse y consolidarse en cada una de las KBs asociadas asociadas a cada aplicación, para asegurarse el compartir todas los mismos objetos comunes, exactamente. De modo que lo que se distribuirá será el folder Núcleo de la KB Núcleo, Núcleo, y se consolidará consolidará en cada cada una de las KBs asociadas a una aplicación (KB ( KB Compras, KB Ventas y KB Sueldos) Sueldos) así así como como en la KB Corporativa. Corporativa. Recién luego de esto, esto, cada desarrollador desarrollador responsable de un un módulo podrá comenzar a trabajar, trabajar, debiendo crear todos los objetos propios de su módulo, en el folder correspondiente a ese módulo en particular. Así, la KB Compras tendrá tendrá 2 folders folders:: el folder Nucleo con los objetos comunes a todos los módulos, y el folder Compras con los objetos propios que implementen ese módulo. Análogamente, las KBs Ventas y Sueldos tendrán el folder Nucleo y su folder propio. propio. Cada KB asociada a una aplicación aplicación tendrá un ambiente de Prototipación, Prototipación, y un ambiente de Test en la plataforma de Producción. Estos modelos permitirán tener un diseño completo de la aplicación, minimizando los tiempos de desarrollo pues: 1. Se estará trabajando con KBs pequeñas, pequeñas, asegurando la integrabilidad con el resto de las aplicaciones 2. Se estarán realizando los primeros niveles de test de funcionalidad para el módulo en forma independiente aseguran asegurando do un ciclo de prototipación dinámico 3. No se afectará al resto del desarrollo desarrollo En la medida que cada desarrollador desarrollador de por finalizado su módulo, distribuirá el folder propio de su KB (por ejemplo el folder Sueldos de la KB Suel Sueldo doss) y este se consolidar consolidaráá en la KB Corporativ Corporativa. a. No distribuirá distribuirá el folder Nucleo de la KB Sueldos, ya que este folder solo se distribuye de la KB Nucleo).
419
Metodolog Metodología ía basada basada en 3 tipos de Bases de Conocimiento Administración de las KBs correspondientes a módulos 1. Se cons consol olid idaa el el Núc Núcle leo o 2. Se crea un folder propio, es decir que identifique a la aplicación, y en el mismo se crean los objetos de la aplicación 3. Una vez finalizado el desarrollo y test del módulo, se distribuirá el folder propio para consolidarlo en la KB Corporativa. Cambios en objetos del Núcleo se deben realizar en la KB Núcleo y luego deben ser redistribuidos a todas las KBs. Incorporar objetos de esencia corporativa en el Núcleo
¿Cómo se procede si uno de los módulos requiere modificar un objeto del Núcleo? Es decir, supongamos que el desarrollador de un módulo se da cuenta que le resulta necesario para su aplicación, agregar un atributo en una transacción del Núcleo. Esto tendrá tendrá un impacto impacto en todas todas las KBs de aplicaci aplicación, ón, y por tanto deberá deberá administr administrarse arse con con cuidado. La forma de proceder es realizar el cambio en la KB Núcleo, y luego redistribuir el Núcleo ( folder Núcleo de la KB Núcleo) Núcleo) a todas las KBs.
420
Metodolog Metodología ía basada basada en 3 tipos tipos de Bases de Conocimiento Características de la KB Corporativa • Contien Contienee el Núcle Núcleo o y las las Aplica Aplicacio ciones nes • Ventajas: • Integri Integridad dad total total de la Base Base de Datos Datos • Minimiz Minimizaa la redunda redundanci ncia a de Datos Datos • Base para para construir construir la Información Información Corpor Corporativa ativa de la Organización
421
