1

Herramientas y metodologas

HERRAMIENTAS Y METODOLOGAS:

Nuestra tarea como profesionales de la informtica es desarrollar y mantener aplicaciones para apoyar al usuario en su actividad final. Para realizar esta tarea se han instrumentado diferentes herramientas y metodologas. Con GeneXus se desarrollan aplicaciones aplicando una metodologa que tiene un enfoque muy diferente al de las metodologas mas comnmente utilizadas. Aprender a utilizado adecuadamente va ms all de conocer el lenguaje de especificacin ms importante es el aprendizaje de una nueva metodologa de desarrollo. y lo

El primer problema al que nos enfrentamos en el desarrollo de aplicaciones es la obtencin del conocimiento de la realidad. Cmo obtener el conocimiento de la realidad en una forma lo suficientemente objetiva y detallada al mismo tiempo, que nos permita construir un modelo corporativo.

2

Todos compartirn la afirmacin de que cada usuario conoce muy bien los objetos con los que trabaja cotidianamente, conoce claramente la informacin que se maneja en ellos, que reglas deben seguirse y que clculos deben realizarse. Por lo tanto, utilizar estas visiones de los objetos de su realidad como fuente de informacin parece muy razonable. Se ha demostrado con mucha rigurosidad que es posible obtener un modelo de datos a partir de la sntesis de visiones, por lo que nuestro problema se ha reducido a un problema matemtico ya que si conseguimos describir adecuadamente estas visiones podremos obtener mediante Ingeniera Inversa el modelo de datos. Este mtodo que se conoce como sntesis de visiones cannicas. Este es el punto de partida de la metodologa de GeneXus: Describir las visiones de los usuarios para modelar el sistema, y se construir a partir de este modelo el soporte computacional (base de datos y programas) para soportarlo. COMPARACIN DE METODOLOGAS Es bueno, para fijar ideas, comparar la metodologa utilizada por GeneXus conocida como Metodologa Incremental con las metodologas tradicionales ms utilizadas actualmente. Algunos de los ejemplos de estas metodologas son: Anlisis Estructurado, Ingeniera de la Informacin, Anlisis Escencial. Estas metodologas son diferentes entre s, pero en todos los casos, separan el anlisis de los datos del de los procesos. Veremos un esquema general que podra aplicarse a cualquiera de stas metodologas y estudiaremos sus problemas. Metodologa Tradicional: La primera tarea, generalmente, es el anlisis de datos.

3

Se pretende analizar la empresa y dar como producto un modelo de datos con las Entidades y Relaciones encontradas (Modelo ER). Aqu se analiza la empresa desde el punto de vista de los objetos que existen en ella y sus relaciones. Construir un sistema integrado, que requiere un modelo de datos Corporativo de la empresa no es una tarea simple debido a que el nmero de objetos y relaciones hacen que esta tarea sea extremadamente compleja. Debido a la complejidad de la construccin de un sistema integrado, lo que se hace normalmente es dividirlo en mdulos, y cada uno solucionar los problemas operativos de un rea en particular de la empresa. Simplificaremos notablemente la tarea de modelado ya que lo que precisamos normalmente son 10 o a lo sumo 20 archivos para cada modelo. Los mdulos operan sin una real integracin, lo que hace que exista informacin redundante y como consecuencia todo intento de buscar informacin fuera del entorno de cada aplicacin resulte imposible o por lo menos peligroso. En caso de que deseramos posteriormente realizar la integracin de esos mdulos es necesario realizar modificaciones al modelo de datos (lo que a pesar de la complejidad podramos calificar como posible), pero las modificaciones que deberemos realizar en los programas tienen un costo tan grande que hacen inviable la realizacin de la integracin. La empresa tendr de esta forma, resueltos sus problemas operativos, pero luego aparecern con mucha claridad los problemas de la carencia de informacin que permitan orientar la gestin y la toma de decisiones de alto nivel, ya que la informacin que se necesita es en general de naturaleza corporativa. En la medida que nos orientamos cada vez ms a las bases de datos corporativas, la cantidad de objetos que integran la base de datos y sus relaciones se hacen ms complejas. Esto lleva a que el diseo de una base de datos corporativa sea una tarea muy complicada y en la que son muchos los errores que se pueden cometer. GeneXus apunta a la creacin de sistemas corporativos, brindando herramientas y una metodologa que hagan posible la realizacin de esta tarea.

4Continuando con el proceso de desarrollo en una metodologa tradicional, luego de obtener el modelo de datos se pasa a disear la base de datos. Podemos ver que entre un buen modelo de datos, y el diseo de la base de datos necesaria para soportarte, existe una transformacin trivial. Por ello, para mayor claridad del dibujo, eliminaremos la etapa intermedia y colocaremos directamente la base de datos. Pero el modelo de datos no es suficiente para desarrollar los programas de aplicacin, porque describe los datos, pero no los comportamientos. Se recurre a una tarea generalmente llamada Anlisis Funcional, donde se estudia la empresa desde el punto de vista de las fundones y que tiene como resultado una Especificacin Funcional. El producto de la funcin anterior es la Especificacin Funcional. Sera deseable que esta Especificacin Funcional fuera independiente de la Especificacin de Datos. Pero esto no es lo comn en las metodologas estudiadas. Las especificaciones producidas son "file dependents" y, en consecuencia, modificaciones en el diseo de la base de datos, implican la necesidad de revisar las especificaciones funcionales. Esta es la causa fundamental de los grandes costos de mantenimiento que deben soportar las empresas. Entre las alternativas ms usadas se destacan la programacin en lenguajes de 3a. generacin, y en lenguajes de 4a. generacin. Lenguajes de 3a. Generacin: Lenguajes de bajo nivel como pueden ser COBOL, RPG. C, PASCAL, ADA, FORTRAN. Lenguajes de 4a. Generacin: Lenguajes de programacin de alto nivel como pueden ser CA IDEAL. INFORMIX 4GL. NATURAL 2, PROGRESS, etc. Desde un punto de vista conceptual, ambos casos son idnticos. En ambos el analista debe estudiar el problema, transformarlo en un algoritmo y codificar dicho algoritmo en el lenguaje de programacin. Sin embargo, existe una fuerte diferencia: en los lenguajes de 4a. generacin se escribe mucho menos (probablemente 10 veces menos) y, como consecuencia, la productividad es mucho mayor y el nmero de errores cometidos es mucho menor. Podra argumentarse en contrario, que se pierde flexibilidad con estas herramientas, lo que es cierto en trminos tericos, pero es irrelevante en trminos prcticos, dado que hoy estas herramientas estn dotadas de primitivas que permiten complementar su cdigo, por lo que su aplicabilidad ha crecido mucho. El problema visto, de que las descripciones de los procesos dependen de la base de datos, afecta a ambos por igual. Como consecuencia, los lenguajes de 4a. generacin permiten aumentos de productividad muy grandes sobre los de 3a., en la tarea de desarrollo, pero ayudan bastante poco en la de mantenimiento. Otra alternativa es la utilizacin de un "generador" que es una herramienta que puede interpretar la especificacin funcional, (que obviamente debe ser totalmente rigurosa), y producir automticamente los programas.

5Aqu existe una diferencia conceptual muy grande con el caso anterior. En este caso el analista describe el problema de una forma declarativa (no existe algoritmo ni codificacin procedural alguna). Algunos ejemplos son ADELIA, AS/SET. LANSA, SYNON. TELN. etc. Existe otra categora de herramientas conceptualmente idntica: la de aquellas que, simplemente, interpretan la especificacin, como por ejemplo: MAGIC y SAPIENS. La programacin en ambos casos es totalmente automtica, por lo que el aumento de productividad sobre las herramientas de 3a. generacin es muy grande. Podra argumentarse en contrario, como a menudo se ha hecho con las herramientas de 4a. generacin, que se pierde flexibilidad con estas herramientas, lo que es cierto en trminos tericos, pero es irrelevante en trminos prcticos, dado que, hoy, estas herramientas estn dotadas de Lenguajes de Diagramas de Accin, (en la prctica lenguajes de 4a. generacin), que permiten complementar su cdigo, por lo que su aplicabilidad ha crecido mucho. El problema visto, de que las descripciones de los procesos dependen de la base de datos, afecta tambin a las aplicaciones generadas mediante estas herramientas. Como consecuencia, los Generadores y los Interpretadores (como los lenguajes de 4a. generacin) ayudan bastante poco en la tarea de mantenimiento. Resumiendo aqu las tres opciones vistas: Lenguajes de 3a. Generacin Lenguajes de 4a. Generacin Generadores Baja productividad en el desarrollo Buen aumento de productividad en el desarrollo sobre L3G.

Buen aumento de productividad en el desarrollo sobre L3G y L4G.

Desde el punto de vista del mantenimiento, ninguna de las herramientas ayuda mucho dado que, en todas ellas, se utilizan descripciones de procesos que pueden perder su validez cuando existen modificaciones de archivos y que, por ello, deben ser revisadas y mantenidas manualmente. Existe, sin embargo, un postulado cuyo cumplimiento evitara este problema: PUEDE OBTENERSE UNA BASE DE DATOS ESTABLE. Lamentablemente, este postulado es falso, y sobran los contraejemplos que lo demuestran.

METODOLOGA CENEXUS: Los fundadores de ARTech han desarrollado una amplia actividad de consultara internacional en diseo de grandes bases de datos. Cuando se comenzaron a utilizar verdaderos modelos corporativos, que normalmente poseen cientos de tablas, les qued claro que no deba perderse ms tiempo buscando algo que no existe: las bases de datos estables. Luego de importantes investigaciones, desarrollaron una teora, organizaron una metodologa e implementaron una herramienta para posibilitar el desarrollo incremental y permitir la convivencia con las bases de datos reales (inestables), a costo mnimo.

6Desarrollo con GENEXUS:

Utilizando GENEXUS, la tarea bsica del analista es la descripcin de la realidad. Slo el hombre podra desarrollar esta tarea, ya que slo l puede entender el problema del usuario. Desde luego que esto modifica la actividad del analista e, incluso, su perfil ptimo, ya que lo transforma en un "Business Analyst". Ahora trabaja en alto nivel, discutiendo problemas con el usuario y probando con l las especificaciones a nivel de prototipo, en vez de desarrollar su actividad a travs de tareas de bajo nivel como son: disear archivos, normalizar, disear programas, programar, buscar y eliminar los errores de los programas.

Al crear un nuevo sistema o proyecto Genexus, se crea una nueva Base de Conocimiento. Una vez creada la nueva Base de Conocimiento, el siguiente paso es empezar a describir los objetos de la realidad mediante objetos Genexus. A partir de los objetos definidos en la Base de Conocimiento, GENEXUS genera automticamente tanto los programas de creacin / reorganizacin de la base de datos como los programas de la aplicacin.

7El trmino Base de Conocimiento hace referencia a la capacidad de reutilizar en forma automtica el conocimiento almacenado y sobre todo a la capacidad de realizar inferencias que permiten obtener ms conocimiento.

