01-IntroduccionTeorica

1

INTRODUCCIÓN TEÓRICA

2

BASEDE

DATOSPROGRAMAS

REALIDAD

Herramientas y Metodologías

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.

3

VISIONESDE

USUARIOS

SatisfaceMODELO DE

LA REALIDAD Ingeniería Inversa

Modelado de la realidad a partir de las visiones de

los usuarios

BASEDE

DATOSPROGRAMAS

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, GeneXusconstruye el soporte computacional -base de datos y programas- en forma totalmente automática.

4

Comparaciónde

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.

5

Metodología Tradicional

6

ANÁLISISDE

DATOS

BASEDE

DATOS

ANÁLISISFUNCIONAL

PROGRAMACIÓN

PROGRAMAS

GENERACIÓN/INTERPRETACIÓN

ESPECIFICACIÓNFUNCIONAL

MODELODE

DATOS

REALIDAD

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 and conquer”), 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.

7

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.

8

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.

9

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.

10

Desarrollo con GeneXus

REALIDAD

DESCRIPCIÓNDE 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.

11

REALIDAD

Desarrollo con GeneXus


BASEDE

DATOS

PROGRAMAS

BASE DECONOCIMIENTO

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.

12

Comparación de Metodologías

ANÁLISISDE

DATOS

ANÁLISISFUNCIONAL

MODELODE

DATOS

REALIDAD

PROGRAMACIÓN PROGRAMAS

GENERACIÓN/INTERPRETACIÓN

ESPECIFICACIÓNFUNCIONAL


BASE DECONOCIMIENTO

BASEDE

DATOS

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.

13

Reportes(Rpts)

Procedimientos(Procs)

Work Panels (Wkps)

Web Panels(Wbps)

Objetos GeneXus(más importantes)

Transacciones(Trns)

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.

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

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

Work PanelsPermiten al usuario realizar interactivamente consultas a la base de datos, a través de una pantalla. Ejemplo: un work panel 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 windows y se prestan para múltiples usos. No permiten la actualización de la base de datos, sino solo su consulta1.

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

14

Web PanelsSon similares a los work panels, salvo que son usados a través de browsers en ambiente Internet/Intranet/Extranet.

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.

15

Proceso de desarrollo de unaaplicación con GeneXus

Base de ConocimientoBase de Conocimiento

BaseBasede de

DatosDatos

Transacciones(Trns)

Reportes(Rpts)


Work Panels (Wkps)

Web Panels(Wbps)

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.

16

Creación de la Base de Datos

BaseBasede de

DatosDatos

Programas Creación

BD

Reportes(Rpts)


Work Panels (Wkps)

Web Panels(Wbps)


Transacciones(Trns)

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.

17

Programas de Aplicación

(Trns, Rpts, Procs, Wkps, Wbps, DVs)

Generación de los Programas de la aplicación

BaseBasede de

DatosDatos

Reportes(Rpts)


Work Panels (Wkps)

Web Panels(Wbps)


Transacciones(Trns)

Luego, GeneXus genera programas de aplicación para interactuar con la base de datos previamente creada.

18

Resultado final en la Etapa de Desarrollo

BaseBasede de

DatosDatos




Reportes(Rpts)


Work Panels (Wkps)

Web Panels(Wbps)

Transacciones(Trns)

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

19

Las visiones de los usuarios cambian

Nueva Nueva BaseBasede de

DatosDatos

BaseBasede de

DatosDatos



NuevosReportes

NuevosProcedimientos

NuevosWork Panels

NuevosWeb Panels

NuevaNuevaBaseBasede de

DatosDatos

NuevasTransacciones


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

20

Análisis de Impacto Totalmente Automático

Análisisde

impacto

Nueva Nueva BaseBasede de

DatosDatos

BaseBasede de

DatosDatos




DatosDatos

NuevosReportes


NuevosWork Panels

NuevosWeb Panels

NuevasTransacciones


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.

21

Generación de Programas de Reorganización de la Base de Datos

Programasde

Reorganiz.

NuevosReportes


NuevosWork Panels

NuevosWeb Panels

NuevasTransacciones


(Trns, Rpts, Procs, Wkps, Wbps, DVs)Nueva Nueva BaseBasede de

DatosDatos

BaseBasede de

DatosDatos


DatosDatos


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.

22

Análisis automático del impactode los cambios sobre los programas

Análisisde Impacto sobre los programas

NuevosReportes


NuevosWork Panels

NuevosWeb Panels

NuevasTransacciones

Nuevos Programas de Aplicación



DatosDatos


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.

23

Generación automática de nuevos programasNuevos

ReportesNuevos

ProcedimientosNuevos

Work Panels Nuevos

Web PanelsNuevas

Transacciones


DatosDatos



Generación de

programas


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.

24

Nueva realidad, con los cambios en la aplicaciónNuevos

ReportesNuevos

ProcedimientosNuevos

Work Panels Nuevos

Web PanelsNuevas

Transacciones


DatosDatos



De modo que nuevamente contaremos con una aplicación pronta para ejecutar, con los cambios aplicados.

25

Consiste en construir una aplicación mediante aproximacionessucesivas.

DEFINICION INICIAL

Metodología Incremental

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.

26

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

modelode

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.

--------------------------------------------------------------------------------------------------1 En conjunción con los grupos de subtipos (objetos Subtype Group) y los índices de usuario.

27

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

modelode

Diseño

otromodelo

otromodelo

otromodelo

Modelos

A diferencia del modelo de Diseño que es creado automáticamente, estos otros modelosson 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.

28

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

29

Diseño Prototipo Producción

Ciclos de desarrollo

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ónEl bucle Diseño-Prototipo se recorre repetidamente, construyendo y probando sucesivos prototipos.

Ciclo de producciónEl bucle Diseño-Producción se recorre menos frecuentemente, ya que este ciclo correspondea la puesta en producción del sistema y esto se realiza solamente cuando el prototipo hasido aprobado o luego de haber instrumentado y probado algún cambio.

30

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

Documents

01-IntroduccionTeorica