Documento - PuntoExe

PuntoExe Tools
Manual de Uso – Volumen 7
Migraciones Win a Web
INTRODUCCIÓN
Este Volumen 7 del Manual de Uso de las PXTools es la transcripción
del séptimo de los siete videos que contienen la versión ampliada del Curso de
Entrenamiento dictado por el Ing. Juan Marcelo Bustamante (autor de las
PXTools) a un grupo de nuevos usuarios de esta herramienta, a fines de 2007.
Todas las referencias internas para la ubicación de sus contenidos
temáticos o imágenes remiten al momento en que fueron abordados o
mostrados en la grabación original, de modo de poder ampliar en ella cualquier
asunto que pueda haber perdido claridad en la transcripción.
Los títulos de cada tema hacen referencia expresa al video y momento
de la reproducción en el formato:
V Nº | HH:MM:SS
(HoraHora:MinutoMinuto:SegundoSegundo)
de modo que el índice de cada volumen permite ubicar los temas en el propio
documento o en el correspondiente video indistintamente.
Las imágenes se identifican con una combinación de video y momento
de la reproducción en el formato:
VH:MM:SS
(VideoHora:MinutoMinuto:SegundoSegundo)
para que puedan ser referenciadas en cualquiera de los volúmenes del manual.
Con el fin de minimizar el peso de estos documentos en su versión
digital, todas las imágenes contenidas tienen baja resolución, por lo que se
recomienda regular el nivel de Zoom del visualizador antes de proceder a su
lectura.
Página 1 de 44
INDICE
TEMA
Gestión de Proyectos - Categorización
WorkWith Sencillos
WorkWith Complejos
Transacciones Sencillas
Transacciones Complejas
Objetos de Consulta
Parameter Request
Reportes o Procedimientos a PDF sencillos
Reportes o Procedimientos a PDF complejos
Procedimientos con llamadas a Interfaz gráfica
Prompts
Pantallas Composer
Gestión de Proyectos - Temas a considerar
Preparación de ambiente de trabajo
Carga de datos para Testeo
Diseño gráfico
Montaje del Diseño gráfico
Cierre de versión y entrega de Kb
Testing
Gestión de Proyectos - Administración Kbs
Metodología
AdminG
Gestión de Proyectos – Roles del Proyecto
Programadores
Gerente de Proyecto
Encargado de Cuenta
Gestión de Proyectos - Método de Testeo
Cuello de Botella en Consolidación
Implementación alternativa
Actualización de Kbs por cada Versión
Gestión de Proyectos - SAC/ Work Arounds
Evaluación de SACs reportados
Prompts
ToolTipText
Inserción de Datos
Agregar Tabla y Clave Foránea asociada
Campos editables en Grids
Página 2 de 44
UBICACIÓN Pg.
V 7 00:00:00 4
V 7 00:01:27 4
V 7 00:03:15 5
V 7 00:05:30 6
V 7 00:05:45 6
V 7 00:09:18 7
V 7 00:11:05 7
V 7 00:11:57 7
V 7 00:12:48 8
V 7 00:15:24 8
9
V 7 00:16:29 9
V 7 00:21:12 10
V 7 00:21:30 10
V 7 00:23:39 11
V 7 00:24:13 11
V 7 00:24:43 11
V 7 00:25:06 11
V 7 00:25:35 12
V 7 00:27:35 15
V 7 00:27:49 15
V 7 00:28:34 15
V 7 00:32:50 17
V 7 00:33:09 17
V 7 00:33:09 17
V 7 00:41:06 18
V 7 00:42:15 19
V 7 00:42:55 19
V 7 00:44:38 19
V 7 00:58:08 24
V 7 01:03:11 25
V 7 01:12:00 25
V 7 01:14:15 25
V 7 01:17:55 27
V 7 01:19:17 28
V 7 01:20:40 28
V 7 01:21:52 30
Parámetros char y Reglas que se disparan con Ajax
Asignar Texto a un TextBlock mediante proc. Ajax
View
Composer
Level1
ANEXOS
ANEXO 1 – Categorización de Objetos
ANEXO 2 – Guía de diseño
Página 3 de 44
V7
V7
V7
V7
V7
01:23:54
01:24:38
01:25:28
01:28:04
01:29:34
31
31
32
32
33
34
34
36
Gestión de Proyectos - Categorización
V7
00:00:00
El objeto de este capítulo es comentarles a ustedes la experiencia que
hemos tenido nosotros en Gestión de Proyectos y plantearles cuales son los
asuntos que hay que tomar en cuenta para el desarrollo de un Proyecto en el
que intervengan muchos programadores.
Vamos entonces a tratar de mostrar los distintos procesos que se deben
cumplir desde la fase de arranque hasta la fase final de entrega del producto.
Lo primero importante cuando arrancamos un Proyecto es hacer un
estimativo de los tiempos que vamos a requerir para llevarlo a cabo. Sea un
Proyecto de migración o de desarrollo de un nuevo sistema va a ser necesario
analizar a fondo las tareas que lo componen para tener una idea de la duración
del mismo.
Para esto es importante saber cuál es la complejidad de la KB a migrar o
desarrollar y para ello es necesario categorizar los Objetos que la componen en
función de ciertas características que permitan adelantar las dificultades y
facilidades que se van a encontrar en el proceso.
Después veremos que cada categoría está básicamente previendo un
tiempo de desarrollo. Lo que vamos a ver ahora es cuál es el criterio que
seguimos para particionar la KB a migrar o desarrollar, a efectos de su
evaluación.
Contamos con un documento que agregamos como ANEXO 1 a este
manual, que contiene la información acerca de la “Categorización de Objetos” y
vamos a explicar ahora cada una de las categorías que la integran.
WorkWith Sencillos
V7
00:01:27
La primera categoría comprende aquellos Objetos que por su estructura
constituyen los típicos “WorkWith” de GeneXus.
Esta clasificación no es excluyente, puede ser que una KB tenga su
lógica particular y haya que hacer una apertura mayor para determinados
Objetos, pero en este primer grupo incluimos los que llamamos “WorkWith
Sencillos”, que se definen en el documento de la siguiente manera:
“En general el desarrollo de una instancia de Pattern consta de la generación de un
Work With y una Transacción en conjunto. En tal caso la estimación de tiempos de
desarrollo de este tipo de objetos se realiza en conjunto. A los efectos de la
estimación en forma separada se realizará una simple partición de los tiempos a la
mitad.”
Por lo general, lo que nosotros programamos cuando desarrollamos una
Instancia son dos Objetos: El WorkWith y la Transacción. Más allá de esto
cuando categorizamos los Objetos tratamos de separarlos, porque nos pueden
surgir determinados problemas sobre cada uno individualmente, sin perjuicio de
que el programador, en la Instancia, va a trabajar sobre la Transacción y el
WorkWith (eventualmente más de uno aunque esto no sea lo habitual) a la vez.
Lo que caracteriza a los WorkWith Sencillos es que se trata de simples
tuplas de una Tabla, donde se muestran columnas, donde existe una Tabla
Base y no hay mayores inconvenientes.
Página 4 de 44
WorkWith Complejos
V7
00:03:15
Cuando hablamos de WorkWith Complejos, acá lo que estamos tratando
de definir es alguna complejidad adicional.
Por ejemplo, ya no hay una Tabla Base, está recorriendo Tablas
Extendidas, o ya se empieza a definir un Event Load y hay algún tema puntual
que resolver que lo transforma en un WorkWith Complejo, aunque por lo
general los WorkWith no lo sean.
En el sistema GCI (Gestión contable Integral) al que nos hemos referido
en varias oportunidades anteriormente, cuando tuvimos que implementar el
“Trabajar con Transacciones del Presupuestal” ya teníamos el tema del “Insert
Variables”:
que implicaba agregar lógica al “WorkWith” original porque desde este Work
Panel se pasaba a un Selector de tipo de Transacción y ahora tenemos que
saber que esto debe ir unificado con el WorkWith para tratar de minimizar la
cantidad de pantallas.
En Win cuando se ponía Insert se pasaba a una pantallita que pedía
seleccionar el tipo de Transacción deseada en una Grilla y después se pasaba
a la Transacción correspondiente en modo Insert.
Toda esta lógica hubo que pasarla a este WokWith que se transformó en
algo más complejo.
También en este caso teníamos muchas acciones que dependían de
ciertas condiciones y había que desaparecerlas de su columna, como vemos
en la figura anterior.
Todo esto hace que ya no se trate de un WorkWith de Tabla Base sino
de una Tabla más compleja, tiene mucha manipulación, manejo de Múltiples
Órdenes, en fin, este tipo de WorkWith corresponde a la categoría de
Complejos.
Página 5 de 44
También debemos mencionar el caso en que tenemos manipulación de
variables editables en la Grilla. Es otro caso a tomar en cuenta aunque
tengamos soluciones al respecto, como el ForceGridLoad que vimos en V 2 |
01:34:54 para solucionar la recuperación de datos de las variables editables del
Trabajar Con. No obstante sabemos que si tenemos Trabajar Con para el
manejo, por ejemplo de Cancelación de Documentos que vimos en esa misma
oportunidad, tales Objetos deberían estar categorizados como complejos.
Transacciones Sencillas
V7
00:05:30
Lo mismo hicimos con las Transacciones, donde también hay que
categorizarlas en Sencillas y Complejas.
Cuando estamos hablando de Transacciones Sencillas, básicamente
nos referimos a todas aquellas que no son Complejas, dado que éstas últimas
son más fáciles de identificar.
Transacciones Complejas
V7
00:05:45
Transacciones Complejas son, por ejemplo, aquellas que tengan más de
20 Reglas. Este límite lo hemos puesto por experiencia: Cuando trabajamos
con Transacciones con muchas Reglas, al migrarlas a Web podemos empezar
a tener problemas derivados de la combinación de ellas.
Cuando empiezan a coexistir muchas Reglas aparecen problemas, todos
solucionables, sólo que como sabemos, en el ambiente transaccional y aún
más en Web, tenemos que acomodarnos a lo que GeneXus nos da, que a
veces no coincide con lo que necesitamos para evitarlos.
Reglas que funcionan bien en Win, en Web no funcionan y tenemos que
buscar alguna alternativa para poder mantenerlas y eso nos lleva tiempo.
Tiempo para empezar a probar soluciones, sobre todo si no tenemos
experiencia en migraciones Win a Web y tenemos que empezar a darnos
cuenta de cómo funciona la lógica y cuál es el inconveniente.
Otra particularidad que hace a la Transacción Compleja es que tenga
muchas Reglas After Attribute. Si hay mucha interactividad con este tipo de
Reglas es factible que podamos tener algún problemita con la Transacción,
especialmente cuando las dependencias de After Attribute se interrelacionan
éste es un buen motivo para categorizarla como Compleja
Por último también deben considerarse Complejas aquellas
Transacciones que en la lógica del proceso terminan llamando a otras
Transacciones. Y más cuando antes las contemplábamos como UTLs y ahora
sabemos que ya no pueden ser más UTLs, de modo que probablemente la
lógica tenga que cambiar.
Debemos categorizarlas como Complejas porque probablemente en
esos casos tengamos que hacer modificaciones. Recordemos que en Web la
UTL no se puede trasladar entre distintos Objetos. No podemos poner en una
Transacción el “Commit” en no, pues si lo hacemos, cuando pasamos al otro
Objeto se hace el Rollback automático. No existe la lógica que sí existe en Win
de usar una única UTL entre distintos Objetos GeneXus.
Más allá de este tema de la UTL también está el tema de si en el After
Trn estamos invocando a una o más interfaces gráficas porque aquí entramos
en lo que vimos en V 2 | 01:45:20 acerca del Controller para el caso de que sea
Página 6 de 44
una sola invocación a interfaz gráfica, o al efecto de Controller que hicimos con
un procedimiento, la lógica procedural para simular las “n” llamadas para ver de
donde se retorna que vimos en V 4 | 01:11:27, pues si tenemos en el After Trn
más de una invocación a interfaz gráfica, ese After Trn lo tenemos que pasar a
un procedimiento de este tipo que se maneje como Controller.
Y, otra vez, eso nos va a llevar tiempo, adaptar toda esa lógica y
programar el Controller, de modo que también en estos casos debería
categorizarse la Transacción como Compleja.
Objetos de Consulta
V7
00:09:18
Después tenemos los Objetos de Consultas que son aquellos Trabajar
Con que se usan para visualizar datos. No tienen por objetivo el mantenimiento
de la Tabla a través del Insert, Update y Delete sino el de mostrar datos como
resultado de una consulta.
En estos casos se arma una estructura de navegación entre las Tablas
para recorrer visualmente. Por lo general estos tipos de Objetos de Consulta
tienen un Event Load bastante complejos, ya no es recorrer una Tablita sino
que hay que incorporarle a las columnas de la Grillas elementos complejos que
resultan de analizar otras Tablas y extraer nuevos datos, en fin, las consultas
pueden tener lógicas complicadas.
Para diferenciar si pasa a la categoría de Consultas complejas o
sencillas utilizaremos los mismos criterios que la categorización vistos en los
WorkWith.
Parameter Request
V7
00:11:05
En esta Categoría debemos incluir todos aquellos Objetos que van a ser
resueltos mediante el Pattern ParameterRequest.
En el documento mencionado nos referimos a ellos del siguiente modo:
“Este patrón presenta una variante con respecto al Work With. Así por ejemplo,
este patrón toma como Objeto referencia un Reporte o Procedimiento en vez de
una Transacción.
Para la estimación de Tiempo asumimos que las funcionalidades requeridas para la
generación automática de la instancia están implementadas en el Pattern. Si así no
fuera, siempre es posible reprogramar el Pattern para incorporarlas.”
Se trata de aquellos Web Panels a través de los cuales pedimos datos
tabulares en pantalla e invocamos o retornamos a Objetos GeneXus o
simplemente para mostrar datos en forma tabular. En la gran mayoría de los
casos son pantallas que no manejan grillas aunque el Pattern soporte grilla
para casos muy especiales.
Las variantes para diferenciar Parameter Request sencillos o complejos
suelen presentarse en función de la cantidad de datos que se piden en pantalla
o si la lógica de validación de los datos ingresados complica la programación.
Reportes o Procedimientos a PDF sencillos
V7
00:11:57
Esta es una Categoría muy básica. Cuando tenemos este tipo de
Objetos para migrar, hay que declarar que el Reporte es “Main” para poder
Página 7 de 44
compilarlo y que el Call Protocol es HTTP para poder declararlo y además hay
que crear la Regla Output para que diga PDF. Estas son las tres cosas que hay
que hacer para un Reporte, no tiene mayor ciencia, es más, la estimación es
muy pequeña en tiempo al extremo que se estima por cada diez Objetos a
migrar, pero de todas maneras hay que modificarlos y por lo tanto deben ser
tomados en cuenta.
Reportes o Procedimientos a PDF complejos
V7
00:12:48
Específicamente se aplica a aquellos Reportes o Procedimientos que
tengan salida a interfaz gráfica, no a procedimientos que sean internos.
Acá estamos contemplando específicamente Reportes o Procedimientos
que reciban Arrays por parámetro. En Win le pasábamos un Array, el Reporte
lo recibía, después recorría una Tabla Base y al Array lo tomaba en cuenta en
algún momento.
El problema es que los Arrays por parámetro no se pueden pasar en la
URL. Como el Reporte lo tenemos que declarar como “Main”, Call Protocol
HTTP, cuando se invoca al Reporte, se invoca en la URL del Navegador,
donde se pasan los parámetros del Reporte y no es posible representar Arrays
como un parámetro de la URL.
Esto nos obliga a utilizar mecanismos alternativos, que en este caso
consiste en definir una estructura de SDT que represente los valores del Array
o de los Arrays.
Puede tratarse de un conjunto de Arrays que representen un
Estructurado, nos ha pasado de tener que trabajar con tres o cuatro Arrays
pero donde los índices de los Arrays son comunes a todos ellos.
Entonces el Parameter Request que es el que normalmente debe cargar
los Arrays o de alguna manera instanciarlos, después de hacerlo se deben
recorrer esos Arrays y cargar el SDT, luego grabar el SDT en la Web Session,
por ejemplo, con las rutinas de AcSUV que mostramos en V 4 | 00:08:18.
Después en el Reporte hacer lo inverso, quitar el Array del parámetro,
recibir el SDT de la Web Session, recorrer el SDT e instanciar los Arrays. Esto
es lo que normalmente hacemos, no tocamos el Reporte, sólo actuamos sobre
el punto de contacto, tanto en la invocación como en la recepción para
instanciar los Arrays y mantener la lógica que se estaba manejando.
Pero esto lleva un poco de tiempo, hay que armar los SDT, hay que ver
la lógica, hay que ver en qué momento invocarlo, pasar la sesión, entonces
obviamente es un tiempo bastante mayor que para la categoría anterior.
Procedimientos con llamadas a Interfaz gráfica
V7
00:15:24
Este caso es un poco parecido al que vimos en el último punto de las
Transacciones Complejas, cuando encontramos lógicas de procedimientos que
terminan llamando a interfaces gráficas y por este solo hecho constituyen
casos que se deben categorizar por separado.
Se trata de implementar una de las lógicas más complicadas que se
pueden presentar en proyectos de migración, porque si bien proveemos
herramientas para ayudar, la lógica para implementar la solución real del
controlador tiene que ser elaborada en cada caso particular.
Página 8 de 44
Muchas veces no sólo se trata de migrar un procedimiento a un
Controller tipo Web Panel sino ver si estamos en el lugar adecuado para llamar
al Web Panel en función del momento en que se estaba invocando a este
procedimiento, lo que genera bastante demora en el proceso de migración.
Prompts
Después tenemos los Prompts.
Por lo general estos tipos de Objetos no resultan en lógica de
programación compleja ya que se limitan a recorrer las Tablas Bases del
sistema y por lo tanto son categorizados como sencillos.
De todas maneras hay excepciones y para diferenciar si pasa a la
categoría de Prompts complejos utilizaremos los mismos criterios que la
categorización vistos en los WorkWith.
Pantallas Composer
V7
00:16:29
A veces nos resulta difícil explicar esta categoría a clientes que no
conocen los PXPatterns porque refiere a aquellas pantallas que por su extrema
complejidad deban ser resueltas mediante un Composer, tal como vimos en
V 1 | 00:43:38.
Para se realistas en los tiempos, lo que habría que estimar es
individualmente cada componente que lo integra. Si tenemos en un Composer
dos Grillas, seguro vamos a tener que hacer dos WorkWith y habrá que
determinar si cada uno de ellos es sencillo, complejo, en fin, habrá que analizar
su lógica por separado, más allá del Composer en sí que también habrá que
categorizar.
Normalmente lo que se debe es hacer una estimación real de Instancias
que haya que programar y en este caso, a un Composer hay que subdividirlo
en cada una de las lógicas para resolver cada sección de la pantalla.
Generalmente, cuando decidimos programar un WorkWith con estructura
muy compleja mediante un Composer, el problema aquí se presenta cuando
debemos empezar a separar código que teníamos unificado. Teníamos un solo
Event Load en el Work Panel original y tenemos que transformarlo en dos, tres,
cuatro o cinco Events Load dependiendo de la cantidad de componentes que
tenga la pantalla.
Luego el problema no es armar la Grilla o armar el Parameter Request
que por lo general son muy sencillos y la lógica es bastante simple de
implementar. Lo que es más complicado es separar el Event Load principal en
los distintos Events Load que tenemos que implementar individualmente y eso
seguramente nos va a insumir tiempos de desarrollo.
Hasta aquí todo lo relativo a la Categorización. Esta es la categorización
básica que nosotros hacemos, sin perjuicio de que cada sistema debe ser
analizado especialmente para detectar particularidades con las que nos hemos
encontrado en algunos casos. Por ejemplo en algunos clientes nos hemos
encontrado que en la versión Win hacían llamadas a dlls o rutinas externas en
programadas en el lenguaje final a soportar o invocaciones a código embebido
del lenguaje a través de los comandos: DBASE, VB JAVA o NET. Bueno, eso
va a haber que contemplarlo aparte, analizar cuantas llamadas hay porque se
debe considerar, primero ver que hacía cada una de esas dlls o rutinas o
Página 9 de 44
código embebido para después determinar que tendríamos que hacer en la
versión Web y todo esto puede llevarnos mucho más tiempo que en una
migración convencional.
De modo que debemos dedicar un poco de tiempo a analizar donde
pueden estar estos problemas, más allá de esta categorización que permite
estimar grosso modo los tiempos de migración de la mayor parte de los Objetos
del Sistema. Pero en todo caso recuerden que sólo se trata de una estimación
inicial y nosotros nunca cotizamos el Outsourcing en función de ella sino en
función de las horas reales aplicadas al trabajo. Máxime cuando en general
esta categorización la realiza el propio cliente que es quien mejor conoce su KB
y por lo tanto puede cometer menos errores de evaluación.
Sin perjuicio podemos decir que esta categorización, cuando está bien
hecha, permite una estimación de los tiempos del proyecto bastante real y por
lo general tenemos una desviación inferior al 20 % respecto a la planificación
inicial, que es muy aceptable para este tipo de desarrollos. También digamos
que en alguna oportunidad una tarea no llevó mucho más tiempo que el
esperado, pero esto se compensó con otras que finalizaron antes de lo previsto
y esa es la gracia de esta metodología que hasta ahora no nos ha defraudado.
Gestión de Proyectos - Temas a considerar
V7
00:21:12
También hay otros temas que hay que tomar en cuenta cuando
estimamos un proyecto y vamos a pasar a ver los más destacables aunque la
lista no sea exhaustiva.
Preparación de ambiente de trabajo
V7
00:21:30
Recuerden que cuando estamos trabajando con Patterns cada
programador tiene que tener su KB. Y armar esa lógica de KBs en nuestro caso
es más complicado aún porque a los clientes lo que nosotros ofrecemos es la
seguridad de que los programadores están trabajando en un ambiente
protegido y ningún programador tiene la KB completa.
Cuando recibimos la KB de un cliente, lo que hacemos es transformar
todos los Objetos en Objetos Privados y armamos la KB de los programadores
con todos los Objetos Privados de modo que no puede abrir ningún Objeto,
más allá de que GeneXus en todos los casos permita abrir el Form de los
Objetos con interfaz.
Obviamente a partir de que se le asignen tareas, el programador va a
empezar a pedir los Objetos involucrados es forma desprotegida para poder
trabajar sobre ellos.
De modo que en nuestro caso requerimos un tiempo para preparar el
ambiente de trabajo con estas características para cada programador que
integre el equipo de desarrollo.
En ese tiempo debemos pasar todos los Objetos a Privados y esto no lo
hacemos uno a uno sino que generamos un XPZ externo, lo modificamos y
consolidamos de nuevo, eso nos genera los Objetos Privados que después
distribuimos con copyright.
Además, como metodología de trabajo, nosotros trabajamos en un
ambiente centralizado, utilizamos un Terminal Server para el ambiente de
desarrollo, eso nos ayuda bastante a tener localizados los problemas y no
Página 10 de 44
depender tanto de los programadores sino que el administrador y gerente del
proyecto es el que hace esa preparación del ambiente, por tanto esto está
bastante focalizado con independencia del hardware que tiene cada integrante
del equipo.
Carga de datos para Testeo
V7
00:23:39
Cuando brindamos nuestros servicios de Outsourcing al cliente, por lo
general no contamos con las Bases de Datos del sistema a migrar, situación
distinta a la que se presenta cuando el cliente realiza la migración con sus
propios programadores que van a poder apuntar a la Base de Datos que se
esté usando en la versión Win.
Por lo tanto nosotros tenemos que hacer la carga de datos para armar
una Base de Datos coherente donde poder hacer un testeo básico del
desarrollo.
Diseño gráfico
V7
00:24:13
Al diseño gráfico también hay que tomarlo en cuenta dentro de los
trabajos extra programación. Seguramente se van a requerir los servicios de un
diseñador gráfico, dado que como sabemos, en Web hay una lógica visual
distinta que aporta mucho al lucimiento de la aplicación y en ocasiones el
aspecto visual importa tanto o más que el funcional.
Contamos con un documento que agregamos como ANEXO 2 a este
manual, que contiene la información acerca de los requerimientos de la
“Interfaz Gráfica de Usuario” y que les va a servir como guía para solicitar la
especificación del diseño gráfico de la aplicación.
Montaje del Diseño gráfico
V7
00:24:43
Luego que el diseñador realiza la especificación del diseño gráfico es
necesario proceder al montaje. Un poco todo lo visto en el volumen anterior
está orientado a esto, a que conozcan cómo montar el diseño, cómo definir las
Clases de cada elemento, cómo aplicar las directivas del diseñador.
Esto también lleva su tiempo que debe ser tomado en cuenta.
Cierre de versión y entrega de Kb
V7
00:25:06
Este es otro proceso que puede ser necesario realizar con alguna
frecuencia a partir de cierto grado de desarrollo del proyecto, para ir
entregando subsecuentes builds a los validadores finales de la aplicación.
Recuerden que estamos trabajando sobre KBs distribuidas, entonces
hay que volver a centralizar la información en una sola KB, volver a regenerar
todas las Instancias, verificar que los procedimientos que hayan sido
modificados vuelvan al consolidado, en fin, hay un proceso de cierre de versión
que incluso requiere un nuevo proceso de testing primario.
Página 11 de 44
Testing
V7
00:25:35
Nosotros manejamos tres niveles de testeo. Un Testeo primario que es
el que realiza el propio programador a partir de la pantalla Win que está
migrando ejecutando ambas versiones del programa y verificando que se
comportan en forma similar.
Como acabamos de ver, al cerrar la versión se debe reiterar el Testing
primario para asegurar que no se han introducido errores al regenerar todas las
Instancias.
Después y antes del Testeo final siempre a cargo del cliente, realizamos
un Testeo secundario más exhaustivo que está a cargo de una persona que
tenga conocimiento del sistema y que conozca las variantes de
comportamiento que debe soportar la lógica del programa en función de las
distintas condiciones de acceso a cada pantalla.
Como estamos desarrollando en Web tenemos muchas ventajas porque
podemos habilitar el acceso de los propios validadores desde donde se
encuentren para que puedan realizar este Testeo secundario.
Si bien los tiempos del Testeo primario están incluidos en las tareas de
programación y cierre de versión, este segundo nivel de testeo también
requiere un tiempo que debe ser estimado y tomado en cuenta al evaluar el
proyecto.
Todas las etapas que hemos visto hasta ahora para el armado de un
proyecto de migración deben ser documentadas de algún modo y nosotros
usamos las facilidades que nos brinda el programa Excel para hacerlo.
Cuando hacemos una Categorización de Objetos a migrar, es
recomendable no manejar sólo cantidades sino declarar explícitamente qué
Objetos están en cada categoría y documentar esto en una planilla como ésta:
Página 12 de 44
donde podemos ver como títulos de cada columna (recuadro rojo) las distintas
categorías que hemos propuesto para particionar la KB a migrar o desarrollar.
Debajo (recuadro azul) podemos ver el nombre de cada uno de los
Objetos que fueron ubicados en cada categoría. Los colores de fondo en las
celdas responden al estado en que se encuentran los Objetos durante el
proceso de desarrollo. Mediante los diferentes “Tics” podemos ir viendo
rápidamente cuáles y cuántos están migrados, qué promedio llevamos migrado
en cada Categoría (recuadro verde), etc., para llevar un control de la evolución.
De modo que el trabajo de categorización de Objetos debería resultar en
algo de este estilo.
Organizar el trabajo de este modo le sirve además al Gerente de
Proyecto para la asignación de tareas a los programadores.
Si hubiera más de un módulo en el sistema es recomendable asignar un
“Libro” a cada módulo, de modo que la recorrida de cada lista constituya una
secuencia coherente trabajo para un mismo programador.
Luego tenemos otra planilla para la estimación de todos los tiempos del
proyecto, que en el primer “Libro” resume los totales por Categoría que vienen
de la que acabamos de ver:
Ya están precargados los tiempos promedio que no lleva la migración de
cada tipo de Objeto, con lo que se obtienen los parciales y un subtotal general.
También se prevé un “Libro” para documentar los tiempos de algún
SubProyecto que se pueda requerir:
Por ejemplo, hemos tenido casos de clientes que para ciertas Tablas
Base se manejaba directamente la transacción como elemento de recorrida
entre los registros del sistema. En este caso esa funcionalidad no está
soportada por el Pattern por lo que hay dos soluciones al respecto: Tomar en
cuenta en la categorización que una Transacción implementará un WorkWith
relacionado o agregar un subproyecto para realizar el soporte de recorrida de
Página 13 de 44
registros en la propia Transacción. Para este último caso seremos nosotros los
que estimaremos el soporte de dicha funcionalidad en los Patterns.
Otro ejemplo es el tema de la Impresión Batch, si aplica, debe ser
evaluado con sus propios tiempos de desarrollo.
En nuestra versión de esta planilla tenemos un “Libro” adicional para
documentar el desarrollo de nuevas funcionalidades en los Patterns y luego
tenemos un “Libro” que resume todos los tiempos de los anteriores y que
corresponde propiamente al proyecto de migración:
Página 14 de 44
donde incluimos ahora sí, todas las otras tareas extra programación que
forman parte del mismo y que acabamos de mencionar.
Todos estos tiempos deben ser estimados y de esta planilla surge la
cantidad de programadores que requiere el proyecto a partir de la que sugiere
(recuadro) como resultado del tiempo de duración ingresado y el total de horas
a cumplir.
El último “Libro” contiene el Estimativo de Inversión resultante de todo lo
anterior.
Gestión de Proyectos - Administración Kbs
V7
00:27:35
En este tema lo que cuentan son los requerimientos de los Patterns
acerca de la manipulación de una KB, acerca de los cuales algo ya hemos
visto.
Metodología
V7
00:27:49
Acá nosotros no podemos seguir la metodología que de pronto muchos
de ustedes aplican, que consiste en mantener una KB centralizada y que todos
los programadores trabajen sobre la KB centralizada en los distintos modelos
de Prototipo o Producción.
Esto no lo podemos hacer así porque cuando nosotros trabajamos sobre
los Pattern estos bloquean la KB en Modo Diseño. Es como si entráramos en
Modo Diseño lo que descarta la posibilidad de trabajar todos sobre una KB
centralizada.
AdminG
V7
00:28:34
De modo que en lo que llamamos Preparación de Ambiente de Trabajo
lo que hacemos es preparar una KB para cada programador y cuando
comenzamos a prestar servicios de Outsourcing nos dimos cuenta que iba a
Página 15 de 44
ser necesario disponer de algún programa que nos administrara la información
distribuida a los programadores.
Yo les comentaba a algunos de ustedes que el proceso de trabajar con
Instancias no es el problema principal porque cada uno tiene su Instancia, la
genera, la prueba en su ambiente local y esto no ofrece inconvenientes. El
problema se presenta cuando empezamos a manipular Objetos “por debajo”,
por ejemplo, Procedimientos que son llamados por las Transacciones.
En Web, como norma general que deberían aplicar en todos los casos,
toda vez que una Regla de una Transacción invoque a un Procedimiento,
deberían declararle a ese Procedimiento específicamente los valores de “In” y
de “Out”, porque es casi indispensable hacer esto para que funcionen bien
todas las reglas de Ajax.
GeneXus tiene que saber que tiene que llamar, que tiene que invocar y
que tiene que devolver para que funcionen bien las invocaciones. Cuando
llamamos con UDPs, no hay problema, más o menos GeneXus ya sabe que lo
único que se devuelve es lo que está antes de la UDP, pero cuando llamamos
con” Call” es importante saber qué se pasa y qué se devuelve.
El SVT AdminG es un sistema que nos permite administrar la KB,
básicamente trabajamos en un modelo consolidado, hay una KB consolidada y
después una KB para cada programador que en principio tiene los Objetos
protegidos, lo que es ideal porque obliga al programador a pedir el Objeto con
el que va a trabajar para poderlo manipular.
Entonces el programador tiene que pedir un Procedimiento y por esto
imaginen que en el AdminG el concepto es el de manejo de una Bandeja de
Entrada, en el que cada programador tiene los programas que pidió.
Después, de acuerdo con esta lógica, simplemente va a devolver ese
Objeto una vez que haya terminado con él y se puede establecer que
automáticamente pase por un Administrador de KBs. En nuestro caso siempre
pasa por un Administrador de KB para que vea si lo que está devolviendo es
correcto, mismo para después hacer el control de especificación, generación,
compilación y todo lo demás.
Este sistema ofrece múltiples funcionalidades que vamos a mencionar
pero no vamos a ver en detalle como:
• Consulta de Programas: Uno podría consultar por un programa
que no lo ve, o que no lo tiene actualizado y se puede consultar
en la KB centralizada sin tener que abrir esa KB para permitir que
muchos puedan estar consultándola,
• Pedido de Programas, como ya vimos o,
• Pedido de Actualización,
• Pedido Múltiple, para modificar muchos Objetos a la vez,
• Creación Múltiple para crear muchos Objetos a la vez declarando
su creación. Cuando trabajamos con muchos Objetos el tema de
la nomenclatura es importante y AdminG controla que cuando un
programador solicita crear un Procedimiento, ese Procedimiento
al consolidar no se sobre escriba con el de otra KB de otro
programador que de pronto también lo está creando. Se trata de
controlar la unicidad de los programas que se están creando,
• Soporte de Anulaciones y
• Devoluciones de programas a la KB centralizada o entregar a
otros programadores versiones que se están desarrollando.
Página 16 de 44
Gestión de Proyectos – Roles del Proyecto
V7
00:32:50
También debemos hablar de cómo manejar la estructura jerárquica
dentro de un equipo de desarrollo y que relación hay entre los diferentes roles.
Cada proyecto se atiende con una estructura celular básica con pocos
niveles dentro.
Programadores
V7
00:33:09
Integran un grupo colaborativo tratando de especializar a cada
profesional con este rol en los distintos subsistemas del aplicativo a migrar.
Gerente de Proyecto
V7
00:33:09
Uno para cada sistema y en lo posible un solo sistema para cada
profesional con este rol. Una cosa es migrar un sistema con distintos módulos y
otra cosa en migrar dos sistemas con lógicas e implementaciones distintas.
Las tareas del Gerente de Proyectos son variadas y entre ellas
encontramos:
• Análisis de posibles situaciones a contemplar cuando se trata de migrar
una KB, evaluar dónde están los posibles problemas, cómo
solucionarlos, en fin, la idea es darle lo más aceitado posible al
programador el proceso de migración, de modo que su tarea sea como
la de un integrante de una línea de montaje en los tiempos de Henry
Ford: Entra Objeto, proceso, prueba y siguiente Objeto.
Este es el único modo de lograr que los tiempos del proyecto se
cumplan.
• Delegar tareas, esto es asignar tareas a cada programador tratando de
especializar su trabajo en función de los distintos módulos que contenga
el sistema a migrar, de modo que pueda familiarizarse con la lógica del
subsistema que tiene a cargo en un régimen de complejidad creciente a
partir de la migración de sus Tablas Base.
• Otra tarea del Gerente de Proyecto es la concerniente a su rol de KB
Manager. Más allá de que el AdminG nos administre la KB, este rol
sigue existiendo.
Se trata de otorgar los Objetos solicitados o aceptar las devoluciones de
los programadores, evaluar si anduvo bien la consolidación, en una
tarea que es bastante monótona pero que requiere ser estricto porque,
nos ha pasado por ejemplo, que en un Procedimiento se requiere
manejar algún Subtipo de un elemento de la Tabla Extendida y como
ese Subtipo el programador no lo tiene, crea un grupo en su KB.
Ahora, este grupo tiene que estar asociado a alguna Transacción, de
modo que si el programador devuelve sólo el Procedimiento, en la KB
Centralizada este grupo no está asociado a ninguna Transacción y esto
nos va a generar problemas en el ambiente del Consolidado.
Esto se resuelve siendo muy riguroso con las consolidaciones de los
Objetos, ver en cada Procedimiento que se está consolidando los
posibles Warings que se generan, es una tarea muy tediosa pero hay
que hacerla.
Página 17 de 44
•
•
Por otro lado el Gerente de Proyecto es un Tutor y por tanto debe
conocer la forma de programar con las herramientas que estamos
utilizando: Las Pxtools y las otras herramientas de gestión que requiera
el proyecto, de modo de poder asesorar al programador o al tester en
cualquier situación que se presente.
En nuestro caso el Gerente de Proyecto también presta servicios de
Soporte el Cliente en aquellos problemas que suelen presentarse en la
etapa de validación.
Ocurre que puede haber un problema en una pantalla que no deba ser
derivado directamente al programador sino que debe ser abordado
desde un punto de vista más general, pues el requerimiento puede estar
afectando las reglas estructurales de la aplicación en su versión Web,
cambios que deben ser analizados con el cliente antes de bajar el
requerimiento a la tarea de programación.
No siempre es así pero de todos modos tales requerimientos deben ser
evaluados en todos los casos por el Gerente de Proyecto.
Encargado de Cuenta
V7
00:41:06
Se trata del integrante del equipo que se ocupa hacer el seguimiento del
proyecto y de mantener informado al cliente acerca de la evolución del mismo.
Es una tarea que requiere documentar mediante informes semanales el
estado cada tarea, medir los desvíos y permitir evaluar la marcha del proyecto
a fin de poder introducir posibles ajustes.
Página 18 de 44
Gestión de Proyectos - Método de Testeo
V7
00:42:15
El Testeo del desarrollo es todo un tema y nosotros vamos a explicar
una metodología que estamos usando y vamos a ver que esta metodología
inclusive nos ayudó a determinar cuál era el mejor generador de GeneXus a
utilizar en nuestro trabajo.
Hoy día nos hemos especializado en el uso de Java porque Java nos
brinda cierto soporte o ciertas facilidades para esta metodología que estamos
usando para el Testeo. Vamos a explicar un poco cuál es el problema.
Como vimos, el centro del proyecto en realidad es el Gerente y el
problema se presenta en el día a día. Cuando un programador migra una
pantalla, la rutina que debe seguir es entregarla al KB Manager para que la
consolide, para que la incluya en el Consolidado y para que la genere en el
Consolidado. Ese debería ser el proceso habitual.
V7
Cuello de Botella en Consolidación
00:42:55
Como vimos, el centro del proyecto en realidad es el Gerente y el
problema se presenta en el día a día. Cuando un programador migra una
pantalla, la rutina que debe seguir es entregarla al KB Manager para que la
consolide, para que la incluya en el Consolidado y para que la genere en el
Consolidado. Ese debería ser el proceso habitual.
El problema es que si esa metodología la usamos en un ambiente en el
que tenemos cuatro o cinco programadores trabajando en el mismo proyecto,
el rol de KB Manager ocuparía todo el tiempo del Gerente de Proyecto que
quedaría dedicado exclusivamente para eso sin poder atender sus otras tareas.
Sería necesario quitarle esta tarea y adjudicársela a un nuevo integrante
con el rol exclusivo de KB Manager y en nuestro caso esa variante sería muy
costosa y difícil de trasladar al precio del servicio. De modo que tuvimos que
procurar la manera de sortear este “Cuello de Botella”.
Es una situación que genera un cuello de botella en el proceso de
industrialización del desarrollo, para ver la migración en términos de cadena
productiva.
V7
Implementación alternativa
00:44:38
Debimos entonces buscar una metodología alternativa, lo que nos llevó
a evaluar la situación del siguiente modo:
P1
P2
P3
C
70:45:22
Haciendo de cuenta que hay tres programadores, tenemos una KB “P1”,
“P2” y “P3” para cada uno de ellos y una KB consolidada “C”.
Página 19 de 44
P1
P2
P3
C
70:45:37
El proceso normal, estando cada KB en su estado de actualización
correcto, es que cada programador vaya pidiendo los Objetos (flechas rojas)
que requiere para hacer su parte de la migración, conforme a la tarea asignada
por el Gerente de Proyecto.
P1
P2
P3
C
A
70:46:10
Modelo de Testing
El cuello de botella se presenta cuando todos ellos comienzan a
devolver Objetos (flechas azules) y en ese punto (óvalo verde) el KB Manager
tiene que estar consolidando todos esos Objetos.
El KB Manager tiene que estar recepcionando continuamente todos esos
Objetos para pasarlos a una Página Web (figura violeta) que sea un ambiente
de testing.
Vamos a representar ahora otra situación que resulta preferible para el
desarrollo del proyecto. En primer lugar cada KB debería tener su propio
ambiente de Testing local:
A
A
P1
A
P2
P3
C
A
70:46:30
Página 20 de 44
Modelo de Testing
Cada programador tendría que tener su propia versión Web local (figuras
naranja) para poder probar individualmente la aplicación que está migrando. Es
lo que nosotros llamamos hacer el testeo primario, hacer una mínima prueba
de buen funcionamiento.
El problema es que no podemos pedir a un tester o validador secundario
que vaya probando cada Objeto en los distintos lugares. Si estamos trabajando
con Notebooks, o sea, no con Terminal Server, estamos en ambientes
separados, inclusive podríamos estar en redes separadas y el tester podría no
tener acceso a estos ambientes locales de cada programador.
Entonces, es necesario pasar a un Sitio Web, a una Webapp en donde
esté centralizada la información. Por eso el tema de pasarlo a la KB
Consolidada donde nos encontramos otra vez con el problema del KB
Manager.
Para resolverlo, lo que nosotros implementamos fue lo siguiente:
A
A
P1
A
P2
P3
C
A
70:47:59
Modelo de Testing
La KB “C” que tiene un Modelo de Testing apunta a un Servidor Web
que está en la red y lo que hacemos es que cada programador tenga también
un Modelo de Prototipo que apunte al mismo repositorio (flechas marrones).
El Modelo de Testing está en un Servidor Web y lo que hacemos es que
cada programador tenga en su ambiente un Modelo de Prototipo Local vamos a
llamar y un modelo de prototipo común a todos, que nosotros llamamos Modelo
de Testing.
De modo que lo que establecemos es que cada KB de cada
programador tenga dos Modelos de Prototipo, uno Local y uno de Testing, con
lo que logramos solucionar este problema del cuello de botella, porque cada
programador cuando termina de generar sobre su Modelo Local lo que hace es
pasar al Modelo de Testing y sube los Objetos que compiló, los Objetos que
generó los sube al Modelo de Testing. Obviamente este modelo tiene que estar
en una red para que puedan subir los Objetos.
Vamos a ver también que esta metodología que estamos usando tiene
ciertos inconvenientes que hay que tomar en cuenta y tiene una gran ventaja
que consiste en eliminar este cuello de botella. El KB Manager deja de ser
crucial para esta representación porque cada programador apunta en su KB a
ese directorio de Webapp y por lo tanto sube todas las Clases a ese directorio.
Página 21 de 44
Y al tester le podemos decir que tiene un solo lugar para acceder al
sistema que estemos migrando, que es esa Webapp que está relacionada con
el Consolidado también.
¿Cuáles son los inconvenientes que se pueden señalar?
En primer lugar, esto nos determinó que el generador que teníamos que
usar es el generador Java, porque cuando trabajamos con proyectos de
PuntoNet, GeneXus, cuando generamos un nuevo Objeto, en otro objeto que
se llama WebConfig nos genera todas las interdependencias.
En un proyectito que se llama WebConfig se le informa al Internet
Information Server qué DLLs tiene que tomar para referenciar y eso es lo que
puede cargar en memoria, de modo que lo único que puede referenciar de
DLLs externas es lo que está allí indicado.
El problema es que si estamos trabajando con KBs separadas, cada KB
va a armar su proyecto para los Objetos que cada programador tiene y no va a
haber un proyecto general.
En su momento no profundizamos más en la tecnología PuntoNet para
ver si había alguna posibilidad de que en vez de que GeneXus sobrescribiera el
proyecto, que fuera agregando sin sobrescribir el WebConfig original porque
teníamos el problema de que en esa KB centralizada sólo iban a quedar las
referencias a las DLLs de la última KB que subió Objetos al Servidor.
Esto así provocaría muchas pérdidas de referencias a DLLs que
terminarían siendo Procedimientos o Web Panels de otros programadores en el
sistema.
En el caso de Java la referencia es directa, o sea, hay una relación
directa entre la URL cuando se invoca a cualquier cosa debajo del directorio de
servlets, se va a buscar un .class con ese nombre.
En este caso no se requiere de un proyecto centralizado que administre
la ubicación de las referencias, simplemente se va a buscar al directorio
“clases” el nombre que viene solicitado arriba y si no lo encuentra da un error
directamente y esto nos permitió mandar a ese repositorio todas las “clases” de
todas las KBs sin mayores inconvenientes.
Aunque sí hay un segundo inconveniente referido a esta KB de Testeo
(violeta en la figura) que pasamos a señalar.
Por ejemplo, en V 7 | 00:28:34 dijimos que una de las cosas que
deberían hacer toda vez que una Regla de una Transacción invoque a un
Procedimiento, es declararle a ese Procedimiento explícitamente los valores de
“In” y de “Out”.
En los lenguajes tradicionales Java, PuntoNet, cuando se declara un
método que recibe un parámetro se puede declarar un segundo método con el
mismo nombre siempre que tenga parámetros distintos. Tienen que tener o
tipos distintos de parámetros, o Reglas de “In” y de “Out” distintas de
parámetros, o directamente tipos de datos, uno recibe un “In”, el mismo método
recibe un String y los dos métodos son válidos. El lenguaje sabe que si
llamamos al método y le paso una variable de tipo “In” va a atender el método
que está relacionado con la variable de tipo “In” y en el otro caso atiende el
otro. Se trata de poder usar el mismo nombre de método con múltiples
definiciones.
Esto es muy común cuando acostumbramos que los últimos parámetros,
cuando no se pasan se tomen por defecto. Por ejemplo, si decimos Substring
que arranque del cinco y si no definimos el lenght se sabe que es hasta el final.
Página 22 de 44
En realidad estamos declarando un método string que en un caso tiene un solo
parámetro y en el otro caso tiene los dos. Normalmente el primero llama al
segundo con el lenght hasta el total de la variable que está recibiendo.
Esto es típicamente para lo que sirve: Poder declarar menos parámetros
e instanciar algunos otros por defecto.
En GeneXus, cada objeto que nosotros generamos termina utilizando un
método que se llama “Execute” y para GeneXus hay un solo método que debe
existir como “Execute”. El problema es que justamente, cuando declaramos
parámetros de “In” y de “Out” estamos cambiando el método “Execute”. Al
método “Execute” le estamos haciendo declarar variables de “In” y de “Out”.
Entonces lo que nos puede pasar y muy a menudo pasa cuando
estamos trabajando con un repositorio de Testing de estas características, es
que viene un programador, que tiene que migrar una Transacción que trabaja
sobre un Procedimiento básico (que por ejemplo “Devuelvo Empresa”), y
decide declarar correctamente los parámetros de “In” y de “Out” y declara a la
empresa como de “Out”.
Pero es probable que este Procedimiento se use en muchas otras
Reglas de Transacciones, muchos otros lugares donde la empresa hasta ahora
era de “In” y “Out” si no se declaraba explícitamente.
Entonces lo que va a pasar es que cuando este programador haya
modificado el Procedimiento y lo suba al servidor, obviamente va a sobrescribir
la clase que ya existía y va a quedar el método sólo con el “In” y “Out”. Y
cuando otro Web Panel u otra Transacción que ya teníamos generados y
compilados, que estaba llamando al método “Devuelvo Empresa” con empresa
de “In” y “Out”, el error que nos va a dar es “No existe método asociado…”
porque no encuentra el método. No es que no exista el Objeto, aunque el
mensaje no es del todo claro y parecería que no lo encuentra, lo que muchas
veces nos desconcierta porque podemos ver que la clase sí está.
Lo que ocurre es que para Java, en realidad lo que no se encontró es el
método que se acomode a los parámetros declarados en ese Objeto. Como
GeneXus genera un solo método asociado al “Execute”, al sobrescribirlo el
método anterior dejó de estar y el error que nos da es que no existe el método,
pese a que la clase sí está.
Este es un problema que debemos tomar en cuenta porque se nos
puede presentar muy a menudo en la KB de Testeo con este tipo de Objetos
comunes a todo el sistema y constituye la mayor desventaja que podemos
encontrar en el uso de esta metodología que estamos aplicando.
En algunos casos lo que hemos hecho es tratar de detectar un núcleo,
no un núcleo en la terminología de GeneXus que refiere a Tablas Base, sino un
núcleo de programación que detectara aquellos Procedimientos (por lo general
son Procedimientos) que son utilizados en muchos lugares de la KB y a ese
núcleo lo tratamos de tener controlado de alguna manera.
En esos casos lo que hay que identificar es a los Objetos del núcleo y
replicarlos todos a cada uno de los programadores, para que, si uno de ellos
modifica un Procedimiento de estos, entonces lo distribuya y solicite al resto de
los programadores su consolidación para evitar el error anotado al principio.
Queda claro que este Modelo de Testing es para un Testeo secundario
que tampoco es un Testeo final que corresponde al tercer nivel de testeo del
que hablamos en V 7 | 00:25:35.
Página 23 de 44
V7
Actualización de Kbs por cada Versión
00:58:08
Cuando nosotros hacemos un Cierre de Versión, obviamente nuestro
modelo no es el Modelo de Testing sino un Modelo de Producción:
A
A
P1
A
P2
P3
C
A
Modelo de Testing
A
70:58:20
Modelo de Producción
que debe ser generado sólo por la KB consolidada “C” (figura gris).
Este modelo se va cargando en forma distribuida desde todas las KBs
de los programadores y el último modelo que es el de Producción debería estar
administrado solamente por esta KB.
El proceso normal es que el Gerente de Proyecto, a determinada altura
del desarrollo haga lo que llamamos un “Cierre de Versión”, obligue a los
programadores a entregar todo lo que tienen desarrollado hasta ese momento,
entonces sí, realice las funciones que le caben al KB Manager de realizar todas
las consolidaciones, evaluar todas las inconsistencias que se puedan
presentar, especificar todos los Objetos de la KB Consolidada y generar sobre
un Modelo de Producción que debería volver a ser testeado con un Testing
primario para asegurar que no se han introducido errores al regenerar todas las
Instancias.
De este modo el Modelo de Producción debería ser un modelo mucho
más estable que el Modelo de Testing y es el que ya se entrega por lo general
al cliente. Obviamente entregar el Modelo de Testing al cliente es
extremadamente riesgoso y poco recomendable, aunque en algún caso lo
hayamos tenido que hacer por un tema de tiempos frente a un cliente muy
ansioso.
Lo que ocurre es que el pasar por el Consolidado lleva su tiempo porque
probablemente tengamos que devolver muchos Objetos, atender problemas de
requerimientos del cliente, implementar funcionalidades nuevas, en fin, a
nosotros realizar un Cierre de Versión nos lleva aproximadamente tres días y si
estamos trabajando con un modelo medio nuevo para el equipo de desarrollo
nos puede llevar hasta una semana de trabajo.
De modo que deben tener en cuenta que el Cierre de Versión requiere
un tiempo para hacerse correctamente.
Página 24 de 44
Lo que también tenemos que tener en cuenta es que por lo general
cuando hacemos un Cierre de Versión deberíamos redistribuir la versión de la
KB Consolidada a los programadores.
Sería muy recomendable que si hacemos un Cierre de Versión la KB
que tenemos Consolidada sea la nueva KB que todos los programadores
deban tener actualizada para cubrirnos de todos esos problemas que de pronto
en Testing no los tuvimos en cuenta y saltan puntualmente al cerrar la versión,
por ejemplo en aquella pantalla que habíamos migrado y que ahora daría error
porque el Procedimiento que se reutilizó está con parámetros de “In” y “Out” y
nunca se volvió a probar. Este tipo de problemas se solucionan si procedemos
a redistribuir la KB a los programadores con la versión cerrada cada vez que se
genera.
Al respecto, nosotros aún no la hemos utilizado porque es muy reciente,
pero ahora el AdminG provee una funcionalidad para que cuando un
programador entrega un Procedimiento al Consolidado y el KB Manager lo
autoriza, en la noche replicar ese Objeto consolidado a todas las KBs
distribuidas al resto de los programadores. Esto se resuelve a nivel de XPZs
muy pequeños con los cambios ocurridos día a día en la KB Consolidada.
Gestión de Proyectos - SAC/ Work Arounds
V7
01:03:11
Ahora lo que vamos a mostrar son algunos SACs que nos han surgido
en GeneXus a nosotros para que los tengan en cuenta si se les presenta
alguna situación similar en sus desarrollos.
Evaluación de SACs reportados
V7
01:12:00
Para esta oportunidad les he seleccionado algunos mails que
documentan ciertos SACs reportados por nosotros a GeneXus.
A veces es complicado reportar bugs de GeneXus porque por lo general
nos van a pedir el armado de una KB de Prueba que reproduzca el error y eso
no siempre es posible en términos prácticos.
Incluso nosotros tenemos algunos bugs para los que no hemos podido
aún armar esa KB de Prueba. Sobre todo cuando los problemas son
coyunturales de una pantalla determinada y obviamente no vamos a mandar
una KB de un cliente.
Nosotros además como metodología tratamos de no hacer esto ni
siquiera con nuestras propias KBs y en el único caso que entregamos una
Transacción con todas sus dependencias a Artech es cuando nos lo pide el
cliente.
Por este motivo muchas veces tenemos que conformarnos con un “Work
Around” que es lo que queremos compartir con ustedes.
Estos SACs que les voy a mostrar corresponden al Upgrade 2 de Java,
hoy estamos en el Upgrade 3, de modo que algunos pueden haber sido
resueltos, otros no, pero en todo caso es bueno que los conozcan.
Prompts
V7
01:14:15
Vamos a comenzar con el error que detectamos cuando se llamaba a un
Prompt usando la misma variable en otro Prompt:
Página 25 de 44
Tenemos entonces dos Reglas de Prompts a dos Prompts distintos
(recuadro rojo) y estamos involucrando una misma variable (recuadros azules).
En este caso uno de los dos Prompts no va a tener cargado el
hipervínculo con la “manito” para abrir la ventana.
Esta solución que plantean ellos es para el peor de los casos. Se trata
de ver si se puede no pasar la misma variable sino otra variable que tenga el
mismo valor que la anterior pero que GeneXus las tome como temas distintos.
Nuevamente caemos en el tema de que para que funcione el Prompt la
variable tendría que estar en pantalla como vimos al tratar el “InvisibleAttribute”
de la figura 60:30:26.
Y aquí ellos están planteando de modificar el código fuente (recuadro
verde), cosa que no es recomendable porque si generamos la Transacción de
nuevo vamos a pasarle por arriba a esta corrección.
Lo que sí se puede hacer es lo que hemos hecho en algún caso que es
en el Event Start, forzar el Link de un Prompt con el Javascript que llamaría al
Prompt.
De modo que debería declararse la propiedad “Forced”, que genera un
control en pantalla y después en el Event Start de la Transacción puedo poner
“.link=XX” y hardcodeamos el Link para obligar a que lo genere.
Por lo general van a tener que ver otro Prompt para ver cómo se está
generando el Javascript que se llama Javascript: <nombre del Prompt>” y
después viene algo así como lo que recuadramos en violeta en la figura
anterior: “documents.form[0].” y el nombre de la variable (si tiene un “subguión”
es una variable y si no lo tiene es un atributo), todo en mayúscula. De ben tener
cuidado porque en GeneXus la expresión “[0]” no la pueden poner así porque
Página 26 de 44
les da un error (lo considera un elemento interno y reservado), de modo que
tienen que separarlo en tres caracteres: “[“+”0”+”]”.
En el Work Around no toman esta precaución porque se propone
modificar el fuente directamente, lo que como vimos no es nada recomendable.
Alguna vez nos han preguntado porqué no la aplicamos por defecto, si
tenemos la propiedad “Forced” en los Prompts que es la opción más fuerte
para obligar a que el Prompt funcione. Pero lo que pasa es que en algunos
casos no ocurre esto y se da que poniendo la propiedad “Forced” en el Prompt
éste no funciona y si le sacamos la propiedad “Forced” sí funciona.
De modo que lo recomendable cuando se define un Prompt es probar
con el Prompt común (sin “Forced”) y si vemos que no funciona o que no tiene
el comportamiento que nosotros queremos aplicarle la propiedad “Forced” que
nos obliga a que esté asociado a la variable. Recuerden que les dije que con
esta propiedad en “True” estamos obligando a que el Prompt sólo esté
asociado a la variable donde se está declarando el Prompt.
ToolTipText
V7
01:17:55
Esto es una realidad: En la 9.0 el ToolTipText no funciona en columnas,
pero como ya hemos visto en PXPatterns sí lo pueden aplicar.
Más allá de que la propiedad ToolTip de GeneXus no funcione, las
PXTools logran implementarlo incorporando una lógica bastante rebuscada
dentro de la Grilla donde no se utiliza la variable que está asociada al ToolTip
sino que se crea otra variable a la que se le mete un código HTML para poder
representar al ToolTip de modo que funcione en Web con la 9.0.
Es una forma bastante complicada la forma de resolver este problema
del ToolTip pero es una alternativa para resolver algo que en GeneXus no
funciona.
Para nosotros que trabajamos sobre la Instancia todo este Work Around
es transparente, el ToolTip sí funciona aunque a GeneXus no le funcione la
propiedad ToolTip.
Página 27 de 44
Inserción de Datos
V7
01:19:17
Para la Inserción de Datos en la 9.0 hay que tener en cuenta que si
estamos trabajando con una tupla y queremos meter un contenido de una
Variable en un Atributo y ese contenido es más largo que lo que el Atributo
soporta, entonces nos va a dar error GeneXus. Antes, hasta la 8.0 no nos daba
error, nos truncaba el valor, pero ahora nos da error.
Directamente traslada el error de la Base de Datos y no trunca
automáticamente. Decidieron que la acción de truncamiento debería se una
opción del programador de determinar como truncar este contenido que hasta
ahora se truncaba al final.
Si les pasa esto y tenían un contenido de la Variable más larga que lo
soportado por el Atributo les va a saltar un error al aplicar la sentencia.
Agregar Tabla y Clave Foránea asociada
V7
01:20:40
Se han presentado bastantes problemas con el hecho de que GeneXus
en la 9.0 hace un control mucho más estricto del tema de las Claves Foráneas
en las Reorganizaciones.
Es bastante extensa la forma y el Work Around de este SAC que les
conviene leer con atención en la figura siguiente:
Página 28 de 44
Página 29 de 44
El hecho es que si nosotros creamos una Tabla y creamos además una
Clave Foránea en otra Tabla que ya existía, obligatoriamente hay que poner el
“Allow Null” de la columna de ese Atributo en “Yes” para que genere el Nulo
realmente porque si no. para GeneXus es una pérdida de integridad.
Hay una referencia como Clave Foránea a una Tabla nueva y la Tabla
nueva, como no va a tener registros nunca va a poder apuntar a nada.
Entonces, hay bastantes controles de este tipo en las Reorg que va a
haber que tomar en cuenta y descubrimos algún Bug que se reportó en este
Incidente que ahora yo no recuerdo muy bien el detalle y es bastante
complicado ver la simbología por lo que les recomiendo leer.
Campos editables en Grids
V7
01:21:52
Este problema viene de anteriores versiones de GeneXus y la
mostramos simplemente para que se acuerden si se les presenta durante el
desarrollo.
Se presenta cuando nosotros trabajamos con Variables editables en
Grillas, en los WorkWith no nos pasa pero sí nos puede pasar muy a menudo
en los ParameterRequest, que también tiene este soporte de Grillas para pedir
algún dato o para mostrar algún dato.
Si definen Variables editables en la Grilla del ParameterRequest y van a
probar rápidamente como se ve, en general esa Variable, que la definen
editable, no está editable.
Eso es porque hasta que no pongamos un Evento que tenga un “For
Each Line” que esté haciendo una recorrida para tomar en cuenta el dato
editable de la Grilla, no va a dejar editable la Variable.
Este es un comportamiento que viene creo desde la 6.0, que siempre fue
así pero tomen en cuenta que si en un ParameterRequest ponen una Grilla con
una Variable editable y no ponen en ningún Evento de ninguna Acción, en el
Previous Code un “For Each Line”, no les va a quedar editable la Variable.
En este Incidente lo que sugerimos es que por lo menos haya un
Warning. En el Web Panel, si tenemos una Variable editable en la Grilla y
especificamos el Web Panel, debería por lo menos darnos un Warning
advirtiendo que tenemos una Variable editable pero no va a quedar editable
Página 30 de 44
porque no pusimos una Regla For Each Line, para detectar el problema en un
tiempo anterior al de ejecución.
Parámetros char y Reglas que se disparan con Ajax
V7
01:23:54
Este es otro Bug que supuestamente está resuelto en el Upgrade 3.
Si se manipulaban llamados a UDPs o Calls a Procedimientos con
Variables VarChar o Character más largas de por ejemplo 500 caracteres no
funcionaba la Regla. Supuestamente esto ya quedó resuelto y en el Upgrade 3
ya estaría funcionando.
Asignar Texto a un TextBlock mediante proc. Ajax
Página 31 de 44
V7
01:24:38
Aquí se estaba reportando que no funcionaba una Regla tipo
TextBlock.caption=udp (PProc01) if after (b) en el caso de que quisiéramos
hacer algo, mostrar algún contenido que se cargaba dinámicamente por una
UDP.
Había algún Work Around que creo consistía en grabar el contenido en
una Variable y después se le pasaba al TextBlock.caption para no hacer la
asignación directa con la UDP, entonces funcionaba.
View
V7
01:25:28
El otro tema interesante que tienen que tomar en cuenta es el del View
donde si están trabajando con un Tab y tienen una Acción que dispara un
Evento, les puede pasar que cuando cliquean la Acción no hace nada, es como
si no se ejecutara la Acción y si la debaguean y ven que esto llama a un
Procedimiento que graba algo, el Procedimiento nunca se dispara.
El problema se presenta porque el View siempre está pensado para
representar un Registro, estamos viendo un Registro padre y elementos
subordinados en los Tabs o elementos tabulares en el General del View.
Lo que no debería pasar es que cuando tenemos Tabla Base, el For
Each que programamos para instanciar ese Registro del View esté
involucrando de alguna manera a más de un Registro.
Si el Registro que está instanciando el Fixed Data del View está en las
Conditions y el parámetro que se recibe no es la totalidad de la Clave de la
tupla y se está recorriendo más de una tupla en el instanciamiento del Fixed
Data, visualmente es probable que se vea el último Registro de esas tuplas,
pero en esa lógica en el Event Load se están cargando los componentes de los
Tabs y ahí se genera un problema con GeneXus porque obviamente como se
instancian en el Event Load múltiples tuplas y en cada tupla se está haciendo la
carga del componente del Tab, se produce un error de disparo de eventos
dentro de los componentes.
No estamos hablando de los View tradicionales de los que se generan
cuando armamos la Instancia a partir de una Transacción y eso nos va a
instanciar la Clave de la tupla.
Nos referimos a los casos en que programamos una consulta y
decidimos definir un View “a mano”, o que recibe Variables e instanciamos el
“For Each” “a mano”. O se tiene Tabla Base pero en las Conditions del View
tenemos que instanciar cada una de las propiedades que nos determinan la
tupla.
Entonces es muy importante que cuando definan un View tengan en
cuenta de que siempre deben estar instanciando un solo Registro en la Tabla
que estén recorriendo.
Composer
V7
01:28:04
En el Composer pasa algo similar aunque no tiene por qué tener las
características del View. Por ejemplo, les puede pasar de que tengan un
Composer y en el Composer tienen un WorkWith y en el WorkWith tienen una
Acción también, no del tipo Link sino del tipo de Acción que dispara un Evento
de la Acción y la Acción no se les dispara.
Página 32 de 44
Es algo parecido a lo del View, pero cuando disparo el Evento de la
Acción es como que no hace nada, como que se queda en la pantalla y no
termina ejecutando nada.
Esto se debe a un Bug de GeneXus que hemos detectado y no hemos
podido todavía reproducirlo en una KB de Prueba para entregárselo a Artech a
efecto de que lo solucione. Lo que sí encontramos es un Work Around que aún
no sabemos por qué funciona, pero si les ocurre, simplemente en el
Componente anterior (un Componente más arriba del que estamos declarando)
definan un Componente y no llamen a nada.
Si definen un Componente que no llama a ningún Objeto GeneXus se
les va a solucionar el problema en la mayoría de los casos.
No pregunten porqué, pero luego de bastantes pruebas y errores hemos
detectado que teniendo un Componente vacío arriba se soluciona el problema
y la Acción se empieza a disparar.
Level1
V7
01:29:34
Recientemente nos ha ocurrido otro caso: Tenemos un Level 1 en una
Transacción, una Grilla y estamos haciendo una Regla After Attribute del primer
elemento de la Grilla, de la primera columna de la Grilla y detectamos que por
defecto si hacemos eso, dependiendo de la lógica del After Attribute y de cómo
estemos invocando, a veces, no se nos dispara el Ajax, no se dispara la Regla.
Pudimos observar que si íbamos y volvíamos del campo y volvíamos a ir
para adelante ahí sí se disparaba pero en el arranque no se disparaba.
Finalmente descubrimos que la propiedad EnhableHistory de GeneXus,
que es una propiedad que cuando estamos escribiendo en el campo Edit
habilita la sugerencia de las últimas escrituras que hicimos sobre el campo (no
confundir con el Suggest que vimos en la figura 30:12:40), esta propiedad nos
generaba problemas con las Reglas After Attribute.
Entonces, para este caso concreto se habilitó la misma propiedad
EnhableHistory en el Atributo, para poder deshabilitarla, en algún caso que
hubiera que solucionar el Bug que tiene GeneXus.
Tuvimos que agregar una propiedad para poder solucionar el problema
sacando el EnhableHistory, que es una lógica de Javascript que GeneXus
implementa con el navegador y que obviamente alguna cosa hacía que
impedía funcionar correctamente la Regla de Ajax.
Página 33 de 44
ANEXOS
ANEXO 1 – Categorización de Objetos
OBJETOS WORK WITH SENCILLOS (PATTERN WORK WITH).
En general el desarrollo de una instancia de Pattern consta de la generación de un
Work With y una Transacción en conjunto. En tal caso la estimación de tiempos de
desarrollo de este tipo de objetos se realiza en conjunto. A los efectos de la
estimación en forma separada se realizará una simple partición de los tiempos a la
mitad. Lo que caracteriza a los WorkWith Sencillos es que se trata de simples tuplas
de una Tabla, donde se muestran columnas, donde existe una Tabla Base y no hay
mayores inconvenientes.
OBJETOS WORK WITH COMPLEJOS (PATTERN WORK WITH).
Valen aquí las mismas consideraciones hechas en la tarea anterior en cuanto a que
la estimación de tiempos de desarrollo de este tipo de objetos se realiza en
conjunto. A los efectos de la estimación en forma separada se realizará una simple
partición de los tiempos a la mitad. Cuando hablamos de WorkWith Complejos, acá
lo que estamos tratando de definir es alguna complejidad adicional.
Por ejemplo, ya no hay una Tabla Base, está recorriendo Tablas Extendidas, o ya se
empieza a definir un Event Load y hay algún tema puntual que resolver que lo
transforma en un WorkWith Complejo
TRANSACCIONES SENCILLAS (PATTERN WORK WITH).
Valen aquí las mismas consideraciones hechas en la tarea anterior en cuanto a que
la estimación de tiempos de desarrollo de este tipo de objetos se realiza en
conjunto. A los efectos de la estimación en forma separada se realizará una simple
partición de los tiempos a la mitad. El desarrollo del Formulario de las
Transacciones será soportado por los propios Patterns. Podrá ser necesario ajustar
el comportamiento, lo que podría requerir modificaciones a la misma.
TRANSACCIONES COMPLEJAS (PATTERN WORK WITH).
Se consideran transacciones complejas aquellas que:
• Contengan gran cantidad de reglas (más de 20).
•
Contengan reglas con mucha actividad “Client Side Validation” (por
ejemplo: reglas after(attribute))
•
Transacciones que salten a otros objetos con interfaz gráfica (UTL
con un conjunto de Transacciones y Work Panels)
El desarrollo de los Objetos de Complejidad alta requerirían usar recursos
avanzados del Pattern como el controlador de salto programable, conditions en
acciones, soporte de subrutinas y otros, cuando no modificar directamente el
código para solucionar los problemas que se presentan en la Web.
Página 34 de 44
OBJETOS PARA CONSULTAS (PATTERN WORK WITH).
Para la estimación de Tiempo asumimos que las funcionalidades requeridas para la
generación automática de la instancia están implementadas en el Pattern. Si así no
fuera, siempre es posible reprogramar el Pattern para incorporarlas.
OBJETOS DE CARGA DE PARÁMETROS DE REPORTES O
PROCEDIMIENTOS (PATTERN PARAMETER REQUEST)
Este patrón presenta una variante con respecto al Work With ya que por lo general
son ingresos o visualización de datos tabulares sin manejo de grilla. En el caso de
que sea para ingreso de datos puede invocar o retornar a otro Objeto GeneXus (por
ejemplo objetos que instancien datos para invocar a un reporte).
Para la estimación de Tiempo asumimos que las funcionalidades requeridas para la
generación automática de la instancia están implementadas en el Pattern. Si así no
fuera, siempre es posible reprogramar el Pattern para incorporarlas.
OBJETOS REPORTES O PROCEDIMIENTOS A PDF SENCILLOS
En estos casos se asumirá que la adaptación de los reportes a PDF constará de la
inclusión de la regla output y de la definición de tipografía estándar para no afectar
el diseño original en texto.
Por otro lado se estimará la cantidad de reportes que pueden tener vectores o
arrays como parámetros lo que insumirá mayor tiempo que el resto.
OBJETOS REPORTES O PROCEDIMIENTOS A PDF COMPLEJOS
Aquí se estimará la cantidad de reportes o procedimientos con salida a pantalla que
pueden tener vectores o arrays en los parámetros los que insumirán mayor tiempo
que el resto.
Para estos casos será necesario implementar estructuras de SDT que se carguen en
los objetos invocadores de estos reportes o procedimientos y sean almacenadas en
la Web Session. Los reportes tomarán esas estructuras almacenadas y recargarán
los vectores o array para no afectar la programación.
PROCEDIMIENTOS CON INVOCACIÓN A INTERFACES
GRÁFICAS
Más allá de que GeneXus en la 9.0 soporta este efecto cuando se invoca a una sola
interfaz gráfica, no siempre en todos los casos es aplicable y existen metodologías
en los PXPatterns para resolver estos problemas (Insert Variables).
OBJETOS COMPOSER
Cuando nos encontramos objetos que contienen múltiples grillas o elementos
complejos en la pantalla sería del caso separa la estimación en cada elemento que
vaya a representar un patrón PX Composer incluyendo también el propio objeto
Componer.
Página 35 de 44
ANEXO 2 – Guía de diseño
Interfaz Gráfica de Usuario
Guía de diseño para Programadores.
Interfaz Gráfica de Usuario
OBJETIVO
Cuando una aplicación debe implementarse en plataforma Web, a los clásicos
requerimientos de la interfaz gráfica de usuario en cuanto a ser funcionalmente intuitiva se
le suman los propios de un medio que tiene sus propias reglas.
Es importante la forma como se establece el diálogo con el usuario de modo de hacerlo
fluido, ordenado y directo. Debe regularse la cantidad de información que se despliega en
pantalla de modo que su carga no sea interminable ni su navegación excesiva para ejecutar
una acción.
Las interfaces gráficas de usuario de este tipo de aplicaciones deben ayudar a éste a
utilizar las herramientas disponibles, guiándolo a través de los procesos y evitando al
mínimo los posibles errores.
Todo el diseño debe estar al servicio de su objetivo primordial: ayudar al usuario en la
operación del sistema del modo más intuitivo posible.
Por eso la preferencia por los diseños armónicos, los colores no estridentes en
combinaciones adecuadas y equilibradas.
Por eso la necesidad de tener en cuenta las interfaces a las que está acostumbrado el
usuario y tratar de emular ciertas formas de presentar las acciones que realiza (por lo
menos las más frecuentes).
Algunos puntos a tener presente para diseñar una Interfaz Gráfica de Usuario:

