1

INTRODUCCIN TERICA INTRODUCCIN TERICA

2
BASE
DE
DATOS
PROGRAMAS
REALIDAD
Herramientas y Metodologas Herramientas y Metodologas
Nuestra tarea como profesionales de la informatica consiste en desarrollar y
mantener aplicaciones para apoyar al usuario en su actividad. Para realizar esta
tarea existen diferentes herramientas y metodologias.
GeneXus es una herramienta para el desarrollo de aplicaciones sobre bases de
datos. Su objetivo es permitir la implantacin de aplicaciones en el menor
tiempo y con la mejor calidad posible.
GeneXus emplea una metodologia que tiene un enfoque muy diferente al de las
metodologias mas comunmente utilizadas. Por tanto, aprender a utilizar
GeneXus adecuadamente va mas alla de conocer un nuevo lenguaje de
especificacin: lo mas importante es el aprendizaje de una nueva metodologia
de desarrollo.
3
BASE
DE
DATOS
PROGRAMAS
VISIONES
DE
USUARIOS
Satisface
MODELO DE
LA REALIDAD
Ingenieria Inversa
Modelado de la realidad Modelado de la realidad
a partir de las visiones a partir de las visiones
de los usuarios de los usuarios
El primer problema al que nos enfrentamos en el desarrollo de aplicaciones es la
obtencin del conocimiento de la realidad.
cCmo logramos obtener el conocimiento de la realidad de una forma lo
suficientemente objetiva y detallada al mismo tiempo, que nos permita construir un
modelo corporativo?
Dado que los usuarios conocen los objetos con los que trabajan cotidianamente,
conocen la informacin que se maneja en ellos, las reglas que deben seguirse, los
clculos que deben realizarse, entonces, por qu no utilizar esas visiones de los
objetos de su realidad como fuente de informacin?
Puede demostrarse que dado un conjunto de visiones de datos de usuarios, existe
una y solo una base de datos mnima que las satisface. En este estado, el problema
se ha transformado en un problema matemtico, y solo es preciso resolverlo para
lograr automatizar la construccin de la base de datos.
De modo que si se utilizan las visiones que los usuarios tienen de los objetos como
fuente de informacin, a partir de la sntesis de esas visiones, se podra obtener,
mediante ingeniera inversa, el modelo de datos que refleje esa realidad. Este
mtodo es conocido como "sntesis de visiones cannicas.
El punto de partida de la metodologa GeneXus es describir las visiones de los
usuarios para modelar el sistema. A partir de este modelo, GeneXus construye el
soporte computacional (base de datos y programas) para soportarlo.
4
Comparacin Comparacin
de de
Metodologas Metodologas
Para fijar ideas, comparemos las metodologas tradicionales ms utilizadas
actualmente, con la metodologa utilizada por GeneXus, conocida como
metodologa incremental.
Las metodologas tradicionales difieren entre s en varios aspectos, pero tienen
una caracterstica en comn: separan el anlisis de los datos del de los
procesos.
A continuacin veremos un esquema general que podria aplicarse a cualquiera
de las metodologias tradicionales actuales y estudiaremos sus problemas.
5
Metodologa Tradicional Metodologa Tradicional
6
ANLISIS
DE
DATOS
BASE
DE
DATOS
ANLISIS
FUNCIONAL
PROGRAMACIN
PROGRAMAS
GENERACIN/
INTERPRETACIN
ESPECIFICACIN
FUNCIONAL
MODELO
DE
DATOS
REALIDAD
La primer tarea que se realiza generalmente es el Anlisis de Datos,
donde se estudia la realidad en forma abstracta, identificando los objetos
existentes y sus relaciones y se obtiene como resultado un Modelo de
Datos con las entidades y relaciones encontradas (Modelo ER). Es facil ver
que existe una correspondencia muy simple entre el modelo de datos y la
base de datos necesaria para soportarlo. La siguiente tarea entonces, es
disenar esa base de datos, partiendo del modelo de datos.
Construir un sistema integrado, requiere de un modelo de datos
corporativo, y dependiendo del tamano de la empresa, sta puede resultar
una tarea de enorme complejidad.
Cuando esto ocurre, la complejidad suele atacarse dividiendo el sistema en
mdulos (divide and conquer"), cada uno de los cuales soluciona los
problemas operativos de un area especifica de la empresa. De esta forma
la tarea de modelado se simplifica notablemente, pero como contrapartida
los mdulos operan sin una real integracin, lo que provoca que exista
informacin redundante, con todos los problemas que ello acarrea.
En caso de que luego se intente realizar la integracin de esos mdulos,
habra que realizar modificaciones sobre los modelos de datos, lo cual, a
pesar de su complejidad, es una tarea realizable. Sin embargo las
modificaciones que deberan efectuarse sobre los programas asociados
tienen un costo tan elevado que tornan inviable la integracin.
7
Con la divisin del sistema en mdulos la empresa tendra resueltos sus problemas operativos,
pero apareceran indefectiblemente problemas de carencia de informacin que permita orientar
la gestin y la toma de decisiones de alto nivel. En la rbita gerencial la informacin que se
necesita es principalmente de naturaleza corporativa, por lo que la divisin del sistema en
mdulos no satisface las necesidades actuales de obtencin de informacin.
GeneXus soluciona este problema, brindando herramientas y una metodologia que hacen
posible y sencilla la creacin y mantenimiento de sistemas corporativos.
Continuando con el proceso de desarrollo en una metodologia tradicional, una vez obtenido el
modelo de datos, el siguiente paso es disenar la base de datos. Existe una transformacin
trivial entre un buen modelo de datos, y el diseno de la base de datos necesaria para
soportarlo.
Sin embargo, el modelo de datos no es suficiente para desarrollar los programas de aplicacin,
ya que el mismo describe los datos, pero no los comportamientos. Se recurre, entonces, a una
tarea llamada Anlisis Funcional, donde se estudia la empresa desde el punto de vista de las
funciones existentes, y el resultado de dicha tarea es una Especificacin Funcional.
Seria deseable que la especificacin funcional fuera independiente de la especificacin de datos,
pero esto no es asi en las metodologias estudiadas. Las modificaciones en el diseno de la base
de datos, implican la necesidad de revisar las especificaciones funcionales, siendo esta la causa
fundamental de los grandes costos de mantenimiento.
Una vez que se cuenta con la base de datos y la especificacin funcional, ya estan dadas las
condiciones para crear los programas de la aplicacin.
Para ello se cuenta hoy en dia con varias alternativas:
-Programacin en lenguajes de tercera y cuarta generacin:
- Lenguajes de 3ra. Generacin (L3G): lenguajes de bajo nivel como COBOL, RPG, C,
Pascal, ADA, FORTRAN
- Lenguajes de 4ta. Generacin (L4G): lenguajes de alto nivel como CA IDEAL,
INFORMIX 4GL, NATURAL 2, PROGRESS
-Generacin/Interpretacin
Desde un punto de vista conceptual no hay diferencia entre la programacin en lenguajes de
3ra. y de 4ta. generacin. En ambos casos el analista debe estudiar el problema, transformarlo
en un algoritmo y codificarlo en el lenguaje de programacin elegido.
La principal diferencia entre ambas alternativas radica en que en los lenguajes de 4ta.
generacin se escribe mucho menos cdigo (aproximadamente 10 veces menos) y, como
consecuencia, la productividad es mucho mayor y el numero de errores cometidos es mucho
menor.
8
Puede argumentarse que con los lenguajes de 4ta. generacin se pierde flexibilidad, lo que
es cierto en trminos tericos pero irrelevante en trminos practicos, dado que actualmente
estas herramientas estan dotadas de primitivas que permiten complementar su cdigo, por
lo que su aplicabilidad ha crecido mucho.
Ahora, el problema visto de que las descripciones de los procesos dependen de la base de
datos, afecta a ambos por igual, por lo que se concluye que los lenguajes de 4ta. generacin
permiten aumentos de productividad muy grandes sobre los de 3ra. en la tarea de
desarrollo, pero ayudan bastante poco en la etapa de mantenimiento.
Otra alternativa posible, es la utilizacin de un generador", que es una herramienta que
puede interpretar una especificacin funcional y producir automaticamente los programas.
Aqui existe una diferencia conceptual importante con el caso anterior. En este caso el
analista describe el problema de una forma declarativa (no existe algoritmo ni codificacin
procedural alguna). Por ello en este caso la especificacin funcional debe ser formal y
rigurosa. Algunos ejemplos de herramientas de esta clase son ADELIA, AS/SET, LANSA,
SYNON, TELON, etc.
Existe otra categoria de herramientas conceptualmente idntica: la de aquellas que
simplemente interpretan" la especificacin, como MAGIC y SAPIENS, entre otras. La
programacin en ambos casos es totalmente automatica, por lo que el aumento de
productividad sobre las herramientas de 3ra. y 4ta. generacin es muy grande.
Podria argumentarse en contrario, como a menudo se ha hecho con las herramientas de 4ta.
generacin, que se pierde flexibilidad con estas herramientas, lo que otra vez es cierto en
trminos tericos, pero es irrelevante en trminos practicos, ya que hoy en dia estas
herramientas estan dotadas de Lenguajes de Diagramas de Accin (en la practica lenguajes
de 4ta. generacin), que permiten complementar su cdigo, por lo que su aplicabilidad ha
crecido mucho.
El problema visto -las descripciones de los procesos dependen de la base de datos- afecta
tambin a las aplicaciones generadas mediante estas herramientas. Como consecuencia, los
Generadores y los Intrpretes (como los lenguajes de 4ta. generacin) ayudan bastante
poco en la tarea de mantenimiento.
En definitiva, resumiendo las tres opciones vistas:
Lenguajes de 3ra. Generacin
Baja productividad en el desarrollo
Lenguajes de 4ta. Generacin
Buen aumento de productividad en el desarrollo sobre L3G.
Generadores/Intrpretes
Buen aumento de productividad en el desarrollo sobre L3G y L4G.
9
Desde el punto de vista del mantenimiento, ninguna de las herramientas ayuda mucho,
dado que en todas ellas se utilizan descripciones de procesos que pueden perder su
validez cuando existen modificaciones de archivos y que, por ello, deben ser revisadas y
mantenidas manualmente. Por supuesto, el costo de mantenimiento difiere mucho entre
las distintas alternativas vistas, ya que por ejemplo, en el caso de la utilizacin de
Generadores o Intrpretes, una vez modificadas las especificaciones funcionales, la
generacin de los programas es automatica.
Si el postulado de que puede obtenerse una base de datos estable" fuera verdadero,
entonces los problemas anteriores serian irrelevantes. Sin embargo, lamentablemente
este postulado es falso y sobran los contraejemplos que lo demuestran.
Conclusin:
No es posible hacer de forma abstracta un modelo de datos detallado de la empresa y con
el suficiente nivel de detalle y objetividad porque nadie la conoce como un todo. Por el
contrario, es necesario recurrir a multiples interlocutores, cada uno de los cuales aporta
su propia subjetividad. Como consecuencia, durante todo el ciclo de vida de la aplicacin
se producen cambios en el modelo.
Aun si se considerara la situacin ideal, en la cual se conocen exactamente las
necesidades y por tanto es posible definir la base de datos ptima, el modelo, de todas
formas, no podra permanecer estatico, ya que debe acompanar la evolucin de la
empresa.
Todo esto seria poco importante si la especificacin funcional y la base de datos fueran
independientes. Sin embargo, dado que la especificacin funcional se refiere a la base de
datos, las inevitables modificaciones en esta ultima, implican modificaciones (manuales)
en la primera.
Las principales consecuencias de lo anterior son los altos costos de mantenimiento: en la
mayoria de las empresas que trabajan de una manera convencional se admite que el 80%
de los recursos que tericamente estan destinados al desarrollo, realmente se utilizan
para hacer mantenimiento de las aplicaciones ya implementadas.
Dado que es muy dificil en este contexto determinar y propagar las consecuencias de los
cambios de la base de datos sobre los procesos, es habitual que, en vez de efectuarse los
cambios necesarios, se opte por introducir nuevos archivos redundantes, con la
consiguiente degradacin de la calidad de los sistemas y el incremento de los costos de
mantenimiento.
10
Metodologa Metodologa GeneXus GeneXus
Los fundadores de ARTech han desarrollado una amplia actividad de consultora
internacional en diseo de grandes bases de datos, trabajando con verdaderos
modelos corporativos con cientos de tablas.
En su trayectoria, se convencieron de que no deba perderse ms tiempo
buscando algo que no existe: las bases de datos estables.
Luego de importantes investigaciones, desarrollaron una teora, organizaron
una metodologa e implementaron una herramienta para posibilitar el desarrollo
incremental y permitir la convivencia con las bases de datos reales -inestables-
a un costo mnimo.
11
Desarrollo con Desarrollo con GeneXus GeneXus
REALIDAD
DESCRIPCIN
DE OBJETOS
Utilizando GeneXus, la tarea basica del analista es la descripcin de la realidad.
Slo el hombre puede desarrollar esta tarea, ya que slo l puede entender el
problema del usuario.
El analista GeneXus trabaja en alto nivel, en vez de realizar tareas de bajo nivel
como: disenar archivos, normalizar, disenar programas, programar, buscar y
eliminar los errores de los programas.
Para comenzar el desarrollo de una aplicacin con GeneXus, el primer paso
consiste en crear un nuevo proyecto o base de conocimiento.
Una vez creada una nueva base de conocimiento (cuyo trmino en ingls es:
knowdlege base), el siguiente paso es describir las visiones de los usuarios.
Para ello, se deben identificar los objetos de la realidad (prestando atencin a
los sustantivos que los usuarios mencionan en sus descripciones, como por
ejemplo: clientes, productos, facturas) y pasar a definirlos mediante objetos
GeneXus.
Con la definicin de estos objetos, GeneXus puede extraer el conocimiento y
disenar la base de datos y los programas de la aplicacin en forma totalmente
automtica.
12
REALIDAD
Desarrollo con Desarrollo con GeneXus GeneXus
DESCRIPCIN
DE OBJETOS
BASE
DE
DATOS
PROGRAMAS
BASE DE
CONOCIMIENTO
A partir de los objetos definidos en la base de conocimiento, GeneXus
genera automticamente tanto los programas de creacin /
reorganizacin de la base de datos como los programas de la aplicacin.
Si un objeto de la realidad cambia, si se identifican nuevas o diferentes
caracteristicas acerca del mismo, o si se encuentran objetos aun no
modelados, el analista GeneXus debe reflejar dichos cambios en los
objetos GeneXus que corresponda, y la herramienta se encargara
automaticamente de realizar las modificaciones necesarias tanto en la base
de datos como en los programas asociados.
La metodologia GeneXus es una metodologa incremental, pues parte de
la base que la construccin de un sistema se realiza mediante
aproximaciones sucesivas.
En cada momento el analista GeneXus define el conocimiento que tiene y
luego cuando pasa a tener mas conocimiento (o simplemente diferente), lo
refleja en la base de conocimiento, y GeneXus se ocupara de hacer
automaticamente todas las adaptaciones en la base de datos y programas.
Si GeneXus no fuera capaz de realizar automaticamente las modificaciones
en la base de datos y programas conforme se realicen cambios que asi lo
requieran, el desarrollo incremental seria inviable.
13
Comparacin de Comparacin de
Metodologas Metodologas
ANLISIS
DE
DATOS
BASE
DE
DATOS
ANLISIS
FUNCIONAL
MODELO
DE
DATOS
REALIDAD
PROGRAMACIN
PROGRAMAS
GENERACIN/
INTERPRETACIN
ESPECIFICACIN
FUNCIONAL
DESCRIPCIN
DE OBJETOS
BASE DE
CONOCIMIENTO
Como se ha visto, existen varios caminos para la implementacin de
aplicaciones:
1. Programacin utilizando lenguaje de 3era. generacin.
2. Programacin utilizando lenguajes de 4ta. generacin
3. Generacin / interpretacin automtica de la especificacin funcional.
4. Desarrollo incremental.
La productividad en el desarrollo de aplicaciones aumenta de arriba a abajo.
Disminuir en gran forma el mantenimiento de las aplicaciones (datos y
programas), slo se consigue con el desarrollo incremental.
14
Reportes
{Rpts)
Procedimientos
{Procs)
Work Panels
{Wkps)
Web Panels
{Wbps)
Data Views
{DVs)
Objetos Objetos GeneXus GeneXus
(los ms importantes) (los ms importantes)
Transacciones
{Trns)
Y hay ms, que veremos...
Una vez creada una nueva base de conocimiento, el siguiente paso consiste
en comenzar a describir los objetos de la realidad mediante objetos
GeneXus.
Los objetos GeneXus mas importantes son:
Transacciones
Permiten definir objetos de la realidad -reales o imaginarios- que el usuario
manipula (ej: clientes, productos, proveedores, facturas, etc.). Son los
primeros objetos en definirse, ya que a travs de las transacciones,
GeneXus infiere el diseno de la base de datos.
Ademas de tener por objetivo la definicin de la realidad y la consecuente
creacin de la base de datos normalizada, cada transaccin tiene asociada
una pantalla para ambiente windows y otra para ambiente web, para
permitir al usuario dar altas, bajas y modificaciones en forma interactiva a
la base de datos. El analista GeneXus decidira si trabajar en ambiente
windows, web, o ambos, y GeneXus generara los programas para ello.
Reportes
Permiten recuperar informacin de la base de datos, y desplegarla ya sea en
la pantalla, en un archivo o impresa en papel. Son los tipicos listados o
informes. No permiten actualizar la informacin de la base de datos.
Procedimientos
Tienen las mismas caracteristicas que los reportes, pero a diferencia de
stos, permiten ademas la actualizacin de la informacin de la base de
datos.
15
Work Panels
Permiten al usuario realizar interactivamente consultas a la base de datos, a
travs de una pantalla.
Ejemplo: un work panel permite al usuario ingresar un rango de caracteres, y
muestra a continuacin todos los clientes cuyos nombres se encuentran dentro
del rango.
Son objetos muy flexibles que se prestan para multiples usos.
No permiten la actualizacin de la base de datos, sino solo consultarla.
Web Panels
Son similares a los work panels, salvo que son usados a travs de browsers en
ambiente Internet/Intranet/Extranet.
Data Views
Permiten manejar archivos externos como si fueran archivos pertenecientes a
la base de conocimiento.
Existen algunos tipos mas de objetos GeneXus. Los mencionados son los mas
basicos y de mayor importancia.
16
Proceso de desarrollo de una Proceso de desarrollo de una
aplicacin con aplicacin con GeneXus GeneXus
Base de Conocimiento
Base de Conocimiento
Base Base
de de
Datos Datos
Transacciones
(Trns)
Reportes
(Rpts)
Procedimientos
(Procs)
Work Panels
(Wkps)
Web Panels
(Wbps)
Data Views
(DVs)
Los primeros objetos que se definen son las transacciones, ya que es a partir
de ellas que GeneXus extrae el conocimiento necesario para disenar el
modelo de datos normalizado (en 3era. forma normal).
17
Creacin de la Base de Datos Creacin de la Base de Datos
Base Base
de de
Datos Datos
Programas
Creacin
BD
Base de Conocimiento
Base de Conocimiento
Transacciones
(Trns)
Reportes
(Rpts)
Procedimientos
(Procs)
Work Panels
(Wkps)
Web Panels
(Wbps)
Data Views
(DVs)
GeneXus genera automaticamente los programas necesarios para crear la
base de datos y los ejecuta. De esta manera, obtenemos la base de datos
creada por GeneXus en forma automatica.
18
Programas de Aplicacin
(Trns, Rpts, Procs, Wkps, Wbps, DVs)
Generacin de los Generacin de los
Programas de la Aplicacin Programas de la Aplicacin
Base de Conocimiento
Base de Conocimiento
Base Base
de de
Datos Datos
Transacciones
(Trns)
Reportes
(Rpts)
Procedimientos
(Procs)
Work Panels
(Wkps)
Web Panels
(Wbps)
Data Views
(DVs)
Luego, GeneXus genera programas de aplicacin para interactuar con la
base de datos previamente creada.
19
Resultado final en la Etapa de Resultado final en la Etapa de
Desarrollo Desarrollo
Base de Conocimiento
Base de Conocimiento
Programas de Aplicacin
(Trns, Rpts, Procs, Wkps, Wbps, DVs)
Base Base
de de
Datos Datos
Transacciones
(Trns)
Reportes
(Rpts)
Procedimientos
(Procs)
Work Panels
(Wkps)
Web Panels
(Wbps)
Data Views
(DVs)
En este estado la aplicacin est pronta; es decir, una vez que se ha creado la
base de datos y se han generado los programas, la aplicacin se puede
ejecutar.
20
Las visiones de los usuarios Las visiones de los usuarios
cambian cambian
Base de Conocimiento
Base de Conocimiento
Nueva Nueva
Base Base
de de
Datos Datos
Nuevas
Transacciones
Nuevos
Reportes
Nuevos
Procedimientos
Nuevos
Work Panels
Nuevos
Web Panels
Base Base
de de
Datos Datos
Nuevos
Data Views
Programas de Aplicacin
(Trns, Rpts, Procs, Wkps, Wbps, DVs)
Durante el ciclo de vida de la aplicacin, surgira repetidamente la necesidad de
hacer modificaciones en la base de conocimiento, ya sea porque las visiones de
los usuarios cambian, porque se deben hacer correcciones, o agregar nuevo
conocimiento.
Las modificaciones que se realicen en la base de conocimiento, seran analizadas
por GeneXus para evaluar si es necesario efectuar cambios en la base de datos
(modificacin/creacin de tablas/indices), o no.
En caso de tener que realizar cambios, GeneXus detallara los mismos en un
reporte de anlisis de impacto (IAR: Impact Analisis Report), que es un
reporte que explicita todos los cambios sobre tablas, indices, datos, etc. que
habria que realizar para reflejar la nueva realidad.
Asimismo, el anlisis de impacto informa los eventuales problemas que los
cambios en cuestin podrian ocasionar, como inconsistencias o redundancias.
21
Anlisis de Impacto Totalmente Anlisis de Impacto Totalmente
Automtico Automtico
Anlisis
de
impacto
Base de Conocimiento
Base de Conocimiento
Nueva Nueva
Base Base
de de
Datos Datos
Base Base
de de
Datos Datos
Nuevas
Transacciones
Nuevos
Reportes
Nuevos
Procedimientos
Nuevos
Work Panels
Nuevos
Web Panels
Nuevos
Data Views
Programas de Aplicacin
(Trns, Rpts, Procs, Wkps, Wbps, DVs)
Algunas veces la nueva base de datos coincide con la anterior. Otras veces esto
no ocurre, y la base de datos debe sufrir alguna modificacin para representar
la nueva realidad.
El analista debe estudiar el anlisis de impacto y resolver si desea realizar
efectivamente los cambios en la base de datos, o renunciar a ello dejando la
base de datos como estaba.
22
Generacin de Programas de Generacin de Programas de
Reorganizacin de la Base de Datos Reorganizacin de la Base de Datos
Nueva Nueva
Base Base
de de
Datos Datos
Programas
de
Reorganiz.
Base Base
de de
Datos Datos
Base de Conocimiento
Base de Conocimiento
Nuevas
Transacciones
Nuevos
Reportes
Nuevos
Procedimientos
Nuevos
Work Panels
Nuevos
Web Panels
Nuevos
Data Views
Programas de Aplicacin
(Trns, Rpts, Procs, Wkps, Wbps, DVs)
Si el analista opta por aplicar los cambios propuestos, decimos que opt por
reorganizar la base de datos. Utilizamos este trmino para referirnos a la
accin de aplicar cambios fisicos sobre la base de datos.
GeneXus generara los programas que implementan las modificaciones sobre las
estructuras fisicas de la base de datos -reportadas en el IAR- y mediante su
ejecucin, nos brindara la nueva versin de la base de datos con los cambios
efectuados.
23
Anlisis automtico del impacto de Anlisis automtico del impacto de
los cambios sobre los programas los cambios sobre los programas
Nueva Nueva
Base Base
de de
Datos Datos
Anlisis
de Impacto
sobre los
programas
Base de Conocimiento
Base de Conocimiento
Nuevas
Transacciones
Nuevos
Reportes
Nuevos
Procedimientos
Nuevos
Work Panels
Nuevos
Web Panels
Nuevos
Data Views
Nuevos Programas de Aplicacin
(Trns, Rpts, Procs, Wkps, Wbps, DVs)
Ya sea que se requiera reorganizar la base de datos o no, considerando las
nuevas definiciones introducidas y a pedido del analista, GeneXus estudiar el
impacto de los cambios sobre los programas actuales.
El analista puede seleccionar sobre cules objetos quiere realizar el anlisis (si
sobre todos, los que hayan sufrido cambios, o algunos en particular) y para
cada objeto analizado, GeneXus indicar si es necesario realizar cambios en su
programa de aplicacin, o no.
24
Generacin automtica de nuevos Generacin automtica de nuevos
programas programas
Nueva Nueva
Base Base
de de
Datos Datos
Generacin
de
programas
Base de Conocimiento
Base de Conocimiento
Nuevas
Transacciones
Nuevos
Reportes
Nuevos
Procedimientos
Nuevos
Work Panels
Nuevos
Web Panels
Nuevos
Data Views
Nuevos Programas de Aplicacin
(Trns, Rpts, Procs, Wkps, Wbps, DVs)
Por ltimo, a pedido del analista, GeneXus proseguir con la
generacin/regeneracin de los programas de aplicacin que sean
necesarios, obteniendo as una nueva versin de la aplicacin.
25
Nueva realidad, con los cambios Nueva realidad, con los cambios
en la aplicacin en la aplicacin
Nueva Nueva
Base Base
de de
Datos Datos
Base de Conocimiento
Base de Conocimiento
Nuevas
Transacciones
Nuevos
Procedimientos
Nuevos
Work Panels
Nuevos
Web Panels
Nuevos
Data Views
Nuevos
Reportes
Nuevos Programas de Aplicacin
(Trns, Rpts, Procs, Wkps, Wbps, DVs)
Nuevamente la aplicacin estar apta para ejecutarse, con los cambios aplicados.
26
Consiste en construir una aplicacin mediante aproximaciones
sucesivas.
DEFINICION
INICIAL
Metodologa Incremental Metodologa Incremental
La construccin automtica de la base de datos y programas, permite a
GeneXus aplicar esta metodologa de desarrollo, conocida como
metodologa incremental.
Como ya hemos explicado, este proceso se realiza mediante
aproximaciones sucesivas.
27
Modelos Modelos
Dentro de una base de conocimiento coexisten varios modelos
En particular, existe un modelo que se crea automticamente al
crear una nueva base de conocimiento: el modelo de Diseo
BASE DE CONOCIMIENTO
modelo
de
Diseo
El modelo de Diseo corresponde a la representacin lgica del sistema,
esto es, permite describir la aplicacin sin implementarla.
Esto significa que no existir una base de datos fsica asociada a este
modelo, as como tampoco programas de aplicacin ejecutables. Estos
ltimos existirn solo a un nivel conceptual o lgico.
Son los objetos GeneXus que el analista haya definido dentro de este
modelo los que principalmente describen al sistema. En particular, de las
transacciones especificadas GeneXus obtiene el diseo lgico de la base
de datos, y ellas, en conjunto con el resto de los objetos definidos,
constituyen la descripcin lgica de los programas.
Los programas sern el resultado de la codificacin de los objetos
GeneXus en el lenguaje de programacin elegido por el analista, sobre
una base de datos fsica.
Pero esta implementacin (base de datos y programas), que es
enteramente realizada por GeneXus, dnde se realiza?
Aqu es donde entran en juego los otros modelos que pueden definirse
dentro de la base de conocimiento. Cada uno de estos otros modelos,
contendrn una implementacin del sistema.
28
Modelos Modelos
Existen otros modelos que son creados en forma explcita por el
analista
Por qu tener varios de estos modelos, en lugar de uno solo?
Entre otras razones: para tener cualquier nmero de implementaciones del
mismo sistema, asociadas a diferentes plataformas o ambientes (por
ejemplo: iSeries, PC, Client/Server, Web, etc.).
BASE DE CONOCIMIENTO
modelo
de
Diseo
otro
modelo
otro
modelo
otro
modelo
A diferencia del modelo de Diseo que es creado automticamente,
estos otros modelos son creados en forma explcita por el analista. Al
hacerlo, ste debe ingresar los datos de la plataforma o ambiente de
implementacin correspondiente (lenguaje de programacin, DBMS, etc.)
para que GeneXus pueda implementar el sistema para ese modelo.
Los objetos GeneXus definidos en el modelo de Diseo se copian al nuevo
modelo y stos son los que GeneXus codifica para dicho modelo de
acuerdo a su plataforma.
29
Tipos de Modelos Tipos de Modelos
Cada modelo tiene un tipo:
Design (Diseo):
Un slo modelo en la misma base de conocimiento
No tiene base de datos ni programas de aplicacin asociados
Prototype/Production (Prototipo/Produccin):
Pueden haber varios modelos en la misma base de
conocimiento
Cada uno de estos modelos tiene una base de datos asociada
y programas de aplicacin que se generan para la
plataforma o ambiente elegido
Por cada base de conocimiento, habr un y solo un modelo de Diseo, cuya
caracterstica fundamental es que representa al sistema conceptualmente.
Los otros dos tipos se parecen mucho entre s, dado que todo modelo de
Prototipo o Produccin tiene asociada una plataforma o ambiente que le permite
implementar fsicamente el sistema, siendo sta la caracterstica fundamental
que diferencia a estos modelos del de Diseo. La principal diferencia entre ellos
es conceptual (no funcional) y radica en el uso que se hace de los mismos:
- Un modelo de Prototipo se utiliza en la etapa de desarrollo, justamente para
prototipar la aplicacin -de all su nombre- probando lo modelado, haciendo
modificaciones, volviendo a probar.
-Un modelo de Produccin, por el contrario, se utiliza en la etapa de puesta en
produccin, cuando el prototipo fue aprobado y la aplicacin o los cambios
efectuados ya pueden ser llevados al cliente.
Cuando una aplicacin implementada en GeneXus ha sido puesta en
produccin, necesariamente debern haber al menos 3 modelos definidos en la
base de conocimiento:
-el de Diseo, pues se crea automticamente al crear la base de conocimiento
-uno de Prototipo, utilizado para ir desarrollando y probando la aplicacin
-uno de Produccin, pues es necesario tener una imagen fiel de la aplicacin
que se lleva al cliente, en la plataforma de produccin, como veremos
oportunamente.
30
Diseo
Prototipo Produccin
Ciclos de desarrollo Ciclos de desarrollo
En el desarrollo incremental de una aplicacin, pasaremos repetidamente
del modelo de Diseo al de Prototipo con el que estemos probando la
aplicacin, y de ste nuevamente al de Diseo. Con menor frecuencia se
pasar a Produccin.
Ciclo de prototipacin
El bucle Diseo-Prototipo se recorre repetidamente, construyendo y
probando sucesivos prototipos.
Ciclo de produccin
El bucle Diseo-Produccin se recorre menos frecuentemente, ya que
este ciclo corresponde a la puesta en produccin del sistema y esto se
realiza solamente cuando el prototipo ha sido aprobado o luego de haber
instrumentado y probado algn cambio.
31
Ventajas de la Ventajas de la Prototipacin Prototipacin
Permite ver resultados en forma temprana
Permite el seguimiento de los
requerimientos del usuario
Deteccin de errores en forma temprana
Logra el compromiso de los usuarios con el
desarrollo
Sistemas de mejor calidad
Toda comunicacin es susceptible de errores:
El usuario olvida ciertos detalles
El analista no toma nota de algunos elementos
El usuario se equivoca en algunas apreciaciones
El analista malinterpreta algunas explicaciones del usuario
Como la implementacin de sistemas es habitualmente una tarea que insume
bastante tiempo, y muchos de estos problemas slo son detectados en las pruebas
finales del sistema, el costo en tiempo y dinero de solucionarlos se torna muy
grande. Sabido es que la realidad no permanece esttica, por lo que no es razonable
suponer que se pueden mantener congeladas las especificaciones mientras se
implementa el sistema. Sin embargo, debido al tiempo que suele insumir la
implementacin, muchas veces esto se hace y se acaba implementando una solucin
relativamente insatisfactoria.
El impacto de estos problemas disminuira mucho si se consiguiera probar cada
especificacin inmediatamente y saber cul es la repercusin de cada cambio sobre
el resto del sistema. Una primera aproximacin a esto, ofrecida por diversos
sistemas, es la posibilidad de mostrar al usuario formatos de pantallas, informes,
etc., animados por menes. Esto permite ayudar al usuario a tener una idea de qu
sistema se le construir, pero al final siempre se presentan sorpresas.
Una situacin bastante diferente sera la de poner a disposicin del usuario para su
ejecucin, inmediatamente, una aplicacin funcionalmente equivalente a la deseada,
hasta en los mnimos detalles. Esto es lo que hace GeneXus: un prototipo GeneXus
es una aplicacin pronta, funcionalmente equivalente a la aplicacin de produccin.
Esto solo es posible gracias a la construccin automtica que realiza GeneXus del
soporte computacional.
32
La diferencia entre prototipacin y produccin consiste en que la primera se
hace en un ambiente de microcomputador -aunque puede realizarse sobre
cualquier plataforma de las soportadas por GeneXus- mientras que la de
produccin se realiza en el ambiente objeto del usuario. GeneXus puede
generar cdigo para los siguientes lenguajes: .NET, C/SQL, Cobol para iSeries,
Java, RPG para iSeries, Visual Basic (standalone y Client/Server), Visual Fox Pro
(standalone y Client/Server).
El prototipo permite que la aplicacin sea totalmente probada antes de pasar a
produccin. Durante estas pruebas, el usuario final puede trabajar con datos
reales, probando de una forma natural no solamente formatos de pantallas,
informes, etc., sino tambin frmulas, reglas del negocio, estructuras de datos,
etc.