Vous êtes sur la page 1sur 30
INTRODUCCIÓN TEÓRICA
INTRODUCCIÓN TEÓRICA
Herramientas y Metodologías REALIDAD BASE DE PROGRAMAS DATOS Nuestra tarea como profesionales de la informática consiste
Herramientas y Metodologías
REALIDAD
BASE
DE
PROGRAMAS
DATOS
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.

Modelado de la realidad a partir de las visiones de los usuarios MODELO DE LA REALIDAD
Modelado de la realidad a
partir de las visiones de
los usuarios
MODELO DE
LA REALIDAD
Satisface
Ingeniería Inversa
VISIONES
BASE
DE
DE
PROGRAMAS
USUARIOS
DATOS

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.

Comparación de Metodologías
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.

Metodología Tradicional
Metodología Tradicional
ANÁLISIS DE REALIDAD DATOS MODELO DE DATOS BASE DE DATOS GENERACIÓN/ INTERPRETACIÓN ANÁLISIS FUNCIONAL ESPECIFICACIÓN PROGRAMAS
ANÁLISIS
DE
REALIDAD
DATOS
MODELO
DE
DATOS
BASE
DE
DATOS
GENERACIÓN/
INTERPRETACIÓN
ANÁLISIS
FUNCIONAL
ESPECIFICACIÓN
PROGRAMAS
FUNCIONAL
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.

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.

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

de

las aplicaciones ya

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.

Metodología GeneXus
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.

Desarrollo con GeneXus REALIDAD DESCRIPCIÓN DE OBJETOS Utilizando GeneXus, la tarea básica del analista es la
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.

Desarrollo con GeneXus REALIDAD DESCRIPCIÓN DE OBJETOS BASE BASE DE DE CONOCIMIENTO DATOS PROGRAMAS A partir
Desarrollo con GeneXus
REALIDAD
DESCRIPCIÓN
DE OBJETOS
BASE
BASE DE
DE
CONOCIMIENTO
DATOS
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.

Comparación de Metodologías ANÁLISIS DE REALIDAD DATOS DESCRIPCIÓN DE OBJETOS MODELO DE DATOS BASE DE BASE
Comparación de Metodologías
ANÁLISIS
DE
REALIDAD
DATOS
DESCRIPCIÓN
DE OBJETOS
MODELO
DE
DATOS
BASE DE
BASE
CONOCIMIENTO
DE
DATOS
GENERACIÓN/
INTERPRETACIÓN
ANÁLISIS
FUNCIONAL
ESPECIFICACIÓN
PROGRAMACIÓN
PROGRAMAS
FUNCIONAL

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.