Como se ha visto, existen varios caminos para la implementacin de aplicaciones:1. PROGRAMACIN UTILIZANDO LENGUAJE DE 3A. GENERACIN. 2. PROGRAMACIN UTILIZANDO LENGUAJES DE 4A. GENERACIN 3. GENERACIN / INTERPRETACIN AUTOMTICA DE LA ESPECIFICACIN FUNCIONAL. 4. DESARROLLO INCREMENTAL.

La productividad en el desarrollo de aplicaciones aumenta de arriba a abajo. Disminuir en gran forma el mantenimiento de las aplicaciones (datos y programas), slo se consigue con el desarrollo incremental.

La primera tarea que hay que realizar es pasar a describir los objetos de la realidad, mediante objetos Genexus. Para ello existen 5 objetos bsicos: Transacciones: Las transacciones permiten definir los objetos de la realidad. La mayor parte de las transacciones pueden ser identificadas prestando atencin a las entidades que el usuario menciona (por eje. Clientes, Proveedores, Artculos). A partir de las transacciones Genexus infiere el diseo de la base de datos.

8Procedimientos: Procesos no interactivos de actualizacin de la base de datos (procesos baten). Reportes: Recuperan informacin a partir de los datos almacenados y no los alteran. Los reportes son lo que conocemos habitualmente como listados. Paneles de trabajo: Permite definir consultas interactivas a la base de datos. Es un objeto muy flexible que se presta para mltiples usos. Menes: Objetos organizadores del resto. Sistematizacin del conocimiento:

Veamos ahora con ms detalle el proceso de desarrollo de una aplicacin con GeneXus. GeneXus captura el conocimiento que reside en los objetos descritos y lo sistematiza en una base de conocimiento. GENEXUS funciona basado en su capacidad de inferencia. As infiere, por ejemplo:En el modelo de datos: las tablas, las restricciones de integridad y los ndices necesarios. Los programas de creacin y/o de reorganizacin de la base de datos. Los programas de la aplicacin. Los anlisis de impacto de los cambios.

9

A partir del conocimiento especificado a travs de las transacciones, GENEXUS disea el modelo de datos normalizados (en 3 Forma normal).

GENEXUS genera automticamente los programas necesarios para crear la base de datos, y la crea mediante ellos. GENEXUS genera automticamente, a partir de la base de conocimiento, los programas de la aplicacin.

10

En este estado, la aplicacin est lista.

Como se ha dicho, durante el ciclo de vida de la aplicacin, existen muchas modificaciones.

11Ante cambios en las visiones de usuarios, GENEXUS disea la nueva base de datos.

Algunas veces, la nueva base de datos coincide con la anterior, en cuyo caso, todos los programas existentes seguirn siendo vlidos. Otras veces, existen cambios en la base de datos. El anlisis de impacto de los cambios nos informa si debe reorganizarse la base de datos, cmo debe ser hecha esa reorganizacin y, los eventuales problemas que esa reorganizacin podra ocasionar. Una vez analizado el anlisis de impacto, el analista resolver efectuar la reorganizacin o renunciar a ella volviendo a la situacin anterior.

Si el analista ha dado el visto bueno a la reorganizacin, GENEXUS genera automticamente los programas necesarios para esa reorganizacin. GENEXUS, considerando la base de conocimientos nueva y la vieja, estudia el impacto de los cambios sobre los programas actuales y produce un informe sobre el tema. La reorganizacin

12consiste entonces, en ejecutar esos programas. En realidad es de esperar que tengan muchas tablas comunes, que no se modificarn en la reorganizacin.

GENEXUS genera / regenera automticamente los programas necesarios.

13Ahora se tienen las nuevas aplicaciones. El ciclo de mantenimiento est completo.

Mltiples Plataformas de ejecucin a partir de una nica especificacin.ARQUITECTURAS CENTRALIZADAS Plataforma AS/400 ARQUITECTURAS FILE SERVER Plataforma DOS WINDOWS Lenguaje Generado Foxpro, Clipper Foxpro for Windows Visual Basic Visual Fox Lenguaje Generado COBOL/ 400, RPG/400

DBF DBF Access DBF

ARQUITECTURAS CLIENT/ SERVER Plataforma FOXPRO FOR WIN, VB, VFP Lenguaje Generado ORACLE MS SQL SERVER INFORMIX DB2 Common Servers DB2/ 400

Unix, NT Alfa, Windows NT y 95 Unix, NT RS6000, OS2 AS400

La construccin automtica de la Base de Datos y programas a partir de una nica fuente de especificacin permitir a GENEXUS aplicar una metodologa de desarrollo que podramos llamar "Metodologa Incremental", ya que el proceso se realiza mediante aproximaciones sucesivas.

14En cada momento desarrollamos la aplicacin con el conocimiento que tenemos y luego cuando pasamos a tener ms (o simplemente diferente) conocimiento, GENEXUS se ocupar de hacer automticamente todas las adaptaciones en la base de datos y programas. El incrementar una aplicacin implica cambios en la base de datos y programas. Los cambios en la base de datos pueden tener un costo aceptable, pero el alto costo de las adaptaciones de los programas haran inviable la aplicacin de este mtodo si no fueran resueltos automticamente. Ciclos Diseo-Prototipo y Diseo-Produccin

El trabajo consiste de dos ciclos: el Ciclo de Prototipacin y el Ciclo de Produccin. Ciclo de Prototipacin: El diseador recorrer repetidamente el bucle Diseo-Prototipo durante la fase de diseo, construyendo y probando sucesivos prototipos del modelo. Ciclo de Produccin: Por el contrario, pasar menos frecuentemente al bucle de Diseo-Produccin, ya que la generacin del sistema se realiza solamente cuando el prototipo ha sido totalmente aprobado, o luego de haber instrumentado y probado algn cambio. Prototipacin Integral en PC:

15La construccin automtica del soporte computacional nos dar la gran posibilidad de crear prototipos. Verdaderos prototipos, ya que estos tendrn un funcionamiento equivalente al del sistema en produccin real, permitiendo que se pruebe hasta el ltimo detalle de la aplicacin. Los resultados que todos quieren ver, estn en forma de programas ejecutando, lo que no es posible sin la utilizacin de prototipos. Ventajas de la Prototipacin: Permite ver resultados en forma temprana Permite el seguimiento de los requerimientos del usuario Deteccin de errores en forma temprana Logra el compromiso de los usuarios con el desarrollo Sistemas de mejor calidad Toda comunicacin es suceptible de errores: 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, adems, la implementacin del sistema es, habitualmente, una tarea que consume bastante tiempo. Como muchos de estos problemas slo son detectados en las pruebas finales del sistema, el costo (tiempo y dinero) de solucionarlos es muy grande y la realidad cambia, por lo que no es razonable pensar que se pueden mantener las especificaciones mientras se implementa el sistema. La consecuencia de mantener las especificaciones, es que se acaba implementando una solucin relativamente insatisfactoria. El impacto de estos problemas disminuira mucho si se consiguiera probar cada especificacin, inmediatamente, y saber cual es la repercusin de cada cambio sobre el resto del sistema. Una primera aproximacin a esto, ofrecida por diversos sistemas, es la posibilidad de mostrar al usuario formatos de pantallas, informes, etc. animados por menes. Esto permite ayudar al usuario a tener una idea de qu sistema se le construir pero, al final, siempre se presentan sorpresas. Una situacin bastante diferente sera la de poner a disposicin del usuario para su ejecucin, inmediatamente, una aplicacin funcionalmente equivalente a la deseada, hasta en los mnimos detalles. Esto es lo que hace GeneXus: Un prototipo GeneXus es una aplicacin pronta, funcionalmente equivalente a la aplicacin de produccin. La diferencia entre prototipacin y produccin consiste en que la primera se hace en un ambiente de PC, mientras que la produccin se realiza en el ambiente objeto del usuario (AS/400, PC o redes de PC). El prototipo permite que la aplicacin sea totalmente probada antes de pasar a produccin. 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 tambin frmulas, reglas del negocio, estructuras de datos, etc. Problema: Analizar un proceso de emisin de las facturas en una empresa:

Ahora vamos a concentramos en cul es la forma prctica utilizada por GeneXus, para la captura de la realidad de la que tanto hablamos. Jean Dominique Wamier y Ken Orr, formularon una teora acerca de cmo puede ser construida una aplicacin de procesamiento de datos. Algunos de sus enunciados fueron los siguientes:

16

Los datos y los procesos estn estructurados. Todos los procesos son subdivididos en subconjuntos partiendo del nivel ms alto y empleando reglas de subdivisin adecuadas (de manera Jerrquica). Todo Proceso tiene un Comienzo, un Cuerpo, y un Final. Esta regla se aplica a la organizacin de datos y resultados.

Resolucin: Tenemos en este proceso 5 niveles, distinguiendo en cada nivel, los conjuntos repetitivos de lo que est presente una sola vez. Vemos que la gestin jerrquica de los datos hace aparecer relaciones entre los conjuntos definidos en los distintos niveles.

Existe entonces una ley de correspondencia: Un elemento de un conjunto de un nivel inferior, se corresponde con uno del nivel superior, si esta incluido en l. Todo conjunto de nivel inferior se llama Conjunto de Partida y todo conjunto de nivel superior se llama Conjunto de Llegada. En el momento de jerarquizar procesos y datos, sera muy bueno que obtuviera este tipo de relaciones. El no observar esta ley es fuente de confusin, eliminando la claridad y la simplicidad de la organizacin de los datos tanto como la de los procesos. DISEO DE TRANSACCIONES Notacin GeneXus para Transacciones: Ejemplo: Proceso de Emisin de Facturas FacNro* CliCod CliNom FacFch (ProdCod* ProdNom ProdPre) Cdigo de la factura Cdigo del cliente Nombre del cliente Fecha de la factura Cdigo del producto Nombre del producto Precio del producto

17

El siguiente paso es encontrar una forma de notacin adecuada para GeneXus. Por ejemplo, una transaccin de emisin de Facturas tendr la siguiente notacin. Cada nivel definir un conjunto de atributos que deben operar en conjunto. Se ingresarn, eliminarn o modificarn conjuntamente en la base de datos. Precisamos entonces encontrar un conjunto de atributos que acte como identificador de cada instancia de este conjunto. Notaremos a estos atributos con un asterisco. Este es en definitiva el concepto de clave primaria por lo que en la eleccin de estos atributos debemos atender a todas las reglas correspondientes a su definicin. El conjunto de atributos entre parntesis representa la ocurrencia de varios para cada instancia del nivel anterior. En el ejemplo, una factura tiene varios productos. Definicin del diseo de Base de Datos en 3era Forma Normal para soportar las transacciones definidas.

Veamos el proceso de obtencin de una base de datos en 3a Forma normal a partir de las especificaciones de transacciones. Para esto utilizaremos como ayuda las dependencias funcionales que se derivaran de la definicin de la transaccin. La definicin de esta primera transaccin a determinado las siguientes dependencias funcionales. FacNro FacNro FacNro CliCod CliNom FacFch

Por lo que se definir una tabla con el siguiente diseo FacNro* CliCod CliNom FacFch Tenemos adems las siguientes dependencias funcionales determinadas por el 2do nivel de la transaccin.

