Estándar de Programación

ESTÁNDAR DE

DESARROLLO

VERSION 1.0

Agosto 2001

Estándar de desarrollo

ÍNDICE

TABLA DE FIGURAS.....................................................................................................2

Revisiones..........................................................................................................................4

Entorno de desarrollo.......................................................................................................6

Procedimiento de desarrollo.............................................................................................8

Interfaces de usuario (pantallas)...................................................................................11

Interfaces de usuario (informes)....................................................................................20

Normas de desarrollo......................................................................................................23

Sangrado..................................................................................................................................23

Mayúsculas/Minúsculas.........................................................................................................23

SQL & PL/SQL. Reglas básicas en la programación..........................................................24

Alias..........................................................................................................................................26

Comentarios............................................................................................................................27

Optimización...........................................................................................................................28Reglas generales sobre índices:...........................................................................................................28Combinaciones.....................................................................................................................................33Optimización Or..................................................................................................................................35Operador In..........................................................................................................................................36Operador Exists....................................................................................................................................36

Nomenclatura de objetos en PL/SQL...................................................................................37

Declaraciones...........................................................................................................................38

Nomenclatura de objetos de Forms & Reports....................................................................38

Cuaderno de pruebas......................................................................................................39

TABLA DE FIGURAS

Figura 1. Definición de etiquetas.................................................................................................................11Figura 2. Título de la ventana forms mdi.....................................................................................................12Figura 3. Título de una ventana de un módulo de la aplicación..................................................................12Figura 4. Título de una ventana de un módulo de la aplicación maximizada..............................................12Figura 5. Cabecera de la aplicación.............................................................................................................13Figura 6. Barra de herramientas...................................................................................................................14Figura 7. Campos no accesibles...................................................................................................................15Figura 8. Radio Groups................................................................................................................................16Figura 9. Check Box y Buttons....................................................................................................................16Figura 10. Bloque multiregistro con datos no continuos.............................................................................17Figura 11. Bloque multiregistro con datos continuos..................................................................................17Figura 12. Canvas stacked view..................................................................................................................18Figura 13. Canvas Tab o de pestañas...........................................................................................................18Figura 14. Lista de valores...........................................................................................................................19Figura 15. Hoja de cabecera de un informe.................................................................................................20Figura 16. Cabecera de un informe con parámetros en todas las páginas...................................................21Figura 17. Pie de un informe en todas las páginas.......................................................................................21Figura 18. Cabecera de un listado con logotipo...........................................................................................22

Página 2 de 39


Página 3 de 39


Revisiones

Usuario Fecha de revisión Motivo Versión

Pendiente de incluir:

1. Maximizar, minimizar y trabajar con ventanas.2. Formato estándar para campos tipo fecha y numéricos.3. Navegación por defecto y validaciones.4. Estándar respecto a las transacciones (una transacción única).5. Pasos en la instalación de una máquina cliente.6. Procedimiento de recepción de aplicaciones y puesta en explotación.7. En la creación de tablas temporales se crea una columna denominada ‘Terminal’

varchar2 de 30 pos. En la cual se guarda el nombre del equipo y el proceso que realice la grabación en dicha tabla. Ejemplo

Nombre del equipo: PROCESOProceso ………….: V21316

c.Terminal: PROCESOV21316

Antes de insertar registros en una tabla temporal se procede a eliminar los registros existentes que correspondan al equipo y proceso que vayamos a lanzar (por si existen registros de ejecuciones anteriores). Antes de salir de la forma (y después de tratar los registros) se realiza borrado de lo registros creados.

El nombre de una tabla temporal debe construirse terminando con el sufijo TEMP, de la siguiente forma Nombretabla_TEMP.

8. Nomenclatura de los objetos tablas, indices, sinónimos ...Las tablas temporales deben tener su propia nomenclatura.

9. Definir a raiz de los últimos cambios estructura de trabajo, localización de los trabajos realizados por empresas externas, pasos a seguir para la implantación de los mismos.

10. En la ejecución de los módulos debe introducirse la grabación de los datos al final del módulo no se deber realizar un commit en medio de transacciones debe realizarse después de realizarse la transacción, limpiar el form y se sigue la entrada de datos.

11. En el mismo nivel de PFP de Astican-netfi1 se crea directorio Pf_astigrup. Corresponde a los módulos de la plataforma para empresas del grupo. Cuando se compile un módulo para Astican de la plataforma económico financiera después de realizar modificaciones en este se debe compilar también para la BD. De Astander y de Astigrup(130.130.0.2).

12.

Página 4 de 39


Objetivos.

El objetivo de este documento es generar un estándar visual y de programación, así como establecer un plan genérico de pruebas. De esta forma, este documento podrá ser utilizado por cualquier analista/programador, como el documento base para desarrollar cualquier módulo en el sistema de información de Arehucas.

En términos generales y a modo de resumen, el documento define los siguientes puntos:

aspecto visual definitivo de las pantallas de la aplicación y de los informes.

definición de la nomenclatura de los objetos a crear en las pantallas e informes.

descripción de las pruebas genéricas a realizar en todos los módulos que se generen, independientemente de las pruebas específicas de cada módulo.

Página 5 de 39


Entorno de desarrollo

El entorno de desarrollo se define de la siguiente forma:

Todas las aplicaciones se encuentran en un Sistema de archivos distribuido (DFS) soportado por Windows 2003 Server , en la raiz “\\dasa\informatica”, carpeta desarrollo\proyectos\ .

La estructura de directorios de desarrollo será la siguiente:

Directorio FunciónProyectos Contiene las aplicaciones desarrolladas por la empresa

Aplicación 1 Aplicación de …

Listados Listados desarrollados en Report 3.0Pantallas Pantallas desarrolladas en Forms 6.0SQL Código Sql de la aplicación

Iconos Contiene todos los iconos de las aplicacionesResto de aplicaciones

Estructura igual que la existente en aplicación 1Genérico Contiene los ficheros necesarios para el correcto funcionamiento

de las aplicaciones (*.dll, *.res, etc.)Librerías Contiene todos los fuentes de las librerías usadas en las

aplicacionesMenus Contiene todos los fuentes de menús usados en las aplicacionesPlantillas Contiene todas las plantillas que se usarán como base en el

desarrollo de los módulos.Envios Directorio donde se realizan las entregas de módulos finalizados

