I

UNIVERSIDAD CATÓLICA DE CUENCA

UNIDAD ACADÉMICA DE INGENIERÍA DE SISTEMAS

ELÉCTRICA Y ELECTRÓNICA

FACULTAD DE INGENIERÍA DE SISTEMAS

GENEXUS

“GENEXUS COMO ALTERNATIVA PARA LA CONSTRUCCIÓN DE

SOFTWARE”

TRABAJO DE INVESTIGACIÓN PREVIO A LA OBTENCIÓN DEL TÍTULO DE

INGENIERO EN SISTEMAS

INVESTIGADOR:

JOHNY XAVIER ORTIZ CAMPOVERDE

DIRECTOR:

ING. DIEGO CORDERO

CUENCA – ENERO 2012

II

HOJA DE APROBACIÓN

ING. DIEGO CORDERO

CERTIFICA:

Haber dirigido y revisado prolijamente cada uno de los capítulos del

presente trabajo de investigación de tema: “GENEXUS COMO

ALTERNATIVA PARA LA CONSTRUCCIÓN DE SOFTWARE”,

realizado por el Tnlg. Johny Xavier Ortiz Campoverde, y por

cumplir todos los requisitos, autorizo su presentación.

Cuenca, de 2012.

…………………………………..

Ing. Diego Cordero

DIRECTOR

III

RESPONSABILIDAD

Todos los criterios vertidos en el presente trabajo

de investigación, son de exclusiva responsabilidad

de su autor.

…………………………………..

Tnlg. Johny Xavier Ortiz Campoverde

IV

Dedicatoria

A mi querida Madre, mi esposa y mi hija personas las

cuales me han dado la fuerza, apoyo, comprensión y

todo el cariño que me han brindado en estos años de

estudio, y a través toda mi carrera estudiantil, para

llegar a culminar una etapa muy importante en mi

vida.

Tnlg. Johny Xavier Ortiz Campoverde

V

Agradecimiento

A la Universidad Católica de Cuenca, por permitirme

formarme y forjar mi futuro profesional dentro de tan

prestigiosa institución educativa.

Al Ing. Diego Cordero, por brindarme sus sabios

consejos y su guía a través del desarrollo de esta

investigación.

VI

ÍNDICE

Portada……………………………………………………………………………….I

Hoja de Aprobación………………………………………………………………...II

Responsabilidad…………………………………………………………………….III

Dedicatoria………………………………………………………………………….IV

Agradecimiento……………………………………………………………………...V

Índice……………………………………………………………………………….VI

Introducción………………………………………………………………………….1

CAPÍTULO I

ARQUITECTURA GENEXUS

A. Concepto.………………………………………………………………….….2

B. Arquitectura…….............................................................................................2

C. Protocolos de Comunicación…..……………………………..………….......3

D. ¿Cómo Implementar una Aplicación 3 Capas?………………....……..........4

E. Ciclo de Vida de una Aplicación....................................................................5

F. Principales Características……………………………………..……............5

G. Metodología de GeneXus…………………………………………...............6

H. Base del Conocimiento..................................................................................10

I. Desarrollo Incremental………………………………………………….....10

J. Ciclos de la Herramienta.…........... …………………………………….…..11

CAPÍTULO II

OBJETOS GENEXUS

K. Transacciones....………………………………………………………......13

L. Reportes………….......................................................................................13

M. Procedimientos……………………………………………………………15

N. Work Panels……………………………………………………………….17

O. From……………………………………………………………………….20

P. Web Objects………………………………………………………..………23

Q. Transacciones Web…………………………………………………..........23

R. Web Panels………………………………………………………..….........23

VII

S. Menus…….……………………………………………………….……….24

T. Data Views..………………………………………………………….......24

U. Tables.........................................................................................................27

V. Funcionamiento de reglas…………………………………………..........29

W. Styles…………………………………….................................................37

X. Ejemplo de uso de Themes…..………………………………………..…38

CAPÍTULO III

Y. Análisis de Impacto………….…………………………….…..……….....39

Z. Diagrama de navegación ………………………………………..…….....39

AA. Especificación…………………….……………………………..…….…42

BB. Generación de Programas………………………………………..…….…42

CC. Ejecución…………………………………………….……………..….….42

CAPÍTULO IV

DD. Captura del Conocimiento………………………….………..……….…44

EE. Creación de base de Conocimiento……………….…………...…….…..44

FF. Transacciones de la Aplicación……………..……………………….…..44

GG. Objetos de la Aplicación…………………………………………….…..45

HH. Prototipo…………………………………………………………….…...46

CAPÍTULO V

CONCLUSIONES Y RECOMENDACIONES

II. Conclusión………………………………………………………………..49

JJ. Recomendación…………………………………………………………..49

KK. Bibliografía……………………………………………………………….50

1

INTRODUCCIÓN.

GeneXus es una herramienta para el desarrollo de aplicaciones sobre bases de datos. Su objetivo es ayudar a

los analistas de sistemas a implementar aplicaciones en el menor tiempo y con la mejor calidad posible.

Desde un punto de vista teórico, GeneXus es una herramienta asociada a una metodología de desarrollo de

aplicaciones.

En cuanto a la metodología, tiene algunos puntos de contacto con las metodologías tradicionales, pero aporta

enfoques bastante diferentes en otros. Por otro lado, algunos de los enfoques metodológicos son bastante

diferentes que los habituales, como el comenzar el análisis de la aplicación por la interfaz con el usuario y la casi nula referencia a la implementación física del sistema, entre otros.

Además la herramienta GeneXus es basada en conocimiento, orientada principalmente a aplicaciones de clase

empresarial para la web y plataformas Windows. El desarrollador especifica sus aplicaciones en alto nivel (de

manera mayormente declarativa), a partir de lo cual se genera código para múltiples entornos.

GeneXus incluye un módulo de normalización, que crea y mantiene una estructura de base de datos óptima,

basada en el modelo de datos no normalizado definido por los usuarios, un lenguaje declarativo (basado en

reglas) y un lenguaje simple pero poderoso.

Se puede obtenerse una versión de prueba de GeneXus accediendo a: http://www.genexus.com

Debido al avance de las tecnologías de información y la alta competencia desarrollada por las grandes

empresas que comercializan sus productos no solo en forma local sino también en forma global, ya que mediante

el uso del internet se ve necesaria la explotación de nuevas herramientas que permitan cubrir sus expectativas de mercado.

Por esta razón, para cubrir las diferentes demandas de estas empresas, los desarrolladores de software tienen

que buscar las herramientas que permitan cumplir no solo con las necesidades del cliente sino también con las suyas, pudiendo tener al alcance varias plataformas de desarrollo como Cobol, Visual Basic, Visual FoxPro,

Ruby, C#, Java.

GeneXus es una excelente herramienta de generación de código en diferentes plataformas.

Tiene un costo elevado lo que produce un alza en el precio final de los productos desarrollados, por esta razón

la mayoría de los desarrolladores opta por la opción de software de código abierto. (R., 2009). (Consultores,

2008)1

[1] ARTech Consultores S. R. L. 1988-2003.

2

CAPÍTULO I

A. Concepto.

ARTech, creó la GXDL (GeneXus Developer Library), una biblioteca que centraliza toda esta información técnica, cuyo objetivo es brindar a los desarrolladores una fuente única de información potenciada con una

“ingeniería de búsqueda” que les permita acceder rápida y fácilmente a la información técnica (versión, notas,

manuales, tips, White Papers, etc.).

Para el desarrollo más rápido de aplicaciones web podemos usar los Patterns (patrones), estos nos facilitaran el trabajo en gran manera.

Podríamos vender nuestra aplicación en casi cualquier lenguaje extranjero haciendo pocos o ningún cambio en

el código, usando Application Localization.

Nota: Application Localization. (A partir de la versión 9.0 de GeneXus se permite traducir las aplicaciones

realizadas con GeneXus tanto a los lenguajes estándares de GeneXus como a lenguajes definidos por el usuario.

Esto permite a los desarrolladores personalizar las aplicaciones cuando hay términos del negocio que cambian

según los países.)

Acceder a más bases de datos que nunca: Ha sido agregado el soporte a MySQL. Manteniendo nuestra

aplicación “en el campo de juego” con el Nuevo generador .Net Mobile.

Crear aplicaciones más fáciles de usar con “no código”, autocompletar, combos linkeados o list boxes.

Encapsular la lógica de nuestra aplicación con Businnes Components (Componentes de Negocio) y luego consumarlos nosotros mismo o deje que otros lo hagan mediante Web Services o J2EE.

Heredar bases de datos más rápido y fácil. Usando la nueva Data base Reverse Engineering Tool (Base de

datos de herramientas de ingeniería inversa).

Hablaremos sobre las características de las aplicaciones distribuidas.

En nuestro caso la herramienta nos permite la posibilidad de desarrollar aplicaciones distribuidas en 3 capas,

describiremos cual es la arquitectura de este tipo de aplicaciones, cuáles son sus componentes y cuáles son sus

principales beneficios frente a una aplicación en 2 capas.

B. Arquitectura.

Un sistema distribuido se basa en el concepto de distribuir lógicamente la ejecución de una aplicación, que

también puede estar distribuida físicamente o puede estar corriendo en una misma computadora.

La idea principal de un sistema distribuido, es la división lógica de la aplicación en varias capas, de forma de repartir las responsabilidades de realizar tareas específicas en cada una de ellas.

En nuestro caso las aplicaciones distribuidas van a estar basadas en una arquitectura de 3 capas, es decir, que

cada una de las capas se va a especializar en realizar determinadas tareas.

En la primera capa se encuentran los componentes de la aplicación que implementan la interfaz de la misma con el cliente (Capa de Presentación).

En la segunda se hallan los componentes que se ocupan de ejecutar la lógica del negocio de la

aplicación, es decir todo lo que es comportamiento del sistema (Servidor de Aplicaciones).

Y en la tercera capa están los componentes encargados de realizar toda la manipulación y

persistencia de los datos (Servidorde Base de Datos).

3

A diferencia de las aplicaciones Cliente/Servidor tradicionales (2 capas), donde la ejecución de todo el código

de la aplicación (lógica del negocio) se realiza en el cliente, en una aplicación 3capas, se distribuye el código;

ejecutando parte en el cliente y parte en el servidor de aplicaciones. De esta forma logramos ganar en escalabilidad, seguridad y performance.

Cabe aclarar que en una arquitectura como esta, el servidor de aplicaciones puede a su vez comunicarse con

otros servidores de aplicaciones, distribuyendo de esta forma la responsabilidad de los servicios que son provistos

al cliente.2 (Salsano, 2006).

Del mismo modo, el servidor de la base de datos no tiene porqué ser uno solo, sino que se puede contar con

varios.

Es este tipo de arquitectura, los clientes se comunican con el servidor de aplicaciones mediante un protocolo

de comunicación específico según el lenguaje de la aplicación y el servidor utilizado como se muestra en la figura nº1, a su vez, el servidor de aplicaciones se comunica con la base de datos mediante un protocolo de

comunicación o driver específico según el BMS utilizado.

Fig. 1. Arquitectura en tres capas

(http://oness.sourceforge.net/proyecto/html/ch03s02.html, 2004)

C. Servidores de aplicaciones:

En una aplicación 3 capas se debe definir qué parte del código va a ser ejecutada en el cliente y qué parte va a

ser ejecutada en forma remota, de este modo necesitamos contar con lo que llamamos un servidor de aplicaciones

que va a ser el encargado de ejecutar los servicios definidos como remotos, que van a ser solicitados por los diferentes clientes de la aplicación.

Cuando el cliente requiere algo (por ejemplo datos), se comunica con el servidor de aplicaciones solicitándole

que ejecute determinado proceso remoto, con determinados parámetros. El servidor de aplicaciones dispara dicho

proceso, y luego se comunica con el cliente para retornarle el resultado si corresponde.

Un servidor de aplicaciones puede atender a muchos usuarios y puede ser servidor de más de una aplicación a

la vez.

2 (generated with GeneXus X Evolution 2) gxwiki@gxtechnical.com

4

Un servidor de aplicaciones está ubicado entre el cliente de la aplicación y la base de datos. De esta forma es

más fácil controlar la seguridad de la información ya que desde el cliente nunca se accede directamente a la base

de datos, sino que siempre se accede a través del servidor de aplicaciones.

Resumiendo, un servidor de aplicaciones tal como lo dice el nombre, provee los servicios que los clientes

necesitan, los cuales se traducen en aplicaciones compuestas de diferentes procesos que son expuestos para que

los clientes los puedan utilizar; estos servicios se encargan de procesar la información según las reglas del

negocio definidas.

D. Protocolos de comunicación.

Para que el cliente y el servidor de aplicaciones se puedan comunicar debemos tener un protocolo de

comunicación entre ambos, de forma tal que hablen el mismo lenguaje.

Cada vez que un cliente realiza un pedido al servidor de aplicaciones lo hace a través del protocolo de

comunicación (él sabe cómo hacer el pedido al servidor de aplicaciones del mismo modo que el servidor de

aplicaciones sabe cómo retornar el resultado de dicho pedido al cliente). De esta forma, la comunicación es

transparente tanto para el Emisor del pedido como para el receptor.

1) ¿Cómo implementar una aplicación en 3 capas?: En una arquitectura tradicional en 2

capas (cliente-servidor), toda la lógica de la aplicación se ejecuta en el cliente y el acceso a la base de datos se