18

FacNro, ProdCod FacNro, ProdCod FacNro, ProdCod FacNro, ProdCod

ProdNom ProdPre FacLinCnt FacLinImp

Que definirn una tabla con el siguiente diseo ProdCod* ProdNom ProdPre FacLinCnt FacLinImp

La definicin de dos nuevas transacciones: Clientes y Productos han determinado la aparicin de nuevas dependencias funcionales. GeneXus disear las nuevas tablas que correspondan (Clientes y Producto) y realizar las modificaciones necesarias en las ya existentes (Factura y Factura1) para considerar el conjunto total de dependencias funcionales. CliCod ProdCod CliNom ProdNom, ProdPre

La siguiente dependencia funcional FacNro CliNom

Se ha vuelto transitiva a partir de la existencia de las dependencias funcionales. FacNro CliCod CliCod CliNom

Por lo que deber modificarse la tabla Factura. Anlogamente con la tabla Factura1 y las dependencias funcionales FacNro, ProdCod ProdCod ProdNom, ProdPre ProdNom, ProdPre

19

Es conveniente usar padrones para los nombres de atributos. Facilitan la tarea de darle nombre a un atributo dentro de las reglas establecidas Facilitan la tarea de integracin de bases de conocimiento

ARTech ha definido un Standard para la nomenclatura de atributos, el GIK (GeneXus Incremental Knowledge Base). Puede gustarnos ms o menos que otros. Lo importante es que es el utilizado por la comunidad de usuarios GeneXus. Esto viabiliza reutilizacin de conocimiento entre ellos. Nombre de atributo Objeto + Categora + Calificador Objeto, Es el nombre de la transaccin a la que pertenece el atributo. Categora, Es la categora semntica del atributo.

20Calificador, Puede existir uno o dos calificadores.

Ejemplo: de Nomenclatura GIK Objeto Cli Cli Cli Cli FacVta FacCmp Tipos de Datos: Numeric, Character, Date Long Varchar VarChar - Equivalente al Character, salvo en la forma en que se almacena en la BD. DateTime - Los valores de M y N no afectan la forma de almacenar el tipo de datos, sino la forma de aceptar o mostrar su contenido. Long Varchar: Permite almacenar una cantidad de caracteres indefinida. Se utiliza normalmente para almacenar textos, descripciones, comentarios, etc. El largo que se le asigna es considerado el largo mximo (la implementacin depende de la plataforma). VarChar: Permiten almacenar texto de largo variable. Su funcin, en contraposicin al character, es la de optimizar el almacenamiento en la base de datos. Definicin: Varchar(M, N)M: Es el largo mximo posible que depender del DBMS. Si el largo asignado al atributo es mayor que el soportado por el DBMS se utilizar el mximo soportado. N: Es el largo promedio. Se utiliza para optimizar los accesos a disco en algunos DBMSs.

Categoras Cod Nom Fch Fch Nro Nro

Calificador

Ini Fin

La idea es que si el valor de un atributo varchar es menor o igual que N, se almacenan N caracteres (rellenados con blancos) en el registro del archivo y se utiliza un nico acceso a disco para leerlo o grabarlo. En caso que el valor del atributo varchar sea mayor que N, se almacenan los primeros N en el registro del archivo y el resto en un rea de overflow para lo cual es necesario un acceso adicional tanto para lectura como para escritura. Se le pueden aplicar todas las funciones y operadores existentes para el tipo de datos character. El tipo de datos Varchar es equivalente al tipo Character en todos los sentidos salvo en la forma en que se almacena en la base de datos. Para los DBMS que no soportan este tipo de dato se crean como Character. DateTime: Permite almacenar una combinacin de fecha y hora (hasta el segundo). DateTime(M. N)M = Largo de la fecha. Valores posibles: 0, 8 y 10. N = Largo de la hora. Valores posibles: 2, 5 y 8.

21Los valores de M y N, no afectan la forma de almacenar el tipo de datos sino especficamente a la forma de aceptar o mostrar su contenido. En caso que M sea 0 (no se considera la fecha) para un campo que ha de ser ingresado, el valor de fecha a asignar ser el mnimo soportado por el DBMS y reconocido como fecha vaca o nula en GeneXus. En caso que N sea distinto de 8 para un campo que ha de ser ingresado, los valores no aceptados (minutos o minutos y segundos) sern considerados en cero. Dominios: Cuando debemos usar dominios? Atributos con la misma definicin No existe relacin entre ellos Ejemplo: Direccin Char30 Direccin del Cliente Atributos Direccin del Banco El objetivo de los dominios es permitir usar definiciones de atributos genricos y luego poder asociar un atributo con su correspondiente dominio. En el ejemplo, el dominio Direccin es definido como Char de 30. Los atributos direccin del banco y del diente son asociados a l. Por lo tanto, si en el futuro se cambia la definicin de este dominio, los cambios van a ser automticamente propagados a todos los atributos que pertenezcan a ste. De esta forma los dominios permiten un mayor nivel de abstraccin en la definicin de la aplicacin. Reglas: Se utilizan para definir el comportamiento de las transacciones. Algunas reglas- Defult, Error, Ask, Msg, Asignacin, Add, Subtract, etc. Default(FacFch, &today); Error('No se permiten clientes sin nombre') ifnull(CliNom);

Dominio

Pueden incluir: atributos, variables, constantes y funciones. Las reglas son LOCALES a la transaccin. Programacin DECLARATIVA Segn el Anlisis Orientado a Objetos, para cada objeto del sistema se debe definir cual es su estructura y su COMPORTAMIENTO. En el caso de las Transacciones, el comportamiento se define mediante el uso de Reglas (Rules). Algunas reglas: Defult: Se utiliza para definir los valores por defecto de algunos atributos. Error: Es para definir los controles que deben cumplir los datos, por ejemplo si no queremos permitir que queden ingresados clientes sin nombre:

22Error('No se permiten clientes sin nombre')ifnull(CliNom); Cuando se cumple la condicin ( null(CliNom) ) se despliega el mensaje ('No se permiten clientes sin nombre') en pantalla y no se permite continuar hasta que el usuario ingrese un nombre sobre el campo CliNom. Asignacin: Dentro de las reglas de la transaccin se permiten definir asignaciones a atributos, dicha asignacin implica una actualizacin en la tabla base del nivel o en alguna de las tablas que pertenecen a la tabla extendida del nivel. Una asignacin en las reglas es LOCAL (vale solo para la transaccin en la cual fue definida). Orden de evaluacin: La definicin de reglas es una forma DECLARATIVA de definir el comportamiento de la transaccin. El orden en el cual fueron definidas no necesariamente indica que ese sea el orden en que se encuentran en el programa generado. GeneXus se encarga de determinar el orden correcto segn las dependencias de atributos existentes (en este tema entraremos en detalle mas adelante).

Tool Bars de Controles:

Usados en el diseo de Pantallas: Atributo / Variable Recuadro Botn Bitmap Tab Control PrintBIock

Se utiliza para disear la pantalla (form) en forma grfica. Mientras se est diseando un form (de TRN's, WKP's o Reports) est disponible la tool bars de Controles que contiene los tipos de controles que se pueden agregar al form que se est editando. Tab Control: Permite definir varios controles dentro de un Tab Control. Tiene una o varias pginas. - Defult: Dos pginas - Agregar o eliminar pginas: Botn derecho sobre el Tab Control - Pgina Ttulo rea til - Check Box de Hide Tabs Para diseo de Wizards(Recuadro al cambiar de pantalla)

Slo para los generadores visuales.

23Un Tab Control tiene una o varias pginas (por defecto tiene dos). Cada pgina tiene un ttulo y un rea til, es decir donde se ponen los controles de esa pgina. Slo una de las pginas puede estar activa a la vez y es la que se puede ver. Del resto slo se ver su ttulo. Las opciones Edit/Add Tab Page y Edit/Remove Tab Page son para agregar y eliminar pginas respectivamente. Puede accederse tambin a estas opciones con botn derecho sobre el Tab Control. Hide Tabs: Para mostrar slo la pgina activa y no mostrar los tabs. til para la definicin de Wizards. Generacin de HELP Tipo Windows: Es necesario generar y compilar el Help. - Opcin: Build/Generate Help - El compilador viene con el Visual Basic/Foxpro/Visual FoxPro Disponible solamente en los generadores windows.

Esto es para los generadores Windows. Se genera un .HLP compatible con el Help de Windows. El compilador de Help como se mencion ms arriba viene con el Visual Basic/FoxproA/isual FoxPro y se requiere como mnimo la version3.10.505. Botn de Help: - Llama al help del objeto. F1: - Llama al help del atributo en donde se encuentra el cursor. Si ese atributo no tiene help se llama al help del objeto. INTEGRIDAD REFERENCIA:

Diagrama de Bachean:

Las reglas de integridad referencial permiten asegurar la consistencia entre los datos de las distintas tablas. El diagrama anterior se ha inspirado en los conocidos Diagramas de Bachman, y tiene la virtud de explicitar la integridad referencial del modelo de datos.

24En el ejemplo, existe una relacin entre la tabla Clientes y Departamentos y tambin entre Clientes y Categoras. La relacin entre dos tablas se determina analizando los atributos que tienen en comn. Por ejemplo, entre las tablas Clientes y Categoras tenemos que el atributo comn es el cdigo de la categora, que es la clave primaria de la tabla Categora. Decimos que la relacin entre ambas tablas es 1-N, que indica que un cliente tiene una categora y una categora tiene N clientes. Tambin es usual decir: . La tabla Categoras est Superordinada a la tabla de Clientes . La tabla de Clientes est Subordinada a la tabla de Categoras Esta relacin implica que la informacin contenida en ambas tablas no es independiente, por lo que es necearlo realizar controles para que la informacin sea consistente. A estos controles se les llama de Integridad Referencial y bsicamente son los siguientes: Cuando se crean registros en la tabla subordinada (Client), debe existir el registro correspondiente en la tabla superordinada (Catego). Cuando se elimina un registro en la tabla superordinada (Catego), no deben existir el registros correspondientes en la tabla subordinada (Client). Definicin de ndices: Tabla Tipo Catego Depart Client PK PK PK FK FK CatCod DtoCod CliCod DtoCod CatCod Indice Composicin

Definicin de ndices: Para hacer eficiente los controles de Integridad, GeneXus crea automticamente ndices, que son vas de acceso eficientes a las Tablas. Existen tres tipos de ndices: Primarios, Extranjeros y del Usuario. ndice Primario (PK): El ndice primario es el que se define para la Clave Primaria, se utiliza para el control de unicidad de los registros y para el control de que cuando se crean registros en la tabla subordinada (Client), debe existir el registro correspondiente en la tabla superordinada (Catego). Con GeneXus todos los ndices primarios son definidos automticamente a partir de los identificadores de las transacciones. ndice Extranjero (FK): Los ndices extranjeros son utilizados para hacer eficientes los controles de integridad inter-tablas. Tambin son definidos automticamente. Cuando se elimina un registro en la tabla superordinada (Catego), no deben existir registros correspondientes en la tabla subordinada (Client). ndice del Usuario: Los ndices del usuario se definen, fundamentalmente, para recorrer los datos por determinado orden de una forma eficiente. Por ejemplo, en la tabla Client se puede definir un ndice por CliNom, que es muy til para los listados ordenados por nombre.