por el proveedorTraspaso Contiene módulos desarrollados en Forms 6.0 pendientes de

pasar a explotación

Página 6 de 39


Procedimiento de desarrollo

A continuación se describen los pasos a realizar para el desarrollo y puesta en explotación de los módulos. Estos pasos afectarán tanto a los módulos migrados como a cualquier módulo nuevo desarrollado.

Desarrollo de aplicaciones

Cada programador desarrollará en su entorno local, variando la variable del regedit FORMS60_PATH y REPORTS60_PATH.

En estas variables, como primer elemento deberá aparecer el directorio local de programación de cada uno. El resto de elementos serán los directorios de desarrollo de las aplicaciones:

Directorio_local\\dasa\informatica\desarrollo\proyectos\aplicacion\\\dasa\informatica\desarrollo\proyectos\aplicacion\binarios \\dasa\informatica\desarrollo\proyectos\aplicacion \librerias \\dasa\informatica\desarrollo\proyectos\aplicacion \plantillas

El regedit no admite el path con el formato \\nombre_equipo, con lo que utilizaremos una unidad compartida. Cada programador podrá definir la suya, aunque se ancoseja que sea la unidad .

El acceso directo de la herramienta de desarrollo, así como del runtime de desarrollo deberá iniciarse en el directorio de desarrollo local (campo Iniciar en del acceso directo).

Se utilizará una conexión a una base de datos de desarrollo que se definirá para cada aplicación.

Envío de fuentes

El jefe del proyecto enviará los fuentes a modificar junto con un documento con la descripción de los cambios a realizar

Recepción de las aplicaciones

Cuando el proveedor termina con la migración de los módulos, nos entrega un documento con la relación de los módulos migrados, así como una breve descripción de las posibles incidencias encontradas.