realiza desde el cliente. Por lo que podemos decir que deberíamos tener clientes con alto potencial, capaces de ejecutar la aplicación con una alta performance; además cada uno de estos clientes debería estar configurado para

acceder a la base de datos con el driver que corresponda según el DBMS que utilicemos.

Con esto logramos un alto acoplamiento con los clientes, nuestras aplicaciones dependen muchísimo de los

clientes en los cuales están corriendo. No solo dependemos del tipo de cliente, sino que juega un rol muy importante la cantidad de clientes conectados a la base de datos, recuerde que por cada cliente hay una conexión a

la misma.

Con las aplicaciones en 3 capas logramos distribuir el trabajo entre los clientes y los servidores de

aplicaciones, podemos decidir qué se va a ejecutar en el cliente y qué se va a ejecutar en el servidor de aplicaciones.

Como ya hemos dicho anteriormente, las responsabilidades se dividen en tres capas, en el cliente se ejecuta

todo lo que es la lógica de interfaz con el usuario, en el servidor de aplicaciones se ejecuta lo que es lógica del

negocio y acceso a la base de datos y en el servidor de base de datos se mantiene la información.

Implementando aplicaciones distribuidas logramos:

2) Escalabilidad: El sistema debe poder adaptarse a un aumento en la cantidad de usuarios de la aplicación

sin perder calidad en la performance del mismo.

La cantidad de conexiones a la base de datos es limitada, por lo tanto, la aplicación debería ser independiente

de la cantidad de usuarios conectados. En este tipo de arquitectura manejamos las conexiones desde el servidor de

aplicaciones, lo que hace que la cantidad de conexiones esté totalmente controlada desde ahí. Esto es así porque

en una aplicación en 3 capas, a diferencia de las aplicaciones cliente/servidor tradicionales, las conexiones a la base de datos se manejan mediante un pool de conexiones en el servidor de aplicaciones.

Además debe permitir realizar cambios en la configuración y que estos sean transparentes para los clientes. Si

el acceso a la base de datos se realiza desde el cliente hacia el servidor de base de datos, se debe tener

configurado un driver de acceso a la base en cada uno de los clientes, sea cual sea la plataforma de la aplicación y el DBMS utilizado. En una arquitectura en 3 capas este driver sólo debería instalarse en el servidor de

aplicaciones.

3) Seguridad (GeneXus & genexus, 2010): No hay conexión entre el cliente y el DBMS, con lo cual

Ganamos en seguridad, ya que tenemos controlado quien accede a los datos.

4) Performance: Ejecutar los procedimientos que acceden a la base de datos en el servidor de aplicaciones,

tiene la ventaja de que los datos no viajan por la red sino que se procesan en el servidor de aplicaciones, evitando

así saturar la misma. La cantidad de conexiones a la base de datos también afecta la calidad de la aplicación, ya

que cuando tenemos una red con muchos usuarios conectados se comienza a degradar la performance del servidor

de la base de datos.

5

E. Ciclo de vida de una aplicación.

Una aplicación tiene un ciclo de vida, que comienza cuando se planifica la misma y termina cuando la aplicación sale de producción. GeneXus acompaña todo este ciclo.

1) Para desarrollar una aplicación: Como una aplicación con GeneXus se desarrolla de una manera

incremental, es muy importante la participación de los usuarios en todas las etapas del desarrollo, se recomienda

tener un usuario principal disponible para la prueba de los prototipos y tener acceso a los demás usuarios de una

manera fluida.

Dado que con GeneXus los miembros del equipo estarán la mayor parte del tiempo trabajando en tareas de

diseño y no de codificación, se debe tomar como criterio general el trabajar en equipos pequeños, por ejemplo, de

no más de cinco personas.

2) Obtener una imagen global: Se deben tener entrevistas con el nivel gerencial más alto posible, de

modo de obtener información sobre la posición relativa e importancia de la aplicación dentro de toda la

organización.

3) Definir el alcance de la aplicación: Luego de un estudio primario se debe decidir cuál será el

alcance de la aplicación para poder cumplir con el objetivo. Para ello se recomienda seguir el Principio de Esencialidad:

“Solo lo imprescindible, pero todo lo imprescindible”

4) Mantener el diseño simple: Se debe planificar pensando en un proceso de diseño y desarrollo

incremental. Comenzando por pequeños pasos y verificando la evolución del modelo frecuentemente con el

usuario.

5) Orientarse a los datos [3]

(Tecnicos, 2009): En esencia una aplicación es un conjunto de mecanismos

para realizar ciertos procesos sobre ciertos datos por lo tanto, en el análisis de la aplicación, se puede poner

mayor énfasis en los procesos o en los datos en las metodologías tradicionales como el Análisis Estructurado el análisis se basa en los procesos.

En general, este análisis es top-down: se comienza con la definición más abstracta de la función del sistema y

luego ésta se va descomponiendo en funciones cada vez más simples, hasta llegar a un nivel de abstracción suficiente como para poder implementarlas directamente, sin embargo este enfoque tiene ciertos inconvenientes:

Las funciones de un sistema tienden a evolucionar con el tiempo, y por tanto, un diseño basado en las

funciones será más difícil de mantener. Frecuentemente se descuida el análisis de las estructuras de datos.

No facilita la integración de aplicaciones.

F. Principales características. Diseño basado en el conocimiento:

Diseño inteligente del modelo de datos.

Diseño y prototipo independiente de la plataforma. Desarrollo automático:

Generación automática de la base de datos y el código.

Generación y mantenimiento automático de la documentación de la aplicación.

Mantenimiento inteligente. Migración automática de los datos a la nueva estructura.

Desarrollo e implementación multiplataforma.

Es un sistema computarizado capaz de resolver problemas en el dominio en el cual posee

conocimiento específico. La solución es esencialmente la misma que hubiera dado un ser humano confrontado con idéntico

problema, aunque no necesariamente el proceso seguido por ambos puede ser igual.

1) Desarrollo automático:

3 (http://www.gxtechnical.com/gxdl)

6

Generación automática de la base de datos y el código donde el desarrollador se debe preocupa más es

por la interfaz.

Generación y mantenimiento automático de la documentación de la aplicación. Mantenimiento inteligente.

Migración automática de los datos a la nueva estructura.

Desarrollo e implementación multiplataforma.

2) Usabilidad: GeneXus : Cuenta con un ambiente de desarrollo más amigable orientado a intenciones y

necesidades del desarrollador, que hacen intuitivo su uso y facilitan su aprendizaje, por lo tanto en el análisis de

la aplicación se puede poner mayor énfasis en los procesos o en los datos. Si el diseño se basa en los datos se pueden obtener las siguientes ventajas:

3) Más estabilidad:4 Los datos tienden a ser más estables que los procesos y en consecuencia la aplicación

será más fácil de mantener.

4) Facilidad de integración con otras aplicaciones: Difícilmente una aplicación sea totalmente

independiente de las otras dentro de una organización. La mejor forma de integrarlas es tener en cuenta los datos

que comparten.

Por lo tanto orientarse a los datos parecería ser más beneficioso.

La pregunta natural que surge es.

¿Cómo analizar los datos?

La respuesta de GeneXus es:

Analizar directamente los datos que el usuario conoce, sin importar como se implementarán en el

computador.

De esta manera se alcanzan dos objetivos importantes: el análisis se concentra en hechos objetivos, y éste puede ser evaluado directamente por los usuarios, utilizando la facilidad de prototipación de GeneXus.

G. Metodología GeneXus. 5

Para comenzar el desarrollo de una aplicación con GeneXus, se debe crear un nuevo

proyecto o base del conocimiento.

En segundo lugar hay que describir las visiones de los usuarios, a partir de las cuáles GeneXus captura y sistematiza el conocimiento. Para ello, se deben identificar los

objetos de la realidad 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 totalmente automática.

5 http://genexusred.blogspot.com

7

Fig.1.2 Metodología GeneXus

Fuente:http://genexusred.blogspot.com/2009/08/metodologia-genexus.html (Vicente, 210)

Si algún objeto de la realidad cambia o se identifica nuevas características del mismo o objetos aun

no modelados esos cambios se deben realizar el los objetos de GeneXus que corresponda 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 la construcción de un sistema se realiza mediante aproximaciones sucesivas.

Si bien GeneXus eleva en mucho la productividad en el desarrollo de aplicaciones en comparación con

las metodologías tradicionales, el punto más fuerte es sin duda la enorme disminución en los costos de

mantenimiento.

GeneXus incluye un módulo de normalización, que crea y mantiene una estructura de base de datos

óptima basada en el modelo de datos no normalizado definido por los usuarios, un lenguaje declarativo

(basado en reglas) simple pero poderoso.

Los lenguajes para los que se puede generar código incluyen.

Cobol

Visual Basic

Visual FoxPro

Ruby C#

Java

Actualmente con énfasis en los últimos tres. 6

GeneXus puede generar la aplicación en diversas plataformas. Así, por ejemplo, se puede implementar

la aplicación para DBMS como.

6 http://genexusred.blogspot.com GeneXus en la red

8

Microsoft SQL Server

Oracle

IBM DB2 Informix

PostgreSQL

MySQL.

NOTA: Sin duda GeneXus eleva en mucho la productividad en el desarrollo de aplicaciones en

comparación con las metodologías tradicionales pero el punto más fuerte es sin duda la enorme

disminución en los costos de mantenimiento.

1) Generadores: GeneXus nos ofrece dos posibilidades a la hora de implementar una aplicación WIN en

3 capas, podemos optar por el generador Java o por el generador .NET. En ambos casos las

aplicaciones tienen las mismas características típicas de una aplicación distribuida, como mostramos

anteriormente:

tenemos clientes que ejecutan parte del código de la aplicación.

El servidor de aplicaciones que se encarga del código definido como remoto y de la conexión a la

base de datos,

Y por último tenemos el servidor de base de datos.

Los generadores se diferencian en la plataforma a utilizar para implementar la aplicación, en los servidores de aplicaciones y en los protocolos de comunicación que utilizamos, y en algunas

propiedades específicas dependiendo de la plataforma que manejemos. Otra diferencia que existe, es a

la hora de distribuir las aplicaciones, como se muestra en la figura Nº1.3.

Para generar una aplicación WIN en 3 capas con GeneXus sólo basta cambiar una propiedad a nivel del modelo. En esta propiedad, llamada Protocolo, se selecciona el protocolo de comunicación entre cliente

y el servidor de aplicaciones según la plataforma en la cual se va a generar la aplicación. El valor

predeterminado de esta propiedad es NO y si no se cambia, se genera en 2 capas (cliente/servidor

tradicional).

A continuación mostramos cuales son las posibilidades que nos brinda GeneXus en cada plataforma

para implementar una aplicación en 3 capas:7

7 Powered by GXwiki 4.0 Beta1 (generated with GeneXus X Evolution 2)

9

Java

Fig. 1.3: Aplicación en tres capas bajo plataforma java

Fuente: http://wiki.gxtechnical.com/commwiki/servlet/hwiki?Aplicaciones+multi-capas+con+GeneXus,

.Net

Fig.1.4: Aplicación en tres capas bajo plataforma .net8

Fuente: http://wiki.gxtechnical.com/commwiki/servlet/hwiki?Aplicaciones+multi-capas+con+GeneXus,

¿Cómo distribuye GeneXus el código generado?

8 http://wiki.gxtechnical.com

10

Como ya hemos dicho, basta con cambiar una propiedad en el modelo para generar una aplicación en 3 capas,

en lugar de una en 2 capas tradicional. Pero este cambio tan simple abarca un cambio estructural en nuestra

aplicación, con esto logramos que los objetos sean generados en forma distribuida, de manera que parte del código de ese objeto se ejecutará en el cliente y otra parte se ejecutará en el servidor de aplicaciones.

H) Base de conocimiento.9

Una base de conocimientos es un depósito de información creado gracias a una extensa investigación

organizada en un árbol de conocimientos completo.

Nuestras bases de conocimientos se crean con el propósito de cubrir todos los aspectos de la evaluación y no

únicamente las características y las funcionalidades. Al almacenar los datos de los vendedores en un árbol de conocimientos podemos organizar con eficiencia las necesidades de los negocios y los usuarios pueden enfocarse

en sus prioridades en el nivel de los detalles de su selección.

Además de tener una visualización organizada de todos los aspectos de su evaluación, una base de conocimientos

permite almacenar notas, comentarios y otros datos importantes para cada nivel del árbol de conocimientos.

También reúne toda la información y las valoraciones de los vendedores, así como sus prioridades

personalizadas.

Las bases de conocimiento se han clasificado en dos grandes tipos:

1) Bases de conocimiento entendido por máquinas: Diseñadas para almacenar conocimiento en una

forma legible por el computador usualmente con el fin de obtener razonamiento deductivo automático aplicado a

ellas.

Contienen una serie de datos usualmente en la forma de reglas que describen el conocimiento de manera lógicamente consistente.

Operadores lógicos como Y (conjunción), O (disyunción), condición lógica y negación son utilizada para

aumentarla desde el conocimiento atómico

2) Bases de conocimiento entendido por Humanos: Están diseñadas para permitir a las personas

acceder al conocimiento que ellas contienen, principalmente para propósitos de aprendizaje.

I) Desarrollo incremental.10

En un esquema incremental no se encaran grandes problemas, sino que se van resolviendo los pequeños

problemas a medida que se presentan.

Es importante tener en cuenta que todo el proceso de desarrollo es incremental y por lo tanto no es necesario