25Los ndices del usuario NO son definidos automticamente ya que no se usan para los controles de integridad. En una Base de Datos Relacional los ndices se utilizan slo por problemas de performance, pero siempre es posible acceder a los datos de la tabla por cualquiera de los atributos de la misma. CONCEPTO DE TABLA EXTENDIDA: Definicin de Tabla Extendida: Dada una tabla de la base de datos, se denomina tabla extendida de la misma al conjunto de atributos conformado por: - Atributos que pertenecen a la tabla. - Atributos que tengan una relacin N-1 con la tabla extendida determinada hasta el momento. Los criterios de normalizacin del diseo de la base de datos apuntan a minimizar la posibilidad de inconsistencia en los datos. Una base de datos diseada de esta manera tiene una serie de ventajas importantes (tal es as que actualmente la normalizacin de datos es un standard de diseo), pero se deben tener en cuenta tambin algunos inconvenientes. El inconveniente ms notorio es que los datos se encuentran dispersos en muchas tablas, y por lo tanto cuando se quieren hacer consultas ms o menos complejas a la base de datos se debe consultar una cantidad importante de tablas. As, por ejemplo, para listar las facturas sera necesario consultar las tablas Cabezal y lneas de Facturas, Clientes, Categoras y Productos. Para simplificar esta tarea GeneXus utiliza el concepto de tabla extendida.

Tabla BaseCategora Cliente Factura

Tabla ExtendidaCategora Cliente Categora Factura Cliente Categora Factura1 Producto Factura

Factura1

26Cliente Categora Producto

Producto

ATRIBUTOS FORMULAS: Caractersticas: Relacin entre Atributos, Constantes o Funciones. Definicin Global, definidas a nivel del modelo. Atributo Virtual (No se almacena en la tabla). Son calculadas siempre que se hace referencia al atributo. Un atributo es una frmula si su valor se puede calcular a partir del valor de otros atributos. En cada transaccin se puede definir qu atributos son frmulas, pero esta definicin es global (no es local a la transaccin), es decir toda vez que se necesite el atributo se calcula la frmula, tanto en transacciones como en los otros objetos GeneXus. Existe una similitud entre frmulas y asignaciones (regla), incluso la sintaxis de definicin es similar. La diferencia entre ambas es que una frmula es GLOBAL (vale para todos los objetos GeneXus que la utilicen), mientras que una asignacin en las reglas es LOCAL (vale slo para la transaccin en la cual fue definida). Cuando un atributo es frmula, ste no est almacenado (a no ser que se lo defina como redundante) y cuando es una Asignacin, por ser esta local, si esta almacenado. Clasificacin: Horizontales: Una o varias expresiones aritmticas condicionales. Verticales: SUM COUNT Aggregate / Select: Select Max, Min, Find Aggregate Sum, Count, Set Frmula Horizontal: Los atributos involucrados en la misma deben pertenecer a la tabla extendida del atributo definido como frmula. Frmula Vertical: Los atributos involucrados deben pertenecer a la tabla directamente subordinada del atributo definido como frmula. Son incondicionales. Aggregate / Select: Pueden navegar sobre cualquier tabla del modelo. Son condicionales.

Fmulas Horizontales: Atributo = if; if; Otherwise;

27

: es una expresin aritmtica que puede involucrar atributos, constantes y funciones. Los atributos que participan de la expresin deben pertenecer a la tabla base y/o a tablas que estn en una relacin N para 1 con la tabla sobre la que se define la frmula (es decir, a la tabla extendida del atributo definido como frmula). El atributo frmula deja de estar almacenado en la tabla y decimos que es un atributo virtual. : Es la condicin de disparo de la frmula. Cuando se define una frmula horizontal, GeneXus sabe cual es la tabla extendida del atributo que se est definiendo como frmula, y controla que todos los atributos utilizados en dicha frmula se encuentren en ella.

Frmulas Horizontales: Ejemplo: TRANSACCIN CliCod* CliNom CliTotCmp CliTotPgo TABLA CliCod* CliNom CliTotCmp CliTotPgo

CliSdo = CliTotCmp - CliTotPgo Un atributo puede definirse como frmula cuando su valor se obtiene siempre de un clculo que puede involucrar atributos, constantes y/o funciones. Por ejemplo, el saldo del cliente es siempre la diferencia entre el total de compras y el total de pagos. Diferencias entre Frmulas y Reglas: Frmula: La frmula es una definicin global ya que est a nivel del modelo de datos, su valor ser calculado cada vez que se utilice en cualquier objet GeneXus ya que el atributo no est almacenado en la tabla. Regla: La regla est definida a nivel local en la transaccin. Cada vez que se mencione el atributo, su valor no se calcular, sino que se tomar directamente de la tabla.

28

En el ejemplo, definimos al importe del producto en la factura (FacLinImp) como una frmula horizontal, por lo cual dicho atributo no est almacenado en la tabla Factura1. Frmulas Verticales: SUM - COUNT Sintaxis: - AtriFla = SUM(Att) - AtriFla = COUNT(Att) Caractersticas: - Att debe pertenecer a una tabla directamente subordinada a la tabla en la que se encuentra AtriFla. - Son incondicionales. - Navegacin vertical Performance Caractersticas de las Frmulas Verticales: SUM: Suma un atributo perteneciente a una tabla directamente subordinada. COUNT: Cuenta las filas de una tabla directamente subordinada. Se utilizan cuando el valor de un atributo se obtiene sumando o contando filas de una tabla que est directamente subordinada. La tabla est en una relacin 1 a N. Se consideran todas las filas que pertenecen a la relacin ya que no se pueden establecer condiciones. Se resuelve mediante una navegacin vertical, de ah el nombre Frmulas Verticales. Performance: El hecho que la frmula no est almacenada puede ocasionar problemas de performance, debido al tiempo que puede demorar el reclculo. Para evitar este inconveniente se puede definir la frmula como REDUNDANTE. En este caso la frmula se almacena en la Base de Datos y no es necesario recalcularla cada vez que se use. Profundizaremos en este tema ms adelante.

29Precisamos calcular ahora el subtotal de las lneas de la factura, que hemos llamado FacSubTot. Este atributo est en el cabezal de la factura y el atributo a ser sumado en las lneas. Estas tablas estn en una relacin de 1 a N. por lo que no podemos utilizar una frmula horizontal. Precisamos una frmula que recorra todas las lneas de la factura y las sume, utilizamos para esto una frmula SUM( ) perteneciente a las llamadas Frmulas Verticales. Se puede decir que un SUM redundante es equivalente a la regla ADD.

Frmulas Verticales:

Slo se puede definir entre atributos de tablas directamente subordinadas. Dentro de una frmula vertical no se puede mencionar directa o indirectamente una frmula AGGREGATE/SELECT. El atributo mencionado en la frmula COUNT no puede formar parte de ninguna clave. El atributo mencionado en la frmula SUM puede ser frmula. Para frmulas de frmulas GeneXus determina cul es el orden de evaluacin correspondiente. Frmulas Aggregate/Select: Son frmulas que permiten buscar, sumar, contar atributos que cumplan determinadas condiciones, en cualquier tabla del modelo. Aggregate - Sum - Count - Set Select - Max - Min - Find Frmulas Aggregate: Sum: Suma condicionalmente atributos de cualquier tabla del modelo. Count: Cuenta condicionalmente filas de cualquier tabla del modelo. Set: Imprime instancias de un atributo en determinadas condiciones.

30

Frmulas Seiect: Find: Buscar el valor de un atributo en determinadas condiciones. Max: Buscar el mximo valor de un atributo en determinadas condiciones. Min: Buscar el mnimo valor de un atributo en determinadas condiciones.

Sintaxis: - atrib = Sum | Count (, , ) - atrib = Set(, , ) - atrib = Max | Min(, , , ) - atrib = Find(, , )

atrib: es el atributo que se define como frmula. Sum: (atributo a ser sumado, condiciones que debe cumplir, valor por defecto) Set: Selecciona las primeras ocurrencias (hasta 50) del atributo que cumplen la condicin , y las manipula como si fueran un solo atributo. Si no se especifica ninguna condicin, las primeras 50 ocurrencias sern seleccionadas. : Es el valor por defecto devuelto cuando ningn registro cumple la condicin . Si no se menciona nada en se devuelve el nulo del tipo de datos de . Max: (atributo a maximizar. condiciones de maximizadn, valor por defecto en caso de no encontrar quien cumpla con las condiciones, valor de retomo en caso de encontrar) Find: (atributo a buscar, condiciones de bsqueda, valor por defecto en caso de no encontrar quien cumpla con las condiciones). Frmulas Aggregate: .Sum() Aggregate .Count() Aggregate Se utilizan cuando el valor de un atributo se obtiene sumando o contando filas de cualquier tabla del modelo que cumplan una determinada condicin. Atributo = Sum | Count (, , 0) Factura1 FacNro* ProdCod* FacLinCnt FacDscto FacLinImp FacNro 1 1 1 1 ProdCod 1 2 3 4 FacDscto 10 0 20 0

FacTotArtDscto = 2 Find: Se utiliza para obtener el valor de un atributo que est en cualquier tabla del modelo, pudiendo establecerse relaciones con cualquiera de los atributos de la tabla. Sintaxis: Atributo=Find(, , ) IF = DocFch, , MonCot) Fecha del Documento 15/01/94, le corresponde la cotizacin del da 16/01/94. MonFch MonCot 10/01/94 100 11/01/94 110 12/01/94 112 13/01/94 115 16/01/94 117 17/01/94 118 Consideraciones aplicables a todas las frmulas Aggregate/Select: Atributo = Find(, , ) IF En la definicin de la frmula intervienen atributos de varias tablas: La tabla en la que est definido el atributo frmula (tabla de partida). La tabla extendida de la tabla de partida. La tabla en la que se busca (tabla de llegada). IMPORTANTE: No se pueden utilizar atributos de la tabla extendida de la tabla de llegada: Documentos (Tabla de partida) Cotizaciones (Tabla de llegada)