Los módulos migrados serán puestos por parte del proveedor en el directorio del servidor de desarrollo \\Nombre_equipo\envios. Una vez recibidos los módulos, se copiarán todos en el directorio de traspaso (\\Nombre_equipo\traspaso, para realizar la compilación. En este directorio se encuentran siempre los ficheros de plantillas (Plantilla*.fmb), así como las librerías (*.pll), para que no se produzcan errores de compilación.

De igual forma, en este directorio existen dos ficheros, genera.bat y genera60.bat, que nos permiten realizar compilaciones masivas. Para compilar todos los módulos residentes en traspaso, basta con ejecutar el fichero genera60.bat. Los ficheros tipos menú, debemos compilarlos manualmente Si no se produce ningún error, procedemos a la recolocación de todos los módulos:

1. Desde el directorio de Envíos:

Los ficheros *.fmb (pantallas) se copiarán en el directorio pantallas de la aplicación migrada, tanto en el servidor de desarrollo como en el de explotación. Ej.:

Página 7 de 39


\\Nombre_equipo_desarrollo\Aplicaciones\nombre_aplicacion\pantallas \\Nombre_equipo_explotacion\Aplicaciones\nombre_aplicacion\pantallas

Los ficheros *.rdf (pantallas) se copiarán en el directorio listados y en binarios de la aplicación migrada, tanto en el servidor de desarrollo como en el de explotación. Ej.:

\\Nombre_equipo_desarrollo\Aplicaciones\nombre_aplicacion\listados\\Nombre_equipo_explotacion\Aplicaciones\nombre_aplicacion\listados\\Nombre_equipo_explotacion\Aplicaciones\binarios

Las librerías *.pll pasarán al directorio de librerías y a binarios. Ej.:

\\Nombre_equipo_desarrollo\Aplicaciones\librerias\\Nombre_equipo_explotacion\Aplicaciones\librerias\\Nombre_equipo_explotacion\Aplicaciones\binarios

Menús.

\\Nombre_equipo_desarrollo\Aplicaciones\Menus\\Nombre_equipo_explotacion\Aplicaciones\Menus

2. Desde el directorio de traspaso.

Los ficheros *.fmx y *.mmx pasarán al directorio \\nombre_equipo_explotacion\aplicaciones\binarios, salvo los ficheros *.fmx de las plantillas.

Si se produce algún error, se documenta en el fichero de documentación de entrega y se devuelve el módulo, sin copiarlo en ningún sitio.

Una vez esté todo colocado en su sitio, eliminamos los ficheros del directorio de envíos (\\nombre_equipo_desarrollo\envios) y limpiamos el directorio de traspaso (\\nombre_equipo_desarrollo\traspaso), eliminando los *.fmx, *.mmx, *.rdf y todos los *.fmb salvo las plantillas. Al final, en este directorio sólo deben quedar los fuentes de las plantillas y las librerías.

Página 8 de 39


Interfaces de usuario (pantallas)

Puntos a tener en cuenta para la estandarización de la interfaces de pantallas de usuario.

1. Entorno de implantación para el que se va a desarrollar la aplicación:

Cliente/Servidor, orientando la programación al entorno de internet.

2. Resolución y altura de los campos.

Todas las pantallas tendrán una resolución de 800 x 600 pixeles (puntos). La altura de los campos será de 14 puntos.

3. Tipo de letra y tamaño. Presentación de los campos.

La fuente y el tamaño de los campos y etiquetas de formularios será Ms Sans Serif de 8 puntos y aspecto normal. Todas las etiquetas estarán alineadas con sus campos respectivos al principio, tanto si se definen en la parte superior del campo como a la izquierda del campo. En los campos de tipo importe la etiqueta se alineará a la derecha por defecto. Si existe solapamiento con el campo siguiente, la alineación se realizará donde origine menor confusión (siempre según el diseño del módulo). Todos los campos tendrán aspecto lowered, salvo los campos informativos ( ver Figura 7. Campos no accesibles) o que se especifique lo contrario en el diseño del módulo.

4. Color y tipo de letra del registro activo.

El tipo de letra y tamaño no cambiará para el registro activo, por lo que mantenemos la Ms Sans Serif de 8 puntos y aspecto normal. El color de fondo será r88g100b100, y el color de la letra del registro activo será darkblue.

Página 9 de 39

Figura 1. Definición de etiquetas

Etiquetas a la izquierda del campo

Eti

quet

as e

ncim

a de

l cam

po

Eti

quet

a de

cam

po im

port

e al

inea

da a

la d

erec

ha


5. Color y tipo de letra del registro no activo.

El tipo de letra y tamaño no cambiará para el registro no activo, por lo que mantenemos la Ms Sans Serif de 8 puntos y aspecto normal. El color de fondo será blanco, y el color de la letra del registro activo será negro.

Todas estas características referentes a los puntos 4 y 5 quedarán almacenadas en varios visual atributtes que pertenecen a la plantilla y que se utilizarán como elementos referenciados.

6. Título de la ventana principal.

La ventana principal de la aplicación, FORMS_MDI_WINDOW, llevará como título el nombre de la empresa, obteniéndolo en función de la empresa seleccionada.

Esta ventana siempre se iniciará de forma maximizada.

7. Título del resto de ventanas.

El título del resto de ventanas se compondrá con los siguientes términos:

Módulo nombre_del_módulo. Título_opción_menú. Opción nº_opción_menú.Módulo FAC0030. Consulta Conceptos Facturas. Opción 18030202

Si la ventana interior aparece maximizada, el título queda de la siguiente forma:

La obtención de la información para crear los títulos de las ventanas se realizará dinámicamente, y el código necesario estará almacenado en librerías PL/SQL.

Página 10 de 39

Figura 2. Título de la ventana forms mdi

Figura 3. Título de una ventana de un módulo de la aplicaciónFigura 4. Título de una ventana de un módulo de la aplicación maximizada.


8. Definición de la cabecera de la aplicación.

La cabecera muestra en la parte izquierda el logotipo de la aplicación, que variará según la empresa en la que estemos trabajando. El nombre del fichero de logo de la empresa viene determinado por el anagrama de la empresa seleccionada; tomando en la pantalla inicial de acceso a la aplicación el anagrama de la empresa ‘02’ por defecto. En el resto de las pantallas el logo se cargará de forma automática según la empresa seleccionada.

En la parte central de la cabecera se muestra la aplicación a la que pertenece el módulo, y debajo se mostrará el título de la opción de menú seleccionada.

En la parte derecha de la pantalla se mostrará la fecha actual, el nombre del usuario que está ejecutando la aplicación y la moneda en la que se está trabajando. Todos estos campos deberán estar alineados a la derecha.

Los campos definidos en la cabecera no tendrán bordes ni efectos 3D. El color del fondo de toda la cabecera y de los campos definidos en ella será el mismo que tiene el canvas por defecto (gris).

La cabecera irá encuadrada en un rectángulo con la definición del borde hundido.

9. Menú de las pantallas

El menú de las pantallas afecta a todas las pantallas de la aplicación, y estará formado por los siguientes elementos:

Acción Editar Consultar Campo AyudaImprimir Pantalla Cortar CTRL + X Entrar Consulta Campo Anterior TeclasEspecificar Impresora Copiar CTRL + C Ejecutar Consulta Campo Siguiente Visualizar Error

Pegar CTRL + V Cancelar Consulta LimpiarSalir de la Pantalla

Editar DuplicarLista de Valores

Página 11 de 39

Figura 5. Cabecera de la aplicación.


10. La barra de herramienta estándar se incorporará a todas las ventanas que proceda, y será como la mostrada en la Figura 6. Barra de herramientas. Algunos botones de la barra de herramientas aparecerán deshabilitados en algunas pantallas, inhibiendo de esta forma su función. Todos los botones irán encuadrados en un rectángulo con la propiedad bevel a lowered y con color de fondo darkgray. Esta barra de herramientas estará definida en una plantilla y se incorporará a los módulos como referencia.

Si algún icono no está incluido en la barra de herramientas estándar, se utilizará el que define Oracle por defecto. El icono de cambio de euros a Ptas. mostrará las siguientes imágenes según la moneda que tengamos seleccionada:

Estamos en pesetas y queremos pasar a euros

Estamos en euros y queremos pasar a pesetas

Además de cambiar el icono, cambiaremos el hint y el tooltip, mostrando un mensaje como “Cambiar de euros a pesetas” o “Cambiar de pesetas a euros”.

Esta funcionalidad estará almacenada en código PL/SQL en librerías.

Página 12 de 39

Figura 6. Barra de herramientas


11. Campos no accesibles

Los campos no insertables, ni actualizables, ni accesibles, así como los campos que muestran totales, estarán deshabilitados, por lo que la letra que ya viene por defecto será gris. Tendrán la misma apariencia que los campos normales bevel lowered. Algunos campos que son únicamente informativos aparecerán como display items, con el fondo de color exactamente igual al canvas (gris por defecto) y sin aspecto en tres dimensiones, según se decida en el diseño del módulo.

12. Campos que totalizan

Los campos que muestran totales irán separados de los operandos por una línea con la propiedad bevel hundida (ver Figura 7. Campos no accesibles).

13. Bloques de información

Cada bloque de información estará incluido en un rectángulo con la propiedad bevel con valor ‘Inset’, y mostrarán la etiqueta con la definición del bloque en la esquina superior izquierda. De igual forma, si existen datos que se deban agrupar por relación en la información de los campos (y según la definición de cada diseño en particular), estos aparecerán encuadrados en rectángulos rectángulo con la propiedad bevel con valor ‘Inset’ y con la etiqueta (según diseño) en la esquina superior izquierda.

Página 13 de 39

Figura 7. Campos no accesiblesCampos informativos

Campos no accesibles

Línea de separación de totales


Página 14 de 39

Asp

ecto

del

rec

táng

ulo

inse

t

Etiqueta en la esquina superior izquierda Grupo de campos relacionados con rectángulo inset


14. Definición de Radio Buttons, check box o buttons.

Radio Groups. Se mostrarán etiquetas que identifiquen el valor del campo asociadas directamente al campo, no como texto independiente. Si las etiquetas no son suficientemente descriptivas, se añadirá una etiqueta común para todos los radio buttons del radio group. Mantendrá la configuración de fuente y tamaño de letra como el resto de campos (Ms Sans Serif 8). Como atributos de registro actual no utilizará el mismo que el bloque al que pertenece, ya que la etiqueta aparecería con el fondo azul. Llevará asociado un atributo visual exactamente igual para el registro activo y el no activo, con el fondo gris

igual que el canvas y la letra de color negro.

Check Box. Se mostrarán etiquetas que identifiquen el valor del campo asociadas directamente al campo, no como texto independiente. Mantendrá la configuración de fuente y tamaño de letra como el resto de campos (Ms Sans Serif 8). Como atributos de registro actual no utilizará el mismo que el bloque al que pertenece, ya que la etiqueta aparecería con el fondo azul. Llevará asociado un atributo visual exactamente igual para el registro seleccionado y el no seleccionado, con el fondo gris igual que el canvas y la letra de color negro.

Buttons. El botón podrá mostrar una etiqueta descriptiva con su funcionalidad o un icono

que sea completamente intuitivo (al estilo de los botones de la barra de herramientas), según se decida en el diseño en cada caso (ver Figura 9. Check Box y Buttons).

Página 15 de 39

Figura 8. Radio Groups

Figura 9. Check Box y Buttons

Radio buttons

Check BoxButtons


15. Bloques multiregistro.

Los bloques multiregistro se construirán encerrados en un rectángulo de aspecto Inset como el resto de bloques monoregistro. Todos incorporarán una barra de desplazamiento a la derecha de anchura 12 puntos. Según sea la tipología de la información a mostrar, la visualización de los registros podría variar.

Si la información mostrada se corresponde con un conjunto de datos continuos, los campos deben tener aspecto normal (no lowered) y con una separación de 1 punto.

Si por el contrario, la información mostrada en cada registro no es continua entre sí, los campos deben tener el aspecto lowered y con una separación de 0 puntos.

Página 16 de 39

Figura 10. Bloque multiregistro con datos no continuos

Figura 11. Bloque multiregistro con datos continuos


16. Múltiples datos.

En el caso de querer mostrar múltiple información que no es completamente visible en una única pantalla, se podrán adoptar dos soluciones según se decida en el diseño del módulo.

Si la información a mostrar pertenece a un único bloque (una única tabla), se utilizarán canvas stacked, con barra de desplazamiento horizontal y una vista sobre el canvas adaptada a las necesidades del diseño.

Si la información a mostrar pertenece a varios bloques, utilizaremos pestañas para incluir toda la información. Cada pestaña estará identificada con una etiqueta descriptiva, y mantendrá el mismo formato que el canvas content o el stacked, en cuanto al color, fuente y tamaño de letra.

17. Campos tipo lista.

Página 17 de 39

Figura 12. Canvas stacked view

Figura 13. Canvas Tab o de pestañas.

Canvas Stacked View con una porción visible


Los campos que sean de tipo lista y que no lleven valores fijos asociados, se cargarán en tiempo de ejecución a partir de la tabla CG_REF_CODES, en caso de estar definidos en dicha tabla.

18. Listas de valores

Las listas de valores asociadas a campos se mostrarán siempre al lado del campo que contiene la lista, poniendo la propiedad ‘Automatic Position’ a ‘Yes’. Si el número de registros a mostrar es demasiado grande, se ejecutará la lista de valores con un filtro previo, poniendo la propiedad Filter Before Display’ a ‘Yes’. El atributo visual de una lista de valores debe incluir la letra Ms Sans Serif de tamaño 8 y el fondo gris igual que el canvas. La altura quedará establecida en 200 puntos y la anchura dependerá de los datos a mostrar. Todas las listas de valores llevarán títulos descriptivos asociados.

Página 18 de 39

Figura 14. Lista de valores


Interfaces de usuario (informes)

Puntos a tener en cuenta para la estandarización de la interfaces de informes de usuario. Estas reglas serán tomadas como base, prevaleciendo siempre cualquier especificación particular en el documento de diseño de cada listado.

En función del número de parámetros de un listado disponemos de dos tipos de diseño:

Si el nº de parámetros es excesivo, de forma que en la cabecera de todas las hojas del listado ocupa mucho espacio, crearemos una página inicial con la información de todos los parámetros, y en las cabeceras de las restantes hojas, mostraremos únicamente los parámetros más importantes.

Si el nº de parámetros del listado no es excesivo, no se incluirá una página inicial. Todos los parámetros aparecerán en la cabecera de las hojas del listado.

1. Los listados que incluyan página de cabecera contendrán la siguiente información:

Anagrama de la empresa. Se pasa como parámetro. Nombre del report. Si es posible se recuperará de forma dinámica en la ejecución del

listado, utilizando código PL/SQL. En caso contrario, se pasará como parámetro.

Estos dos campos estarán en la parte izquierda de la hoja y alineados a la izquierda.

Fecha. Fecha actual con formato DD/MM/YYYY HH24:MI Numeración de las páginas. Página actual de total_páginas.

Estos dos campos estarán en la parte derecha de la hoja y alineados a la derecha.

Moneda. Encima del título del listado aparecerá la moneda seleccionada. Título del listado. El título del listado podrá ser un texto fijo, valores pasados como

parámetros, o una combinación de ambos. Aparecerá centrado en la página de cabecera.

Estos seis campos aparecerán en todas las hojas del listado.

Usuario. Nombre de usuario que ejecuta el listado (se pasa como parámetro). Parámetros. Parámetros que se le pasan al listado para su ejecución.

Página 19 de 39

Figura 15. Hoja de cabecera de un informe


2. Los listados sin página de cabecera llevará los parámetros en la cabecera de todas las hojas del listado. Siempre se pondrán los parámetros en la cabecera según se defina en el diseño de cada módulo.

3. Excepto en la página de cabecera, todas las hojas incluirán en el pie el texto “Servicio de Informática”. Este texto estará definido en el margen de los listados.

Página 20 de 39

Figura 16. Cabecera de un informe con parámetros en todas las páginas

Figura 17. Pie de un informe en todas las páginas.


4. En determinados casos, se incluirá el logotipo de la aplicación en el listado, utilizando como base el logotipo obtenido a partir del anagrama de la empresa seleccionada. La aparición del logotipo en el listado se hará dinámicamente, utilizando código PL/SQL.

Página 21 de 39

Figura 18. Cabecera de un listado con logotipo


Normas de desarrollo

En este apartado se detallan una serie de reglas para que la generación de código PL/SQL sea legible, modular y optimizado.

Sangrado

La programación de triggers, procedimientos, funciones o paquetes en Forms 6.0 utilizará el sangrado de TRES espacios utilizando el tabulador para introducirlos. Para ello es necesario modificar o incluir en el registro de Windows la siguiente cadena:

HKEY_LOCAL_MACHINE/SOFTWARE/ORACLE/DE_PREFS_TABSIZE = 3.

Las cláusulas FROM, GROUP BY, ORDER BY, HAVING, etc. deberán estar sangradas a la misma altura que la instrucción SELECT (o cualquier otra instrucción DML/DDL).

Una subconsulta dentro de una consulta se regirá por las mismas reglas que las instrucciones DDL, manteniendo el sangrado como si de una consulta principal se tratara.

Mayúsculas/Minúsculas

Todas las palabras clave se escriben en mayúsculas.Todos los elementos definidos por el usuario se escriben en minúsculas.

Ejemplo:

DECLARE v_numero NUMBER(8);BEGIN SELECT * FROM nombre_de_tabla WHERE empresa = 1;EXCEPTION WHEN NO_DATA_FOUND THEN V_numero := 0;END;

Longitud máxima de línea de 80 caracteres

Para facilitar el cumplimiento de esta norma se utiliza una ventana predefinida con esta longitud.

Una cosa en cada línea

Cualquier sentencia de manipulación o definición de datos empezará en una nueva línea, manteniendo el sangrado correspondiente

Página 22 de 39


Todos los nombres de tablas irán precedidos por el nombre del propietario.

Comentarios

Comentar las sentencias SQL siempre que sea posible, y en caso de excesiva complejidad. Si un comentario ocupa una única línea, utilizar ‘—‘; si por el contrario, va a ocupar más de una línea, utilizar ‘/*’ y ‘*/’ para delimitar el inicio y fin del comentario.

Poner los comentarios en líneas nuevas, a no ser que sean aclaratorios de determinadas instrucciones (partes de un select, etc.) y quepan en una única línea, en cuyo caso irán a la derecha de la codificación con la marca ‘—‘.

Si utilizamos comentarios o mensajes para depurar el programa, eliminarlos una vez se finalice la comprobación.

Los comentarios que ocupen más de una línea irán encima del código comentado, y alineados con la instrucción comentada.

Página 23 de 39


SQL & PL/SQL. Reglas básicas en la programación.

Comentarios en triggers

En la cabecera del trigger creado se debe incluir una breve descripción de la funcionalidad del programa

/* Descripción del trigger */

Funciones, procedimientos y paquetes)