definir en esta etapa todas las transacciones y cada una de ellas en su mayor detalle.

Por el contrario, lo importante aquí es reconocer las más relevantes y para cada una de ellas identificar y definir

su estructura.

Entre las ventajas del modelo incremental se encuentran:

Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema. Pueden empezar a usarlo

desde el primer incremento.

Los clientes pueden aclarar los requisitos que no tengan claros conforme ven las entregas del sistema.

Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede distribuir en cada incremento. Las partes más importantes del sistema son entregadas primero, por lo cual se realizan más pruebas en

estos módulos y se disminuye el riesgo de fallos.

Algunas de las desventajas identificadas para este modelo son:

Cada incremento debe ser pequeño para limitar el riesgo (menos de 20.000 líneas). Cada incremento debe aumentar la funcionalidad.

Es difícil establecer las correspondencias de los requisitos contra los incrementos.

Es difícil detectar las unidades o servicios genéricos para todo el sistema.

9 Base del conocimiento: www.wikipedia.com 10 http://wiki.gxtechnical.com

11

J) Ciclos de la herramienta.

1) Diseño: Esta tarea es realizada conjuntamente por el analista y el usuario, y consiste en identificar y

describir las visiones de datos de los usuarios. El trabajo se realiza en el ambiente del usuario. Este esquema permite trabajar con un bajo nivel de

abstracción, utilizando términos y conceptos que son bien conocidos por el usuario final.

Una consecuencia muy importante, es que la actitud del usuario se transforma en francamente participativa. El sistema pasa a ser una obra conjunta y como el usuario sigue permanentemente su evolución, su calidad es mucho

mejor que la habitual.

De acuerdo a lo visto, GeneXus captura el conocimiento por medio de visiones de objetos de la realidad del usuario.

Los tipos de objetos soportados por GeneXus son:

Transacciones, Reportes, Procedimientos, Paneles de trabajo, objetos Web, menús, vistas de datos, estilos y

depósito de datos.

La tarea de diseño consiste, fundamentalmente, en identificar y describir estos objetos. A partir de estas descripciones, y automáticamente, GeneXus sistematiza el conocimiento capturado y va construyendo, en forma

incremental, la Base de Conocimiento.

Esta Base de Conocimiento es un repositorio único de toda la información del diseño, a partir de la cual GeneXus crea el modelo de datos físico (tablas, atributos, índices, redundancias, reglas de integridad referencial,

etc.) , y los programas de aplicación.

Así, la tarea fundamental en el análisis y diseño de la aplicación se centra en la descripción de los objetos

GeneXus.

2) Prototipo: En las tareas de diseño están implícitas las dificultades de toda comunicación humana:

El usuario olvida ciertos detalles.

El analista no toma nota de algunos elementos.

El usuario se equivoca en algunas apreciaciones. El analista interpreta mal algunas explicaciones del usuario.

Pero además la implementación de sistemas es habitualmente una tarea que asume bastante tiempo por lo que:

Como muchos de estos problemas sólo son detectados en las pruebas finales del sistema, el costo (tiempo y

dinero) de solucionarlos es muy grande.

La realidad cambia por ello no es razonable pensar que se pueden congelar las especificaciones mientras se implementa el sistema.11

La consecuencia de la congelación de las especificaciones es que 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 demostrar al usuario

formatos de pantallas, informes, etc. animados por menú es. Esto permite ayudar al usuario a tener una idea de

qué sistema se le construirá pero, posteriormente, siempre se presentan sorpresas.

Una situación bastante diferente sería la de poner a disposición del usuario para su ejecución, inmediatamente,

una aplicación funcionalmente equivalente a la deseada, hasta en los mínimos detalles.

11 Ing. Carlos Marín Arevalo (Genexus)

12

3) Esto es lo que hace GeneXus: Un prototipo GeneXus es una aplicación pronta, funcionalmente

equivalente a la aplicación de producción.

La diferencia entre prototipación y producción consiste en que la primera se hace en un ambiente de

microcomputador, mientras que la producción se realiza en el ambiente objeto del usuario ( IBM i Series, Cliente

/ Servidor, JAVA, .NET) . El prototipo permite que la aplicación sea totalmente probada antes de pasar a producción.

Durante estas pruebas, el usuario final puede trabajar con datos reales, o sea que prueba, de una forma natural,

no solamente formatos de pantallas, informes, etc. sino también fórmulas, reglas del negocio, estructuras de datos, etc.

La filosofía de GeneXus es de desarrollo incremental. Cuando se trabaja en un ambiente tradicional, los

cambios en el proyecto hechos durante la implementación y, sobre todo, aquellos que son necesarios luego de que el sistema está implantado, son muy onerosos.

GeneXus resuelve este problema: construye la aplicación con una metodología de aproximaciones sucesivas

que permite, una vez detectada la necesidad de cambios, prototiparlos y probarlos inmediatamente por parte del usuario, sin costo adicional.

4) Producción: GeneXus genera automáticamente el código necesario para:

Crear y mantener la base de datos.

Generar y mantener los programas para manejar los objetos descritos por el usuario.

Los ambientes y lenguajes actualmente soportados son:

Múltiples plataformas.

Servidores con Sistemas Operativos: UNIX, LINUX, Windows NT/ 2000, Servers, etc.

Sistemas de Gerencia de Base de Datos: Oracle, Microsoft, SQL Server, etc.

Lenguajes: Java, C#, Visual Basic, etc. Internet: C#, JAVA, etc.

Web Servers: Microsoft I IS, Apache, WebSphere.

Múltiples arquitecturas: Centralizada, Cliente/ Servidor de dos o t res capas, Sistemas distribuidos

en múltiples capas en .NET, etc. Nuevas plataformas de ejecución: JAVA, Microsoft .NET.

5) Visión global a los objetos GeneXus:12

La característica más importante de GeneXus, en sus

objetos es la facilidad y la rapidez con la cual se puede hacer los cambios al proyecto y la que lo

diferencia de manera más clara de sus competidores es el mantenimiento, tanto de la base de datos

(estructura y contenido) como de los programas es que es totalmente automático.

12 Laboratorio Ing. Soft., Ingeniería de software 2, Departamento de Informática, 2002.

13

CAPITULO II:

Objetos de GeneXus.

K) Transacciones.13

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.

Veamos ahora como pueden optimizarse las transacciones.

1) Propiedad Optimize for multi tier execution (Optimizar la Propiedad para la ejecución de

varios niveles): La propiedad “Optimizeformulti-tierexecution” tiene por defecto el valor “Yes”, lo cual

hace que todas las reglas de la transacción se ejecuten en el servidor de aplicaciones.

Pero debemos recordar que en el servidor de aplicaciones sólo podemos ejecutar código que no contenga interfaz, por lo tanto, si en las reglas tenemos llamadas aun objeto con interfaz (transacción, work panel o reporte), la

aplicación va a cancelar.

Mediante esta propiedad con valor “No”, podemos definir que las reglas se ejecuten en el cliente, de esta

forma, estaríamos resolviendo el problema funcional, pero estaríamos perjudicando significativamente la performance de la aplicación. Entonces, no debemos cambiar esta propiedad, y encontrar una alternativa a este

tipo de llamadas en las reglas de las transacciones.

Por ejemplo, supongamos que se tiene la siguiente regla

Call(TdatosPersonas, PerCod, ….) on after confirm;

Esta regla estaría disparando la transacción „datos Personas‟ luego de confirmar la trn actual, es el caso común de

transacciones nidadas.

Esta regla se podría eliminar y pasar a los eventos de la siguiente manera:

Event AfterTrn Call(TdatosPersonas, PerCod, ….)

End event

Logrando así, la misma funcionalidad, sin perder performance. En caso de una llamada a un work panel (panel

de trabajo), tratar de usar la regla “msg” o error”.

L) Reportes:14

Los reportes dinámicos permiten al usuario final extraer directamente información de la base

de datos, sin necesidad de tener conocimientos técnicos, y sin necesidad de que los analistas realicen ningún

desarrollo adicional.

Los reportes dinámicos se realizan con GeneXusQuery, un “Add-In” de Excel que se agrega automáticamente

al mismo al instalar GeneXusQuery.

El usuario ingresa a Excel y a través de la barra de herramientas de GeneXusQuery puede formular sus propias

consultas seleccionando los atributos a consultar, sin necesidad de especificar tablas ni navegaciones.

El resultado de la consulta se devuelve en una “pivottable”( tabla dinámica) o en una “query table” (tabla de consulta) dentro de una planilla de Excel, permitiendo luego al usuario manipular esa información con toda la

potencia de la planilla electrónica.

En momento de creación o reorganización de la base de datos con GeneXus, se genera automáticamente la “meta data”, permitiéndole al usuario que formule a partir de ese mismo momento sus consultas dinámicamente

desde Excel con GeneXusQuery. No es necesario realizar ningún desarrollo adicional para ello.

13 http://genexusred.blogspot.com 14 http://genexusred.blogspot.com

14

El usuario puede además de formular sus consultas, catalogarlas organizándolas en carpetas (folders) para su

uso posterior; graficarlas, publicar el resultado en Internet, definir seguridad tanto sobre atributos como sobre

consultas, etc.

1) Formulación de consultas. Para formular una consulta, el usuario ingresa a Excel y selecciona en la barra de herramientas de GeneXusQuery la opción “New Query”. Se le presenta una pantalla como se muestra en la figura nº2.1, donde a

la izquierda aparecen todos los atributos que el usuario tiene habilitados para consultar, para que seleccione los

atributos que desea consultar (los cuales se van colocando del lado derecho a medida que los vamos

seleccionando).

Fuente: www.gxtechnical.com/gxdlsp/pub/genexus/.../9.0/manualnet90.htm (Sassagima, 2009)

Fig. 2.1: Generación de consultas

El usuario puede cambiar la función que se le aplicará a los atributos seleccionados (por ejemplo: podrá

indicar promedios, porcentajes, contar valores de un atributo, etc.). Podrá también restringir los valores a mostrar

en la consulta, especificando filtros a los atributos de la consulta (lista de valores, condiciones complejas, etc.).

Podrá definir alertas (marcar los valores que cumplan determinadas condiciones en determinado color).

Una vez especificada la consulta, se ejecuta la misma y se presenta el resultado en Excel de la siguiente forma:

15

Fuente: www.gxtechnical.com/gxdlsp/pub/genexus/.../9.0/manualnet90.htm

Fig. 2.2: Consultas importadas a Excel

M) Procedimientos.15

El procedimiento es el objeto GeneXus con el que se definen todos los procesos no interactivos de

actualización de la base de datos y las subrutinas de uso general.

Este objeto tiene todas las características de los reportes (cualquier reporte se puede implementar como un

procedimiento) y algunas características particulares para la actualización de la base de datos.

Vamos a ver entonces los comandos disponibles en los procedimientos para la actualización de la base de datos.

1) Modificación de datos: La modificación de datos de la base de datos se realiza de forma implícita, ya

que no hay un comando específico de modificación (como podría ser REWRITE), sino que basta con asignar un valor a un atributo dentro de un FOR EACH para que automáticamente se realice la modificación.

Por ejemplo supongamos que queremos tener un proceso batch que actualiza el atributo ArtPrcUltCmp para

adecuarlo según la inflación para todos los artículos almacenados:

Programa:

For each

ArtPrcUltCmp = ArtPrcUltCmp * (1 + &Inf) endfor

Reglas:

Parm(&Inf );

Se puede modificar más de un atributo dentro del mismo FOR EACH.

Por ejemplo, si también queremos modificar el atributo.

15 ARTech Consultores S. R. L. 1988-2003.

16

ArtFchUltCmp, poniéndole la fecha de hoy:

Foreach

ArtPrcUltCmp *= (1 + &Inf) ArtFchUltCmp = Today( )

endfor

La modificación física no se realiza inmediatamente después de cada asignación, sino en el endfor.

En estos dos ejemplos se modificaron atributos de la tabla base del FOR EACH, pero también es posible

actualizar atributos de las tablas pertenecientes a la extendida, utilizando el mismo mecanismo de asignación de

atributos.

No todos los atributos pueden ser modificados. Por ejemplo, no se pueden modificar los pertenecientes a la

clave primaria de la tabla base del FOR EACH (en este caso ArtCod).

Tampoco se pueden modificar los atributos que pertenecen al índice (el orden) con el que se está accediendo a

la tabla base.

Si se quiere actualizar un atributo que es clave candidata, se controlará la unicidad del nuevo valor.

si por algún motivo dejamos como identificador del 2do nivel de la transacción “Pedidos” el atributo PedLinNro, en lugar de ArtCod, pero no queremos permitir que se repitan los artículos en las líneas de un pedido, dijimos que

una solución posible era definir un índice compuesto por PedNro y ArtCod, de tipo UNIQUE (con esto

establecemos que PedNro y ArtCod forman una clave candidata).

Supongamos ahora, que el artículo de código 2 no se está fabricando más, y que existe uno parecido, el 5. Debemos cambiar los pedidos, de forma tal de sustituir las líneas donde se encontrara el artículo 2, por el artículo

5. Quedaría de la siguiente manera:

Foreach WhereArtCod = 2

DefinedbyPedCnt

ArtCod = 5

Endfor

Pero si para un pedido dado existían líneas con los dos artículos, el 2 y el 5, cuando se quiera realizar la

asignación dentro del ForEach, se encontrará que ya existe un registro con esos valores de PedNro, ArtCod. Pero

