INTRODUCCIÓN TEÓRICA

INTRODUCCIÓN TEÓRICA
1
Herramientas y Metodologías
REALIDAD
BASE
DE
DATOS
PROGRAMAS
Nuestra tarea como profesionales de la informática consiste en desarrollar y mantener
aplicaciones para apoyar al usuario en su actividad. Para realizar esta tarea existen diferentes
herramientas y metodologías.
GeneXus es una herramienta para el desarrollo de aplicaciones sobre bases de datos. Su objetivo
es permitir la implantación de aplicaciones en el menor tiempo y con la mejor calidad posible.
A grandes rasgos, el desarrollo de una aplicación implica tareas de análisis, diseño e
implementación. La vía de GeneXus para alcanzar el objetivo anterior es liberar a las personas
de las tareas automatizables (como el diseño de la base de datos), permitiéndoles así
concentrarse en las tareas realmente difíciles y no automatizables (como comprender los
problemas del usuario).
GeneXus emplea una metodología que tiene un enfoque muy diferente al de las metodologías
más comúnmente utilizadas. Por tanto, aprender a utilizar GeneXus adecuadamente va más allá
de conocer un nuevo lenguaje: lo más importante es aprender su metodología.
2
Modelado de la realidad a
partir de las visiones de
los usuarios
MODELO DE
LA REALIDAD
BASE
DE
DATOS
Satisface
Ingeniería Inversa
PROGRAMAS
VISIONES
DE
USUARIOS
El primer problema al que nos enfrentamos en el desarrollo de aplicaciones es la obtención del
conocimiento de la realidad.
Nadie dentro de la empresa conoce los requerimientos y el alcance de la aplicación a desarrollar
como un todo. Entonces, ¿cómo 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?
Este conocimiento se encuentra en cada una de las visiones de los usuarios. Cada usuario conoce
bien los objetos con los que trabaja cotidianamente, la información que se maneja en ellos, las
reglas que deben seguirse, los cálculos que deben realizarse.
Por lo tanto, el punto de partida de la metodología GeneXus es: describir las visiones de los
usuarios para modelar el sistema; y a partir del modelo de la realidad definido, GeneXus
construye el soporte computacional -base de datos y programas- en forma totalmente
automática.
3
Comparación
de
Metodologías
Para fijar ideas, comparemos las metodologías tradicionales más utilizadas actualmente, con la
metodología utilizada por GeneXus, conocida como metodología incremental.
Las metodologías tradicionales difieren entre sí en varios aspectos, pero tienen una característica
en común: separan el análisis de los datos del de los procesos.
A continuación veremos un esquema general que podría aplicarse a cualquiera de las
metodologías tradicionales actuales y estudiaremos sus problemas.
4
Metodología Tradicional
5
ANÁLISIS
DE
DATOS
REALIDAD
MODELO
DE
DATOS
BASE
DE
DATOS
GENERACIÓN/
INTERPRETACIÓN
ANÁLISIS
FUNCIONAL
ESPECIFICACIÓN
FUNCIONAL
PROGRAMAS
PROGRAMACIÓN
La primera tarea que se realiza generalmente es el Análisis 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 fácil 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 diseñar
esa base de datos, partiendo del modelo de datos.
Construir un sistema integrado, requiere de un modelo de datos corporativo, y
dependiendo del tamaño de la empresa, ésta puede resultar una tarea de enorme
complejidad.
Cuando esto ocurre, la complejidad suele atacarse dividiendo el sistema en módulos
(“divide y vencerás”), cada uno de los cuales soluciona los problemas operativos de un
área específica de la empresa. De esta forma la tarea de modelado se simplifica
notablemente, pero como contrapartida los módulos operan sin una real integración, lo
que provoca que exista información redundante, con todos los problemas que ello acarrea.
En caso de que luego se intente realizar la integración de esos módulos, habrá que realizar
modificaciones sobre los modelos de datos, lo que a pesar de su complejidad es una tarea
realizable. Sin embargo las modificaciones que deberán efectuarse sobre los programas
asociados tienen un costo tan elevado que suelen tornar inviable la integración.
Con la división del sistema en módulos la empresa tendrá resueltos sus problemas
operativos, pero aparecerán indefectiblemente problemas de carencia de información que
permita orientar la gestión y la toma de decisiones de alto nivel. En la órbita gerencial la
información que se necesita es principalmente de naturaleza corporativa, por lo que la
división del sistema en módulos no satisface las necesidades actuales de obtención de
información.
GeneXus soluciona este problema, brindando herramientas y una metodología que hacen
posible y sencilla la creación y mantenimiento de sistemas corporativos.
6
Una vez obtenido el modelo de datos, el siguiente paso de una metodología tradicional es diseñar la base de datos.
Existe una transformación trivial entre un buen modelo de datos y el diseño de la base de datos necesaria para
soportarlo.
Sin embargo, el modelo de datos no es suficiente para desarrollar los programas de aplicación, ya que el mismo
describe los datos, pero no los comportamientos. Se recurre, entonces, a una tarea llamada Análisis Funcional,
donde se estudia la empresa desde el punto de vista de las funciones existentes, y el resultado de dicha tarea es
una Especificación Funcional.
Sería deseable que la especificación funcional fuera independiente de la especificación de datos, lo que no ocurre
en las metodologías estudiadas. Las modificaciones en el diseño de la base de datos implican la necesidad de
revisar las especificaciones funcionales, siendo esta la causa fundamental de los grandes costos de mantenimiento
que tienen estos sistemas.
Una vez que se cuenta con la base de datos y la especificación funcional, ya están dadas las condiciones para crear
los programas de la aplicación.
Para ello se cuenta hoy en día con varias alternativas:
• Programación en lenguajes de tercera y cuarta generación (L3G, L4G)
• Generación/Interpretación
Desde un punto de vista conceptual no hay diferencia entre la programación en lenguajes de 3ra. y de 4ta.
generación. En ambos casos el analista debe estudiar el problema, transformarlo en un algoritmo y codificarlo en el
lenguaje de programación elegido.
La principal diferencia radica en que en los lenguajes de 4ta. generación se escribe mucho menos código
(aproximadamente 10 veces menos) y, como consecuencia, la productividad es mucho mayor y el número de
errores cometidos es mucho menor.
El problema 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. generación permiten aumentos de productividad muy grandes sobre los
de 3ra. en la tarea de desarrollo, pero no ayudan en la etapa de mantenimiento.
Otra alternativa es la utilización de un “generador”: una herramienta que puede interpretar una especificación
funcional y producir automáticamente los programas. Aquí 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 codificación
procedural alguna). Por ello la especificación funcional debe ser formal y rigurosa. Existen actualmente en el
mercado varias herramientas de esta clase.
Existe asimismo otra categoría de herramientas conceptualmente idéntica: la de aquellas que simplemente
“interpretan” la especificación. La programación en ambos casos es totalmente automática, por lo que el aumento
de productividad sobre las herramientas de 3ra. y 4ta. generación es muy grande.
El problema visto -las descripciones de los procesos dependen de la base de datos- afecta también a las
aplicaciones generadas mediante estas herramientas. Como consecuencia, los Generadores e Intérpretes (como
los lenguajes de 4ta. generación) no ayudan lo suficiente en la tarea de mantenimiento.
En definitiva, 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. El costo de mantenimiento, claro está,
difiere enormemente entre las distintas alternativas vistas, ya que en el caso de la utilización de Generadores o
Intérpretes, una vez modificadas las especificaciones funcionales la generación de los programas es automática.
Si el siguiente postulado: “puede obtenerse una base de datos estable” fuera verdadero, los problemas anteriores
serían irrelevantes. Sin embargo, sobran contraejemplos que hablan de lo contrario.
Conclusiones:
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 múltiples
interlocutores, cada uno de los cuales aporta su propia subjetividad. Como consecuencia, durante todo el ciclo de
vida de la aplicación se producen cambios en el modelo.
7
Aun si se considerara la situación ideal, en la cuál se conocen exactamente las necesidades y por tanto es
posible definir la base de datos óptima, el modelo, de todas formas, no podrá permanecer estático, ya que debe
acompañar la evolución de la empresa.
Todo esto sería poco importante si la especificación funcional y la base de datos fueran independientes. Sin
embargo, dado que la especificación funcional se refiere a la base de datos, las inevitables modificaciones en
esta última, implican modificaciones (manuales) en la primera.
Las principales consecuencias de lo anterior son los altos costos de mantenimiento: en la mayoría de las
empresas que trabajan de una manera convencional se admite que el 80% de los recursos que teóricamente
están destinados al desarrollo, realmente se utilizan para hacer mantenimiento de las aplicaciones ya
implementadas.
Dado que es muy difícil 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 degradación de la calidad de los sistemas y el incremento de
los costos de mantenimiento.
8
Metodología GeneXus
Los fundadores de ARTech han desarrollado una amplia actividad de consultoría internacional en
diseño de grandes bases de datos, trabajando con verdaderos modelos corporativos con cientos
de tablas.
En su trayectoria, se convencieron de que no debía perderse más tiempo buscando algo que no
existe: las bases de datos estables.
Luego de importantes investigaciones, desarrollaron una teoría, organizaron una metodología e
implementaron una herramienta para posibilitar el desarrollo incremental y permitir la
convivencia con las bases de datos reales –inestables- a un costo mínimo.
9
Desarrollo con GeneXus
REALIDAD
DESCRIPCIÓN
DE OBJETOS
Utilizando GeneXus, la tarea básica del analista es la descripción de la realidad. Sólo el ser
humano puede desarrollar esta tarea ya que sólo él puede entender el problema del usuario.
El analista GeneXus trabaja en alto nivel, en vez de realizar tareas de bajo nivel como: diseñar
archivos, normalizar, diseñar programas, programar, buscar y eliminar los errores de los
programas.
Para comenzar el desarrollo de una aplicación con GeneXus, el primer paso consiste en crear un
nuevo proyecto o base de conocimiento.
Una vez creada una nueva base de conocimiento (en inglés: knowledge base; abreviado: KB), el
siguiente paso es describir las visiones de los usuarios. Para ello se deben identificar los objetos
de la realidad (prestando atención 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 definición de estos objetos, GeneXus puede extraer el conocimiento y diseñar la base de
datos y los programas de la aplicación en forma automática.
10
Desarrollo con GeneXus
REALIDAD
BASE
DE
DATOS
DESCRIPCIÓN
DE OBJETOS
BASE DE
CONOCIMIENTO
PROGRAMAS
A partir de los objetos definidos en la base de conocimiento, GeneXus genera
automáticamente tanto los programas de creación / reorganización de la base de
datos como los programas de la aplicación.
Luego, si un objeto de la realidad cambia, si se identifican nuevas o diferentes
características del mismo, o si se encuentran objetos aún no modelados, el analista
GeneXus debe reflejar dichos cambios en los objetos GeneXus que correspondan, y la
herramienta se encargará automáticamente de realizar las modificaciones necesarias tanto
en la base de datos como en los programas asociados.
La metodología GeneXus es una metodología incremental, pues parte de la base de que
la construcción 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 más conocimiento (o simplemente diferente) lo refleja en la base de
conocimiento y GeneXus se ocupará de hacer automáticamente todas las adaptaciones
en la base de datos y programas.
Si GeneXus no fuera capaz de realizar automáticamente las modificaciones en la base de
datos y programas conforme se realicen cambios que así lo requieran, el desarrollo
incremental sería inviable.
11
Comparación de Metodologías
ANÁLISIS
DE
DATOS
REALIDAD
DESCRIPCIÓN
DE OBJETOS
MODELO
DE
DATOS
BASE DE
CONOCIMIENTO
BASE
DE
DATOS
GENERACIÓN/
INTERPRETACIÓN
ANÁLISIS
FUNCIONAL
ESPECIFICACIÓN
FUNCIONAL
PROGRAMACIÓN
PROGRAMAS
Como se ha visto, existen varios caminos para la implementación de aplicaciones:
1. Programación utilizando lenguajes de 3era. generación.
2. Programación utilizando lenguajes de 4ta. generación
3. Generación / interpretación automática de la especificación 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), sólo se
consigue con el desarrollo incremental.
12
Objetos GeneXus
(más importantes)
Transacciones
(Trns)
Reportes
(Rpts)
Procedimientos
(Procs)
Web Panels
(Wbps)
y hay más, que veremos...
Una vez creada una base de conocimiento, el siguiente paso consiste en comenzar a
describir los objetos de la realidad mediante objetos GeneXus.
Los objetos GeneXus más importantes son:
Transacciones
Permiten definir los objetos de la realidad que el usuario manipula (ej: clientes, productos,
proveedores, facturas, etc.). Son los primeros objetos en definirse, ya que a través de las
transacciones, GeneXus infiere el diseño de la base de datos.
Además de tener por objetivo la definición de la realidad y la consecuente creación de la
base de datos normalizada, cada transacción 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 decidirá si
trabajar en ambiente windows, Web, o ambos, y GeneXus generará los programas para
ello.
Reportes
Permiten recuperar información de la base de datos, y desplegarla ya sea en la pantalla, en
un archivo o impresa en papel. Son los típicos listados o informes. No permiten actualizar la
información de la base de datos1.
Procedimientos
Tienen las mismas características que los reportes, pero a diferencia de éstos, permiten
además la actualización de la información de la base de datos.
Web Panels
Permiten al usuario realizar interactivamente consultas a la base de datos, a través de una
pantalla. Ejemplo: un web panel que permite al usuario ingresar un rango de caracteres y
muestra a continuación todos los clientes cuyos nombres se encuentran dentro del rango.
Son objetos muy flexibles que se utilizan exclusivamente en ambiente web y se prestan
para múltiples usos. No permiten la actualización de la base de datos, sino solo su consulta1.
Son usados a través de browsers en ambiente Internet/Intranet/Extranet.
-----------------------------------------------------------------------------------------------------1 No es inherente a este tipo de objetos la modificación de la base de datos, pero como
veremos más adelante, existen unos componentes llamados “business components” que lo
harán posible, rompiendo con su naturaleza de solo consulta.
13
Existen algunos tipos más de objetos GeneXus, algunos de los cuales veremos en este curso,
como los Subtype Groups y los Structured Data Types, que si bien son objetos que se
definen en la base de conocimiento (KB) mediante el mismo procedimiento que los ya
mencionados, tienen algunas características que los diferencian de la mayoría de ellos, como el
hecho de no generar programas propios, sino que su conocimiento es reutilizado dentro de los
otros objetos.
14
Proceso de desarrollo de una
aplicación con GeneXus
Transacciones
(Trns)
Reportes
(Rpts)
Procedimientos
(Procs)
Web Panels
(Wbps)
Base
Basede
deConocimiento
Conocimiento
Base
de
Datos
Los primeros objetos que se definen son las transacciones, ya que es a partir de ellas que
GeneXus extrae el conocimiento necesario para diseñar el modelo de datos normalizado (en
3era. forma normal). Luego se van definiendo los demás objetos que correspondan.
15
Creación de la Base de Datos
Transacciones
(Trns)
Reportes
(Rpts)
Procedimientos
(Procs)
Web Panels
(Wbps)
Base
Basede
deConocimiento
Conocimiento
Base
de
Datos
Programas
Creación
BD
GeneXus genera automáticamente 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
automática.
16
Generación de los
Programas de la aplicación
Transacciones
(Trns)
Reportes
(Rpts)
Procedimientos
(Procs)
Web Panels
(Wbps)
Base
Basede
deConocimiento
Conocimiento
Base
de
Datos
Programas de Aplicación
(Trns, Rpts, Procs, Wkps, Wbps, DVs)
Luego, GeneXus genera programas de aplicación para interactuar con la base de datos
previamente creada.
17
Resultado final en la Etapa de Desarrollo
Transacciones
(Trns)
Reportes
(Rpts)
Procedimientos
(Procs)
Web Panels
(Wbps)
Base
Basede
deConocimiento
Conocimiento
Base
de
Datos
Programas de Aplicación
(Trns, Rpts, Procs, Wkps, Wbps, DVs)
Una vez creada la base de datos y generados los programas, contamos con una aplicación pronta
para ejecutar.
18
Las visiones de los usuarios cambian
Nuevas
Transacciones
Nuevos
Reportes
Nuevos
Procedimientos
Nuevos
Web Panels
Base
Basede
deConocimiento
Conocimiento
Base
de
Datos
Nueva
Nueva
Base
Base
de
de
Datos
Datos
Programas de Aplicación
(Trns, Rpts, Procs, Wkps, Wbps, DVs)
Durante el ciclo de vida de la aplicación, surgirá 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 simplemente agregar nuevo conocimiento.
Las modificaciones que se realicen sobre la base de conocimiento serán analizadas por
GeneXus para evaluar si es necesario efectuar cambios en la base de datos (por
ejemplo: modificación/creación de tablas/índices), o no.
En caso de detectar cambios para efectuar en la base datos, GeneXus detallará los mismos en un
reporte de análisis de impacto (IAR: Impact Analisis Report), que es un reporte que
explicita todos los cambios sobre tablas, índices, datos, etc. que habría que realizar para reflejar
la nueva realidad.
Asimismo, en el reporte de análisis de impacto se informan los eventuales problemas que los
cambios en cuestión podrían ocasionar, como inconsistencias o redundancias.
19
Análisis de Impacto Totalmente Automático
Nuevas
Transacciones
Análisis
de
impacto
Base
de
Datos
Nuevos
Reportes
Nuevos
Procedimientos
Nuevos
Web Panels
Base
Basede
deConocimiento
Conocimiento
Nueva
Nueva
Base
Base
de
de
Datos
Datos
Programas de Aplicación
(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 modificación para representar la nueva realidad.
El analista debe estudiar el reporte de análisis 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.
20
Generación de Programas de
Reorganización de la Base de Datos
Nuevas
Transacciones
Programas
de
Reorganiz.
Base
de
Datos
Nuevos
Reportes
Nuevos
Procedimientos
Nuevos
Web Panels
Base
Basede
deConocimiento
Conocimiento
Nueva
Nueva
Base
Base
de
de
Datos
Datos
Programas de Aplicación
(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 término para referirnos a la acción de aplicar cambios físicos sobre la
base de datos.
GeneXus generará los programas que implementan las modificaciones sobre las
estructuras físicas de la base de datos, y mediante su ejecución nos brindará la nueva
versión de la base de datos con los cambios efectuados.
21
Análisis automático del impacto
de los cambios sobre los programas
Nuevas
Transacciones
Nuevos
Reportes
Nuevos
Procedimientos
Base
Basede
deConocimiento
Conocimiento
Nueva
Base
de
Datos
Nuevos
Web Panels
Análisis
de Impacto
sobre los
programas
Nuevos Programas de
Aplicación
(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 podrá seleccionar sobre cuáles objetos quiere realizar el análisis (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 aplicación, o no.
22
Generación automática de nuevos programas
Nuevas
Transacciones
Nuevos
Reportes
Nuevos
Procedimientos
Base
Basede
deConocimiento
Conocimiento
Nueva
Base
de
Datos
Nuevos
Web Panels
Generación
de
programas
Nuevos Programas de
Aplicación
(Trns, Rpts, Procs, Wkps, Wbps, DVs)
Por último, a pedido del analista, GeneXus proseguirá con la generación/regeneración
de los programas de aplicación que sean necesarios, obteniendo así una nueva
versión de la aplicación.
23
Nueva realidad, con los cambios en la aplicación
Nuevas
Transacciones
Nuevos
Reportes
Nuevos
Procedimientos
Nuevos
Web Panels
Base
Basede
deConocimiento
Conocimiento
Nueva
Base
de
Datos
Nuevos Programas de Aplicación
De modo que nuevamente contaremos con una aplicación pronta para ejecutar, con los cambios
aplicados.
24
Metodología Incremental
Consiste en construir una aplicación mediante aproximaciones
sucesivas.
DEFINICION
INICIAL
La construcción automática de la base de datos y programas, permite a GeneXus
aplicar esta metodología de desarrollo, conocida como metodología incremental.
Como ya hemos explicado, este proceso se realiza mediante aproximaciones
sucesivas.
25
Modelos
Î Dentro de una base de conocimiento coexisten varios modelos
Î En particular, existe un modelo que se crea automáticamente al
crear una nueva base de conocimiento: el modelo de Diseño
BASE DE CONOCIMIENTO
modelo
de
Diseño
El modelo de Diseño corresponde a la representación lógica del sistema, esto es,
permite describir la aplicación sin implementarla.
Esto significa que no existirá una base de datos física asociada a este modelo, así como
tampoco programas de aplicación ejecutables. Estos últimos existirán solo a un nivel
conceptual o lógico.
Son los objetos GeneXus que el analista haya definido dentro de este modelo los que
principalmente describen al sistema. En particular, de las transacciones especificadas1
GeneXus obtiene el diseño lógico de la base de datos, y ellas, en conjunto con el resto de
los objetos definidos, constituyen la descripción lógica de los programas.
Los programas serán el resultado de la codificación de los objetos GeneXus en el
lenguaje de programación elegido por el analista, sobre una base de datos física.
Pero esta implementación (base de datos y programas), que es enteramente realizada
por GeneXus, ¿dónde 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, contendrán una implementación
del sistema.
-------------------------------------------------------------------------------------------------En conjunción con los grupos de subtipos (objetos Subtype Group) y los índices de
usuario.
1
26
Modelos
Î Existen otros modelos que son creados en forma explícita por el
analista
Î ¿Por qué tener varios de estos modelos, en lugar de uno solo?
Î Entre otras razones: para tener cualquier número de implementaciones del
mismo sistema, asociadas a diferentes plataformas o ambientes (por
ejemplo: iSeries, PC, Client/Server, Web, etc.).
BASE DE CONOCIMIENTO
modelo
de
Diseño
otro
modelo
otro
modelo
otro
modelo
A diferencia del modelo de Diseño que es creado automáticamente, estos otros
modelos son creados en forma explícita por el analista. Al hacerlo, éste debe ingresar
los datos de la plataforma o ambiente de implementación correspondiente (lenguaje de
programación, DBMS, etc.) para que GeneXus pueda implementar el sistema para ese
modelo.
Los objetos GeneXus definidos en el modelo de Diseño se copian al nuevo modelo y éstos
son los que GeneXus codifica para dicho modelo de acuerdo a su plataforma.
27
Tipos de Modelo
Î Cada modelo tiene un tipo:
Î Design (Diseño):
ÎUn sólo modelo en la misma base de conocimiento.
ÎNo tiene base de datos ni programas de aplicación
asociados.
Î Prototype/Production (Prototipo/Producción):
ÎPuede haber varios modelos en la misma base de
conocimiento.
ÎCada uno de estos modelos tiene una base de datos
asociada y programas de aplicación que se generan para la
plataforma o ambiente elegido.
Por cada base de conocimiento, habrá un y sólo un modelo de Diseño, cuya característica
fundamental es que representa al sistema conceptualmente.
Los otros dos tipos se parecen mucho entre sí, dado que todo modelo de Prototipo o Producción
tiene asociada una plataforma o ambiente que le permite implementar físicamente el sistema,
siendo ésta la característica fundamental que diferencia a estos modelos del de Diseño. 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
aplicación –de allí su nombre- probando lo modelado, haciendo modificaciones, volviendo a
probar.
-Un modelo de Producción, por el contrario, se utiliza en la etapa de puesta en producción,
cuando el prototipo fue aprobado y la aplicación o los cambios efectuados ya pueden ser llevados
al cliente.
Cuando una aplicación implementada en GeneXus ha sido puesta en producción, necesariamente
deberá haber al menos 3 modelos definidos en la base de conocimiento:
- el de Diseño, pues se crea automáticamente al crear la base de conocimiento,
- uno de Prototipo, utilizado para ir desarrollando y probando la aplicación,
- uno de Producción, pues es necesario tener una imagen fiel de la aplicación que se lleva al
cliente, en la plataforma de producción, como veremos oportunamente.
28
Ciclos de desarrollo
Diseño
Prototipo
Producción
En el desarrollo incremental de una aplicación, pasaremos repetidamente del modelo de
Diseño al modelo de Prototipo con el que estemos probando la aplicación, y de éste
nuevamente al modelo de Diseño. Con menor frecuencia se pasará al modelo de
Producción.
Ciclo de prototipación
El bucle Diseño-Prototipo se recorre repetidamente, construyendo y probando sucesivos
prototipos.
Ciclo de producción
El bucle Diseño-Producción se recorre menos frecuentemente, ya que este ciclo
corresponde a la puesta en producción del sistema y esto se realiza solamente cuando el
prototipo ha sido aprobado o luego de haber instrumentado y probado algún cambio.
29
Ventajas de la Prototipación
•
•
•
•
•
Permite ver resultados en forma temprana
Permite el seguimiento de los requerimientos del usuario
Detección de errores en forma temprana
Logra el compromiso de los usuarios con el desarrollo
Sistemas de mejor calidad
Toda comunicación es susceptible de errores:
•
•
•
•
El
El
El
El
usuario olvida ciertos detalles
analista no toma nota de algunos elementos
usuario se equivoca en algunas apreciaciones
analista malinterpreta algunas explicaciones del usuario
Como la implementación de sistemas es habitualmente una tarea que insume bastante tiempo, y
muchos de estos problemas sólo 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 estática, 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 implementación, muchas
veces esto se hace y se acaba implementando una solución relativamente insatisfactoria.
El impacto de estos problemas disminuiría mucho si se consiguiera probar cada especificación
inmediatamente y saber cuál es la repercusión de cada cambio sobre el resto del sistema. Una primera
aproximación a esto, ofrecida por diversos sistemas, es la posibilidad de mostrar al usuario formatos
de pantallas, informes, etc., animados por menús. Esto permite ayudar al usuario a tener una idea de
qué sistema se le construirá, pero al final siempre se presentan sorpresas.
Una situación bastante diferente sería la de poner a disposición del usuario para su ejecución, una
aplicación funcionalmente equivalente a la deseada hasta en los mínimos detalles. Y esto es lo que
ofrece GeneXus! Un prototipo GeneXus es una aplicación pronta funcionalmente equivalente a la
aplicación de producción.
Así es que la aplicación puede ser totalmente probada antes de ponerse en producción; y durante las
pruebas, el usuario final puede probar de una forma natural no solamente formatos de pantallas,
informes, etc., sino también fórmulas, reglas del negocio, estructuras de datos, etc., y trabajar con
datos reales.
Esto solo es posible gracias a la construcción automática que realiza GeneXus del soporte
computacional (base de datos y programas).
30