Consideraciones de performance: Tanto las frmulas Verticales como las frmulas Agregate/Select, implican la realizacin de navegaciones en la Base de Datos, por lo que es importante considerar la forma en que esto es realizado. Las frmulas Verticales pueden almacenarse en forma redundante y GeneXus se encargar de mantenerlas actualizadas. Uso de la frmula MAX(): Ejemplo: Buscar el precio del producto segn la fecha de la Factura. Transaccin Productos ProdCod* ProdDsc (ProdFch* ProdPre) Transaccin Factura FacNro* CliCod FacTot FacFch (ProdCod'* FacProdPre FacLinCnt FacLinImp)

34Atributo = MAX(Atributo a Maximizar), (Condicin de Maximizacin), (Valor por defecto), (Atributo a devolver) IF (Condicin de ejecucin) Uso de la Frmula Max( ) para buscar el precio del producto segn la fecha de la factura. Definimos la transaccin de productos de tal forma de guardar el histrico de precios, con la fecha de aumento de precio asociada. Con la fecha de la factura buscaremos el precio del producto correspondiente. Por ejemplo: Fecha de Factura: 10/10/93 Precio producto correspondiente: 220

correspondiente al 3/10/92

Incluiremos en las lneas de la factura el atributo ProdCod. No podemos incluir ProdFch debido a que no podramos saber que valor darle a la fecha para poder heredar directamente el ProdPre. Definimos el atributo FacProdPre y buscaremos con una frmula el precio correspondiente de acuerdo a la fecha de factura. Buscaremos el precio de fecha mxima anterior a la fecha de factura. La frmula quedara: FacProdPre = Max (ProdFch, ProdFch = &Nom); Hidden: En los paneles, GeneXus infiere automticamente cuales son los atributos y variables que debe incluir en el subfile. Esta regla es usada para indicarle explcitamente a GeneXus cuales atributos o variables debe incluir en el subfile sin estar presentes en el mismo. Se usa cundo por razones de presentacin, no es conveniente mostrar un atributo en el rea de subfile de la pantalla, pero se quiere capturar su valor cuando se haga el load de la misma.

68Workfile_lines (): Dado que los subfiles se cargan en archivos temporales y que no existe un lmite en la cantidad de lneas a cargar en ellos en PC o LAN , puede traer problemas si la tabla base asociada tiene muchos registros ya que el archivo temporal tendra todos los registros de la tabla base. Usando esta regla, se menciona en MaxLine la mxima cantidad de lneas que se permite cargar en el subfile. Si el lmite especificado se excede, se despliega el siguiente mensaje Nmero de lneas excede xxxx ". Propiedades ms importantes: Loading Load Records Load at Startup Automatic Refresh Refresh Timeout (FoxPro only)

Load Records: Los posibles valores son 'Load on request' o 'Load all records'. Load on request: A medida que se va paginando va cargando los registros del subfile ('Carga a pedido'). Load all records: Carga todos los registros. Load at Startup: Los valores posibles son 'Yes' o 'No'. Yes: Inmediatamente despus de ejecutar el Workpanel se carga el subfile. No: No carga el subfile de un panel hasta que no se ingresen los valores de la parte fija del WorkPanel. Automatic Refresh: Esta property es especialmente til en el caso de un subfile con slo variables, cuando uno desea que se haga automticamente un refresh cada vez que uno de los valores de la parte fija son modificados. Los valores posibles son: Only when variables in condition change (default): Tiene el comportamiento de siempre. When any variable changes: Genera un refresh cada vez que cualquier variable de la parte fija del Workpanel es modificada. Refresh Timeout: Esta property es para que se haga un refresh del subfilo automticamente si el usuario no efectu ninguna operacin en el lapso de tiempo especificado. No hay valores predefinidos. Debe especificarse un valor en segundos (lapso de tiempo). Work-Panel con o sin Tabla Base ? Los atributos que determinan la tabla base y su extendida son los definidos en: Panel Reglas Hidden y Order Eventos (fuera de comandos For Each) Work Panel sin tabla base comando LOAD

Work -Panel con tabla base: En la navegacin:

69For Each [Tabla Base] Order: Atributos del ndice por clave Primaria (si no se incluy regla order) Index: Clave primaria (si no se incluy regla Order) // Otros For Eachs definidos en los eventos Endfor Work -Panel sin tabla base: No se mencionan atributos en: Panel Reglas Hidden( ) y Order( ) Eventos En este caso se genera slo un Evento Load, y es en l donde se deben cargar los datos en el subfile, haciendo for each a la (s) tabla(s) deseadas cargando las variables del form. Dilogo Modal/No Modal: Property Modal dialog - En transacciones y work panels (llamados). Opciones: - Yes if parameters specified - Yes - No Slo generadores Visuales. La property Modal Dialog permite elegir si el dilogo ser modal o no modal para ese objeto. Las opciones de esta property son: Yes if parameters specified: Es la opcin por defecto. Significa que si el objeto tiene parmetros, el dilogo ser modal y si no tiene el dilogo ser no modal. Yes: Dialogo modal. No: Dialogo no modal SUBTIPOS:

70Hay que definir el banco origen y destino en la misma transaccin. Esto no es correcto pues tengo que poner atributos con el mismo nombre en la misma transaccin. Para estos casos GeneXus provee los Subtipos, los cuales permiten definir que dos atributos que se llaman diferente, corresponden al mismo concepto.

Hay que definir atributos con distinto nombre y que tengan una dependencia funcional. Los atributos que se encuentran en una relacin Subtipo/Supertipo siempre comparten la misma definicin. Se realizan los controles de integridad referencial. La tabla extendida que se obtiene con la definicin del subtipo, es la misma que se obtendra en el caso que se utilizara directamente el supertipo.

71

Todava queda algo por determinar. Tenemos dos bancos y dos nombres pero en ningn lugar indicamos el nombre a que banco corresponde. Es ac donde aparece la necesidad de definir grupos. Decimos que el Cdigo de Banco Origen y el Nombre pertenecen al mismo Grupo. Algunas Consideraciones: El subtipo y supertipo sern definidos del mismo tipo, GeneXus lo determina as y cuando se quiere definir un subtipo este "hereda" la definicin del supertipo. No incluir subtipo y supertipo en la misma transaccin, ni tampoco en la misma tabla extendida. No se pueden actualizar los subtipos inferidos (Add, Subtract). No se pueden definir redundantes los subtipos inferidos. Por ejemplo: TraBcoOriNom DATA VIEWS: DataViews - Archivos Externos: Los Data Views de GeneXus permiten manejar Archivos Externos como si fueran Archivos pertenecientes a la Base de Conocimiento. Propiedades: Definicin Global Uniformizacin de la nomenclatura Para trabajar con Archivos Extemos en GeneXus tenemos dos posibilidades: Sin tabla Asociada Con tabla Asociada

72

Los Data Views de GeneXus permiten manejar Archivos Externos como si fueran archivos pertenecientes a la Base de Conocimiento. En el Data View se puede indicar que se manejar una transaccin interna asociada, o no. Data View con transaccin interna asociada: Supongamos que desde una Base de Conocimiento se desea manejar el archivo externo clientes.dbf cuyos campos son: - Cdigo* - Nombre - Dir - Tel 1) Se debe crear una transaccin de clientes definiendo los atributos que se deseen manejar de la tabla externa. Estos atributos internos deben coincidir en lo que se refiere a tipos y tamaos con los campos externos, pero los nombres pueden ser redefinidos respetando la nomenclatura GIK. 2) Se debe crear un Data View e indicar en l, cual es la transaccin interna asociada. Asimismo se deben indicar las correspondencias entre los atributos internos y los campos externos. Tambin se debe ingresar en el Data View, informacin relacionada al Archivo Externo como ser la plataforma y ubicacin (esto debe ser indicado tanto en el caso que el Data View tenga una transaccin interna asociada, o no). 3) Los objetos GeneXus deben definirse haciendo referencia a los atributos internos de los clientes, sin embargo los programas son generados utilizando los campos externos en forma transparente. Nota: Si bien se define una transaccin de clientes, esta no provoca la creacin de una tabla fsica por estar asociada a un DataView. Esta transaccin se especifica y genera como cualquier objeto de la Base de Conocimiento y en ejecucin, accede en forma interactiva a los registros de la tabla externa en forma transparente. Data View sin transaccin interna asociada: En este caso, se debe crear un Data View, sin crear previamente una transaccin interna. La forma de acceder al Archivo Externo es nicamente mediante la definicin de procesos batch utilizando los External File Commands: XFOR EACH, XNEW, etc. Definicin de un Data View:

Assoc. table: En este punto se debe seleccionar la tabla interna asociada al Data View.

73Composition: Aqu se deben indicar las correspondencias entre los atributos internos y los campos externos. [Nombre Interno] [Nombre Interno] [Nombre Interno] [Nombre Externo] [Nombre Externo] [Nombre Externo]

Cuando no se menciona el Nombre Externo es porque coincide con el Nombre Interno. En el ejemplo, el nombre y la direccin del cliente en el Archivo Externo se llaman CliNom y CliDir respectivamente. Indices: En esta lista, se deben definir los ndices internos que GeneXus usar en la aplicacin. Plataform Specific Information: Aqu se debe completar informacin del archivo externo (como ser la plataforma y ubicacin).

Indices:

74Name: Nombre del ndice que GeneXus usar en la aplicacin. Unique o Duplcate: Si permite tener o no llave duplicada. Compositions: Es la lista "ordenada" de campos que componen al ndice. Los atributos mencionados ac deben ser parte de la Composition del Data View. Platform Specific Information / Add:

Las propiedades del Data View pueden definirse para cada plataforma o por modelo. Esto nos brinda la posibilidad de especificar diferentes ubicaciones del mismo Data View dentro de la misma plataforma pero para diferentes modelos. Por ejemplo, si se quiere darle diferente ubicacin para el modelo de Prototipo Fox y para el modelo de Produccin Fox, debe seleccionarse DBFCDX(model2) y DBFCDX(model 3) indicando la ubicacin para cada uno de los modelos. En cambio, si se quiere la misma ubicacin para todos los modelos Fox debe seleccionarse la plataforma DBFCDX. Platform Specific Information / Edit:

75Estas propiedades varan dependiendo de la plataforma seleccionada. En este caso, por ejemplo, el archivo externo es un archivo de texto y por tanto las propiedades son referenciales a un archivo de este tipo. Associated Table:

Data View con Tabla Interna Asociada: Se trata al archivo externo como una tabla ms del modelo. Se pueden utilizar los mismos comandos utilizados para acceder a las Tablas Internas (For Each, etc.) Se deben mencionar los atributos internos y Genexus al generar los programas, utilizar los campos externos de forma transparente.

Existe una relacin de uno a uno entre los atributos de la Tabla Interna del Data View y los del Archivo Externo.

76

Los atributos definidos para la Tabla Interna y para el Data View. Estos atributos no pueden ser asociados.

Si la Tabla Interna tiene ms atributos que el Archivo Externo no es vlida la asociacin.

En el ejemplo, se pide tener tambin como datos del cliente el E-Mail y la direccin.

77Asociacin Dinmica: Las definiciones del Archivo Externo e ndices asociados coinciden con las definiciones de la Tabla Interna y sus ndices (tanto en nombres como en la composicin). En este caso coincide todo. Si ocurre esto no hay que detallar composicin ni de ndices del Data View. Lo nico que hay que hacer es asociar el Data View a la tabla externa (Platform Specific Information). Tener en cuenta que el ndice y archivo externo deben estar ubicados en el mismo directorio.

Reorganizaciones Data Views: 1. EXISTE TABLA ASOCIADA Si cambia la estructura de la tabla asociada, el cambio es detectado en el Anlisis de Impacto. No se generan programas de reorganizacin. 2. NO EXISTE TABLA ASOCIADA No aparece en el anlisis de impacto. EFICIENCIA Y PERFORMANCE DE LAS APLICACIONES:

Puntos a Considerar: Optimizacin de la Entrada-Salida Uso de Calls Open y Close de archivos Uso de ndices Temporales Optimizacin de Entrada-Salida: Dado que el acceso a las tablas es costoso, vamos a ver cmo minimizarlo.

78Uso de Calls: Vamos a ver cundo debemos empezar a preocupamos por el uso de este comando. Open y Close de archivos: Cunto y cmo influyen las operaciones de apertura y cierre de archivos en el tiempo de respuesta de nuestra aplicacin. Uso de ndices temporales: Evaluacin del costo de creacin de ndices temporales vs. el costo de mantenimiento de ndices permanentes.

Normalmente los programas procesan registros agrupando aquellos que tengan ciertas caractersticas comunes, por ejemplo, todas las facturas de un determinado cliente, o las ventas de una clase de artculos. Estas caractersticas comunes, se establecen a travs de condiciones que determinan un filtro sobre los registros. Tales condiciones se especifican en GeneXus de diversas formas; as pueden ser por ejemplo WHEREs en un FOR EACH, condiciones en una formula Aggregate/Select, parmetros, etc. Ejemplo: De todos los Clientes, quiero imprimir los datos de aquellos cuyo cdigo este en un rango determinado. El tiempo necesario para realizar el proceso con los registros que cumplen las condiciones, determina el grado de "Optimizacin" que tiene la estrategia de acceso elegida. Decimos que una estrategia de acceso esta ms "optimizada" que otra, cuando es necesario un menor tiempo para leer todos los registros que cumplen las condiciones establecidas. La Optimizacin consiste en posicionarse lo ms cerca posible del primer registro del grupo que cumple las condiciones y desde all leer secuencialmente hasta el ltimo que las cumpla. Lo que se establece en definitiva, es un intervalo que cubre todos los registros que cumplen las condiciones. En este intervalo no necesariamente todos los registros cumplen la condicin. En estos casos, la mejor estrategia consiste en tener el menor intervalo tal que cubra a todos los registros que

79cumplirn la condicin. Igualmente las lecturas se realizarn para todos los registros de este intervalo, pero solamente se considerarn aquellos que cumplan con las condiciones. Definicin de Filtros: Clusula Where en For Each Conditions en Prcs, Rpts, Wkps. Parm( ) en Trns, Prcs, Rpts, Wkps

Where: La clusula "Where" permite filtrar registros en la navegacin de un determinado grupo FOR EACH. Por ejemplo: Para establecer los filtros descritos anteriormente, utilizaramos la siguiente especificacin: FOR EACH WHERE CliCiu = 'Montevideo' .AND. CliCod >= 1 .AND. CliCod= &IniCod .and. CliCod &FinCod Endfor Cod 1 *2 *3 *4 5 Nombre Smith Jones Ball King Ander

Starting Point Ending Point

Read Read Read

&IniCod = 2 &FinCod = 4

El orden en que deban considerarse los registros, junto con las condiciones de "filtro" determinarn la mejor estrategia de acceso. El orden puede considerarse como una condicin previa, para la definicin de la Optimizacin de las condiciones de filtro. Es decir, que la estrategia de acceso se define, tomando en cuenta como primera cosa el orden que se haya definido. Ejemplo: Condiciones de Filtro no compatibles con el Orden

For each Order CliCod Where CliCod = &IniNom .and. Clinom ) Mayor o Igual (>=)

82 Igual (=) Si el orden es descendente Menor ( 3 Posicin de comienzo: A>=5 Orden: ABC Condiciones: A > 5 .and. B < 2 .AND. C>3 Posicin de comienzo: A > 5 La Posicin Final (Consideraciones para su definicin): Se consideran las condiciones por: Si el orden es ascendente Menor (=) Igual (=) Las condiciones deben estar relacionadas por .And. Diagrama de Navegacin: Ejemplo: Diagrma de navegacin: For each CliCod Where CliCod >= &lniCli .AND. CliCod = &IniCli Loop While CliCod = &IniCli .AND. CliCod &cta Call('Pvalida, ...) Endfor En el AS/400 las funciones resueltas con Calls en los programas generados son: Time( ), Today( ) (se ejecuta una vez por programa), Cdow( ), Cmonth( ), Userid( ), UsercIs( ), Wrkstn( ). Los calls en XBASE no tienen en s mismos un gran costo, pero pueden generar cierres y reaperturas de tablas que s importan. Se implementaron dos esquemas distintos de calls (entendiendo por Call: el call propiamente dicho y las UDP y UDF ), los que dependen del tipo de ndice que se est utilizando.

84Indices NTX/IDX/NDX a) Cuando el Objeto llamado no utiliza ninguna tabla abierta por el objeto llamador: En este caso el objeto llamador (X) no cierra ninguna de las tablas que utiliza para realizar el llamado (call) , y el objeto llamado (Y) abre y cierra nicamente las tablas que utiliza. b) Cuando el Objeto llamado (Obj.Y), utiliza alguna tabla abierta por el objeto llamador. En las llamadas (calls) a otros objetos, el programa llamado cierra las tablas que necesita, que hayan sido abiertas por el programa llamador y las abre con los ndices que deba utilizar. Antes de retomar, el programa llamado cierra todas las tablas que us. El programa llamador, despus de retomar del programa llamado, abre aquellas tablas que necesita y fueron cerradas por el programa llamado. Resumiendo: El llamado siempre cierra lo que usa y el llamador se tiene que preocupar de reabrir lo que corresponda, el peor caso es cuando los dos usan las mismas tablas y el mejor es cuando usan todas distintas. a) PgmaX Open A, B, C Call Y Close A, B, C Open B Close A, B, C Indices CDX En este caso, en los objetos llamados, no se cierran las tablas que haban sido abiertas en los objetos llamadores y solamente reabren los ndices de la forma que los necesita. PgmaX Open A, B, C ....... Call Y Restaura todo a como estaba antes del call ....... Cise A, B, C PgmaY Open D, E Reposiciona Indices B, C Close D, E Pama Y OpenD, E .... Close D, E b) Pgma X OpenA, B, C Call Y Pgm Y OpenD, E Close B y Open B . Close B, D, E

ndices Temporales: En Client/Server los ndices temporales se construyen ms rpidamente que en File/Server, ya que solo se indexarn los registros que cumplan las condiciones y no requiere un uso exclusivo de la tabla. En File/Server, se construye el ndice para la ejecucin del programa y luego se borran. El tiempo de creacin es considerable dependiendo del nmero de registros de la tabla y de la cantidad y largo de los campos. En el AS/400 se usa la instruccin OPNQRYF para definir ndices temporales. Dependiendo de todo eso es que conviene o no crearse un ndice de usuario.

85MULTIPLES FORMS: Mltiples Forms por Objeto: Poder tener N pantallas por objeto. Permitir dentro de una misma KB tener modelos en los que se genera para ambiente grfico y otros en los que se genera para ambiente caracteres. Form Classes:

Crate automatically in new objects: Significa que cada vez que se crea un nuevo objeto, automticamente se crea un form de esa clase en el mismo. Cuando se importa, se genera automticamente un form para cada clase que sea Autocreate. Puede haber una o ms classes Autocreate. Crate Reports and Procedures using "Form que se seleccione": Como en reports y procedures no hay multi-form, se elige entre el Graphic y Text. New Class: Classes definidas por el usuario que pueden ser tanto Graphic como Text. Mltiples Forms por Objeto: Form Classes - Graphic y Text (son del sistema) - Definidas por el usuario (modo texto o grfico) Cada objeto tiene forms que pertenecen a alguna de las form classes y cada Modelo tiene asociado una lista de Form Classes para cada generador del mismo. - Opcin: File/ Edit Model/ Model Forms Las Form Classes y sus propiedades son globales a la KB (File/Form Classes), pero se pueden editar desde cualquier modelo. A su vez, en cada modelo se puede definir una lista de form classes de preferencia (File/Edit Model/Model Forms) para cada generador del modelo.

86El default de un form puede ser en base a otro form o en base al default de Genexus. Cundo decide GX el form a utilizar? En tiempo de Especificacin Apertura del objeto Apertura del objeto: para decidir cual mostrar en forma inicial. La lista de forms del modelo se tiene en cuenta en 2 casos: 1.- Al especificar un objeto, para decidir cul form considerar para cada objeto, se toma la primer form class de la lista del modelo y se busca si existe en el objeto un form de esa clase. Si no existe, se busca de la form class que sigue en la lista y as hasta encontrar o que se acabe la lista. Si se acaba la lista y no se encontr, entonces de acuerdo al generador (grfico o de caracteres) se busca un form que sea de ese tipo, si tampoco se encuentra entonces se especifica cualquiera y en el caso que haya que convertir, se convierte a texto. En cualquier caso, en el reporte de la especificacin aparece cul fue la form class que se eligi para cada objeto. 2.- Al abrir el objeto, para decidir cul mostrar en forma inicial STYLES: Propiedades de los Styles: Permiten la definicin de standards. La definicin es "por tipo" de objetos (transacciones, work paneis, etc). Objeto GeneXus no tenido en cuenta al normalizar. Los Styles son otro objeto GeneXus, su forma de definir es similar a la de los otros objetos, pero con la particularidad de que NO son tenidos en cuenta en la normalizacin o generacin de programas. Slo se utilizan para definir standards, sin la necesidad de tener que disear Form por Form. Pueden ser modificados, y automticamente se reactualizan los forms necesarios. Hay Styies para transacciones, work panels, etc., pero un style es de un solo tipo. Las excepciones a esta regla son los Styles de Work Panels que sirven tambin para Prompts y los Styles de Report y Procedure que pueden usarse para cualquiera de los dos. Nota: No existen Styles de Styles Definicin de un Style:

Object/New Object. Ejemplo de un Style de transaccin.

87

Style:

Se ven en los forms unas lneas que definen diferentes reas. Lo que est dentro del rectngulo es la denominada "Data rea" (rea de datos). El resto del form es la "Style rea". A su vez, la Style rea est dividida en 8 sectores (ver figura). Cuando el desarrollador empiece a usar styles las lineas de la data rea aparecern solas. De todas maneras tambin se pueden hacer aparecer con un botn de la toolbar. Los controles que estn completamente comprendidos en un sector conservan su posicin relativa a ste, cuando se mueven las lneas. Aquellos controles que pasan desde un lado de una lnea hacia el otro, conservan su posicin relativa a la lnea (se mueven junto con la lnea). Si un control pasa por encima de 2 lneas paralelas (o dicho de otra manera, comienza antes de la lnea de borde izquierdo de la data rea y termina despus de la lnea del borde derecho, o bien la misma situacin con respecto a los bordes superior e inferior), pueden suceder dos cosas: A) Es un control con "autoresize". En este caso, el control mantiene su posicin relativa a la primera de las lneas que cruza.

88B) Es un control sin "autoresize". El control se agranda o se achica tanto como se separen o acerquen las lneas, manteniendo cada uno de los extremos del control su posicin relativa a la lnea ms cercana.