esos valores deben ser únicos, por lo que no se realizará la actualización para ese registro. Si se quiere realizar alguna acción cuando se encuentra duplicada una clave candidata, se utiliza la cláusula WHEN DUPLICATE del

foreach:

For each

Where ArtCod = 2 Defined by PedCnt

ArtCod = 5

WHEN DUPLICATE

Msg( „Ya existe una línea con ese artículo‟) Endfor

En el Listado de Navegación se informa cuáles son las tablas que se están actualizando marcando con un

símbolo correspondiente a un lápiz estas tablas. En el ejemplo de actualización del precio y fecha de la última compra de un artículo el Listado de Navegación nos muestra como la figura siguiente:

Fig. 2.3: Listado de Navegación del procedimiento de actualización de Artículos.

17

N) Work panels. Con workpanels (paneles de trabajo) se definen las consultas interactivas a la base de datos, en ambiente Windows. Si bien este es un objeto muy flexible que se presta para múltiples usos, es especialmente útil para

aquellos usuarios que utilizan el computador para pensar o para tomar decisiones. La forma de programar los

workpanels está inspirada en la programación de los ambientes gráficos, especialmente la programación dirigida

por eventos.

1) Elementos: Para cada workpanel se puede definir:

2) Form: Al igual que las transacciones, se debe definir el form, que será la interfaz con el usuario. Pero a

diferencia de las transacciones, los workpanels son objetos que solo se utilizan en ambiente de Windows, por

lo que el form de un workpanel es análogo al formGUI Windows de una transacción. Para programar una pantalla Web, para consulta de datos, se utilizará el objeto web panel, que se mencionará más adelante.

3) Eventos: Aquí se define la respuesta a los eventos que pueden ocurrir durante la ejecución del work panel.

Por ejemplo, qué respuesta dar cuando el usuario presiona Enter o un botón, etc.

La forma tradicional de programar la interfaz entre el usuario y el computador (incluidos los lenguajes de

cuarta generación) es someter la pantalla al programa. Es decir, desde el programa se hacen “calls”(llamadas), a la pantalla. En workpanels es lo opuesto: el programa está subordinado a la pantalla, ya que una pantalla realiza

“calls” al programa para dar respuesta a un evento.

Esta forma de trabajar es conocida como EventDriven (dirigida por eventos) y es típica de los ambientes GUI “Graphic User Interface”( Interfaz gráfica de usuario), en donde ya ha demostrado su productividad,

fundamentalmente porque en este no se le programa la tarea repetitiva que implica el manejo de toda la interfaz,

se necesita programar sólo la respuesta a los eventos.

A partir de la versión 7.5 de GeneXus se incorpora la posibilidad de definir varios grids dentro de un mismo workpanel, lo que no era posible en versiones anteriores.

Hasta esa versión solo podían mostrarse en pantalla los datos de una tabla de la base de datos (y de su extendida), por lo que si queríamos listar información de varias tablas distintas, teníamos que dividir la

información en distintos workpanels.

Aquí un ejemplo de la programación de un evento.

Fig. 2.4: workpanels de la tabla proveedor

Este es un evento definido por el usuario, al que se le debe asociar un nombre, en este caso, „Insertar‟. En este evento se llama a la transacción de proveedores. Luego de llamar a la transacción, se ejecuta el comando Refresh,

que indica que se debe cargar nuevamente el grid, ya que se ha adicionado un nuevo proveedor y

Queremos que éste aparezca en la pantalla. También se podría haber usado el comando con el parámetro keep (RefreshKeep) que hace que una vez que el comando refresh se ejecute, el cursor quede posicionado en la misma

línea del grid en la que estaba antes de la ejecución.

18

4) Condiciones: En esta sección se definen las restricciones sobre los datos a recuperar de la misma

forma que en los reportes. Lo interesante de las condiciones en los workpanels, es que en las mismas se pueden utilizar variables que se

encuentran en la pantalla, de tal manera que el usuario, cambiando los valores de estas variables cambia los datos

que se muestran en el grid sin tener que salir de la pantalla.

5) Reglas/Propiedades: Definen aspectos generales del work panel, como los parámetros que recibe,

etc.

6) Ayuda: Texto para la ayuda a los usuarios en el uso del work panel.

7) Documentación (:). Texto técnico para ser utilizado en la documentación del sistema.

8) Solapas de acceso a los elementos (:). Como para todo objeto GeneXus, se puede acceder a varios de los elementos como se muestra en la figura

Nº2.5 que lo componen utilizando las solapas que aparecen bajo la ventana de edición del objeto:

Fig: 2.5.- Solapas que figuran en la parte inferior de la ventana de edición de un work panel

Aquí presentaremos las características y usos más salientes de los workpanels.

9) Ejemplo (:). Para ilustrar el uso de este tipo de objetos, vamos a realizar una serie de consultas encadenadas.

Estas consultas comienzan con un work panel de proveedores, donde se despliegan todos los proveedores y el

usuario selecciona uno para luego realizar alguna acción con él. En este caso para cada proveedor seleccionado se podrá:

10) Visualizar los pedidos del proveedor(:). Al workpanel lo llamaremos “Trabajar con Proveedores” dado que es precisamente lo que buscamos: trabajar

o efectuar alguna acción con los proveedores.

El form en ejecución se verá: como se muestra en la siguiente figura.

Fig. 2.6.- Form de “Trabajar con Proveedores” en ejecución

Fuente:www.gxtechnical.com/gxdlsp/pub/genexus/.../9.0/manualnet90.htm

19

Fig. 2.7.- Visualizar datos de un proveedor

Fuente:www.gxtechnical.com/gxdlsp/pub/genexus/.../9.0/manualnet90.htm

Aquí se muestra el código y nombre de todos los proveedores del sistema, en la grilla. Luego el usuario puede posicionarse sobre una línea y hacer algo con ese proveedor.

Por ejemplo, si el usuario presiona el botón de “Visualizar” en el proveedor 125, se abre una ventana donde se

muestran los datos de ese proveedor: Análogamente, si se presiona el botón “Pedidos” se abrirá la siguiente ventana

Fig. 2.8.- Visualizar pedidos de un proveedor

Fuente: www.gxtechnical.com/gxdlsp/pub/genexus/.../9.0/manualnet90.htm

20

A su vez este workpanel podría extenderse, permitiendo seleccionar algún pedido para visualizar qué artículos

lo componen y así sucesivamente. Las acciones que vimos en el primer workpanel se aplican a una línea, pero existen otras acciones que no se

aplican a ninguna línea en particular por ejemplo, si queremos insertar un nuevo proveedor. Si se elige esta acción

(presionando el botón “Insertar” que figura en el form) se pasa el control a la transacción de proveedores para

permitir el ingreso de un nuevo proveedor.

Fig. 2.9.- Insertar un nuevo proveedor

Fuente: www.gxtechnical.com/gxdlsp/pub/genexus/.../9.0/manualnet90.htm

Veamos ahora cómo se define el primer work panel del ejemplo.

O. Form. El form de un workpanel se define de forma similar al form GUI Windows de una transacción.

Fig: 210.- Form del work panel “Trabajar con Proveedores”

Fuente: www.gxtechnical.com/gxdlsp/pub/genexus/.../9.0/manualnet90.htm

21

Cuando se define un grid en el form se inserta como cualquier otro control, utilizando la paleta de

herramientas “Controls” se está indicando que se va a mostrar una cantidad indefinida de datos (en este caso, los

proveedores).

Si bien sólo se pueden ver simultáneamente las líneas presentes en la pantalla, GeneXus nos permite utilizar

mecanismos para que el usuario se pueda paginar o mover dentro de la lista.

El workpanel anterior contiene un grid cuyas columnas corresponden a los atributos PrvCodyPrvNom.

Los grids pueden contener atributos, variables y elementos de arrays de una y dos dimensiones. Aquí los

atributos serán de salida, es decir, se utilizan para mostrar información de la base de datos, y las variables de entrada. Estas se utilizan fundamentalmente para solicitar información al usuario.

1) Grilla: El ícono de la paleta de herramientas como se muestra en la figura nº2.11, nos va a permitir

insertar un grid en el form del workpanel y definir las características del mismo, como los atributos y variables

que conformarán las columnas del grid, los títulos de tales columnas, etc.

Fig. 2.11.- Paleta de Herramientas “Controls” para un work panel

Una vez insertado el control en el form, se abre automáticamente el siguiente diálogo, donde se especifican las

columnas:

Fig. 2.120.- Diálogo de Propiedades del control grid.

Fuente: www.gxtechnical.com/gxdlsp/pub/genexus/.../9.0/manualnet90.htm

En “Name” se permite dar un nombre al control, lo que será necesario si luego se le quieren asociar propiedades, eventos o métodos al mismo. Si se van a incluir varios grids dentro del form, entonces será

Insertar control grid

22

indispensable identificarlos, por lo que se vuelve fundamental asignar valor a estar propiedad para cada uno de

los grids insertados.

Para seleccionar los atributos y variables que van a ser incluidos en el grid se debe presionar el botón “Add”.

el botón “Hide” nos permite ocultar la columna seleccionada. Esto resultará necesario cuando no se quieran

mostrar en pantalla determinados datos, pero sea indispensable tenerlos cargados, para poder luego utilizar sus

valores cuando se seleccione una línea y se quiera efectuar alguna acción sobre la misma.

Los botones “MoveUp” y “Move Down” nos van a permitir cambiar el orden en que se van a desplegar los

atributos en el grid.

Con la solapa “Column” vamos a poder cambiar los títulos de las columnas (por defecto, para un atributo toma

el valor de la opción “TitleColumn” del atributo, y en caso de tratarse de una variable no escalar, podremos

seleccionar el elemento de la variable que queremos utilizar en esa columna, indicando valores de fila y columna.

Con las solapas “Colors” y “Fonts” podemos cambiar los colores y el tipo de letra de las columnas y de las

filas.

Con la solapa “Control Info” se selecciona el tipo de control a utilizar para cada atributo o variable del grid, y dado el tipo, indicar la información necesaria para ese tipo.

Las opciones disponibles son: Edit, Check box, Combo y Dynamic Combo (o el default del atributo o variable de

la columna). 16

La solapa “Advanced” nos va a permitir configurar ciertas propiedades que tienen que ver con la carga del

grid. Si no se configuran, entonces valen para ese grid las opciones a nivel del objeto, que son las que figuran

bajo la categoría “Loading” en el diálogo de propiedades del workpanel.

Fig. 2.13.- Diálogo de propiedades de una transacción

Fuente: www.gxtechnical.com/gxdlsp/pub/genexus/.../9.0/manualnet90.htm

16 ARTech Consultores S. R. L. 1988-2003. (Diseño de Aplicaciones con GeneXus)

23

Podemos también ajustar manualmente el ancho de cada columna desmarcando la opción de “Auto Resize”. Si

esta opción queda marcada, el ancho de la columna es determinado porGeneXus en función del largo del atributo o variable y del título de la columna.

El check box “Horizontal Scroll” permite que en tiempo de ejecución aparezca una barra de scroll horizontal

(además de la de scroll vertical que aparece automáticamente).

P. Objetos Web. Son similares al conjunto de WorkPanels y Transacciones, pero son usados en browser o ambiente Internet / Intranet / Extranet.

Los Objetos Web (WEB OBJECTS) se utilizan para desarrollar aplicaciones para Internet. Generan código

HTML, el código que los navegadores interpretan pudiendo interactuar con la base de datos, permitiéndonos de esta forma la generación de páginas web dinámicas además de la generación de páginas estáticas.

Los Objetos Web los podemos clasificar en: Transacciones con form Web (HTML) y en Web Panels. El

desarrollo es inmediato, ya que cualquier usuario GeneXus va a trabajar con los Objetos Web de la misma forma con la que lo hace con el resto de los objetos GeneXus, de esta manera logramos optimizar tiempos de desarrollo.

Q. Transacciones Web. 17

Las Transacciones Web no son un nuevo tipo de objeto GeneXus, sino un form más para las transacciones que

permiten su ejecución en navegadores.

Para diseñar el form Web (HTML) de una transacción, se debe abrir la transacción y seleccionar la opción

Object/Web Form del menú GeneXus o la solapa etiquetada como “Web Form”.

Las Transacciones Web facilitan en gran manera el diseño de las aplicaciones Web porque permiten resolver el ingreso de datos realizando automáticamente, para ejecutarlas, sólo se requiere un navegador instalado en el

cliente.

R. Paneles Web (web panel). Se puede decir que los objetos web panel y workpanel son similares ya que ambos permiten definir consultas

interactivas a la base de datos. Son objetos muy flexibles que se prestan para múltiples usos, cuya programación

está dirigida por eventos. De todos modos, hay algunas diferencias entre ellos, causadas principalmente por el esquema de trabajo en Internet.

Una particularidad fundamental que diferencia a estos dos objetos es que en los web panels, en tiempo de

ejecución, el resultado de la consulta se genera en HTML para que sea posible la presentación en un navegador.

S. Menus.

Los menús también se generan a partir de los diagramas de navegación. Al definir un punto de menú en una

navegación el editor la copia automáticamente al objeto MnuMain.

Este objeto contiene la lista de opciones definidas para la aplicación. Cuando se graba una navegación también se

graba el objeto MnuMain (si se hizo algún cambio en él), y al grabar este último se genera el procedimiento responsable de carga el menú que le corresponde a cada usuario.

Si se desea modificar el menú, por ejemplo para agregar una opción que no se define a partir de un diagrama de

navegación, se puede editar el objeto MnuMain. Al abrir el objeto se presenta un editor con una estructura de

árbol (similar a la de los formularios). Dentro de cada opción se indica su nombre, el objeto que tiene asociado y también los perfiles que están habilitados para utilizar la opción.

Junto con el menú se define un procedimiento hijo. En este procedimiento se genera el código que carga el menú.

Dentro de este código se evalúa el perfil del usuario actual y se incluyen únicamente las opciones que le

corresponden.

17 ARTech Consultores S.R.L. 2011

24

T. Vista de datos (data views). Una DataView le permite crear diferentes vistas de los datos almacenados en una DataTable, una capacidad que suele utilizarse en aplicaciones de enlace a datos. 18

Mediante una DataView puede exponer los datos de una tabla con distintos criterios de ordenación y filtrar los

datos por el estado de fila o basándose en una expresión de filtro. Una DataView proporciona una vista de datos

dinámica en la DataTable subyacente: el contenido, el orden y la pertenencia reflejan los cambios en cuanto se

producen.

Este comportamiento difiere del método Select de la DataTable, que devuelve una matriz de DataRow de una

tabla basada en un filtro o un orden determinado este contenido refleja cambios en la tabla subyacente, pero la

pertenencia y la ordenación siguen siendo estáticas. Las capacidades dinámicas de la DataView hacen que resulte ideal para las aplicaciones de enlace a datos.

Una DataView proporciona una vista dinámica de un único conjunto de datos, similar a la vista de una base de

datos, a la que puede aplicar distintos criterios de ordenación y filtrado. Sin embargo, al contrario que una vista

de base de datos, una DataView no puede tratarse como una tabla y no puede proporcionar una vista de tablas combinadas.

Tampoco puede excluir columnas que existen en la tabla de origen ni puede anexar columnas, como columnas

de cálculo, que no existen en la tabla de origen.

1) Asistente Generador de Datos (GeneXus Data View Generator Wizard): Este es un asistente