Cualquier función, procedimiento o paquete incluirá una pequeña cabecera con los siguientes datos:

/* Descripción: Descripción del programa Parámetros de entrada: Relación de parámetros de entrada Parametros de salida: Relación de parámetros de salida Programador: Nombre del programador Fecha de creación: Fecha

ModificacionesProgramador Fecha Observaciones*/

Comentarios en el módulo

Cada módulo tendrá el siguiente comentario en la propiedad ‘Comments’:

/* Nombre: Nombre del módulo Descripción: Descripción del módulo Parámetros de entrada: Relación de parámetros de entrada Parametros de salida: Relación de parámetros de salida Programador: Nombre del programador Fecha de creación: Fecha*/

Optimización

Página 24 de 39


Las siguientes reglas se definen como base para intentar optimizar las consultas. De cualquier forma, si es posible, usar herramientas de depuración para mejorar el tiempo de respuesta de las consultas.

Evitar el uso de la cláusula NOT siempre que sea posible. Es preferible utilizar la cláusula IN que la cláusula OR. Evitar las condiciones complejas. Intentar reducirlas a condiciones simples con operadores

lógicos. Evitar el uso de la cláusula between. Sustituir esta cláusula por dos comparaciones. En la cláusula LIKE, no poner el símbolo ‘%’ en la primera posición, ya que esto inhabilita

