INTRODUCCIN TERICA

Herramientas y Metodologas
REALIDAD

BASE DE DATOS

PROGRAMAS

Nuestra tarea como profesionales de la informtica consiste en desarrollar y mantener aplicaciones para apoyar al usuario en su actividad. Para realizar esta tarea existen diferentes herramientas y metodologas. 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. A grandes rasgos, el desarrollo de una aplicacin implica tareas de anlisis, diseo e implementacin. La va de GeneXus para alcanzar el objetivo anterior es liberar a las personas de las tareas automatizables (como el diseo de la base de datos), permitindoles as concentrarse en las tareas realmente difciles y no automatizables (como comprender los problemas del usuario). GeneXus emplea una metodologa que tiene un enfoque muy diferente al de las metodologas ms comnmente utilizadas. Por tanto, aprender a utilizar GeneXus adecuadamente va ms all de conocer un nuevo lenguaje: lo ms importante es aprender su metodologa.

Modelado de la realidad a partir de las visiones de los usuarios

MODELO DE LA REALIDAD

Satisface Ingeniera Inversa

BASE DE DATOS

PROGRAMAS

VISIONES DE USUARIOS

El primer problema al que nos enfrentamos en el desarrollo de aplicaciones es la obtencin del conocimiento de la realidad. Nadie dentro de la empresa conoce los requerimientos y el alcance de la aplicacin a desarrollar como un todo. Entonces, cmo 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 informacin que se maneja en ellos, las reglas que deben seguirse, los clculos que deben realizarse. Por lo tanto, el punto de partida de la metodologa 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 automtica.

Comparacin de 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 podra aplicarse a cualquiera de las metodologas tradicionales actuales y estudiaremos sus problemas.

Metodologa Tradicional

ANLISIS DE DATOS

REALIDAD

MODELO DE DATOS

BASE DE DATOS GENERACIN/ INTERPRETACIN

ANLISIS FUNCIONAL ESPECIFICACIN FUNCIONAL

PROGRAMAS PROGRAMACIN

La primera 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 fcil 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 disear esa base de datos, partiendo del modelo de datos. Construir un sistema integrado, requiere de un modelo de datos corporativo, y dependiendo del tamao 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 rea especfica 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, 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 debern efectuarse sobre los programas asociados tienen un costo tan elevado que suelen tornar inviable la integracin. Con la divisin del sistema en mdulos la empresa tendr resueltos sus problemas operativos, pero aparecern 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 metodologa que hacen posible y sencilla la creacin y mantenimiento de sistemas corporativos.

Una vez obtenido el modelo de datos, el siguiente paso de una metodologa tradicional es disear la base de datos. Existe una transformacin trivial entre un buen modelo de datos y el diseo 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. Sera deseable que la especificacin funcional fuera independiente de la especificacin de datos, lo que no ocurre en las metodologas estudiadas. Las modificaciones en el diseo 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 especificacin funcional, ya estn dadas las condiciones para crear los programas de la aplicacin. Para ello se cuenta hoy en da con varias alternativas: Programacin en lenguajes de tercera y cuarta generacin (L3G, L4G) 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 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 nmero 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. generacin 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 utilizacin de un generador: una herramienta que puede interpretar una especificacin funcional y producir automticamente 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 codificacin procedural alguna). Por ello la especificacin funcional debe ser formal y rigurosa. Existen actualmente en el mercado varias herramientas de esta clase. Existe asimismo otra categora de herramientas conceptualmente idntica: la de aquellas que simplemente interpretan la especificacin. La programacin en ambos casos es totalmente automtica, por lo que el aumento de productividad sobre las herramientas de 3ra. y 4ta. generacin es muy grande. 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 e Intrpretes (como los lenguajes de 4ta. generacin) 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 utilizacin de Generadores o Intrpretes, una vez modificadas las especificaciones funcionales la generacin de los programas es automtica. Si el siguiente postulado: puede obtenerse una base de datos estable fuera verdadero, los problemas anteriores seran 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 mltiples 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 cul se conocen exactamente las necesidades y por tanto es posible definir la base de datos ptima, el modelo, de todas formas, no podr permanecer esttico, ya que debe acompaar la evolucin de la empresa. Todo esto sera 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 ltima, implican modificaciones (manuales) en la primera. Las principales consecuencias de lo anterior son los altos costos de mantenimiento: en la mayora de las empresas que trabajan de una manera convencional se admite que el 80% de los recursos que tericamente estn destinados al desarrollo, realmente se utilizan para hacer mantenimiento de las aplicaciones ya implementadas. Dado que es muy difcil 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.