que consta de 5 páginas, a continuación se detalla las funcionalidades que se pueden obtener de cada una.

Pagina 1: Objetivo: establecer la conexión.

Fig. 3.1.- Página 1 del Data View GeneratorWizard

Fuente:www.gxtechnical.com/gxdlsp/pub/genexus/.../9.0/manualnet90.htm

18 ARTech Consultores S.R.L. 2011

25

En la Fig. 3.1, se selecciona el modo de conexión a utilizar (ODBC u OLEDB) así como todo lo necesario

para realizar la conexión a la base de datos que contiene las tablas a “importar”. Al seleccionar el modo de conexión aparecerán todos los DataSources disponibles (si se eligió ODBC) olos

OLEDB Providers (si se eligió OLEDB).

Se debe seleccionar uno de la lista, ingresar el usuario/password y presionar el botón “Next”. En caso de haber utilizado previamente el DVG y haber salvado la información de conexión, entonces se puede utilizar el botón

OPEN con el cual se recuperará dicha información.

Página 2:

2) Objetivo: Seleccionar las tablas y vistas lógicas a “importar”:

Fig. 3.2.- Página 2 del Data View GeneratorWizard

Fuente:www.gxtechnical.com/gxdlsp/pub/genexus/.../9.0/manualnet90.htm

En esta página aparecen dos ventanas, la de la izquierda muestra las tablas base de datos, tablas, vistas lógicas,

etc. disponibles para ser importadas.

Nota: La información que aparece en la ventana izquierda depende del usuario que se ha conectado a la base de

datos y del DBMS que se esté utilizando.

En particular se verán las tablas de aquellas bibliotecas que se hayan especificado, a nivel de DataSource, en la opción “Default Libraries” del Tab “Server”. Recuerde comenzar la lista de bibliotecas con una coma “,”, en caso

contrario puede presentarse el siguiente error: “SQL0204 – QCMDEXC in XXX type *N not found”.

En la ventana derecha se mostrarán las tablas seleccionadas para importar. El usuario debe seleccionarla la ventana izquierda (doble click). Es posible seleccionar el esquema (o biblioteca en el caso del AS/400) en cuyo

caso se incluirán todas las tablas del mismo.

El botón SAVE tiene como objetivo salvar la información ingresada hasta el momento (conexión y lista de

tablas seleccionadas). El archivo donde se salvará dicha información tiene extensión GDC “GeneXus Generator

Configuration” (Configuración del generador GeneXus).

26

Nota: Si se está utilizando el DVG con el DB2/400 recuerde configurar el DataSource para que utilice el

“Systemnaming Convention (*SYS)” en la página “Format” la opción “Naming convention”.

Página 3

3) Objetivo: Configurar los parámetros de importación:

Fig. 3.3.- Página 3 del Data View GeneratorWizard

Fuente:www.gxtechnical.com/gxdlsp/pub/genexus/.../9.0/manualnet90.htm

Esta página es similar a la disponible en el File View Generator distribuido con la Versión 6.0 y anteriores de

GeneXus. Su funcionalidad depende de si el DVG fue ejecutado por fuera de GeneXus o desde el mismo. Los valores

marcados más adelante con un asterisco (*) no pueden ser modificados si se ejecutó el DVG desde Genexus.

Export File Directory: (*) Ingresar el directorio donde será creado el archivo de exportación.

Nota:(GXW.XPW). No debe incluir la barra (\) al final.

Si fue ejecutado desde GeneXus entonces ese directorio es el de la KB y no puede ser modificado (aparece

“Read-only”). Dicho directorio debe existir, en caso contrario no se habilitará el botón NEXT.

4) Carpeta: Nombre de la carpeta de la base del conocimiento donde se crearán los objetos “importados”.

5) Generador de vista de datos: Con esta opción se determina si se generará un Data View con la estructura

para cada tabla a importar.

6) Recuperar información del índice: Si esta opción está marcado significa que para cada tabla importarán

también todos los índices de la misma (primario, claves foráneas, de usuario, etc.).

Además al marcarlo se pueden generar también las transacciones asociadas a las tablas, en caso de no marcarlo

no se recuperará la información de los índices y por consiguiente no se podrán definir las transacciones. Las tablas serán importadas como Data Views pero no se asociarán a tablas de la KB.

27

Nota: si no se importan los índices o sea que no se asocian las Data Views a tablas de la KB, las tablas

importadas solo pueden ser accedidas con comando Xs (XforEach, Xnew, etc.).

Es recomendable que se asocien a tablas de la KB de modo tal de facilitar el uso de las mismas, por más que

luego la transacción creada no sea usada como tal.

7) Generador de transacción: Si se marca esta opción se generará una transacción con la estructura de cada tabla

a importar. Ver la información referente a “RetrieveIndex Information”( Recuperar información del Índice de) e

“IdentifyMultil evel transactions” (Identificar las transacciones Multinivel).

i. Identificar transacciones multi-nivel(:). Si no se marca esta opción cada tabla a importar definirá una transacción a una vista de datos diferente. Las transacciones generadas serán entonces todas de un solo nivel.

Si se marca entonces se buscan ciertos patrones de subordinación para definir transacciones de más de un nivel.

Se deben cumplir los siguientes “patrones”:

La llave primaria de cada nivel subordinado debe ser un súper set de la llave primaria del nivel superordinado.

Ejemplo:

Tabla 1(Nivel superodinado) Tabla 2 (Nivel subordinado) FacNro* FacNro*

FacFchFacNroLin*

FacImpLin

El nombre de la tabla de las líneas (subordinada) debe estar contenido en el nombre de la tabla del cabezal

(superordinada), sin considerar los números finales en el nombre de ambas.

Ejemplo que cumple:

Nombre de tabla Se incluye en transacción

Facturas Facturas

Factura1 Facturas Ejemplo que no cumple:

Nombre de tabla Se incluye en trn

FacCabFacCab

FacLinFacLin

No deben existir atributos redundantes del nivel subordinado en el nivel superordinado.

Independientemente de que el DVG reconozca tablas como “multilevel”, el desarrollador puede editara posteriori las transacciones para diseñarlas como mejor representen su realidad.

Maximum NameLength (*): Esto determina a cuantos caracteres se determinará la unicidad del nombre.

Por ejemplo, si se ingresa 5 la unicidad del nombre de las transacciones se controlará en los 5primeros caracteres.

NOTA: Esta opción, tanto como la “table namelength”( tabla de la longitud del nombre), etc. existe sólo por

compatibilidad conversiones DOS de GeneXus, es recomendable no modificarlas y dejar los valores por default.

Nota: se controla que en los nombres de las transacciones los primeros 7 caracteres sean únicos y en el nombre de

los data Views los 8 primeros.

La finalidad de este check no es determinar cuántos caracteres hacen único el objeto sino cuantos caracteres en

total tendrá el nombre del objeto.

U. Tablas. NameLength (*): idem que Maximum numericlength de transacciones.

Whenunknown file type:19Con este radio button se determina el comportamiento a tener en caso de encontrar un tipo de datos desconocido para GeneXus.

19 ARTech Consultores S. R. L. 1988-2003.

28

El primero de los valores produce que no se importe la información de esa tabla y el segundo valor es para

importar dicha información pero ignorando el atributo de tipo “desconocido”.

1) Atributos: Si algún atributo supera ese límite se importa con la cantidad de posiciones que se incluya en

este parámetro.

Ejemplo: se tiene un Numérico de 20 y se configura como Maximum numeric Length 15, entonces ese atributo será definido como N(15).

2) Atributos de sesión (Attributes Sign): Los atributos en la base de datos no tienen signo, al importarlos

estos check boxes controlan a cuales se les agregará signo y a cuáles no.

3) Atributos sin decimales (Attributeswithout decimal places): los atributos que no tengan decimales se

definirán con signo.

4) Los atributos con decimales (Attributeswith decimal places): los atributos que tengan decimales se

definirán con signo.

5) Agrandar la imagen (Enlarge Picture): Se agrandará la foto una posición (Z) más en todos los

atributos numéricos.

6) Generar el esquema (Generate schema): Se incluirá en la información de las tablas e índices

importados el esquema al cual pertenecen (salvo en AS/400 en el cual no existe el concepto de esquema).

7) Ubicación Generar (Generate Location): Se incluirá en la información de la tabla e índices

importados el nombre de la base de datos a la cual pertenecen. En AS/400 este nombre en realidad es el nombre de la biblioteca.

Nota: si se marca cualquiera de estos dos check boxes las tablas serán calificadas, es decir se utilizará esquema

de la tabla o biblioteca/tabla. 20 Por este motivo es recomendable no marcar ese check box si se utilizarán las tablas de otros schemas/bibliotecas.

Por ejemplo: cuando se “importa” la información de una tabla que está en la biblioteca COMPRAS, pero

luego se quiere utilizar la tabla de la biblioteca VENTAS y se calificó no se podrá hacer puesto que la “apertura” de la tabla es biblioteca/tabla.

Página 4

Objetivo: resolver los conflictos de nombres, etc. así como los cambios de tipo de datos que se requieran.

Fig. 3. 4: Página 4 del Data View GeneratorWizard

Fuente:www.gxtechnical.com/gxdlsp/pub/genexus/.../9.0/manualnet90.htm

Al generar objetos GeneXus a partir de una base de datos se pueden generar conflictos, principalmente en 3

aspectos:

20 W. Stallings. Ed. Pearson - Prentice Hall,

29

Nombres duplicados

Problemas de normalización/nomenclatura

Necesidad de cambio de tipo/largo

8) Conflictos: Nombres duplicados: Los objetos en GeneXus (transacciones, etc.) se identifican por los 7

primeros caracteres. Los atributos por los 10 primeros, y el resto (Data View, tablas e índices) por los 8 primeros caracteres.

Es decir, que en esos N primeros caracteres los nombres deben ser únicos, en caso contrario se dará un conflicto

de nombres. Al importar conocimiento de una base de datos puede darse que no se cumpla con la unicidad en los N primeros

caracteres. Este caso desarrollador podrá establecer “reglas” para resolverlos.

9) Conflictos: Problemas de normalización: Para GeneXus los atributos que se llaman igual representan

lo mismo mientras que los que tienen diferente nombre representan cosas diferentes.

Si por ejemplo, el atributo que representa el código de cliente en la tabla de clientes se llama “CliCod” mientras que el mismo atributo en la tabla de cabezales de factura se llama “FacCliCod”, GeneXus no podrá

inferir que ambos son el mismo atributo.

El contraejemplo sería el caso de dos atributos con igual nombre en tablas diferentes que no tienen relación

entre ellos. GeneXus “entenderá” que ambos representan el mismo dato y que sí están relacionados.

Las reglas de transformación podrían ser utilizadas para resolver cualquiera de los casos mencionados

indicándole a GeneXus cuál es la exacta relación de los atributos que componen nuestra base de datos.

10) Conflictos: Interpretación de los tipos de datos: Para GeneXus los tipos de datos que existen son:

Numérico, Date, DateTime, Carácter, VarChar yLongVarchar. En muchos DBMS no existen esos tipos de datos o

existen variaciones a los mismos. Por ejemplo: en Oracle no existe el tipo de datos “Date” entonces los “Date” de GeneXus son creados como “DateTime” en Oracle. Al realizar la “ingeniería inversa” GeneXus no puede saber

que el atributo que Oracle le dice que tiene tipo DateTime debe ser representado como un Date de GeneXus y no