Estructura simple y adaptable a todos los programas.

Mayoría de colores planos, o con degradé simples fácilmente realizables con los
temas de GeneXus.

Paleta de colores basada en colores descansados, con la ayuda de contrastes
para lograr destaques en puntos importantes de la pantalla.
sistema de iconos que resalten sobre la estructura básica manteniendo el
equilibrio cromático; se leen como parte de un sistema pero conservan su
individualidad para su mejor reconocimiento por parte del usuario.
Guía de diseño para Programadores.
Página 36 de 44
2
Interfaz Gráfica de Usuario
ÍNDICE
Introducción -------------------------------------------------------------------- Pag. 3
Aspecto General de Pantallas -------------------------------------------- Pag. 4
Página Principal --------------------------------------------------------------- Pag. 5
Sectores: ubicación de elementos, colores, tipografías
.
Área de Contenidos---------------------------------------------------- Pag. 6
Lineamientos Generales---------------------------------------------- Pag. 7
Título de la Sección---------------------------------------------------- Pag. 8
Área de Datos----------------------------------------------------------- Pag. 9
Espacio de Código----------------------------------------------------- Pag. 10
Linea de Mensajes----------------------------------------------------- Pag. 10
Elementos generales
Grillas de datos-------------------------------------------------- Pag. 11-12
Botones ------------------------------------------------------------ Pag. 13
Pestañas (Tabs)------------------------------------------------- Pag. 14
Resent Link------------------------------------------------------- Pag. 15
Pop ups ------------------------------------------------------------ Pag. 16
Iconos -------------------------------------------------------------- Pag. 17
INTRODUCCIÓN
Este documento es un modelo de Guía de Interfaz Gráfica de Usuario.
Como tal, contiene las especificaciones que permiten determinar todos los
comportamientos gráficos de las pantallas de diálogo del sistema, las cuales deben ser
personalizadas para cada aplicación.
Por este motivo los valores indicados encolor rojo corresponden al diseño propuesto como
ejemplo, pero pueden ser cambiados a gusto del diseñador.
En su carácter de Guía para la programación contiene algunos elementos definidos
estrictamente y otros mediante reglas que determinan un comportamiento común pero se
adaptan a las necesidades de cada programa.
3
Guía de diseño para Programadores.
Interfaz Gráfica de Usuario
ASPECTO GENERAL DE PANTALLAS
Guía de diseño para Programadores.
Página 37 de 44
4
Interfaz Gráfica de Usuario
PAGINA PRINCIPAL
Siguiendo un diseño establecido pero que puede ser modificado hemos dividido la pantalla
en 4 sectores: Cabezal, Menú Principar, Área de Contenidos y Pie.
En particular la Barra de Menús no tiene por qué estar a la izquierda ni ser vertical.
Perfectamente puede ser horizontal y ubicarse debajo del Cabezal, por ejemplo.
Con el fin de no condicionar aquellas áreas que son de libre diseño sólo vamos a ocuparnos
en este documento del área de contenidos.
5
Guía de diseño para Programadores.
Interfaz Gráfica de Usuario
ÁREA CONTENIDOS
Se deben especificar aquí las políticas generales de diseño para esta área de la Interfaz
Gráfica de Usuario (GUI).
Es el objetivo mostrar una pantalla con la mayor cantidad de elementos que puedan ser
requeridos para resolver todas las alternativas de un programa.
Guía de diseño para Programadores.
Página 38 de 44
6
Interfaz Gráfica de Usuario
16px
4px
LINEAMIENTOS GENERALES.
Lineamientos Generales
Todos los elementos gráficos que sirvan de fondo a elementos del área de contenidos
estarán a 4px del borde del área de menús.
Todos los textos, tablas o íconos del área de contenidos se ubicarán a16px del borde del
área de menús.
Ningún elemento podrá tocar los bordes del área de contenidos.
La Fuente usada para todos los textos de la aplicación esla Verdana.
El color de fondo para el área de contenidos es:R 222 G 223 B 231
Con preferencia se usará para los textos el formato Mayúscula/Minúscula evitando en lo
posible las frases y/o palabras Todas en Mayúscula.
7
Guía de diseño para Programadores.
TÍTULO DE LA SECCIÓN O MODULO:
La primera línea se reserva para el Título de la Sección o Módulo con que se está
trabajando.
El fondo tiene una altura de 22px y ocupa todo el ancho del área de contenidos.
Formato del Título
cuando sea necesario
contar con un subtítulo
interno a los datos, se
utilizará el mismo formato
que el subtítulo general.
Altura del Fondo: 22px
Color del Fondo: R 247 G 215 B 132
Texto: Verdana Regular 14pts.
Color: R 49 G 97 B 148
Caja: Mayúscula/Minúscula
SubTítulo
Sólo para cuando la pantalla lo tiene, se reserva un espacio de22px de altura para el
SubTítulo
Formato del SubTítulo
Texto: Verdana Bold 10pts.
Color: R 49 G 97 B 148
Caja: Mayúscula/Minúscula
Espacio para íconos y/o botones
Sin Fondo. Altura 30px
Los íconos (17px x 17px c/u ) se alinean a la izquierda y los botones de texto 20px
(
de alto )
a la derecha.
Esta zona se reserva (cuando sea necesario) para íconos y/o botones que sean opciones de
la pantalla activa.
Guía de diseño para Programadores.
Página 39 de 44
8
Interfaz Gráfica de Usuario
AREA DE DATOS
Reservada para el ingreso y muestra de Datos, Grillas, Botones de acción, Tabs, etc.,
relativos al proceso que se está corriendo.
El Área de Datos ocupa el mismo lugar en todas las pantallas, pero la ubicación relativa de
los elementos que contiene depende de la información que se presente.
Todos sus elementos se alinearán siempre a la izquierda.
Para mostrar información dinámica (mensajes de error ) no se utilizará ventana pop up sino
su despliegue en la parte inferior del Área de Datos.
Para mostrar información de ayuda para el ingreso de datos a un campo (prompts), se
utilizará una ventana pop up que es llamada desde un ícono especial (para todo el sistema)
que se ubica a la derecha de dicho campo.
Los subtítulos que agrupan cierta información tendrán el mismo formato que
los subtítulos generales.
Formato de SubTítulos:
Fuente: Verdana regular para datos y bold para subtítulos.
tamaño: 8 pts. para datos y 10 para subtítulos.
Color: negro.
Caja: Mayúscula/Minúscula.
9
Guía de diseño para Programadores.
Interfaz Gráfica de Usuario
Espacio de Código y Botones
A la izquierda se escribe el código del objeto GeneXus de manera de facilitar el soporte
técnico.
A la derecha se ubican los botones de acciones.
Formato del Código del Objeto:
Fuente: Verdana regular.
Tamaño: 7 pts.
Color: R 153 G 153 B 153
HTrTPC01
Línea de Mensajes
Código y Botones
Mensajes
En la última línea se colocarán los mensajes de alerta, error e información que la aplicación
dé al usuario.
Formato de Mensajes:
Fuente: Verdana regular.
Tamaño: 9 pts.
Color: negro.
Caja: Mayúscula/Minúscula.
Guía de diseño para Programadores.
Página 40 de 44
10
Interfaz Gráfica de Usuario
ELEMENTOS
Grilla de Datos
Colores:
Fondos: fajas de 20 px. de alto blancas y R 214 G 223 B 231. Sin filetes.
Empezando con blanco.
11
Guía de diseño para Programadores.
Interfaz Gráfica de Usuario
Títulos de columnas
Fuente: Verdana bold.
Tamaño: 8 pts.
Color: blanco.
Caja: Mayúscula/Minúscula.
Color de Fondo: R 0 G 73 B 115.
Altura de Fondo: 20 px. Sin filete.
División entre las Columnas: filete de 2px. de ancho del color de fondo
(R 214 G 247 B 255).
Datos de grilla
Fuente: Verdana regular.
Tamaño: 8pts.
Color: negro.
Alineación: izquierda (excluyendo cifras que requieran alineación en puntuación o derecha).
Caja: Mayúscula/Minúscula (siempre que sea posible).
Los títulos y los datos estarán alineados y separados del borde
aproximadamente 5px.
Paginación de grilla de datos
La ubicación de la paginación se adapta a los estándares de generación de patterns de
GeneXus: arriba de la grilla a la izquierda.
Los botones serán los siguientes:
(se incluyen archivos).
Guía de diseño para Programadores.
Página 41 de 44
12
Interfaz Gráfica de Usuario
BOTONES
Espacio de Código y Botones
A la izquierda se escribe el código del objeto GeneXus de manera de facilitar el soporte
técnico.
A la derecha se ubican los botones de acciones.
Formato del Código del Objeto:
Fuente: Verdana regular.
tamaño: 7 pts.
Color: R 153 G 153 B 153
Línea de Mensajes
En la última línea se colocarán los mensajes de alerta, error e información que la aplicación
dé al usuario.
Formato de Mensajes:
Fuente: Verdana regular.
Tamaño: 9 pts.
Color: negro.
Caja: Mayúscula/Minúscula.
Botones
Se establece una serie de botones comunes a la aplicación que, en caso que aparezcan
todos, deberán mantener el orden establecido por defecto de GeneXus:
Confirmar, Eliminar, Salir, Ayuda. (Ver Gráfico).
El resto de los botones de opciones y acciones específicas de la aplicación posee las
mismas características formales y su orden debe ser establecido.
Todos los botones tienen 20 px. de altura y ancho variable según el texto interior. Se
recomienda que la diferencia entre el ancho del botón y el del texto esté entre 24 y 40 px.
en total (12 y 20 px. de cada lado). Los textos
largos tendrán menos “botón sobrante” que los textos cortos.
Se deberá dejar un espacio entre botón y botón equivalente a 8 a 10 px. aproximadamente.
El texto del interior tendrá, en todos los casos, el siguiente formato:
Fuente: Verdana bold.
Tamaño: 9 pts.
Color: R 49 G 48 B 41.
Alineación: centrada.
Caja: Mayúscula/Minúscula.
La serie de botones comunes se entregan como imágenes con texto incluido. Para el resto
de los botones se contará con tres archivos que forman el fondo (dos extre
mos y un medio)
y las especificaciones vistas del formato de texto.
13
Guía de diseño para Programadores.
Interfaz Gráfica de Usuario
PESTAÑAS (TABS)
Pestañas (Tabs en Patterns)
El texto interior de los Tabs tendrá, en todos los casos, el siguiente formato:
Fuente: Verdana bold.
Tamaño: 9 pts.
Color: R 107 G 105 B 107.
Color Activada: R 49 G 48 B 41.
Alineación: centrada.
Caja: Mayúscula/Minúscula.
Para los Tabs se contará con diez archivos con las partes necesarias para formar el fondo
y las especificaciones vistas del formato de texto.
El fondo de la zona activa será del mismo color que la parte inferior del Tab seleccionado:
R 239 G 239 B 239.
Guía de diseño para Programadores.
Página 42 de 44
14
Interfaz Gráfica de Usuario
Recent Link
Link a pattern padre:
debajo del título y a la derecha
(dentro del pattern).
Fuente: Verdana bold.
Tamaño: 8 pts.
Color: R 49 G 97 B 148.
Caja: Mayúscula/Minúscula.
Paginación e Íconos de la Grilla
Los botones de paginación se ubicarán a la
izquierda y los iconos referentes a la
pestaña seleccionada a la derecha.
15
Guía de diseño para Programadores.
Interfaz Gráfica de Usuario
POP UPS.
El color de fondo de las pop ups es:
R 231 G 231 B 231.
Las especificaciones de texto son las mismas ya detalladas para pantallas normales.
Guía de diseño para Programadores.
Página 43 de 44
16
Interfaz Gráfica de Usuario
ICONOS
Presentamos aquí los iconos generales de la aplicación y los iconos específicos
de las pantalla que son comunes a todas las aplicaciones.
Iconos Comunes 17x17 px
Subir Archivo a Servidor
ORDEN PREESTABLECIDO
Ver Archivo Subido
Escanear
Exportar Hoja de Calculo
Exportar a Editor de Texto
Imprimir
Graficar
ICONOS COMPLEMENTARIOS
Aplicar Filtros / Actualizar Datos
A la derecha del Ultimo Filtro
Buscar
Agregar Nuevo en Grilla
Arriba de la Grilla a la Derecha
ICONOS GRILLAS 17x17 px
Editar
Guía de diseño para Programadores.
Primer Lugar de la Grilla
Eliminar
Segundo Lugar de la Grilla
Copiar
Tercer Lugar de la Grilla
17
P untoE xe Consultores
www.puntoexe.com.uy
409-29-76 / 401-76-64
Juan D. Jackson 1286
Montevideo - Uruguay
Página 44 de 44