Tres Tipos de Controles: Controles que vienen de la default Data rea Los que vienen del Style Controles del Usuario - Los que agrega el usuario al objeto. - Los que vienen de la data rea del Style. Los controles en la Data rea del style se pasan al objeto slo en caso de inicializacin (cuando el objeto es creado basado en el style y no en futuras reaplicaciones) y una vez en el objeto es considerado como un control de usuario dentro de ste. Creacin de un objeto basado en un Style: Al momento de crear el objeto, en el Information/StyIe se elige el Style deseado. Relacin entre las partes del objeto y del Style: - Form y Properties: Relacin dinmica - Otras partes del objeto: Relacin esttica Dinamismo con las properties - Los objetos heredan las propiedades del style asociado - El dinamismo es "por property" Cuando se crea un objeto con un Style asociado, el objeto se inicializa con todas las partes del Style (a excepcin del Information, obviamente). Excepto para el Form y las properties, la relacin entre las partes del objeto y del Style es esttica (si se cambia el Style no se cambia el objeto). Pero tanto para el Form como para las properties puede ser dinmica (que por ejemplo, cuando se cambie el Form del Style se cambie el form del objeto). En el caso de las properties, el dinamismo se mantiene en forma independiente para cada property. Cuando el objeto es creado sin especificar un Style asociado, GeneXus considera de todas maneras para el form la asociacin a un Form Style Default. Es decir que aunque el objeto no tenga Style asociado, a los efectos del form es como si estuviera asociado a un Style Default. Cuando se crea un objeto, se tiene Syle dinmico, pero dinamismo con la default data rea slo si el objeto es una transaccin. En las prximas transparencias veremos cmo es que se pierde el dinamismo. El estado de dinamismo se puede ver por el color con el que estn dibujadas las lneas. Si son rojas, est dinmico. Si no est dinmico, son azules.

89

Las lneas de la data rea estn en azul indicando que se perdi el dinamismo con la default data rea. Las lineas de la style rea estn en rojo indicando que existe dinamismo entre la style rea de la transaccin de clientes y la styie rea del style. NOTA: Se puede perder el dinamismo con la style rea del Style y seguir teniendo dinamismo con las properties del Style (siendo esto ltimo "por property"; es decir, teniendo dinamismo con algunas properties y no con todas). Cmo asociar Styles a objetos existentes: Opciones - Information/StyIe - Reapply Form Style Cuando se crea un objeto nuevo con un Style asociado, el objeto es inicializado con todas las partes del Style. Cuando el objeto ya existe, y se le asocia un Style, lo nico que hereda de ste es el Form y las Properties (slo las properties que tienen en el objeto los valores por default), siendo el dinamismo de las properties "por property" (se respetan las otras partes del objeto: Event, Rules, etc.). En otras palabras, es til asociar un Styie a un objeto existente cuando se quiere utilizar slo los Form del Style y las properties del Style en el objeto. Para asociar un Style (o cambiar el Style asociado) a un objeto ya existente se debe editar la "Information" del mismo, seleccionando alli el Style deseado. Para aplicar el Style a cualquiera de los forms del objeto se usa el men Edit / Reapply Form Style. Antes de aplicar el Style, hay que tener en cuenta que aquellos controles que no provenan del Style asociado anteriormente (controles del usuario), permanecern en el form del objeto, con lo que pueden ocurrir superposiciones. Qu pasa con el dinamismo ? Cuando se pierde? - Cuando se modifican los controles que vienen de la DDA los controles que vienen de la "styie rea" del Style

90 el seteo de una property Opciones: - Edit \ Default Data rea - Edit \ Reapply Styie Form Si se modifica un control que figura en el form como resultado del clculo de la Default Data rea (control que viene de la DDA), se pierde el dinamismo en sta (por ej.: si en una transaccin se modific uno de los controles correspondientes a los atributos de la estructura, al agregar nuevos atributos en la misma no aparecern automticamente en la Data rea). Anlogamente, si se modifica cualquiera de los controles que vienen de la styie rea del Style, se pierde el dinamismo con el Style. Si se modifica el valor de una property en el objeto, entonces se pierde el dinamismo con "esa property" del style. No se pierde ninguno de los dinamismos al agregar nuevos controles (ya sea en la Data rea o en el Style rea) del objeto que se est diseando. Estos controles se consideran "de usuario". Tampoco se pierde ninguno de los dinamismos al modificar o borrar cualquiera de los controles "de usuario". Una vez que se pierde el dinamismo con la Data rea o con el Styie, se puede recuperar utilizando las opciones de men Edit - Default Data rea y Edit - Reapply Form Style, respectivamente. Cambio en el tamao de la Data rea: Para agrandar o achicar la data rea, slo sirve mover los bordes derecho y/o inferior. El form del Style tiene la capacidad de adaptarse al tamao de la Data rea del objeto en el que se lo utiliza. Cuando la Data rea se agranda (ya sea debido al calculo de Default Data rea o a la accin del usuario) el mecanismo de aplicacin dinmica del Style se encarga de agrandar tambin el frame, y mover hacia la derecha y hacia abajo los controles que estn a la derecha y abajo de la Data rea respectivamente. Similar comportamiento se observa al achicar la Data rea (se achica el frame y los controles se mueven hacia la izquierda y hacia arriba). El tamao de la data rea definido en el form del style (y por lo tanto tambin el tamao del frame) se considera como tamao mnimo de la data rea del form del objeto. Consideraciones para el diseo de Styles: Los controles que queden dentro de la Data rea del Style son considerados como "Controles del usuario". Definir fonns para diferentes form classes si los objetos que lo usan tienen mltiples forms. (Ej.: definir un form grfico y uno de texto en el style). Cuando se ponen Eventos y Rules incluir comentarios al principio sobre que cambios se deben realizar en el objeto.

Cuando se ponen Evento y Rules, incluir comentarios al principio sobre qu cambios se deben realizar en el objeto. Por ejemplo, en las rules de un Style para transacciones poner: //sustituir "clave" por el nombre del atributo clave noaccept(clave)

91Master Style: Objetivo: Style default Se define por modelo Por "tipo de objeto" salvo: - Prompt - Workpanel - Report/procedure - report/procedure definidos en forma independiente para cada modelo dentro de la KB. - File/Edit Model/Master Styles Master Style: Existe la posibilidad de declarar, para cada tipo de objeto, cul de los styles existentes en el modelo se desea que sea considerado como Master Style (es decir, cul se desea utilizar en lugar del "default style"). No es que se tenga que "crear un Master Style" sino que entre aquellos que ya existen, se puede elegir uno y declararlo como Master. Esta declaracin es de carcter opcional: es posible no declarar a ninguno como Master y simplemente funcionar todo como hasta ahora (utilizando el "default style"). En File/Edit Model/Master Styles se designa el Master Style para cada tipo de objeto. En cada caso estn disponibles los styies existentes y la opcin "(None)". Si bien al momento de crear un objeto style, se puede elegir tanto crear un Report Style como un Procedure Style, el tipo del style que en definitiva se crea es siempre Procedure Style. Los Procedure Style pueden ser usados como style tanto para Reports como para Procedures. De la misma manera pueden ser elegidos tanto como para Master Style de Reports como para Master Style de Procedures. Por otro lado, los Work Panel Style pueden ser usados como style tanto para Work Paneis como para Prompts. Master Style: Precedencias: - Style asociado - Master Style - Default MENU BAR Y TOOL BAR: Tipo de objeto Men Bar: Para definicin de Men Bar y Tool Bar - Object/New Object/Menu Bar Add y Delete de tems - Edit/Insert y Edit/Delete respectivamente - Subitems - Personalizacin del tem Help/About Slo en generadores grfico: - VB, VFP - JAVA (en un futuro) Cada objeto GeneXus que tenga Form puede tener su propio Men Bar y Tool Bar. Para definirlos, se usa el tipo de objeto GeneXus Men Bar. Para agregar o borrar opciones (tems) del Men Bar, se utilizan las opciones Edit/Insert y Edit/Delete respectivamente.

92La definicin de la Tool Bar es exactamente igual a la del Men Bar, slo que en los tems de la Tool Bar se debe definir tambin el bitmap correspondiente. El tem Help/About llama a un work panel GX_ABOUT. GeneXus por defecto ya provee este work panel, en caso de querer personalizarlo se debe crear un nuevo work panel con este mismo nombre con la informacin deseada. Tipo de objeto Men Bar: Definicin de Eventos: Cada tem sin subitems puede tener asociado un evento (Object/Events). Nombre del evento: palabra Men Bar + nombre del tem Son generales No se permiten atributos. En transacciones y work panels - Property Windows Interface/Menubar: *Default, *None, lista de Men Bars existentes. - Pueden programarse eventos para los tems del Men Bar. Son particulares Se permiten atributos. Los eventos definidos en el Men Bar son generales, por lo cual se ejecutarn en todos los objetos que utilicen el Men Bar. Por esta razn es que no se permite el uso de atributos en los mismos. Luego de definido un Men Bar, se debe indicar en que objetos se utilizar. Esto se indica con la property Windows Interface de las transacciones y work panels. En las transacciones y work panels que utilicen el Men Bar definido, se pueden programar eventos para los tems del Men Bar. Como estos eventos son particulares de cada objeto, s se pueden usar atributos. Si un mismo evento se programa en el Men Bar y en el objeto, se ejecuta el del objeto. PROPIEDADES, EVENTOS Y MTODOS ASOCIADOS A LOS CONTROLES: Propiedades de los Controles: Cada control en un Form tiene un 'nombre y 'propiedades' asociadas. Insert/Property: despliega la lista de propiedades vlidas para cada control. Segn el tipo de control, las properties que tiene asociadas. Slo en generadores grficos: - VB, VFP - JAVA (en un futuro) Algunos controles tienen un nombre por defecto, pero hay otros que no; por lo cual si se les quiere aplicar alguna property hay que asociarles un nombre ya que de lo contrario no aparecen en la columna Control al hacer Insert/Property. En el caso del Form el nombre del control (por defecto) es Form. Si se desea cambiar el ttulo de un Form, la forma es: Form.Caption = Datos del Cliente' + CliNom En el caso de un control tipo texto, se le debe dar un nombre. El 'nombre del control para atributos/variables es el nombre del atributo/variable. NOTA: Si una variable es un vector, debe indicarse un nombre a cada posicin del vector para diferenciarlas.

93Dilogo: Select Property Se accede a travs de la opcin Insert/Property cuando se editan: - Rules, Eventos, Subrutinas, etc en transacciones, work panels y web panels No disponibles en reports y procedures