como un DateTime de GeneXus. Las reglas de transformación podrían ser utilizadas para “aclarar” estas

ambigüedades.

V. Funcionamiento de las reglas: En la Fig. 3.4 se divide en dos partes (Conflicting Objects y

ReplacementRules).

1) Sección Objetos en Conflicto: En la parte superior se despliegan los objetos que serán generados. Se

pueden visualizar todos (“Show AllObjects”) o solamente aquellos que tienen conflicto.21 Los posibles mensajes de error o “warning” a encontrar en la parte superior son: · Nombre de los conflictos dos

objetos tienen el mismo nombre interno, considerando la unicidad de los mismos según la cantidad de caracteres

indicados en el “name length” del tipo de objeto.

2) Nombre Duplicado: Dos objetos tienen exactamente el mismo nombre interno, independiente mente de la

longitud del nombre.

3) Atributos Duplicados (DuplicatedAttribute): Dos atributos de diferente nombre y mismo tipo tienen el

mismo nombreinterno. (WARNING)Sección Replacement Rules.En la parte inferior se visualizan las reglas que

el desarrollador haya ingresado.

4) Las reglas son de dos tipos: Particulares o globales. Las primeras aplican a un objeto o grupo de objetos

determinados y las globales a todos los objetos.

Para crear una nueva regla se puede utilizar el botón “add” en la parte inferior de la pantalla o dando doble click

sobre un objeto y utilizando el botón Generate Rule. En el primer caso la regla a establecer, por defecto, es

global, en el segundo caso por defecto es particular al objeto seleccionado en ese momento.

5) Reglas de sustitución de nombres: Un objeto tiene un nombre interno (nombre del objeto en la base de

conocimiento GeneXus) y un nombre externo (nombre en la base de datos). Por defecto ambos se definen iguales,

incluso el nombre de las transacciones (las cuales no existen en la base de datos) estará dado por el nombre de la

tabla del primer nivel de la misma.

21 (A. León-García e I.) ARTech Consultores S. R. L. 1988-2003

30

Dichas reglas básicamente buscan un string en el nombre interno del objeto y lo sustituyen por otro en el nombre

interno.

6) Ejemplo (Definición de Regla Global).

Fig. 3.5.- Conflicto de nombres

En esta figura se muestra el conflicto en los nombres de índices pues sus nombres internos coinciden en los 10

primeros caracteres.

Se decide establecer una regla que sustituya “SYS_C00” por “S”.

Para ello se utiliza el botón “add” (parte inferior de la pantalla) con lo cual aparecerá el siguiente diálogo:

Fig. 3.6.- Diálogo de Definición de Reglas

Fuente:www.gxtechnical.com/gxdlsp/pub/genexus/.../9.0/manualnet90.htm

En la sección Name Substitution de este diálogo, se puede establecer qué string buscar y por qué string reemplazarlo. Se buscarán todos los objetos cuyo nombre “coincida” con “Find What” y se reemplazará el

nombre interno (o parte del mismo) por el string ingresado en “Replace With”.

31

El texto ingresado en “Find What” será buscado dentro del nombre del objeto en función de la selección

realizada en el recuadro de “Modifiers” según el siguiente detalle:

7) Empezar por (Beginswith): Busca los nombres de objeto que empiecen con el texto ingresado.

8) Termina con (EndsWith): Busca los nombres de objeto que terminen con el texto ingresado (ver

GIKWord).

9) Contiene (Contains): Busca los nombres de objetos que contienen en cualquier parte el texto ingresado.

10) Es Igual a (IsEqualto): Busca los nombres de objeto que coincidan exactamente con el texto ingresado

(esto sería similar a una regla particular, las cuales se detallan más adelante en este documento).

11) GIK Word: Se reconoce el formato GIK para los nombres, es decir, las letras mayúsculas se asumen como

separadores.

Ejemplo: si se busca el string “CLI” y se marca este check box, entonces el objeto “CliCod” cumplirá con el patrón mientras que “ClientesNac” no, ya que CliCod cumple el formato GIK.

12) Coincidir Mayúsculas y Minúsculas (Match Case): La búsqueda se realizará considerando

exactamente la combinación de mayúsculas y minúsculas del texto ingresado.

13) Parar Después de Aplicar (Stop afterapply): Si está marcado y se aplica la regla, el resto de las reglas

que existan para el objeto se descartan.

En nuestro ejemplo solo ingresamos:

Fig. 3.7.- Ejemplo de definición de regla de sustitución

Fuente:www.gxtechnical.com/gxdlsp/pub/genexus/.../9.0/manualnet90.htm

Una vez ingresada la misma (botón OK) aparecerá en la parte inferior de la pantalla y mediante el botón

“apply rules” se aplica (ejecuta) la regla. El resultado luego de la ejecución se muestra en la figura siguiente.

32

Fig. 3.8.- Resultado de aplicación de regla de sustitución

Fuente:www.gxtechnical.com/gxdlsp/pub/genexus/.../9.0/manualnet90.htm

Como vemos en el ejemplo los conflictos con los objetos “SYS_C00” han desaparecido. Si se desea ver como

ha quedado resuelto (cuál es el “rename” que se producirá) se puede marcar el check box “ShowallObjects” y se

obtendrá la siguiente pantalla. En este diálogo se puede ver cuáles serán los cambios que se producirán (objetos

marcados con ).

Ejemplo: el índice cuyo nombre externo es “SYS_C001301” quedará con nombre interno “S1301”.

Ejemplo (Definición de Regla Particular).

Volviendo a la pantalla que muestra solo los conflictos (“Show allobjects” desmarcado), tenemos lo siguiente:

Fig. 3.9: Resultado de aplicación de regla de sustitución

Fuente:www.gxtechnical.com/gxdlsp/pub/genexus/.../9.0/manualnet90.htm

33

En este caso los conflictos con los índices desaparecieron, sin embargo quedan pendientes de resolver otros conflictos.22

Por ejemplo la tabla “PRIMARI1” generará una transacción con el nombre“PRIMARI1”, al igual que la tabla

“PRIMARIA” generará una transacción “PRIMARIA”.

El problema es que ambas coinciden en sus 7 primeras letras (PRIMARI) que es el límite para la unicidad de

nombres de objetos GeneXus.

Por este motivo se muestra en la primer línea de la parte superior que PRIMARI1 genera conflicto con PRIMARIA y en la segunda que PRIMARIA genera conflicto con PRIMARI1.

Podríamos aplicar una regla global como la vista anteriormente, tratando de reducir el largo del nombre

sustituyendo “PRI” por “P” o cualquier ejemplo similar.

Sin embargo se debe considerar que esta regla aplicará a todos los objetos (tengan o no conflicto) por lo cual

pueden renombrarse objetos que no quieren renombrarse.

Lo que haremos es aplicar una regla particular, es decir con un alcance (scope) determinado.

Para ello podemos dar “doble-click” sobre el objeto en conflicto, con lo que se puede visualizar un diálogo como el siguiente:

Fig. 3.10.- Diálogo de objeto con conflicto.

Fuente:www.gxtechnical.com/gxdlsp/pub/genexus/.../9.0/manualnet90.htm

También se implementó un menú que se despliega al hacer click sobre el objeto en conflicto con el botón

derecho del mouse. Este menú tiene dos opciones: Properties (del ítem seleccionado) y Create Rule (para crear

una regla de alcance particular sobre el ítem seleccionado).

Luego podemos utilizar el botón “Generate Rule” que aparece en este diálogo o seleccionar la sección “Scope” del diálogo de definición de reglas visto anteriormente.

22 ARTech Consultores S. R. L.

34

En cualquiera de los dos casos aparecerá un diálogo similar a la siguiente figura:

Fig. 3.11: Ejemplo de definición de alcance de una regla.

Fuente:www.gxtechnical.com/gxdlsp/pub/genexus/.../9.0/manualnet90.htm

En este diálogo se puede determinar el alcance de la regla, es decir sobre que objetos se va a aplicar. Para ello

existen dos grillas, la de la izquierda muestra los objetos disponibles y un filtro para acotar dicha lista. La de la

derecha muestra los objetos sobre los cuales aplicará la regla.

En este ejemplo se aplicará la regla (cambiar PRIMARI1 por PRIMA) solo para la transacciónPRIMARI1.

De este modo se puede acotar el alcance de una regla, es decir, determinar sobre que objeto o grupo de objetos

aplicará la misma.

Nota: en cualquier momento se pueden salvar las reglas ingresadas hasta el momento, para ello se utiliza el botón

SAVE.

35

14) Modificación del alcance de una regla:

Fig. 3.12: Resultado de aplicación de reglas.

Fuente:www.gxtechnical.com/gxdlsp/pub/genexus/.../9.0/manualnet90.htm

Como se puede ver en este diálogo el conflicto a nivel de esas transacciones desapareció, sin embargo siguen

existiendo otros conflictos.

Para resolverlos se ingresan reglas globales y particulares de modo tal de llegar al estado “No conflicts” como

se ve en el diálogo siguiente:

36

Ç

Fig. 3.13: Ejemplo de diálogo sin conflictos.

Fuente:www.gxtechnical.com/gxdlsp/pub/genexus/.../9.0/manualnet90.htm

NOTA: recuerde utilizar el botón SAVE para salvar las reglas ingresadas, en caso contrario si necesita volver a

importar el conocimiento de esa base de datos deberá ingresar todas las reglas nuevamente.

A pesar de no existir conflictos se pueden aplicar reglas de “renombre” de objetos para cumplir con el estándar de la KB que consolidará ese XPW o por cualquier otro motivo que se requiera (cambio de idioma, atributos que

se llaman diferente se deberían llamar igual, etc.).

15) Modificación del orden de aplicación de las reglas: Es importante destacar que las reglas aplican

sobre los nombres internos. Por este motivo es fundamental el orden de aplicación de las mismas.

Supongamos que se tienen las reglas:23

Sustituir “A” por “B” y otra regla que sea “sustituir “B” por “C” en ese orden.

Se tienen los objetos A, B , C y D.

Al aplicar las reglas sucederá lo siguiente:

23 ARTech Consultores S. R. L.

37

A pasará a ser B (regla 1), este B pasará a ser C (regla 2)

B pasará a ser C (regla 2) El resultado final es C, C, C y D.

Si se cambia el orden de modo que queden las reglas: sustituir “B” por “C” y sustituir “A” por “B”, entonces

el resultado final será:

B,C, C,D

NOTA: no solo el orden de aplicación influye sobre el resultado final, también existe el “check box” llamado

“Stop after apply” en el diálogo de definición de reglas.

Fig. 3.14.- "log" de la información generada.

Fuente:www.gxtechnical.com/gxdlsp/pub/genexus/.../9.0/manualnet90.htm

En esta página (última del GX DVG Wizard) se muestra un “log” del XPW generado.

Si el DVG fue ejecutado desde GeneXus al dar “Finish” el mismo será consolidado en la KB desde donde se

ejecutó. Si fue ejecutado por fuera de GeneXus simplemente termina la aplicación habiendo generado el XPW

con la información, el mismo puede ser consolidado en cualquier KB (incluso utilizando versiones 5.6 o 6.0 de

GeneXus).

El botón SAVE tiene como objetivo salvar la información de conexión, selección de tablas y opciones utilizadas.

W. ESTILOS (STYLES).24

La introducción de este nuevo objeto, brinda varias ventajas al momento de desarrollar aplicaciones Web con GeneXus, que detallamos a continuación:

Las aplicaciones web deben Tener una buena apariencia.

24 ARTech Consultores S.R.L.(Visión General )

38

Crear una aplicación Web implica crear una interfaz “visualmente atractiva” para el usuario. Como

contra parte, no es el desarrollador del sitio quien tiene los conocimientos y el tiempo para diseñar un

sitio con esas características. En versiones anteriores, una vez creada la estructura y lógica de un objeto Web, era necesario agregarle

a posteriori el trabajo de diseño, para que el mismo fuese visualmente aceptable para integrarse al sitio

Web.

El trabajo de diseño no es fácil, tiene muchas exigencias, y por lo tanto es necesario invertir mucho tiempo en él; cuando ese tiempo debería ser dedicado al desarrollo de la funcionalidad de la aplicación.

Hasta ahora hacía falta una forma de hacer que el desarrollador de la aplicación se olvidara por

completo del diseño gráfico de la misma.

Ahora el desarrollador puede focalizarse en la funcionalidad de la aplicación. Un Tema agrupa en “clases” la configuración de los controles, es decir, las clases son “diseños” para

todos los controles, por ejemplo, clases de botones, clases de grillas, clases de tablas, etc.

Lo único que el usuario tiene que hacer es asignar determinada clase a los controles, y los controles van

a reflejar las configuraciones de esa clase. Es decir que ahora no será necesario actualizar los valores de las propiedades de los controles

individualmente, y en cada form.

Entonces el usuario se desentiende completamente de lo que es el diseño propiamente dicho, del

control. Cuando se hace una aplicación Web es necesario que el sitio se vea “uniforme”.

Esto implícitamente requiere de un alto costo de mantenimiento, ya que si por ejemplo hay que cambiar el

color de una grilla de azul a celeste, probablemente habría que hacerlo en todas las páginas del sitio para

mantener la uniformidad del mismo.

Antes, había que ir por cada uno de los controles grid de cada objeto. Hoy el cambio se realiza en un solo lado: el

tema.

Todos los objetos basados en él van a reflejar el cambio automáticamente, y no solo eso! Sino que si se realiza

