genexus - DSpace de la Universidad Catolica de Cuenca

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
I
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
II
RESPONSABILIDAD
Todos los criterios vertidos en el presente trabajo
de investigación, son de exclusiva responsabilidad
de su autor.
…………………………………..
Tnlg. Johny Xavier Ortiz Campoverde
III
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
IV
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.
V
Í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
VI
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
VII
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.
1
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).
2
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) [email protected]
3
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.
4
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.
[3]
5) Orientarse a los datos (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:



F.
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.
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)
5
 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:
4
3) Más estabilidad: 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
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.
http://genexusred.blogspot.com
6
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
7






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)
8
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 .net 8
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
9
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:









9
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.
Base del conocimiento: www.wikipedia.com
http://wiki.gxtechnical.com
10
10
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)
11
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.
12
5)Visión global a los objetos GeneXus: 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.
12
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
14
http://genexusred.blogspot.com
http://genexusred.blogspot.com
13
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:
14
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.
15
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.
16
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.
17
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
18
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
19
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
20
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.
Insertar control grid
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á
21
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)
22
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).
Objetos Web.
P.
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
23
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
24
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).
25
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.
26
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.
27
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,
28




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
29
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”.
30
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)
8)
Empezar por (Beginswith): Busca los nombres de objeto que empiecen con el texto ingresado.
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.
31
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
32
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.
33
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.
34
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:
35
Ç
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.
36
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.
24
W. ESTILOS (STYLES).
La introducción de este nuevo objeto, brinda varias ventajas al momento de desarrollar aplicaciones Web con
GeneXus, que detallamos a continuación:

24
Las aplicaciones web deben Tener una buena apariencia.
ARTech Consultores S.R.L.(Visión General )
37










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
2)
GeneXus Theme.
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.
38
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.
26
1)
Estructura: 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
26
ARTech Consultores S.R.L.(Visión General )
Facultad de Ingeniería Universidad de la República, Nicolás Castagnet ,2007
39
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
40




7)
8)
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:
FormWebPanel: La página se representa con un WebPanel generado a partir de un objetoForm.
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.
41
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
42

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

28
Haga clic en Execute en el Executiondialog box para ejecutar su aplicación.
Pressman, R, Ingeniería del Software: Un enfoque práctico, McGraw Hill 1997.
43
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.
44
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.
45
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.
46
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 ANS2002).
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
C#: Es un lenguaje de programación orientado a objetos desarrollado y estandarizado por Microsoft
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.
8)
9)
32
http://www.tayuda.com (tutoriales)
47
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.
48
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.
49
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.
50