Form: Permite seleccionar para que tipo de form (Graphic, Text o de Usuario) se le asignar una propiedad a un control. Control: Muestra la lista de controles que hay en el form que se est diseando y que tienen un nombre asociado. Property: Despliega la lista de propiedades que se pueden aplicar al control seleccionado y en la segunda columna se despliegan los tipos de cada property. El Help trae el Help de la property seleccionada Eventos en Controles: Insert/Events Permite asociar Eventos a cada Control. - DbIClick - Click - RightButton - IsValid - GotFocus - OnLineActivate DbIClick: El cdigo asociado a dicho evento se ejecuta al hacer "doble click" sobre el campo. Click: El cdigo asociado a dicho evento se ejecuta al hacer "click" sobre el campo. Right Button: Se dispara cuando se presiona el botn derecho del mouse. IsValid: Se dispara cuando se hace la validacin del control. GotFocus: Se dispara al entrar al campo despus de validar el campo anterior. Evento OnLineActivate: Evento asociado al control "subfile" Se dispara cuando se activa una lnea en el subfile:

94- al clickear una lnea con el mouse - moverse a travs de la grilla con el teclado - cuando se hace refresh de la grilla. Los valores son los de la lnea "nueva" Los for each incluidos en este evento se anidan a la tabla base del workpanel. Disponible en transacciones y work panels. OnLineActivate: Es un evento asociado al tipo de control subfile. Los For Eachs que se incluyan en dicho evento estarn anidados a la tabla base del work panel, es decir, se comportan igual a los For Eachs del evento Enter. Eventos en Controles:

Form: Permite seleccionar para que tipo de form se le asociar un evento a un control. Control: Muestra la lista de controles que hay en el form que se est diseando. Event: Despliega la lista de eventos que se pueden aplicar al control seleccionado. Mtodos: Se aplican a los controles. Sintaxis: - . ([]) Segn el tipo de control (edit, check box, etc) son los mtodos que se pueden asociar. Se accede a travs de la opcin Insert/Methods cuando se editan: - Rules, Eventos, Subrutinas en transacciones, work panels y web panels. Slo en generadores grfico: VB, VFP, JAVA (en un futuro) - A excepcin del mtodo SetFocus que ser implementado en todos los generadores. La forma de trabajar es similar a la de Properties y Eventos. NOTA: Los generadores texto ignoran los mtodos en tiempo de especificacin.

95OBJETOS MAIN: Objetos Main: GeneXus genera ejecutables por cada objeto Main.

Cualquier objeto se puede definir como el principal de un ejecutable. Esto, se define en el tab Options del Information del objeto que quiero definir como ejecutable. El ejecutable contiene al objeto en s y todos los que este llama. Llamadas a objetos Main: Cuando desde un objeto se llama a otro objeto que es Main: - GeneXus genera un cali a un ejecutable (en lugar de un call comn) - Son compilables Qu ocurre si un objeto que no es Main pasa a serlo? Ejemplo: - TrnA Wpanel B Call(PImpClis) Call(PImpClis) - PImpClis no es main: GeneXus gener entonces en los programas asociados a la Trn A y Wpanel B un call al programa PImpCIis. El Proc ImpCIis pasa a ser Main: - En los programas asociados a la Trn A y Wpanel B GeneXus debera cambiar el call al programa PImpCIis por un call a un ejecutable "ImpCIis", con lo que deberamos regenerar estos objetos. Para evitar la regeneracin de todos los objetos llamadores: GeneXus usa un concepto llamado STUBS Stubs: Cuando el objeto ImpCIis pasa a ser Main, GeneXus en lugar de generar un nico programa asociado al objeto, realiza lo siguiente: - Genera el programa PimpClis que slo contiene el Call al Ejecutable correspondiente.

96- Genera otro programa que es el que contiene la lgica del objeto ImpCIis y ser el principal del ejecutable. Esto permite no tener que regenerar todos los objetos que llaman al objeto ImpCIis. Al programa que contiene slo el llamado al ejecutable se le denomina STUB. Tenemos entonces 2 programas generados, asociados a un mismo objeto GX: GeneXus necesita internamente nombrarlos diferentes. - Para la denominacin del programa STUB se siguen las convenciones de siempre (P=Procs, W=Work Panels etc.) - Para la denominacin del programa que sera el principal del ejecutable (el que contiene realmente el cdigo) se usan las siguientes convenciones: Transaccin N Work Panel U Report O Procedure A Men L Web Panel H Siguiendo con el ejemplo, para el objeto ImpCIis, GX generar 2 programas: PImpCIis.xxx y AImpCIis.xxx (xxx= extensin del generador corresp.) y el ejecutable se llamar AImpCIis.exe Web Panel: Permite construir pginas WEB dinmicas que interactan con la base de datos. C/SQL - Con todos los DBMS, excepto AS/400 Visual Basic - Access RPG/400 -AS/400 Los web panels pueden generarse tanto con Visual Basic como con C/SQL. Por lo tanto, pueden ejecutarse en un servidor Windows NT (VB, C/SQL) o en servidores UNIX (usando C/SQL). En caso de generar con RPG, el servidor de Internet debe ser al AS/400. Pueden usar todas las bases de datos soportadas. Restriccin: Con el generador C/SQL no puede usarse el dbms AS/400.

97EJERCICIOS PRCTICOS: Ejercicios de TRANSACCIONES: En los ejercicios de transacciones, se muestra una imagen de cada form. Las estructuras de las transacciones debern incluir los atributos que aparecen en los forms, pero podr ser necesario incluir otros atributos. Recordar que GeneXus normaliza la base de datos, y que las estructuras de las transacciones deben incluir todos los atributos que son utilizados en ellas, incluyendo reglas y eventos. Esto no es necesario para la definicin de frmulas en las que hay que tener en cuenta el concepto de tabla extendida. Pases:

Field Map: PaisCod Identificador de Pas PaisNom Nombre del Pas Reglas: 1. No se permiten pases sin nombreerror( ) if null ( paisnom)

Char. 4 Char. 30

Clientes:

98Field Map: Clild CliNom EliDir CliTel PaisCod PaisNom CliSexo CliSaldo CliTotCmp CliTotPag

Identificador de Cliente Nombre Cliente Direccin Telefono Identificador de Pas Nombre del Pas Sexo Saldo del cliente Total de Compras Total de Pagos

Num. 4.0 Char. 20 Char. 20 Num. 6.0 Char. 4.0 Char. 30 Char 1 Num. 7.2 Num 7.2 Num 7.2

ZZZ9

ZZZZZZ9

Definir los dominios: Nombre Direccin Telfono Definir el siguiente Control: Sexo - Radio Button Reglas: 1. No se permiten clientes sin nombre: err(ASG) if null ( ) 2. Avisar, en caso de que no se ingrese la direccin: err(ASG) if null (

)

Frmulas: 1. El saldo del cliente, se calcula como la diferencia entre compras y pagos. Utilizar el botn derecho sobre el atributo en la estructura de la transaccin para la definicin de la frmula. Sugerencias para la definicin de transacciones: Utilizar el Diagrama de Transacciones (Opcin-.Tools/Diagrams/Transactions) Utilizar el Diagrama de Tablas (Opcin: Tools/Diagrams/Tables) Utilizar la opcin: Tools/Browsers. Utilizar la insercin de reglas, funciones, etc. (Opcin: Insert/Rules, Insert/Functions.etc.) Productos: Field Map: ProdId ProdDsc ProdStkMin ProdStkAct ProdFchLta ProdPrecLta Reglas: Cdigo del Producto Descripcin del Producto Stock mnimo Stock Actual del Producto Fecha de Lista del Producto Precio Unitario Char Char Num Num Date Num 5 15 4.0 4.0 8 7.2

1. No aceptar el stock del producto si se esta modificando un articulo ya existente, pero permitir ingresar el stock cuando se inserta un nuevo artculo (en insert). 2. No permitir ingresar un stock nulo. Crear el prototipo de la aplicacin: Recordar que con el botn derecho (seleccionando de la lista de objetos) podemos especificar. Facturas:

99

Field Map: FacId FacFch FacTpo CliId CliNom FacLinNro ProdId ProdDsc FacLinCnt FacProdPre FacLinImp FacTotal Generalidades:

Identificador de Factura Fecha de factura Tipo de la factura (Crdito o Contado) Identificador de Cliente Nombre del Cliente Nro. de Lnea Cdigo del Producto Descripcin del Producto Cantidad de la Linea Precio del Producto en la Factura Importe de linea Total de Factura

Num. 6.0 Date 8 Char 1 Num. 4.0 Char 20 Num 2.0 Char 5 Char 15 Num 4.0 Num 7.2 Num 7.2 Num 7.2

1. Definir el atributo FacTpo como un Combo Box 2. Definir el atributo FacTotal con CourierNew de 12 en color Rojo. Reglas: 1. Numerar las lneas de la factura en forma automtica (Regla Serial).

2. Hacer que la fecha de la factura sea la del da por defecto. 3. Actualizar el total de compras del cliente si la factura es de tipo Crdito

1004. Evitar que se ingresen mas de 10 lneas en la factura (ver frmula 4). 5. No permitir ingresar fechas nulas, ni mayor a la del da.

6. Actualizar el stock del producto 7. Controlar que el stock del producto no sea menor que cero. 8. Advertir cuando se sobrepasa el stock mnimo del producto Frmulas: 1. Encontrar el precio del producto de acuerdo a la fecha de la factura (FacProdPre). 2. Calcular el importe de cada lnea de la factura (FacLinImp). 3. Calcular el total de la factura (FacTotal). 4. Contar la cantidad de lneas ingresadas. Probar las siguientes facilidades: Drag and Drop de controles entre forms de transacciones. Utilizar el List Datbase (Opcin: Tools/List Datbase) Utilizar List Attributes (Opcin: Tools/List Attributes) Ejercicios de Reportes y Procedimientos: Listado de clientes ordenado por nombre en un rango de nombres definido por el usuario. Los datos que se desean listar para cada Cliente son: Nombre, Direccin y Telfono. Listado de la factura al finalizar el ingreso de la misma en la transaccin de facturas. Listado de ventas por cliente, incluyendo slo los clientes que tienen facturas (Corte de Control). Cliente: CliXXX Nro. Factura 000001 000002 Total de ventas: $2524 Cliente: CliYYY Nro. Factura 000010 000011 Total de ventas: $1000 Procedimiento para generar una nueva lista de precios en los productos. El procedimiento pedir dos parmetros: Fecha del aumento Porcentaje de aumento La nueva lista de precios para cada producto tendr la fecha ingresada como parmetro y el precio que resulte de aplicar el porcentaje de aumento al ultimo precio de cada producto cuya fecha sea menor a la ingresada por parmetro. Fecha 01/01/98 010298 Importe $700 $300 Fecha 01/01/98 010298 Importe $1024 $1500

101

Numerar automticamente la Factura. Para ello necesitaremos tener una estructura auxiliar donde guardar el ltimo nmero de Factura. Utilizar una udp para realizar la numeracin de la Factura. Ejercicios de Work-PaneIs: Crear un folder y agrupar en ste, los Work-PaneIs Trabajar con Clientes: Se trata de un Work-Panel que muestra los clientes en forma de lista, y permite las siguientes opciones: Visualizar slo los clientes que estn en el rango que el usuario determine. Posicionamiento por Nombre de Cliente dentro de los clientes en el rango (Regla Search). Dar Altas, Bajas y Modificaciones a clientes, e