el índice. Limitar el uso de conversiones implícitas de datos (números a caracteres, etc.). Siempre que

se pueda, realizar la conversión explícitamente. Sustituir, si es posible, la cláusula HAVING por una cláusula WHERE. Evitar el uso de la cláusula IS NULL ó IS NOT NULL, sustituyéndolas por el uso de

funciones u operadores matemáticos. Evitar combinaciones ascendentes y descendentes en una consulta. Como regla general, empezar la cláusula FROM por las tablas que devuelvan más registros

(tablas detalle), y luego las maestras. Las condiciones de unión entre tablas detalles y maestras deberán empezar tal y como establece el orden de las tablas en la cláusula FROM, y siempre al principio de la cláusula WHERE.

Realizar las consultas usando siempre la indexación de las tablas.

Reglas generales sobre índices:

1. Un índice sobre una columna sólo se utilizará si la columna es referenciada en una cláusula WHERE.

2. No se utilizará un índice sobre una columna si la columna se modifica de cualquier forma mediante función y/o expresión.

Ejemplo:

No se usa índice.

Select apellido from empWhere sal * 12 = 312000

Sí se usa índice.

Select apellido from empWhere sal = 312000/12

3. Desactivación de la utilización de índices. Podemos usar la modificación de una columna para desactivar la utilización de índices, ya que ocasionalmente la desactivación puede mejorar el rendimiento:

Cuando la tabla contiene sólo un pequeño nº de filas.Cuando se mezclan muchos índices.Cuando el índice no es muy restrictivo.

Página 25 de 39


Es conveniente hacer un análisis completo de la tabla cuando se van a recuperar más de un 30% de las filas.

Ejemplo:

Where columna_carácter ||’ ‘ = …

Where columna_numercia + calor = …

4. Conversión del tipo de datos. La conversión del tipo de datos puede desactivar el uso de índices. Sólo se pueden comparar datos del mismo tipo, por ello los tipos de datos se convierten automáticamente si es necesario.

Tipo carácter y numérico. El tipo carácter se convierte a número (con to_number).Carácter y fecha. El tipo carácter se convierte a fecha (con to_date).Carácter y rowid. El tipo carácter se convierte a rowid (con char_to_rowid).

La conversión de datos se debe realizar explícitamente.

Ejemplo:

No usa índice.Select apellidoFrom empWhere to_char(fecha_alt,’dd/mm/yyyy’) = ‘01/01/2001’

Si usa índice.Select apellidoFrom empWhere fecha_alt = to_date(‘01/01/2001’,’dd/mm/yyyy’)

5. Operador Like. Se puede usar un índice en una cláusula Like si la columna es de tipo carácter y la cadena de comparación empieza por un carácter. En caso de que la columna no sea de tipo carácter (numérico o fecha), Oracle hace una conversión interna.

Si usa índice.Select apellidoFrom empWhere apellido like ‘S%’

No usa índice.Select apellidoFrom empWhere apellido like ‘%S%’