un cambio en el Tema, basta con guardarlo usando el editor (así se obtiene un archivo con extensión .css), y llevar ese archivo a producción. Nada más!! No es necesario generar ni compilar nada.

Mediante la nueva funcionalidad “Themes” introducida, será posible complementar el manejo de “styles”

GeneXus en ambiente web.

Por ejemplo, una vez definido un Master Style, y habiéndole asociado un Theme, los objetos inicializados con este style estarán asociados al mismo Theme.

Los cambios en las propiedades de los controles se realizarán a través de las clases del Theme, no a través del

style propiamente dicho. Como consecuencia de esto, los cambios en el style (indirectamente a través del Theme)

se van a reflejar en el objeto basado en él, asegurando el dinamismo esperado.

X. Ejemplo de uso de Temas “Themes”. El siguiente es un ejemplo básico de uso de temas.

1) Crear un nuevo Tema: Por el menú de GeneXus, ir a Object->New Object, y crear un objeto

GeneXus Theme.

2) Los Styles constituyen un tipo de objeto GeneXus orientado a la definición de interfaces de usuario y estándares de programación. Los Styles ofrecen una serie de mecanismos.

Para definir formatos de pantallas, reglas del negocio y eventos que serán utilizados.

Luego por GeneXus en forma automática, obteniendo sistemas de mayor calidad y Disminuyendo sensiblemente

los tiempos de desarrollo.

El estandarizar lo más posible una aplicación es un reconocido buen criterio de diseño.

En particular, la interfaz de usuario de una aplicación resulta crítica para construir sistemas amigables. Cuanto

más estándar sean los diálogos, más fácil de usar será la aplicación.

39

CAPÍTULO III

Y. Análisis de impacto.25

Una vez descritos los cambios de las visiones de usuarios GeneXus analiza automáticamente cual es el impacto de los mismos sobre la base de datos y produce un informe donde explica cómo debe hacerse la

conversión de los datos y si caben qué problemas potenciales tiene esa conversión (inconsistencias por viejos

datos ante nuevas reglas, etc.). El analista decide si acepta el impacto y sigue adelante o no.

Siempre que vaya del Modelo de Diseño a un Modelo de Prototipo o Producción (modelo objetivo),

GeneXus estima si el modelo objetivo debe ser actualizado para que coincida con el modelo de datos del

Modelo de Diseño. Si es así, GeneXus analiza el impacto de los cambios en la base de datos del modelo. Esto

se llama Análisis de Impacto y produce un Reporte de Análisis de Impacto que contiene lo siguiente:

Una descripción de la conversión de los datos (reorganización) a efectuar.

Advertencias sobre problemas posibles que pueden darse durante el proceso de reorganización (inconsistencias producidas por nuevas reglas aplicadas a viejos datos, etc.)

En base a la información presentada en el Reporte de Análisis de Impacto, usted puede decidir si continúa

con el proceso de reorganización o no.

Reorganización o Programas de Conversión.

Cuando usted está listo para proceder con la reorganización de la base de datos en el modelo objetivo, usted crea los Programas de reorganización y los ejecuta. Los programas de reorganización crean un nuevo

esquema de base de datos en la base de datos física del modelo objetivo y transportan los datos desde el

esquema viejo al nuevo. Este proceso es generalmente considerado como una refactorización de la base de

datos efectuada automáticamente por GeneXus.

Z. Diagrama de navegación: Define la estructura de navegación del sistema presentándolos diversos

caminos existentes, a través de enlaces. Igualmente, este diagrama incluye las herramientas que facilitan el acceso

directo a determinados nodos.

Describe gráficamente el esquema lógico de una base de datos jerárquica como se muestra en la figura nº4.1.

1) Estructura:26

En la Figura se muestra la estructura de los diagramas de navegación. Se

utiliza una representación de árbol para indicar los hijos definidos para cada elemento.

25 ARTech Consultores S.R.L.(Visión General ) 26 Facultad de Ingeniería Universidad de la República, Nicolás Castagnet ,2007

40

Fig. 4.1. Estructura de los diagramas de navegación.

Fuente: http://www.fing.edu.uy/inco/grupos/gris/wiki/uploads/ProyectosGrado/Proceso-NC2006.pdf

2) Elemento y Atributos

3) Raiz (Root.): Raíz del documento. Actúa como contenedor del resto de los elementos.

No tiene atributos.

4) Contexto (Context): Permite configurar el contexto en que se ejecuta la navegación.

Atributos:

5) Tipo (Type): Indica el tipo de contexto. Los valores posibles son:

Menú; Se aplica cuando la navegación se ejecuta desde el menú principal.

Flujo de trabajo (Workflow): Se aplica cuando se ejecuta desde un proceso de Workflow.

Texto (Text): Texto asociado al contexto, su significado depende del tipo de contexto. Si el tipo es

Menu, indica el nombre de la opción de menú. En caso que sea Workflow, indica los datos que se almacenan a

nivel de la instancia del proceso.

6) PERFILES (Profiles): Define los perfiles que están habilitados a ejecutar la navegación. Se aplica

únicamente cuando el tipo de contexto es Menu. Al cargar el menú principal sólo se incluye la opción si el

41

usuario tiene uno de los perfiles válidos. Se puede indicar más de un perfil separándolos por coma. Si el

atributo se deja vacío no se aplica la restricción por perfil.

Form: Representa una página de la navegación.

Atributos:

Title(:). Titulo de la página.

Type(:). Tipo de página. Los valores posibles son:

7) FormWebPanel: La página se representa con un WebPanel generado a partir de un objetoForm.

8) Forma de transacciones (FormTransaction): La página se representa con una Transacción generada a

partir de un objeto Form (sólo se genera el formulario de la misma, y no su estructura).

9) Web Panel: Define que se utiliza un Web Panel externo, su nombre se indica en el atributo Object Name.

10) AfterTrnCode: Código adicional que se incluye en el evento AfterTrn (cuando el tipo es

FormTransaction).

11) Acciones (Actions): Permite asociar acciones que el usuario puede realizar en la página, generalmente se

representan con botones o links dentro de grillas. Cada acción se define con un elemento Action.

12) Nombre del objeto (ObjectName): Se utiliza para representar la página.

13) Parámetros (Parameters): Se invoca al objeto de la página. Los parámetros se calculan de forma

automática en función de los símbolos que se utilicen dentro de las páginas. Sin embargo, se puede

modificar este atributo para agregar variables adicionales dentro de la lista de parámetros.

14) Nombre del símbolo (Selection Name): Se asocia la selección (sólo se muestra cuando hay una

expresión asociada a la página).

15) Fuente (Source) :De donde se obtienen los datos a mostrar/escribir en la página (sólo se muestra cuando

hay una única expresión asociada a la página).

16) Condición (Where): De filtrado sobre los datos (sólo se muestra cuando hay una única expresión

asociada a la página).

17) Orden (OrderBy): Utilizado para mostrar los datos cuando en la fuente se define un conjunto (sólo se

muestra cuando hay una única expresión asociada a la página).

18) Filtros (FilterBy): Que se le presentan al usuario para restringir los registros que se despliegan cuando la

fuente es una tabla (sólo se muestra cuando hay una única expresión asociada a la página).

19) Fuentes de datos (Data Sources): A través de este atributo se puede indicar más de una expresión a la

página. Cada expresión se representa con el elemento Expression.

20) CallOnStart : Permite definir cero o más objetos que se llaman al cargar la página para inicializarla.

Se pueden utilizar para cargar variables adicionales. Cada una de estas invocaciones se representa con el

elemento InitCall.

21) Acción (Action): Define una acción que puede realizar el usuario sobre la página.

Atributos:

Titulo (Caption): Etiqueta que se muestra para identificar a la acción en la página.

Objeto (Object): Objeto que se invoca para ejecutar la acción.

Parámetros (Parameters): Parámetros con que se realiza la invocación. Se pueden incluir tanto

variables como referencias a símbolos. En este último caso se pasa la clave del registro que determina

el símbolo.

22) Expresión (expression): Representa una expresión que determina los datos que se muestran o escriben en

la página.

23) Initcall: Define una invocación para realizar cuando se muestra la página.

Atributos:

Caption: Permite definir un nombre para identificar la llamada.

Object: Nombre del objeto que se invoca.

Parameters: Parámetros con que se realiza la invocación.

24) Ruta(Route): Brinda un camino para ir de una página a otra. Por cada ruta se agrega una opción en la

página de origen que le permite ir a la página destino. 25) Caption: Define la etiqueta de la opción asociada a la ruta. Si no se define este atributo se toma el titulo de

la página destino.

26) Tab: Indica si la ruta se representa como una pestaña en la página de origen. 27) Enlace de Grilla (Grid Link): Indica si la ruta se representa como un link dentro de una grilla de la página

de origen. Sólose puede utilizar si muestra una tabla en dicha página.

28) Insertar (Insert): Indica si se define una operación de inserción. En caso que se indique True se utiliza unatransacción en la página destino y al invocar esta operación se llama en modo INS.

29) Actualizar (Update): Indica si se define una operación de modificación. En caso que se indique True se

utiliza una transacción en la página destino y al invocar esta operación se llama en modo UPD.

42

30) Eliminar (Delete): Indica si se define una operación de borrado. En caso que se indique True se utiliza una

transacción en la página destino y al invocar esta operación se llama en modo DLT27

AA. Especificación. Este proceso genera un archivo de especificación por cada objeto

GeneXus en el modelo de Prototipo o Producción. El archivo de especificación describe el comportamiento del objeto GeneXus y un lenguaje intermediario que es independiente del lenguaje objetivo de la aplicación.

Estos archivos tienen extensión “spc”. Por cada archivo de especificación, GeneXus genera un Reporte de

Especificación (que veremos en el próximo paso) que describe la lógica del objeto y muestra advertencias y errores. Una vez que se ha especificado un objeto (o un grupo de objetos), el analista puede indicar a GeneXus

que genere los programas de la aplicación.

Todo el conocimiento provisto por el analista, o inferida por GeneXus, está disponible en un repositorio activo,

que constituye una muy completa documentación on- line, permanentemente actualizada.

BB. Generación de programas. Una vez que los problemas han sido solucionados o bien se ha aceptado la conversión "default " que GeneXus realiza en forma estándar se generan automáticamente los programas para hacer la conversión (estructura y

contenido) de la vieja base de datos a la nueva.

CC. EJECUCIÓN. A continuación, se pasa al ambiente de ejecución que corresponda (prototipo, producción Internet, producción

Cliente / Servidor, etc.) y se ejecutan los programas de conversión.

En el menú Build, haga clic en Run.: También puede hacer clic en el acceso directo como se

muestra en la figura nº5, a Run en la Barra de Herramientas del Modelo (último botón a la derecha), o

simplemente presionar F5.

Fig. 5.- barra de herramienta

Haga clic en Compile en el Executiondialog box : que se desplegará para compilar su aplicación.

Fig. 5.1: Ventana de Compile.

Fuente: http://es.scribd.com/lucio3107/d/26945674-Primeros-Pasos-Con-Genexus-90

27 Facultad de Ingeniería Universidad de la República, Nicolás Castagnet ,2007

43

Aparecerá una ventana de Compilación GeneXus. Cuando el Estado (Status) de la Tarea Task) cambie

a Succeeded, presione Close.28

Fig. 5.2: Ventana de Compile Completa.

Fuente: http://es.scribd.com/lucio3107/d/26945674-Primeros-Pasos-Con-Genexus-90

Haga clic en Execute en el Executiondialog box para ejecutar su aplicación.

28 Pressman, R, Ingeniería del Software: Un enfoque práctico, McGraw Hill 1997.

44

CAPITULO IV

DD. Capturar el conocimiento. 29

GeneXus es una herramienta que captura el conocimiento contenido en las visiones de los usuarios y lo

sistematiza en una base de conocimiento puro, que permite generar aplicaciones para múltiples plataformas y

arquitecturas.

La idea básica de GeneXus es automatizar todo aquello que es automatizable. Basado en los requerimientos

de los usuarios, realiza el proyecto, generación y mantenimiento automáticos de la base de datos y de los

programas de la aplicación.

Existe en las visiones de los usuarios y sistematizarlo en una base de conocimiento.

La característica fundamental de esta base de conocimiento que la diferencia de los tradicionales diccionarios de datos es su capacidad de inferencia: se pretende que en cualquier momento se puedan obtener de esta base de

conocimiento tanto elementos que se han colocado en ella como cualquier otro que se pueda inferir a partir de

ellos.

EE. Creación de la base del conocimiento.

En primer lugar, se debe crear la Base de Conocimiento y consolidar el archivo“3tierApplicationCourse.xpz”,

que contiene algunas transacciones, workpanels, reportes y procedimientos.

Una vez realizada la consolidación, vamos entonces a crear un modelo de prototipo para realizar la definición del

primer modelo de una aplicación distribuida con .NET. Para poder implementar la aplicación necesitamos contar con un DBMS, en nuestro computador ejemplo vamos a

utilizar SQL Server 2000. Una alternativa es utilizar MSDE, una versión libre y reducida de SQL Server 2000.

Usted deberá crear una base de datos para el ejemplo y un usuario que tenga acceso a la misma.

Abra su GeneXus

En el menú File, haga clic en NewKnowledge Base.

Ponga un nombre a la Base de Conocimiento:

Demo. Haga clic en OK para continuar.

Fig. 6.- creación de base de conocimiento.