Metodologa 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.

Desarrollo con GeneXus

REALIDAD
DESCRIPCIN DE OBJETOS

Utilizando GeneXus, la tarea bsica del analista es la descripcin de la realidad. Slo el ser humano 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: disear archivos, normalizar, disear 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 (en ingls: 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 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 disear la base de datos y los programas de la aplicacin en forma automtica.

10

Desarrollo con GeneXus

REALIDAD

DESCRIPCIN DE OBJETOS

BASE DE DATOS

BASE DE CONOCIMIENTO

PROGRAMAS

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. Luego, si un objeto de la realidad cambia, si se identifican nuevas o diferentes caractersticas del mismo, o si se encuentran objetos an no modelados, el analista GeneXus debe reflejar dichos cambios en los objetos GeneXus que correspondan, y la herramienta se encargar automticamente de realizar las modificaciones necesarias tanto en la base de datos como en los programas asociados. La metodologa GeneXus es una metodologa incremental, pues parte de la base de 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 ms conocimiento (o simplemente diferente) lo refleja en la base de conocimiento y GeneXus se ocupar de hacer automticamente todas las adaptaciones en la base de datos y programas. Si GeneXus no fuera capaz de realizar automticamente las modificaciones en la base de datos y programas conforme se realicen cambios que as lo requieran, el desarrollo incremental sera inviable.

11

Comparacin de Metodologas
ANLISIS DE DATOS

REALIDAD
DESCRIPCIN DE OBJETOS

MODELO DE DATOS

BASE DE DATOS GENERACIN/ INTERPRETACIN ANLISIS FUNCIONAL

BASE DE CONOCIMIENTO

ESPECIFICACIN FUNCIONAL

PROGRAMACIN

PROGRAMAS

Como se ha visto, existen varios caminos para la implementacin de aplicaciones: 1. Programacin utilizando lenguajes 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.

12

Objetos GeneXus (ms importantes)

Transacciones (Trns) Reportes (Rpts) Procedimientos (Procs) Work Panels (Wkps) Web Panels (Wbps)

y hay ms, 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 ms 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 travs de las transacciones, GeneXus infiere el diseo de la base de datos. Adems 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 decidir si trabajar en ambiente windows, Web, o ambos, y GeneXus generar 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 tpicos listados o informes. No permiten actualizar la informacin de la base de datos1. Procedimientos Tienen las mismas caractersticas que los reportes, pero a diferencia de stos, permiten adems la actualizacin de la informacin de la base de datos. 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 utilizan exclusivamente en ambiente windows y se prestan para mltiples usos. No permiten la actualizacin de la base de datos, sino solo su consulta1. -----------------------------------------------------------------------------------------------------1 No es inherente a este tipo de objetos la modificacin de la base de datos, pero como veremos ms adelante, existen unos componentes llamados business components que lo harn posible, rompiendo con su naturaleza de solo consulta.

13

Web Panels Son similares a los work panels, salvo que son usados a travs de browsers en ambiente Internet/Intranet/Extranet. Existen algunos tipos ms 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 caractersticas que los diferencian de la mayora 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 aplicacin con GeneXus

Transacciones (Trns) Reportes (Rpts) Procedimientos (Procs) Work Panels (Wkps) 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 disear el modelo de datos normalizado (en 3era. forma normal). Luego se van definiendo los dems objetos que correspondan.

15

Creacin de la Base de Datos

Transacciones (Trns) Reportes (Rpts) Procedimientos (Procs) Work Panels (Wkps) Web Panels (Wbps)

Base Basede deConocimiento Conocimiento

Base de Datos

Programas Creacin BD

GeneXus genera automticamente 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 automtica.

16

Generacin de los Programas de la aplicacin

Transacciones (Trns) Reportes (Rpts) Procedimientos (Procs) Work Panels (Wkps) Web Panels (Wbps)

Base Basede deConocimiento Conocimiento

Base de Datos

Programas de Aplicacin
(Trns, Rpts, Procs, Wkps, Wbps, DVs)

Luego, GeneXus genera programas de aplicacin para interactuar con la base de datos previamente creada.

17

Resultado final en la Etapa de Desarrollo

Transacciones (Trns) Reportes (Rpts) Procedimientos (Procs) Work Panels (Wkps) Web Panels (Wbps)

Base Basede deConocimiento Conocimiento

Base de Datos

Programas de Aplicacin
(Trns, Rpts, Procs, Wkps, Wbps, DVs)

Una vez creada la base de datos y generados los programas, contamos con una aplicacin pronta para ejecutar.

18

Las visiones de los usuarios cambian

Nuevas Transacciones Nuevos Reportes Nuevos Procedimientos Nuevos Work Panels Nuevos Web Panels

Base Basede deConocimiento Conocimiento

Base de Datos

Nueva Nueva Base Base de de Datos Datos

Programas de Aplicacin
(Trns, Rpts, Procs, Wkps, Wbps, DVs)

Durante el ciclo de vida de la aplicacin, 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 sern analizadas por GeneXus para evaluar si es necesario efectuar cambios en la base de datos (por ejemplo: modificacin/creacin de tablas/ndices), o no. En caso de detectar cambios para efectuar en la base datos, GeneXus detallar los mismos en un reporte de anlisis de impacto (IAR: Impact Analisis Report), que es un reporte que explicita todos los cambios sobre tablas, ndices, datos, etc. que habra que realizar para reflejar la nueva realidad. Asimismo, en el reporte de anlisis de impacto se informan los eventuales problemas que los cambios en cuestin podran ocasionar, como inconsistencias o redundancias.

19

Anlisis de Impacto Totalmente Automtico

Nuevas Transacciones Nuevos Reportes Nuevos Procedimientos Nuevos Work Panels Nuevos Web Panels

Anlisis de impacto

Base Basede deConocimiento Conocimiento

Base de Datos

Nueva Nueva Base Base de de Datos Datos

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 reporte de 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.

20

Generacin de Programas de Reorganizacin de la Base de Datos

Nuevas Transacciones Nuevos Reportes Nuevos Procedimientos Nuevos Work Panels Nuevos Web Panels

Programas de Reorganiz.

Base Basede deConocimiento Conocimiento

Base de Datos

Nueva Nueva Base Base de de Datos Datos

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 fsicos sobre la base de datos. GeneXus generar los programas que implementan las modificaciones sobre las estructuras fsicas de la base de datos, y mediante su ejecucin nos brindar la nueva versin de la base de datos con los cambios efectuados.

21

Anlisis automtico del impacto de los cambios sobre los programas

Nuevas Transacciones Nuevos Reportes Nuevos Procedimientos Nuevos Work Panels Nuevos Web Panels

Base Basede deConocimiento Conocimiento

Anlisis de Impacto sobre los programas

Nueva Base de Datos

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 podr 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.

22

Generacin automtica de nuevos programas

Nuevas Transacciones Nuevos Reportes Nuevos Procedimientos Nuevos Work Panels Nuevos Web Panels

Base Basede deConocimiento Conocimiento

Generacin de programas

Nueva Base de Datos

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.

23

Nueva realidad, con los cambios en la aplicacin

Nuevas Transacciones Nuevos Reportes Nuevos Procedimientos Nuevos Work Panels Nuevos Web Panels

Base Basede deConocimiento Conocimiento

Nueva Base de Datos

Nuevos Programas de Aplicacin

De modo que nuevamente contaremos con una aplicacin pronta para ejecutar, con los cambios aplicados.

24

Metodologa Incremental
Consiste en construir una aplicacin mediante aproximaciones sucesivas.

DEFINICION INICIAL

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.

25

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 especificadas1 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.

-------------------------------------------------------------------------------------------------1 En conjuncin con los grupos de subtipos (objetos Subtype Group) y los ndices de usuario.

26

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.

27

Tipos de Modelo
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): Puede 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 deber 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.

28

Ciclos de desarrollo

Diseo

Prototipo

Produccin

En el desarrollo incremental de una aplicacin, pasaremos repetidamente del modelo de Diseo al modelo de Prototipo con el que estemos probando la aplicacin, y de ste nuevamente al modelo de Diseo. Con menor frecuencia se pasar al modelo de 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.

29

Ventajas de la 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 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 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 mens. 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, una aplicacin funcionalmente equivalente a la deseada hasta en los mnimos detalles. Y esto es lo que ofrece GeneXus! Un prototipo GeneXus es una aplicacin pronta funcionalmente equivalente a la aplicacin de produccin. As es que la aplicacin puede ser totalmente probada antes de ponerse en produccin; y durante las pruebas, el usuario final puede probar de una forma natural no solamente formatos de pantallas, informes, etc., sino tambin frmulas, reglas del negocio, estructuras de datos, etc., y trabajar con datos reales. Esto solo es posible gracias a la construccin automtica que realiza GeneXus del soporte computacional (base de datos y programas).

30