6. Se puede utilizar la parte conductora de u índice concatenado o bien el índice concatenado completo.

Ejemplo:

Utilizando la parte conductora Emp_no del índice concatenado emp_no, apellido, sal.Select apellido

Página 26 de 39


From empWhere emp_no = 1234

Utilizando el índice completo emp_no, apellido, sal.Select apellidoFrom empWhere emp_no = 1234 and apellido = ‘APELLIDO’ and sal = 10000000

7. Valores Null.

No hay entrada de índices si todos los valores de columna de u índice tienen un valor nulo. Los valores nulos no se almacenan en un índice de columna simple.En un índice formado por varios campos, los valores nulos se almacenan si al menos una columna en el índice tiene un valor (distinto de nulo).En un índice los valores nulos de todas las columnas se recuperan mediante un análisis completo de la tabla.

Ejemplo:No se usa índice sobre comision.

Select apellidoFrom empWhere comision is null

Se usa índice sobre sal y comision.Select apellidoFrom empWhere sal = 1000000 and comision is null

8. Operador Not.Las condiciones Not Null recuperan la mayor parte de los registros, por lo que no se usarán índices.

Ejemplo:No se usa índice sobre dept_no.

Select apellidoFrom empWhere dept_no <> 10

Se puede utilizar índice sobre dept_no ( y es más rápida que la instrucción anterior).Select apellidoFrom empWhere dept_no < 10 or dept_no > 10

9. Cláusula Order by.

Se puede utilizar un índice en una cláusula Order by si:

Las columnas en la cláusula Order by no son modificadas por funciones y/o expresiones.

Página 27 de 39


Las columnas en la cláusula Order by son la parte conductora de un índice formado por varios campos.

Al menos una de las columnas del índice está definida como Not Null. No se pueden utilizar otros índices en las cláusulas Where. No se utilizan las cláusulas Union, Minus, Intersect, Distinct o Group by. El índice está en la tabla conductora.

Si no se puede utilizar un índice para una cláusula order by, entonces se utilizará una operación de clasificación.

Ejemplo:El índice sobre dept_no puede ser utilizado por la cláusula Order by si dept_no está definido como not null.

Select apellidoFrom emporder by dept_no

El índice sobre dept_no no puede ser utilizado en la cláusula order by si existe un índice sobre sal.

Select apellidoFrom empWhere sal = 1000000order by dept_no

10. Funciones Max y Min.

Se utilizará un índice para una función max o min cuando: No hay cláusula where o order by. La consulta no es una combinación. La función max o min es la única expresión en la consulta. No se utilizan otros operadores distintos de concatenación o adición en la función max

o min. Sólo hay una única función max o min. Sólo hay una ocurrencia simple de una columna en la función max o min.

Ejemplo:Se usa el índice sobre la columna sal.

Select max(sal)From emp

Select max(sal + 10000)From emp

No se utiliza el índice sobre sal.Select max(sal)From empWhere dept_no = 10

11. Operador Distinct.

No se utilizarán índices con el operador distinct, ya que necesita una operación de clasificación (sort).

Página 28 de 39


12. Operadores Union, Minus e Intersect.

No se usarán índices con los operadores Union, Minus e Intersect, ya que necesitan dos operciones de clasificación. Cada una de las cláusulas Select se optimiza por separado

13. Operador Group by.

No se utilizarán índices con el operador Group by, ya que necesita una operación de clasificación. Utilizar una cláusula where en lugar de una condición Having siempre que sea posible.

14. Indices únicos y no únicos.

Si disponemos de dos índices sobre dos columnas, uno único y el otro no, se activará el uso del índice único. En caso de que ambos sean únicos, se utilizará el último que se haya insertado en la tabla de índices.

Si se pueden utilizar múltiples índices no únicos para igualdades, estos índices se mezclarán, teniendo en cuenta que esta mezcla no se produce si las condiciones son de igualdad y rango no limitado. En este caso, se usará el índice de igualdad. Si las condiciones son de rangos no limitados, sólo se activará uno de los índices.

En caso de disponer de índices concatenados, si podemos activar el índice con condiciones de igualdad y rango no limitado.

Ejemplo:Indices únicos y no únicos.

Create unique index iemp1 on emp(emp_no);Create index iemp2 on emp(apellido);

Select apellidofrom empWhere emp_no = 1234 and apellido = ‘APELLIDO’

Sólo se utilizará el índice sobre emp_no.

Indices únicos.Create unique index iemp1 on emp(emp_no);Create unique iemp2 on emp(apellido);


Se usará el índice insertado en el último lugar de la tabla de índices.

Mezcla de índices.Create index iemp1 on emp(emp_no);Create index iemp2 on emp(apellido);

Página 29 de 39



Los índices sobre emp_no y apellido serán mezclados.

Igualdad y rango no limitado en índices simples.Create index iemp1 on emp(emp_no);Create index iemp2 on emp(apellido);

Select apellidofrom empWhere emp_no = 1234 and apellido > ‘A’

Sólo se utilizará el índice sobre emp_no.

Rangos no limitados en índices simples.Create index iemp1 on emp(emp_no);Create index iemp2 on emp(apellido);

Select apellidofrom empWhere emp_no > 1234 and apellido > ‘A’

Se usará el índice insertado en el último lugar de la tabla de índices.

Igualdad y rangos no limitados en índices concatenados.Create index iemp1 on emp(dept_no, sal);

Select apellidofrom empWhere dept_no = 10 and sal > 10000000

Se usará el índice concatenado.

Combinaciones

Existen tres maneras de combinar tablas.

1. Combinación de análisis completo de tabla.

Las combinaciones de análisis completo de tabla se utilizan para combinaciones del tipo no indexadas de no igualdad. La tabla conductora será la última en la lista From. Por cada registro de la tabla conductora se realizará un análisis completo de la tabla no conductora.

Ejemplo:Select d.nombre, e.apellidoFrom dept d, emp e

Página 30 de 39


Where d.dept_no > e.dept_no.

2. Combinación de clasificación/mezcla.

Las combinaciones de análisis completo de tabla se utilizan para combinaciones del tipo no indexadas de igualdad. Las tablas son mezcladas y clasificadas en base a la condición de combinación. No importa cual es la tabla conductora.

Ejemplo:Select d.nombre, e.apellidoFrom dept d, emp eWhere d.dept_no = e.dept_no.