Fuente: http://es.scribd.com/lucio3107/d/26945674-primeros-pasos-con-genexus-90

FF. Transacciones de la aplicación.

Una transacción es un proceso interactivo que permite a los usuarios crear, modificar o eliminar información de la

base de datos.

Ejemplos:

1) Pantalla para crear, modificar o eliminar los Clientes de la Empresa.

29 Laboratorio Ing. Soft., Ingeniería de software 2, Departamento de Informática, 2002.

45

2) Pantalla de facturación: proceso que permite a un usuario crear facturas e incluso imprimirlas.

3) Una pantalla permite al usuario tomar diferentes acciones como insertar, actualizar, eliminar, imprimir sin tener

que volver al menú para hacerlo.

4) Para crear la primera transacción, que representa una factura, siga los siguientes pasos:

En el menú Object seleccione NewObject

Seleccione el tipo de objeto que quiere crear: Transaction

Ponga nombre al Objeto: Invoice (Factura) Haga clic en OK

Fig. 6.1: creación de una transacción.

Fuente: http://es.scribd.com/lucio3107/d/26945674-Primeros-Pasos-Con-Genexus-90

GG. Objetos de la aplicación30

. Aquí unas muestras de la creación de los objetos que utilizaremos en nuestro desarrollo de la aplicación.

1) La estructura del objeto transacción: Es una descripción de los datos requeridos para conocer el

objeto real que este representa. En la estructura, debemos declarar los atributos (campos) que forman la

transacción (los datos con los que el usuario interactuará) y las relaciones entre ellos. En base a esta

estructura, GeneXus diseña y mantiene automáticamente la base de datos correspondiente (tablas,

claves, índices, restricciones de integridad, etc.) en 3era forma normal. Los elementos claves para definir la estructura de la transacción son los siguientes:

2) Atributos: Cada atributo es definido por su nombre, tipo de datos y descripción.

3) Niveles: Los atributos se agrupan en uno o más niveles, y estos niveles pueden será ni dados o

paralelos (pueden haber múltiples niveles anidados). Por ejemplo: las líneas de una factura representan un nivel anidado al nivel raíz. El nivel de las líneas de la factura de muestra el hecho de que una factura

puede tener muchas líneas, es decir, define una relación de una a muchas entre la factura y las líneas de

la factura.

4) Atributos de Clave Primaria (PK): En cada nivel, uno o más atributos deben ser definidos como la

Clave Primaria del nivel.

30 Cockburn, A., Agile Software Development, Addison Wesley, 2002.

46

5) La Clave Primaria es un identificador de cada instancia del nivel.

Los valores de la Clave Primaria son únicos y una vez que se ingresan no pueden ser actualizados.

Si no existe una Clave Primaria “natural” para su objeto, debe crearse una “artificial”; por

ejemplo, Customer ID.

HH. Prototipo.

En las tareas de diseño están implícitas las dificultades de toda comunicación humana:

El usuario olvida ciertos detalles; El analista no toma nota de algunos elementos;

El usuario se equivoca en algunas apreciaciones;

El analista interpreta mal algunas explicaciones del usuario.

Pero, además, la implementación de sistemas es, habitualmente, una tarea que asume bastante tiempo, por lo que: muchos de estos problemas sólo son detectados en las pruebas finales del sistema, el costo

(tiempo y dinero) de solucionar los es muy grande

1) La realidad cambia: Por ello, no es razonable pensar que se pueden congelar las especificaciones

mientras se implementa el sistema la consecuencia de la congelación de las especificaciones, es que se acaba

implementando una solución relativamente insatisfactoria.

2) 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 posteriormente siempre se presentan sorpresas.

Una situación bastante diferente sería la de poner a disposición del usuario para su ejecución, inmediatamente

una aplicación funcionalmente equivalente a la deseada hasta en los mínimos detalles.

Esto es lo que hace GeneXus: Un prototipo GeneXus es una aplicación pronta, funcionalmente equivalente a

la aplicación de producción.

La diferencia entre prototipación y producción consiste en que la primera se hace en un ambiente de

microcomputador, mientras que la producción se realiza en el ambiente objeto del usuario (IBMiSeries, Client e /

Servidor, JAVA, .NET) .

El prototipo permite que la aplicación sea totalmente probada antes de pasar a producción.

Durante estas pruebas, el usuario final puede trabajar con datos reales, o sea que prueba de una forma natural

no solamente formatos de pantallas, informes, etc. sino también fórmulas, reglas del negocio, estructuras de datos, etc.

La filosofía de GeneXus es de desarrollo incremental. Cuando se trabaja en un ambiente tradicional, los

cambios en el proyecto hechos durante la implementación y sobre todo, aquellos que son necesarios luego de que el sistema está implantado, son muy costosos.

GeneXus resuelve este problema: construye la aplicación con una metodología de aproximaciones sucesivas

que permite, una vez detectada la necesidad de cambios prototiparlos y probar los inmediatamente por parte del usuario, sin costo adicional.31 (Mestras, 2005)

Un Prototipo GeneXus es una aplicación “lista para trabajar” que es funcionalmente equivalente a la

aplicación final de producción. El prototipo está ideado para correr en ambientes PC, pero puede ejecutarse en cualquier plataforma seleccionada. GeneXus es capaz de generar código para los siguientes lenguajes: C# (para

.NET Framework y .NET Compact Framework), Java, C/SQL, Cobol para iSeries, RPG para iSeries, Visual

Basic (standalone y C/S),Embedded Visual Basic, y Visual Fox Pro (standalone y C/S).

31 Sommerville, I., Ingeniería de Software, Pearson Educación, 2002.

47

El prototipo le permite probar la funcionalidad de su aplicación antes de ponerla en producción. Su usuario final

puede fácilmente probar pantallas, reportes, fórmulas, reglas del negocio, estructuras de datos, etc.

Trabajar con un Prototipo consiste en lo siguiente:

Administrar la base de datos física asociada con el Modelo de Prototipo.

Ejecutar la aplicación del Modelo de Prototipo con fines de evaluación.

3) Whitepapers: Es un informe de referencia o guía que ayuda a resolver un problema.

4) Cobol: (Common Business –Oriented Language - Lenguaje Común Orientado a Negocios). COBOL es un lenguaje de programación creado en 1960 con el objetivo de crear un lenguaje universal para cualquier tipo de computadora, orientado a la informática de gestión. Este lenguaje fue creado por la comisión CODASYL, compuesta de fabricantes de computadoras, usuarios y el Departamento de Defensa de EE.UU., creada en mayo de 1959.

La definición se completó unos seis meses más tarde y fue aprobada por la comisión en enero de 1960. COBOL fue diseñado a partir del lenguaje FLOW-MATIC de Grace Hopper y el IBM COMTRAN de

Bob Bemer (ambos participantes de la comisión CODASYL).

COBOL fue revisado en 1961 y 1965 para añadirle funcionalidades. En 1968 llegó la primer versión ANSI del

lenguaje, para luego revisarse en 1974 (COBOL AND-74), 1985 (COBOL ANS-85) y 2002 (COBOL ANS-

2002).

5) Visual Basic: Visual Basic es un lenguaje de programación dirigido por eventos, desarrollado por el

alemán Alan Cooper para Microsoft. Este lenguaje de programación es un dialecto de BASIC, con importantes agregados. Su primera versión fue presentada en 1991, con la intención de simplificar la programación utilizando

un ambiente de desarrollo completamente gráfico que facilitara la creación de interfaces gráficas y, en cierta

medida, también la programación misma. La última versión fue la 6, liberada en 1998, para la que Microsoft

extendió el soporte de este lenguaje hasta marzo de 2008.

En 2001 Microsoft propuso abandonar el desarrollo basado en la API Win32 y pasar a un framework o marco

común de librerías, independiente de la versión del sistema operativo, .NET Framework, a través de Visual Basic

.NET (y otros lenguajes como C Sharp (C#) de fácil transición de código entre ellos); fue el sucesor de Visual

Basic 6.Si bien Visual Basic es de propósito general, también permite el desarrollo de aplicaciones de bases de datos usando Data Access Objects, Remote Data Objects, o ActiveX Data Objects.

Visual Basic (Visual Studio) contiene un entorno de desarrollo integrado o IDE que incluye un editor de textos

para edición del código, un depurador, un compilador (y enlazador) y un constructor de interfaz gráfica o GUI.

6) Visual FoxPro: Es un lenguaje de programación orientado a objetos con un Sistema Gestor de Bases de

datos

7) Ruby: Es un lenguaje de programación interpretado, reflexivo y orientado a objetos, creado por el

programador japonés Yukihiro "Matz" Matsumoto

8) C#: Es un lenguaje de programación orientado a objetos desarrollado y estandarizado por Microsoft

9) Java: Una tecnología desarrollada por Sun Microsystems para aplicaciones software independiente de la

plataforma.

10) Microsoft SQL Server: Es un sistema para la gestión de bases de datos producido por Microsoft basado en

el modelo relacional.

11) Oracle: Es un sistema de gestión de base de datos objeto-relacional (o ORDBMS por el acrónimo en inglés

de Object Relational Data Base Management System), desarrollado por Oracle Corporation.32

12) MySQL: Es un sistema de gestión de base de datos relacional, multihilo y multiusuario con más de seis

millones de instalaciones.

32 http://www.tayuda.com (tutoriales)

48

13) Intranet: Una intranet es una red de ordenadores privados que utiliza tecnología Internet para compartir

dentro de una organización parte de sus sistemas de información y sistemas operacionales

14) Extranet: Una extranet es una red privada que utiliza protocolos de Internet, protocolos de comunicación y

probablemente infraestructura pública de comunicación para compartir de forma segura parte de la información u operación propia de una organización con proveedores.

49

CAPITULO V

II. Conclusión.

GeneXus genera el 100 % de sus Aplicaciones basándose en los requerimientos de usuario, teniendo

libertad de programación y manteniendo de forma automática tanto los Programas como la Base de Datos

de sus Aplicaciones.

GeneXus es una herramienta para el desarrollo de software multiplataforma, que permite desarrollar de

forma verdaderamente incremental, Aplicaciones Críticas de Negocio.

GeneXus soporta los principales Lenguajes y Plataformas de ejecución, así como los más populares sistemas de gestión de Base de Datos.

La idea básica de GeneXus es automatizar todo aquello que es automatizable: De esta manera se evita que el

analista deba dedicarse a tareas rutinarias y tediosas, permitiéndole poner toda su atención en aquello que nunca un programa podrá hacer: entender los problemas del usuario.

Gracias a su inferencia, GeneXus hace en forma automática un conjunto de tareas que al desarrollador le

resulta difícil realizar manualmente

Los clientes podrán regenerar sus sistemas usando simplemente nuevos generadores GeneXus que incluyan

esa nueva tecnología.

Ante cambios en la estructura de datos, GeneXus se encarga de dos cosas. Por un lado, de generar los

programas que modifican la base de datos a la vez que conserva los datos. Por otro lado, también regenera los programas de la aplicación.

JJ. Recomendación.

Luego de finalizado el presente trabajo de investigación y analizadas las conclusiones de la misma, se sugieren

las siguientes recomendaciones.

Esta es quizás la característica más importante de GeneXus, y la que lo diferencia de manera más clara de sus

competidores es el mantenimiento, tanto de la base de datos (estructura y contenido) como de los programas, es

totalmente automático.

GeneXus es una herramienta muy poderosa y muy fácil de manejar para el desarrollo de diferentes aplicaciones,

por su gran variedad de opciones de desarrollo y su fácil mantenimiento.

La Venta de su aplicación en casi cualquier lenguaje extranjero haciendo pocos o ningún cambio en los códigos.

Una de sus grandes virtudes es el acceso a más bases de datos que nunca.

Crear aplicaciones más fáciles de usar con “no código”, autocompletar, combos linkeados o list boxes. Hereda

bases de datos más rápido y fácil.

Ya que las aplicaciones y sus bases de datos son cada vez más complejas, y al diseñar grandes bases de datos (con cientos de miles de tablas) se cometen muchos errores humanos y, básicamente, porque en las grandes

organizaciones no existe nadie que conozca los datos de la empresa con la adecuada objetividad y el suficiente

detalle.

El diseño de las aplicaciones se realiza en computadoras donde se puede probar el sistema en base a la generación

de prototipos. Recién cuando el sistema es aprobado por los usuarios, el programa se genera en forma automática

para la plataforma de producción real.

50

BIBLIOGRAFIA

Consultores, A. (15 de Enero de 2008). Comunidad GeNexus. Uruguay .

GeneXus, l., & genexus, t. (2010). Capasitate con Genexus. Montevideo,, Uruguay.

González, C. S. (28 de Septiembre de 2004). ONess. Recuperado el 2011

http://oness.sourceforge.net/proyecto/html/ch03s02.html, F. (28 de Septiembre de 2004).

http://oness.sourceforge.net/proyecto/html/ch03s02.html. Recuperado el 25 de 12 de 2011, de http://oness.sourceforge.net/proyecto/html/ch03s02.html

R., A. C. (6 de Abril de 2009). Tutorial Genexus. MEXICO CITY, MEXICO, MEXICO.

Salsano, D. (2003 de Diciembre de 2006). GeneXus Vision General. Mexico, Mexico, Mexico.

Sassagima, E. (2009). Aplicaciones Genexus. Mexico.

Tecnicos, G. (2009). http://www.gxtechnical.com/gxdl); . Mexico.

Vicente, J. (210). http://genexusred.blogspot.com.