Objetos GeneXus (más importantes) Transacciones Reportes Procedimientos Web Panels (Trns) (Rpts) (Procs) (Wbps) y hay más,
Objetos GeneXus
(más importantes)
Transacciones
Reportes
Procedimientos
Web Panels
(Trns)
(Rpts)
(Procs)
(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 datos 1 .

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 consulta 1 . 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 componentsque lo harán posible, rompiendo con su naturaleza de solo consulta.

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.

Proceso de desarrollo de una aplicación con GeneXus Transacciones Reportes Procedimientos Web Panels (Trns) (Rpts) (Procs)
Proceso de desarrollo de una
aplicación con GeneXus
Transacciones
Reportes
Procedimientos
Web Panels
(Trns)
(Rpts)
(Procs)
(Wbps)
Base de Conocimiento
Base de Conocimiento
Base
Base
dede
Datos
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.
Creación de la Base de Datos Transacciones Reportes Procedimientos Web Panels (Trns) (Rpts) (Procs) (Wbps) Base
Creación de la Base de Datos
Transacciones
Reportes
Procedimientos
Web Panels
(Trns)
(Rpts)
(Procs)
(Wbps)
Base de Conocimiento
Base de Conocimiento
Programas
Base
Base
dede
Creación
Datos
Datos
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.
Generación de los Programas de la aplicación Transacciones Reportes Procedimientos Web Panels (Trns) (Rpts) (Procs) (Wbps)
Generación de los
Programas de la aplicación
Transacciones
Reportes
Procedimientos
Web Panels
(Trns)
(Rpts)
(Procs)
(Wbps)
Base de Conocimiento
Base de Conocimiento
Base
Base
Programas de Aplicación
dede
(Trns, Rpts, Procs, Wkps, Wbps, DVs)
Datos
Datos
Luego, GeneXus genera programas de aplicación para interactuar con la base de datos
previamente creada.
Resultado final en la Etapa de Desarrollo Transacciones Reportes Procedimientos Web Panels (Trns) (Rpts) (Procs) (Wbps)
Resultado final en la Etapa de Desarrollo
Transacciones
Reportes
Procedimientos
Web Panels
(Trns)
(Rpts)
(Procs)
(Wbps)
Base de Conocimiento
Base de Conocimiento
Programas de Aplicación
Base
Base
dede
(Trns, Rpts, Procs, Wkps, Wbps, DVs)
Datos
Datos
Una vez creada la base de datos y generados los programas, contamos con una aplicación pronta
para ejecutar.
Las visiones de los usuarios cambian Nuevas Nuevos Nuevos Nuevos Transacciones Reportes Procedimientos Web Panels Base
Las visiones de los usuarios cambian
Nuevas
Nuevos
Nuevos
Nuevos
Transacciones
Reportes
Procedimientos
Web Panels
Base de Conocimiento
Base de Conocimiento
Programas de Aplicación
Nueva
Nueva
Base
Base
Nueva
Nueva
Base
Base
dede
Base
Base
(Trns, Rpts, Procs, Wkps, Wbps, DVs)
dede
Datos
Datos
dede
Datos
Datos
Datos
Datos
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.

Análisis de Impacto Totalmente Automático Nuevas Nuevos Nuevos Nuevos Transacciones Reportes Procedimientos Web Panels Análisis Base
Análisis de Impacto Totalmente Automático
Nuevas
Nuevos
Nuevos
Nuevos
Transacciones
Reportes
Procedimientos
Web Panels
Análisis
Base de Conocimiento
Base de Conocimiento
de
impacto
Programas de Aplicación
Nueva
Nueva
Base
Base
Nueva
Nueva
Base
Base
dede
Base
Base
(Trns, Rpts, Procs, Wkps, Wbps, DVs)
dede
Datos
Datos
dede
Datos
Datos
Datos
Datos
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.

Generación de Programas de Reorganización de la Base de Datos Nuevas Nuevos Nuevos Nuevos Transacciones Reportes
Generación de Programas de
Reorganización de la Base de Datos
Nuevas
Nuevos
Nuevos
Nuevos
Transacciones
Reportes
Procedimientos
Web Panels
Programas
Base de Conocimiento
Base de Conocimiento
de
Reorganiz.
Programas de Aplicación
Nueva
Nueva
Nueva
Base
Nueva
Base
Base
Base
Base
dede
Base
(Trns, Rpts, Procs, Wkps, Wbps, DVs)
dede
dede
Datos
Datos
Datos
Datos
Datos
Datos

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.

Análisis automático del impacto de los cambios sobre los programas Nuevas Nuevos Nuevos Nuevos Transacciones Reportes
Análisis automático del impacto
de los cambios sobre los programas
Nuevas
Nuevos
Nuevos
Nuevos
Transacciones
Reportes
Procedimientos
Web Panels
Análisis
de Impacto
Base de Conocimiento
Base de Conocimiento
sobre los
programas
Nuevos Programas de
Nueva
Nueva
Aplicación
Base
Base
dede
(Trns, Rpts, Procs, Wkps, Wbps, DVs)
Datos
Datos

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.

Generación automática de nuevos programas Nuevas Nuevos Nuevos Nuevos Transacciones Reportes Procedimientos Web Panels Base de
Generación automática de nuevos programas
Nuevas
Nuevos
Nuevos
Nuevos
Transacciones
Reportes
Procedimientos
Web Panels
Base de Conocimiento
Base de Conocimiento
Generación
de
programas
Nuevos Programas de
Aplicación
Nueva
Nueva
Base
Base
(Trns, Rpts, Procs, Wkps, Wbps, DVs)
dede
Datos
Datos

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.

Nueva realidad, con los cambios en la aplicación Nuevas Nuevos Nuevos Nuevos Transacciones Reportes Procedimientos Web
Nueva realidad, con los cambios en la aplicación
Nuevas
Nuevos
Nuevos
Nuevos
Transacciones
Reportes
Procedimientos
Web Panels
Base de Conocimiento
Base de Conocimiento
Nueva
Nueva
Base
Base
Nuevos Programas de Aplicación
dede
Datos
Datos
De modo que nuevamente contaremos con una aplicación pronta para ejecutar, con los cambios
aplicados.
Metodología Incremental Consiste en construir una aplicación mediante aproximaciones sucesivas. DEFINICION INICIAL La construcción automática de
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.
Modelos Dentro de una base de conocimiento coexisten varios modelos En particular, existe un modelo que
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 especificadas 1 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.

Modelos Existen otros modelos que son creados en forma explícita por el analista ¿Por qué tener
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
otro
otro
otro
de
modelo
modelo
modelo
Diseño

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.

Tipos de Modelo Cada modelo tiene un tipo: Design (Diseño): Un sólo modelo en la misma
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.

Ciclos de desarrollo Diseño Prototipo Producción En el desarrollo incremental de una aplicación, pasaremos repetidamente del
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 Producción.

menor frecuencia se pasará al modelo de

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.

Ventajas de la Prototipación • Permite ver resultados en forma temprana • Permite el seguimiento de
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

computacional (base de datos y programas).

GeneXus

del

soporte