Esto se ejecuta como dos consultas separadas, mezclándose los resultados.

Select d.dept_no, d.nombrefrom dept dorder by d.dept_no.

Select e.dept_no, e.apellidofrom emp eorder by e.dept_no

3. Combinación con utilización de índice.

Si se puede utilizar un índice para una sola columna del predicado de una combinación, entonces la tabla conductora será aquella que no tiene un índice utilizable en la condición de combinación.

Ejemplo:Create index idept1 on dept(dept_no)

Select d.nombre, e.apellidoFrom dept d, emp eWhere d.dept_no = e.dept_no.

La tabla conductora será emp. Se usará el índice sobre dept_no para acceder a la tabla dept. La tabla emp será analizada completamente.

Si el predicado de una combinación no está indexado, se consideran el resto de los índices para elegir la tabla conductora.

Ejemplo:Create index iemp1 on emp(sal)

Select dept_no, dnombreFrom dept, empWhere dept_no = dept_no. and sal = 100000

Se utilizará el índice sobre Sal para combinar las tablas. Se elige como conductora aquella que tiene índice.

Página 31 de 39


Se utilizarán los índices de las tablas no conductoras para acceder a dichas tablas. Si se puede utilizar un predicado de fila simple para un predicado de no combinación, entonces la tabla conductora será la tabla con el predicado de fila simple.

Ejemplo:Create unique index idept1 on dept(dnombre)Create index iemp1 on emp(sal)

Select dnombre, apellidoFrom dept, empWhere dept_no = dept_no. and dnombre = ‘DEPARTAMENTO’ and sal = 1000000

La tabla conductora es dept. Se usará el índice sobre dnombre para acceder a la tabla dept. Se usará el índice sobre sal para acceder a la tabla emp.

Si se pueden utilizar predicados de fila simple para predicados de no combinación en más de una tabla, entonces la tabla conductora será la tabla mencionada en último lugar en la lista from.

Ejemplo:Create unique index idept1 on dept(dnombre)Create unique index iemp1 on emp(sal)

Select dnombre, apellidoFrom dept, empWhere dept_no = dept_no. and dnombre = ‘DEPARTAMENTO’ and sal = 1000000

La tabla conductora es dept. Se usará el índice única sobre sal para acceder a la tabla emp. Se usará el índice único sobre dnombre para acceder a la tabla dept.

Optimización Or

Esta optimización se utilizará si podemos usar un índice para la cláusula where en ambos lados de la condición Or. La consulta será dividida en múltiples consultas, a partir de las cuales se combinarán los resultados. Esta optimización también será usada en una tabla simple con cláusula in.

Ejemplo:Create index iemp1 on emp(dept_no)Create index iemp2 on emp(oficio)

Select apellidoFrom empWhere dept_no = 10 or oficio = ‘OFICIO’

Operador In

Ejemplo:

Página 32 de 39


Select dept_noFrom DeptWhere Dept_no in (Select dept_no From emp)

La tabla conductora para la consulta es la que aparece en la subconsulta.Esta consulta se transforma en un join, donde el acceso a la subconsulta es secuencial (clasificando los registros y eliminando duplicados), y el acceso a la consulta externa permitirá el uso de índices.Sólo conviene utilizar este operador si la consulta interna es muy selectiva.No utilizar el operador Not In.

Operador Exists

Ejemplo:

Select dept_noFrom DeptWhere exists (Select null From emp Where emp.dept_no = dept.dept_no)

La tabla conductora para la consulta es la que aparece en la consulta principal.Se ejecuta la subconsulta para cada fila de la consulta principal. En ambas consultas pueden utilizarse índices.Sólo conviene utilizar este operador si la consulta principal es muy restrictiva.No utilizar el operador Not Exists.

Página 33 de 39


Nomenclatura de objetos en PL/SQL

Como norma habitual, cualquier objeto que se vaya a utilizar en un bloque PL/SQL deberá nombrarse basándonos en las siguientes reglas.

Variables locales v_nombre_variableVariables globales Sin regla. Se antepone el prefijo global.Procedimientos p_nombre_procedimientoFunciones f_nombre_funcionPaquetes pk_nombre_paqueteExcepciones exc_nombre_excepciónTabla PL/SQL t_nombre_tablaRegistro PL/SQL r_nombre_registroConstantes cn_nombre_constanteCursores cur_nombre_cursor

Página 34 de 39


Declaraciones

Cualquier declaración de una variable que vaya a contener valores de una columna de una tabla de la base de datos, utilizará el atributo %TYPE, para independizar la variable de posibles cambios en la estructura de la base de datos. Además, debería llamarse loa más aproximado posible a la columna de la base de datos, o en su defecto, un nombre suficientemente descriptivo.

V_ob_anno_obra tutor.pr_cargo_producs.ob_anno_obra%type;

Los cursores deberán ser declarados siempre con el prefijo c_nombre_cursor, intentando poner el nombre de la tabla seleccionada, o en su defecto, un nombre significativo.

Si una variable debe ser inicializada, se hará en la sección de declaración de variables.

Nomenclatura de objetos de Forms & Reports

Los nombres de módulos (pantallas e informes) se nombrarán anteponiendo las siglas del aplicativo (2 dígitos) seguidas de una letra indicativa de su funcionalidad principal más un número secuencial de 4 digitos

Los aplicativos son:GE Módulo general de funcionamiento (Menú, cambio de empresa,

parametrizaciones generales etc)AL AlmacénCO Compras y proveedoresVE Ventas y clientesTE Cobros – pagosCB ContabilidadBD Bodega

Las letras son:M = Mantenimiento de maestros y auxiliaresG = Gestion de documentos (Albaranes, Pedidos etc)C = ConsultasI = Pantallas que generan impresiónesR = Report

EjemplosBDM0030.fmbFAC0050.fmbFAR0060.rdf

Biblioecas

Bibliotecas de uso general para todos los módulos:LIB más un número secuencial de 4 dígitos

LIB0000LIB0001.

Página 35 de 39


Bibliotecas de uso en un módulo:Siglas del módulo más un numero secuencial de 4 dígitos

VE0000VE0001.

Los nombres de los objetos de un formulario se deben basar en las siguientes reglas:

Objeto NombrePantallasAlerts al_nombre_alertaCanvases cv_nombre_canvasEditors ed_nombre_editorLovs lv_nombre_lovObject groups ob_nombre_grupo_objetosParameters p_nombre_parámetroPopups Menu pm_nombre_menúProperty Classes pc_nombre_clase_propiedadRecord Groups rg_nombre_grupo_registrosVisual Attributes va_nombre_atributo_visualWindows w_nombre_ventanaBloques b_nombre_bloque (bloque de

control blk_ctrl)Marco de pantalla Fr_nombre_de_marcoItem pantalla (no B.D) n_nombre_de_itemBotones bt_nombre_botonInformesQuerys q_Nombre_consultaSummary Columns cs_columna_sumatoriaFormula Columns cf_columna_formulaPlaceholder Column cp_columna_placeholderGrupos g_nombre_grupoCross Product g_cp_nombre_matrizFields f_nombre_campo

Nomenclatura de objetos de Base de Datos

Tablas.

Se nombran con un máximo de 15 caracteres descriptivos del contenido de la tabla. Se siguen las siguientes normas:

- Utilizar mayúsculas- No incluir en el nombre la función de la tabla, es decir si es un maestro,

histórico etc.- Utilizar el singular del objeto (articulo en vez de articulos)- No utilizar conjunciones ni preposiciones ni articulos- Abreviar las palabras de la forma mas legible y breve posible en 4 digitos

por palabra. Si se necesita abreviar más utilizar 3 ó 2 digitos

Página 36 de 39


- Separar las palabras con guión bajoEjemplos:

Maestro de artículos: ARTICULOMaestro de articulos por almacén (existencias, precios, costo etc): ALMA_ARTI Cabeceras de pedido cliente: CABE_PEDI_CLIEPartes de fabricación: CABE_PART_FABR y LINE_PART_FABR

Columnas.

Se nombran con un máximo de 10 caracteres. Siguiendo las mismas normas que las tablas y además:

- Las fechas se nombran comenzando con f_ salvo que sea suficiente con la palabra fecha

-

Constrains

Se utilizará la opción de nombre automático asignado por el sistema

Página 37 de 39


Cuaderno de pruebas

En este apartado se definen el conjunto de pruebas a realizar en los módulos desarrollados. Todas las pantallas deberán haber superado este conjunto de pruebas generales, independientemente de haber superado las pruebas específicas de cada módulo en particular.

Referente a la migración, el módulo deberá mantener la misma funcionalidad en Forms 6.0 que la disponible en la versión previa Forms 3.0. Exactamente igual en el caso de los reports.

Debe cumplir todas las especificaciones descritas en el estándar visual desarrollado anteriormente en el punto Entorno de desarrollo para el caso de las pantallas, y en el punto Interfaces de usuario (informes) para el caso de los informes.

Verificar la completa funcionalidad del ratón en las pantallas, comprobando que se realizan las validaciones necesarias en los campos dónde estén definidas, así como el no poder acceder a campos dónde no esté permitido el acceso. En los desarrollos en Forms 3.0, la navegación por los campos era secuencial, realizando determinadas funciones de validación o inicialización cuando se pasaba de un campo a otro. Todas estas funciones deben realizarse de la misma manera en forms 6.0. Cuando utilizamos el ratón para realizar la navegación entre dos campos, se deben ejecutar todas las validaciones que existen entre los campos intermedios. También se debe controlar el acceso condicionado, probando que únicamente se puede acceder a un campo en determinadas condiciones que lo habilitan.

Comprobar la correcta navegación entre campos y entre bloques, verificando todas las validaciones.

Dependiendo de la funcionalidad de la pantalla, debemos comprobar lo siguiente:

1. Inserciones. Se tiene que comprobar que las inserciones se realizan correctamente, validando los campos que pertenecen a dominios o que deben contener valores obligatorios, validando rangos si estuvieran definidos, comprobando inserciones o actualizaciones en otras tablas originadas por la inserción actual. Comprobar que no se pueden realizar inserciones en monedas distintas a la moneda base en el período en el que estamos trabajando. Si la inserción no está permitida, se debe comprobar que verdaderamente no se puede realizar.

2. Modificaciones. Se tiene que comprobar que los campos que sean modificables se puedan actualizar, y al contrario, si no son modificables, no se pueden actualizar. Verificación de obligatoriedad, dominios y rangos. Comprobación de actualizaciones, inserciones y/o borrados derivados de la modificación actual.

3. Borrado. Si un bloque de un módulo no debe permitir el borrado, se debe comprobar que efectivamente no lo permite. En caso de que sea permisible, se debe verificar que el borrado es efectivo. Si existen tablas derivadas o relacionadas con la original, y se tuvieran que borrar los registros relacionados (tanto a nivel programático, como por definición del borrado en cascada en la base de datos), se tiene que comprobar que el borrado es correcto.

4. Consultas. El módulo permite realizar consultas. Comprobar que todos los campos en los que se puede realizar una consulta son consultables, ejecutando consultas sencillas y complejas con combinaciones de campos. Comprobar la funcionalidad de conversión de

Página 38 de 39


euros a pesetas y viceversa, en las pantallas donde se permita. Realizar pruebas exhaustivas de consultas en campos numéricos o de importes.

5. Lanzamientos de listados. Comprobar que los campos que se utilizan como parámetros del listado, aceptan los valores adecuados (rangos, dominios, valores fijos), verificando las validaciones en caso de que estén definidas. Comprobar que la selección de la impresora es la adecuada para el listado en cuestión, mostrando un mensaje de error en caso de no ser la impresora adecuada, atendiendo al nº de posiciones horizontales y verticales que conforman el listado.

Comprobar todas las teclas de función que se han particularizado para los módulos, manteniendo la compatibilidad con la nueva definición del teclado en Forms 6.0.

Comprobar que todos los listados funcionan correctamente en euros y en pesetas (donde sea necesario).

Verificar que un listado puede ser convertido a fichero ASCII, manteniendo el sangrado correcto en las columnas.

Todos los listados deben poder ser enviados a fichero, incluyendo todos los tipos de fichero que proporciona la herramienta. El usuario debe ser capaz de manipular los ficheros generados.

Ejecutar el listado con todos los campos al máximo nº de caracteres (obtenido a partir de la información de las tablas o información de control), para evitar que aparezcan campos rellenos con * cuando se desbordan.

Comprobar el salto correcto de páginas en todos los listados.

Página 39 de 39

Documents

Estándar de Programación