Manuel Web

MANUAL DE ESTÁNDARES DE PROGRAMACIÓN
EN AMBIENTE WEB
(EN REVISION)
Gerencias de Sistema y Organización

División de Sistemas Automatizados
JUNIO 2012
UG - 0 0 9 A (1 4 – 1 1 – 2 0 1 1 ) POLITICA DE LA CALIDAD Y AMBIENTE: “CVG-VENALUM, con la participación de sus trabajadores y proveedores, produce, comercializa aluminio y mejora de
forma continua su sistema de gestión, comprometiéndose a: _ Garantizar los requerimientos del cliente. _ Prevenir la contaminación asociada a las emisiones
atmosféricas, efluentes líquidos y desechos. _ Cumplir la legislación y otros requisitos que suscriba la empresa, en materia de calidad y ambiente”.
INTRODUCCIÓN
El desarrollo de la Sociedad de la Información, está requiriendo día a día, más y mayores avances en las
Tecnologías de la Información y las Comunicaciones (TIC). En todo el mundo, en los últimos años, se han
estado elaborando sucesivos planes que apuestan por el uso del software libre y de los estándares abiertos,
como dos de los medios para lograr la extensión de las TIC a todos los ámbitos de la sociedad.
En nuestro país, después de la publicación del decreto N° 3.390, el 23 de diciembre de 2004, donde se ordenó
a la “Administración Pública Nacional emplear prioritariamente Software Libre desarrollado con Estándares
Abiertos, en sus sistemas, proyectos y servicios informáticos”; se puso en marcha toda una serie de acciones, a
fin de lograr en un futuro no muy lejano el logro de este objetivo.
En CVG Venalum, como empresa del estado, se han estado tomando acciones para la prosecución de ese
objetivo. De ahí la necesidad de definir los estándares de trabajo en el ambiente libre, a fin de lograr
aplicaciones cuyo mantenimiento sea más sencillo, donde en los módulos de una aplicación, los nombres de los
archivos y de las variables sigan una convención previamente acordada; páginas livianas, que ocupen menos
ancho de banda, carguen más rápido y de forma más satisfactoria independientemente del navegador;
acuerdos en el uso de tablas, campos y funciones comunes.
OBJETIVO GENERAL
Definir estándares para el desarrollo de aplicaciones, promover y establecer pautas para los nuevos desarrollos,
reducir el tiempo utilizado en el mantenimiento de las mismas y dar flexibilidad para la incorporación de
cambios.
ALCANCE
Los estándares definidos deberán ser utilizados con carácter obligatorio por los analistas de la División de
Sistemas Automatizados al momento de realizar algún desarrollo, así como por entes externos que estén en
calidad de contratación para el desarrollo de aplicaciones Web o de cualquier otra índole para beneficio de la
Organización.
CONSIDERACIONES
Estos estándares aplicarán a todos los desarrollos en CVG VENALUM de aplicaciones web basadas en PHP +
POSTGRE a partir de la fecha de publicación; excluyendo los componentes ya desarrollados que se estén
reutilizando, por ejemplo clases, librerías, o frameworks que la comunidad de Software Libre ponga a
disposición en sus repositorios. Estos últimos deberán ser evaluados por el Comité de Estándares de la División
de Sistemas Automatizados, para determinar la factibilidad de su incorporación a nuestro ambiente de trabajo.
Este documento es producto del trabajo del Comité de Estándares de la División de Sistemas Automatizados.
Cualquier cambio que produzca en él, ya sea por lineamientos externos o internos, así como por los avances e
innovaciones tecnológicas, debe ser aprobado por dicho comité.
1. SERVIDORES.
La infraestructura de servidores para el desarrollo de aplicaciones se describe a continuación:
ALUMINIOLX10: Servidor de Aplicaciones para el ambiente de desarrollo el cual tiene instalado las siguientes
herramientas: PHP (Lenguaje de Programación), apache (Servidor WEB), componentes de conexión a
diferentes bases de datos (PDO-PHP, PDO-OCI, PDO-PgSQL, TDS-SQLServer, SAPRFC librería de conexión
a SAP R/3), Se comunica con ALUMINIOLX45 (servidor de base de datos) a través del puerto 5435.
ALUMINIOLX5 y ALUMINIOLX14: Servidores de Aplicaciones para el ambiente de producción el cual tiene

instalado las siguientes herramientas PHP (Lenguaje de Programación), apache (Servidor WEB), componentes
de conexión a diferentes bases de datos (PDO-PHP, PDO-OCI, PDO-PgSQL, TDS-SQLServer, SAPRFC
librería de conexión a SAP R/3). Se comunica con ALUMINIOLX45 (servidor de base de datos) a través del
puerto 5432.
ALUMINIOLX45: Servidor de Base de Datos separado en 2 cluster, en el cual conviven actualmente las bases
de datos para Desarrollo (puerto 5435) y Calidad (puerto 5432).
Servidores de Aplicaciones
ALUMINIOLX10 ALUMINIOLX5 ALUMINIOLX14
Desarrollo Producción Producción
Servidor de Servidor de Servidor de
Aplicación Aplicación Aplicación
PDO(PHP), PDO(PHP), PDO(PHP),

PDO OCI PDO OCI PDO OCI
(Oracle), (Oracle), (Oracle),
PDO pgsql PDO pgsql PDO pgsql
y TDS y TDS y TDS
(SQLServe (SQLServe (SQLServe
r) r) r)
Puerto: 5435 Puerto: 5432
Desarrollo Producción
ALUMINIOLX45 ALUMINIOLX40
Servidor de Base de datos Servidor de Base de datos
2. LENGUAJES Y HERRAMIENTAS DE DESARROLLO.
Para el desarrollo de aplicaciones Web se emplearan los siguientes lenguajes y herramientas:
• PHP: Lenguaje del lado de servidor

• JavaScript: Lenguaje de lado del cliente
• PostgreSQL: Base de Datos
• PgAdmin: Interfaz de administración de Base de Datos
• Dreamweaver o Eclipse: Editor Web para GNU/Linux o para Windows.
• Umbrello: Editor UML
• DbVisualizer o DBDesigner Fork: Generación y/o Visualización de diagramas de Base de Datos:
• Navegador Web: Mozilla Firefox Versión 3.6+, Internet Explorer Version 7.0.5730.13+
• Complementos Mozilla Firefox: Firebug (Depurador de errores), FireFTP (Conexiones FTP)
3. CRITERIOS PARA DEFINIR EL NEMONICO DE UNA APLICACIÓN.

El “nemónico” se refiere a las siglas del sistema. Debe ser único por aplicación. Y debe cumplir con los
siguientes criterios:
• Tener un mínimo de 6 y un máximo 8 caracteres
• Todos los caracteres deben estar en minúsculas
• Los caracteres del nemónico deben ser estrictamente alfabéticos [a..z], sin la letra ñ
• El nemónico para las aplicaciones que tengan mas de 10 tablas propias, debe iniciar de la siguiente
forma:
si+[combinación de consonantes y vocales pronunciables referentes al sistema]
Ejemplo:
sisoserv (Sistema Integral de Solicitudes de Servicio)
• El nemónico para las aplicaciones que tenga 10 o menos tablas propias, debe iniciar de la siguiente
forma:
mo+[combinación de consonantes y vocales pronunciables referentes al modulo]
Ejemplo:
momecont (Modulo de Mejora Continua)
moditelf (Modulo de Directorio Telefónico)
• Cuando un modulo crezca en el tiempo y se generen mas de 10 tablas el analista debería evaluar la
posibilidad de convertir ese modulo en un sistema integral.
• El nemónico de la aplicación, debe utilizarse obligatoriamente en el nombre de los objetos de base de
datos así como en el nombre de usuario FTP y el nombre del directorio de la aplicación.
4. PAUTAS Y FUNCIONAMIENTO PARA EL DESARRROLLO.
4.1 CONEXIÓN A LA BASE DE DATOS (ALUMINIOLX45).

Para obtener acceso a este ambiente es necesario que se solicite a la División Soporte Técnico la creación
de un usuario de base de datos.
Ejemplo:
Usuario: adminsicd
Clave: venalum
Una vez obtenido usted deberá crear la conexión a la misma a través del icono de la herramienta
PgAdminIII. Luego se presentará la siguiente pantalla:
Al presionar OK, podrá visualizar la siguiente pantalla:
4.2 DEFINICIÓN DE GRUPOS

El desarrollador debe crear un grupo el cual sirve para simplificar la asignación de privilegios. Un grupo
requiere un nombre y puede ser creado vacío (sin usuarios).
4.3 DEFINICIÓN DE USUARIOS Y ROLES
El desarrollador debe crear dos usuarios con la siguiente regla:
• admin + nemónico del esquema donde se alojarán las tablas de la aplicación : Usuario dueño
de todos los objetos creados dentro del esquema de la aplicación. Con este usuario el Analista se
debe conectar a la base de datos para crear todos los objetos.
• user + nemónico del esquema donde se alojarán las tablas de la aplicación : Usuario utilizado
para la conexión desde la aplicación hacia la base de datos. Los permisos de los objetos para este
usuario serán asignados al grupo creado anteriormente.
Nota: Cabe destacar que solo deben existir dos usuarios por esquema, uno admin y uno user.
Para crear estos usuarios se realiza de la siguiente forma:
El rol se asigna en la pestaña “Role membership”:
4.4 DEFINICIÓN DE UN ESQUEMA
Para la creación de un esquema se deben contemplar los siguientes criterios:
• Datos comunes para todas las aplicaciones. Ejemplo: sch_general
• Datos exclusivos de la función de una Gerencia dentro de la empresa.
Ejemplo: sch_personal, creado para alojar los datos de la gerencia de personal
• Datos exclusivos para una aplicación: el uso de este tipo de esquema está restringido para aquellas
aplicaciones donde la cantidad de tablas es superior a 10. Que las mismas estén alojadas de manera
independiente es lo más idóneo.
Ejemplo: sch_soserv, Este esquema contiene las 54 tablas que fueron definidas para la aplicación
sisoserv.
Para crear un esquema en la base de datos de desarrollo se procede de la siguiente manera:
Al presionar OK, el esquema creado podrá visualizarse en la siguiente pantalla:
5. INFORMACIÓN DEL PROYECTO.
La información generada de la nueva aplicación debe ser almacenada en el servidor aluminiolx4, dentro de la
carpeta que se encuentra en la siguiente ruta:
Ruta:: \\aluminiolx4\Sistemas y Organizacion\docum_sa\Documentación de Sistemas y

Aplicaciones\Pasantias
Y una vez dentro de esa ruta se debe abrir la carpeta del año en curso y crear una nueva carpeta con el nombre
del Sistema o Aplicación, seguido del nombre del responsable del mismo.
Carpeta:: nombre_aplicacion + nombres y apellidos responsable
Ejemplo: Carpeta 2012
6. CONFIGURACIÓN DEL MENÚ Y USUARIOS DE UNA APLICACIÓN WEB.
6.1 CONFIGURACIÓN DEL MENU

Para la configuración del menú de una aplicación se debe realizar lo siguiente:
1. Acceder a la BD, esquema general (sch_general) y luego a las tablas de dicho esquema
2. Acceder a la tabla <<sesion_areas>>, donde deberá agregar los links que llevará el menú de la
aplicación:
2.1 Crear en la tabla <<aplicacion>> el registro del sistema o modulo a desarrollar, para ello se posiciona
en la tabla <<aplicacion>> (ver imagen del punto 1) y allí podrás visualizar la documentación de cada
campo así como su tipo de dato de tal manera de tomarlo como guía para armar el sql, finalmente ejecutas
la consulta armada para realizar la inserción.
2.2 Una vez creado el registro del sistema (2.1) se procede de la misma forma a acceder a la tabla
<<sesion_areas>>, e insertar el registro correspondiente
3. Acceder a la tabla <<sesion_perfiles>> donde deberá detallar los roles que deberá tener cada usuario
para las respectivas opciones del menú que se está creando.
4. Acceder a la tabla <<sesion_area_perfil>> donde deberá indicar cuales links u opciones del menú
creados en la tabla <<sesion_areas>>, son a los que tendrá acceso el rol previamente creado en la
tabla <<sesion_perfiles>>:
6.1 CONFIGURACIÓN DE LOS USUARIOS
Para la configuración del / los usuario(s) de una aplicación se debe realizar lo siguiente:
2. Acceder a la tabla <<sesion_usuarios>>, donde deberá buscar a los usuarios de la aplicación por su
numero de cedula y asignarles la clave del usuario. En la siguiente imagen el campo código que
identifica la cedula se define a modo de ejemplo con el valor cero y el campo clave de manera
codificada.(en caso de ser pasante en este punto debe ser guiado por su tutor)
3. Acceder a la tabla <<sesion_acceso>> e indicar el perfil (roles que fueron definidos previamente en la
tabla <<sesion_perfiles>>) que tendrán los usuarios previamente registrados en la tabla
<<sesion_usuarios>>, cuando ingresen en el contenedor de aplicaciones (ver documento que detalla
lo que define el contenedor de aplicaciones).
Nota: para este punto es importarte tomar en cuenta que para el campo cod_empresa los usuarios
venalum les corresponderá el código 1000 y el resto se tomara de la tabla de
<<empresas_contratistas>>.
7. CONFIGURACIÓN DE OPCIONES DE BUSQUEDA EN UN MÓDULO DE UNA APLICACIÓN WEB.
Para la configuración de las opciones de búsqueda de un módulo de una aplicación es necesario

primeramente crear el esquema de trabajo en la BD (ver punto referente a la creación de esquemas), luego
dentro de dicho esquema se procederá a la creación de la vista que mostrara los datos que podrán filtrarse.
Para ello se deben cumplir los siguientes pasos:
2. Acceder a la tabla <<aplicacion_filtro>>, donde deberá registrar las columnas de la vista que pueden
ser filtradas u ordenadas dependiendo de los requerimientos del usuario:
Ejemplo: En la fila siete de la siguiente imagen indica lo siguiente: para la aplicación SICODO
(cod_aplic) se utiliza la tabla/vista (tabla) vis_sicodo_documentos_organizacion de la cual se tomara el
campo fecha_aprobacion (columna) y su descripción (descripcion) en el combo u objeto utilizado de ese
modulo indicara Fecha aprobación.
Esto se debe hacer por cada vista que tenga la aplicación, en caso de que requieran filtrarse los registros.
8. DECLARACION DE OBJETOS Y USUARIOS

En esta sección se definen los estándares a seguir para nombrar los objetos de una base de datos que también
se deben aplicar en el modelado y en el diseño de un modelo relacional.
8.1 DEFINICIÓN DEL OBJETO

Para la creación de los objetos de base de datos se utilizará la siguiente nomenclatura:
Prefijo del objeto + _ + Nemónico + _ + Nombre del Objeto
Donde:
Prefijo del objeto: se refiere a la utilización de prefijos previamente definidos, los cuales son mostrados en
la siguiente tabla:
Object Objeto Prefijo

Table Tabla tbl
Procedure Procedimiento pro
View Vista vis
Schema Esquema sch
Secuencia Secuencia seq
Triggers Disparadores tri
Group Grupos Grp
Function Función fun
Job Tarea job
Type Tipos typ
Nemónico: Se refiere a las siglas del sistema. Debe ser único por aplicación y tener como mínimo 6
caracteres y como máximo 10 caracteres.
Es Importante tomar en cuenta para aquellos objetos de uso general o que puedan ser empleados por
otras aplicaciones, se debe utilizar el nemónico: gral.
Nombre Objeto: Este debe estar en minúscula, en singular y ser lo mas explícito posible. No debe ser
mayor a 40 caracteres, no contener la letra ñ ni ningún carácter especial. Si el nombre es compuesto, debe
separarse utilizando el carácter guión bajo (_).
En este sentido un objeto basados en dichas características correspondería de la siguiente forma:
Prefijo del objeto: tbl +Nemónico: sicob +Nombre del Objeto: documento_beca
Ejemplos:
tbl_sisoserv_grupo_servicio
tbl_gral_centro_gestor_organizacion
fun_gral_unidad_usuario
En caso de existir tablas unidas a través de una relación maestro-detalle, la tabla contentiva del detalle
debe finalizar con un carácter guión bajo (_) seguido de la palabra detalle.
Ejemplo:
tbl_sisoserv_grupo_servicio (MAESTRO)
tbl_sisoserv_grupo_servicio_detalle (DETALLE)
Todos los objetos de base de datos deben estar debidamente comentados. Se debe especificar: autor,
fecha de creación y hacer una breve descripción. En el caso de una tabla, todas las columnas deben estar
debidamente documentadas.
8.2 Definición del propietario del objeto

Para la definición del propietario del esquema y los objetos debe utilizarse la siguiente nomenclatura:
admin. + nemónico
Ejemplo:
Adminsisoserv
La siguiente imagen muestra dentro del explorador de BD donde debe definir el usuario propietario al crear
una tabla
8.3 DEFINICIÓN USUARIO APLICACIÓN
Para la definición del usuario de la aplicación debe utilizarse la siguiente nomenclatura
user + nemónico
Este usuario actualmente se debe definir dentro del contenedor en la carpeta bd en el archivo que lleva
por nombre funciones_bd.inc (ver punto referente a estructura de archivos)
Ejemplo:
Usersisoserv
La siguiente imagen muestra dentro del archivo funciones_bd.inc donde debe definir el usuario de la
aplicación
9. DECLARACION DE CONSTRAINTS (CLAVES PRIMARIAS, FORANEAS, CHEQUEO)
Para nombrar las relaciones entre tablas se definió la siguiente nomenclatura:
Clave Primaria: Su nombre debe cumplir con la siguiente regla:

pk + _ + Nombre de la tabla
Ejemplo:
pk_sisoserv_grupo_servicio
Clave Foránea: Su nombre debe cumplir con la siguiente regla:

fk + consecutivo (debe iniciar en 1) + _ + Nombre de la tabla
Ejemplo:
fk1_sisoserv_grupo_servicio
fk2_sisoserv_grupo_servicio
Clave de Chequeo: Su nombre debe cumplir con la siguiente regla:

ch + consecutivo (debe iniciar en 1) + _ + Nombre de la tabla
Ejemplo:
ch1_sisoserv_grupo_servicio
ch2_sisoserv_grupo_servicio
Clave Única: Su nombre debe cumplir con la siguiente regla:

uk + consecutivo (debe iniciar en 1) + _+ Nombre de la tabla
Ejemplo:
uk1_sisoserv_grupo_servicio
uk2_sisoserv_grupo_servicio
10. DECLARACION DE INDICES

Deben ser creados los índices correspondientes a las claves primarias y foráneas definidas. El nombre de los
índices debe cumplir con la siguiente regla:
Primario:
ipk. + _ + + Nombre de la tabla
Ejemplo:
ipk_gral_persona
Foráneo:
ifk + consecutivo (debe iniciar en 1) + Nombre de la tabla
Ejemplo:
ifk1_sisoserv_grupo_servicio
Adicional:
id + consecutivo (debe iniciar en 1) + Nombre de la tabla
Ejemplo:
id1_sisoserv_grupo_servicio
11. DECLARACION DE ATRIBUTOS

Para la declaración de los atributos se deben tomar en cuenta las siguientes premisas:
1. Identificar el atributo siguiendo las siguientes pautas
1.1 Emplear Letras minúsculas.
Ejemplo correcto: descripcion, Ejemplo incorrecto: DESCRIPCION
1.2 Debe estar expresada en forma singular.
Ejemplo correcto: servicio, Ejemplo incorrecto: servicios
1.3 Definirse lo más explícito posible.
Ejemplo correcto: observacion, Ejemplo incorrecto: obsrv_2
1.4 Utilizar palabras en idioma español.
Ejemplo correcto: estado, Ejemplo incorrecto: status
1.5 La longitud máxima es hasta 30 caracteres
Ejemplo correcto: manejo_acta_integral_fin
Ejemplo incorrecto: manejo_acta_integral_con_finalizacion
1.6 No emplear caracteres especiales ni la letra ñ.
Ejemplo correcto: anno, Ejemplo incorrecto: año
1.7 En caso de ser compuesto debe separarse utilizando el carácter guión bajo (_).
Ejemplo correcto: estado_servicio, Ejemplo incorrecto:estadoservicio
2. Realizar una breve descripción acerca de su uso y señalar todos los valores posibles que puede tener.
Ejemplo comentario atributo estado: estado en el que se encuentra el documento.
1:aprobado 2:rechazado 3:devuelto
3. Si un atributo es definido como un tipo de dato Consecutivo o Autonumérico debe cumplir con la
siguiente regla:nro_ + descriptivo.
Ejemplo: nro_pedido
A continuación, el listado de abreviaturas a ser utilizadas para los atributos comunes:
Atributo Abreviatura
Código cod
Teléfono tlf
Numero num
Numero Nomina nro_nomina
Descripción desc
Fecha fecha
Mínimo min
Máximo max
Inicio ini
Fin fin
Promedio prm
Porcentaje porcentaje
Programado prg
Cantidad cant
Temperatura temp
Último(a) ult
Producción prod
DataWareHouse dwh
Gerencia gcia
División div
Superintendencia suptcia
Departamento dpto
Habitación hab
Organización org
Emergencia emerg
Oficina Ofic
Año anno
12. CONEXIÓN AL SERVIDOR DE APLICACIONES WEB (ALUMINIOLX10).

Para obtener acceso a este ambiente es necesario que se solicite a la División Soporte Técnico la creación de
un usuario FTP. Debe ser nombrado con la siguiente regla:
ftp+_+ Nemónico de la Aplicación
Ejemplo:
Para la aplicación del Directorio telefónico el usuario seria: ftp_modirtlf
Una vez obtenido, el desarrollador tendrá acceso a la estructura de archivos (Servidor de Aplicaciones) a través
del complemento FireFTP ubicado en la opción Herramientas del menú principal del Mozilla Firefox.
Al presionar se mostrara la siguiente ventana:
Al introducir el usuario FTP y la clave y presionar Aceptar se muestra la siguiente pantalla:
13. ESTRUCTURA DE ARCHIVOS.
Los archivos deben estar organizados en directorios estructurados jerárquicamente de acuerdo a su
funcionalidad. Los nombres de los directorios deben ser en minúsculas, y si el nombre es compuesto debe
separarse con el carácter guión bajo (_).
La estructura de directorios del servidor Web está definida como se muestra a continuación (Cada número de la
imagen representa un nivel):
Nivel 1: Directorio donde se definen las carpetas comunes para todas las aplicaciones. Y la ubicación física es
$comun = /data1/webapp/
bd: Contiene los archivos para las conexiones a la Base de Datos, estas conexiones están en un
archivo.php, utilizando conexiones XML, la ubicación de este archivo es /bd/funciones_bd.php
clases: Se almacenan todas las clases generales que pueden ser usadas por cualquier aplicación.
css: carpeta donde se almacenan las páginas de estilo que pueden ser
usadas por cualquier aplicación.
funciones: Contiene todas las funciones PHP y los procedimientos
generales, comunes para todas las aplicaciones.
img: Contiene las imágenes, iconos, etc., que pueden ser usados por
cualquier aplicación.
js: Java Scripts generales que pueden ser utilizados por cualquier
aplicación.
libs: Librerías generales de PHP, principalmente realizadas por terceros.
Plantilla (carpeta Aplicaciones): Contiene
las plantillas que usan las aplicaciones.
Ejemplo: encabezado, pie de página,
mensaje de error.
index.php: pagina default o principal
donde se muestran todas las
aplicaciones en forma de árbol.
Nivel 2: Directorio de Aplicaciones donde se alojan las aplicaciones de acuerdo al área de la empresa donde
pertenecen.
• administración: Contiene todas las aplicaciones relacionadas con el área

administrativa, ejemplo: Sistema de la Calidad (siscal), Evaluación de
Proveedores (sievprov), Así como directorios de cada una de las
gerencias de la empresa para incluir los módulos pertenecientes a las
mismas.
• produccion: Aplicaciones relacionadas con los procesos productivos de la
empresa, ejempl: Sistema Integral de Colada (sicolada), Sistema Integral
de Carbón (sicarbon), etc.
• Servicios: Contiene las aplicaciones destinadas a ofrecer servicios a toda
la empresa y no pertenecen a un usuario en particular. Ejemplo: Sistema
de Solicitudes de Servicios (Sisoserv).
• transferencias: Programas para las transferencias de datos, de otros
repositorios de información, ejemplo: SAP, Oracle, etc.
Nivel 3: Directorio que contiene las carpetas con el nemónico que identifica a cada aplicación integral y la
carpeta de cada una de las gerencias que contendrá a su vez cada uno de los módulos definidos para cada una
de ellas.
Nivel 4: Directorio que contiene la estructura de carpetas específicas de cada sistema integral, o módulos
(aplicaciones pequeñas), referentes a las misma
• clases: Se almacenan todas las clases propias de la aplicación.

• funciones: Contiene todas las funciones PHP propias de la aplicación. En esta carpeta
debe existir el archivo procesar_datos.php (el cual es obligatorio) utilizado para llamar a
procedimientos almacenados que realizan las transacciones de inserción, modificación y
eliminación en la base datos.
• js: Java Scripts propios de la aplicación
• modulos: Ver nivel 4.
• config.php: Archivo de configuraciones, para declarar constantes y validaciones del
sistema.
• index.php: Pagina principal de la aplicación. Esta página puede ser .php o .html (a criterio del desarrolador).
• info.php: Se refiere a la documentación de directorios.
Ejemplo:
Autor: Elvis Pérez
Fecha de Creación: 29 de mayo de 2007
Descripción: Este directorio almacena páginas que permiten gestionar y Publicar el precio del
aluminio para la comercialización.
Nivel 5: Directorio que contiene las carpetas y archivos pertenecientes a los módulos de la aplicación.
Nivel 6: Directorio de datos básicos separados por módulos
La carpeta datos_basicos deberá contener los módulos para administrar los datos básicos de la aplicación.
Todos los módulos estarán separados en carpetas. En cada uno de ellos deben existir como mínimo los
siguientes programas:
• gestion_nombre_modulo.php: este archivo contiene el formulario

para la captura de los datos
• listar_nombre_modulo.php: este archivo contiene las instrucciones
para mostrar los datos
13.1 CRITERIOS PARA CREAR ARCHIVOS EN EL ESQUEMA GENERAL O EN EL NIVEL 1 DE LA

ESTRUCTURA DE ARCHIVOS.
Para la creación de un archivo en el esquema general se debe tener en cuenta la siguiente regla:
nombre + extensión
Nombre: nombre asociado al contenido del archivo, ejemplo: enviar_correo, login, reportes, etc.
Extensión: extensión propia de cada archivo, ejemplo: .php, .js, .css, etc.
Ejemplos:
conexiones.php
librerias.php
enviar_correo.php
reportes.php
ajax.js
estructura_pagina.css
14. ESTÁNDARES DE PROGRAMACIÓN

Cualquiera que sea el proyecto, debe garantizarse un código legible, bien documentado y con una regla
estándar para reducir los tiempos de mantenimiento de las aplicaciones.
14.1 REGLAS DE PROGRAMACIÓN
1.La página principal de la aplicación debe llamarse index.php o index.html

2.Todos los nombres de las páginas de las aplicaciones web deben hacer referencia a la funcionalidad del
archivo, estar escritas en minúsculas y estar separadas por el carácter guión bajo (_). El nombre no debe
tener más de 50 caracteres. Ej:gestion_proyecto_partida.php
3.Para lograr mayor legibilidad del código fuente, debe utilizarse la tabulación en todos los bloques del
código, sin importar cual lenguaje o etiquetado que se este utilizando. A continuación se presenta un
ejemplo de un script PHP embebido de un bloque HTML.
<table>
<tr>
<th>N° de Cuenta</th>
<th>Fecha</th>
<th>Lugar</th>
</tr>
<?php
$rs=EjecutarPDO(_CONEXION,$SQL);
FilasDinamicas($rs);
?>
</table>
4. Cuando el bloque es muy grande es obligatorio colocar un comentario indicando que terminó dicho
bloque.
if (<condiciones>) {
º
º
º
} //fin if (<condicion>)
5. La codificación dentro de todas las paginas PHP debe ser toda en minúscula a excepción del código
SQL (PALABRAS RESERVADAS) y las funciones que estén hechas por terceros.
14.2 DEFINICIÓN DE INSTRUCCIONES SQL
Las instrucciones SQL deben de cumplir con las premisas definidas a continuación, es importante tener en
cuenta que se debe evitar en lo posible la implementación de código sql directo en las páginas (código
duro), es recomendable desarrollarlos dentro de procedimientos almacenados en el esquema que
corresponda a la aplicación dentro de la base de datos y solo invocarlos en las paginas PHP enviándole los
parámetros correspondientes según sea el caso.
En este sentido a continuación se listan dichas premisas:
1. Estar escritas con sus palabras reservadas en mayúsculas y todo lo demás en minúsculas. También
deben estar organizadas según el ejemplo.
Ejemplo:
SELECT id_persona, nombres, apellidos
FROM tbl_gral_persona
WHERE id_persona = '1111111' AND tipo = 'P'
2. Se deben invocar sólo las columnas a ser utilizadas, esto para garantizar un mejor rendimiento.
Además, se debe utilizar tan a menudo como sea posible, la cláusula WHERE para filtrar los datos
consultados. En estos casos se debe tener en cuenta los índices existentes y el orden de los mismos.
Ejemplo:
SELECT nombre, precio, descripción
FROM tbl_gral_producto
WHERE id_producto=xxxxx
3. Evitar hacer consultas masivas como la que se muestra a continuación Salvo aquellas excepciones
que lo ameriten:
SELECT *
FROM alguna_tabla
4. Los nombres de los parámetros en los procedimientos almacenados deben regirse por la siguiente
regla:
p_ + nombre descriptivo
14.3 DEFINICIÓN DE FUNCIONES.
Nombre de la Función: Para definir el nombre de las funciones js o php, se debe seguir la siguiente regla:
nombre descriptivo de la función
Parámetros de la Función: Los parámetros de la función deben seguir la siguiente regla:

p_ + Nombre descriptivo del Parámetro
Es importante destacar que toda función debe tener un encabezado el cual debe llevar la siguiente
estructura:
1.- Descripción de la función
2.- Autor
3.- Fecha de creación
4.- Modificaciones: Autor, Fecha de modificación y Descripción de la modificación
Las modificaciones deben quedar en forma ascendente por la fecha de modificación y separadas por una
línea en blanco.
14.4 DOCUMENTACIÓN.
El código debe tener comentarios explicativos. Las convenciones para la documentación son las
siguientes:
1. Para los comentarios entre las líneas, se recomienda dejar siempre una línea en blanco, antes de
escribir el comentario. El mismo se debe iniciar con mayúscula.
Ejemplo:
//Se realiza la consulta en la base de datos
$rs = ejecutar_pdo(_CONEXION, $SQL);
//Si la acción seleccionada ha sido editar, se busca el consecutivo en BD

if($accion==’Editar’){
$punto= $_POST["id"];
$sql = "SELECT consecutivo

FROM tbl_sisoserv_grupo_servicio
WHERE id_grupo = “.$punto.”;
$rs1 = ejecutar_pdo(_CONEXION, $sql);
}
2. Para los comentarios en una línea de código, se recomienda que inicien siempre al mismo nivel, para simplificar
la lectura. El mismo se debe iniciar con mayúscula.
Ejemplo:
$rs = ejecutar_pdo(_CONEXION, $SQL); //Se realiza la consulta en BD
if($accion==’Editar’){
$punto= $_POST["id"];
$sql = "SELECT consecutivo
FROM tbl_sisoserv_grupo_servicio
WHERE id_grupo = “.$punto.”; //Se busca el consecutivo en BD
$rs1 = ejecutar_pdo(_CONEXION, $sql);
3. Las condiciones demasiado extensas se tabulan de la siguiente manera:

if (<condicion> && <condicion> && <condicion> &&
<condicion> && <condicion> && <condicion> &&
<condicion> && {
4. Los programas fuentes (.php, .js, .html, .css, .xml, etc) o procedimientos de BD, debe contener obligatoriamente
el siguiente encabezado:
Descripción: Resumen de la funcionalidad del programa.
Autor: Nombre analista desarrollador del programa, En el caso de pasantias, Debería de mostrarse el
nombre del pasante y el tutor. En el caso de varios autores, Debería escribirse los nombres de todos.
Fecha Creación: Formato: DD-MM-YYYY
Parámetros: En el caso de Procedimiento de BD que reciban parámetros indicarlos.
URL: http:// + servidor + / + alias
Accesos: Los esquemas de BD a los que va acceder el programa.
Alias: Nombre del directorio virtual, si existe
Numero de Versión: Este valor se deberá inicializar en todos los programas en 1. A partir del pase a
producción cada vez que se haga modificación del archivo en el servidor de aplicaciones, la macro que
controlara los pases a producción, garantizara que este número se incremente después de 5 revisiones.
Número de Revisión: Este valor se deberá inicializar en todos los programas en 0. A partir del pase a
producción cada vez que se haga modificación del archivo en el servidor de aplicaciones la macro que
controlara los pases a producción, garantizara que este número se incremente en uno.
Motivo Modificación Breve descripción de las razones de la última modificación
Modificado por: Autor de de la última modificación
Fecha Modificación: Fecha de la última modificación
NOTA: TODAS Y CADA UNA DE LAS MODIFICACIONES DEBEN SER REGISTRADAS Y

CONSERVADAS. EN ORDEN ASCENDENTE, DE LA MAS RECIENTE A LA MAS ANTIGUA
Ejemplo:
/*------------------------------------------------------------------------------------*/
/*
Descripción: Clase evaluacion, creacion, consulta, modificacion y eliminacion de evaluaciones
de proveedores.
Autor: Homer Garcia
Fecha creación: 19/02/2010
Parámetros: N/A
URL: http://aluminiolx5/sievprov/
Accesos:
Alias: sievprov
Número de versión: 1
Número de revisión: 0
Motivo de modificación: N/A
Modificado por: N/A
Fecha modificación: N/A
*/ /*------------------------------------------------------------------------------------*/
14.5 RE UTILIZACIÓN DE CÓDIGO

El programador debe utilizar las funciones, plantillas y clases definidas en los directorios de uso común al
momento de realizar un programa.
14.6 ESTRUCTURA DEL ARCHIVO PHP

La estructura del archivo PHP, debe obedecer a la plantilla que esta disponible para los programadores en
el directorio del esquema general en la siguiente ruta:
plantilla/pla_estructura_archivo_php.php
(NO SE ENCUENTRA EL ARCHIVO INDICADO)
14.7 EJECUCIÓN DE OPERACIONES EN LA BASE DE DATOS.
• ejecutar_ pdo(): Función utilizada para realizar ejecución de procedimientos almacenados o

consultas SQL (solo SELECT) desde los programas hacia la Base de Datos.
Ejemplo:
$reg =ejecutarPDO(_CONEXION, $SQL);
<?php
//--------------------[ bloque encabezado]----------------------------------------------------------//
Se realiza el comentario de estructura de encabezado de archivo propuesta en el punto
anterior
//--------------------[ bloque inclusión de librerías]---------------------------------------------//
Se realizan todos los include, de las librerías o funciones a utilizar en esta pagina
//--------------------[ bloque de seguridad]------------------------------------------------------//
Se realizan las validaciones de seguridad correspondiente, validar sesiones expiradas,
permisos para acceder a esta pagina y otros validaciones que requiera la pagina
//--------------------[ bloque de funciones]------------------------------------------------------//
Se realizan la funciones propias de la pagina
//--------------------[ bloque parámetros de entrada e iniciar de variables]----------//
Se realizan toda la captura de parámetro de entrada y la inicialización o declaración de una
variable o constante
//--------------------[ bloque de operaciones especiales]-----------------------------------//
Se realizan aquellas operaciones de validación o consultas a la base de datos.
//--------------------[ bloque from-end]---------------------------------------------------------//
Se realiza el cuerpo de la pagina, o se crea el formulario
//--------------------[ bloque cierre de conexiones]------------------------------------------//
Se realiza el cierre de las conexiones en caso de que se requiera.
?>
NOTA: Dependiendo de la funcionalidad que vaya a tener el archivo, esta estructura puede cambiar el
orden propuesto, sin embargo, se debe tratar de cumplir en la mayoría de los casos.
• Para los procesos de insertar o actualizar registros se debe crear un procedimiento almacenado el
cual realice esta operación en el servidor de Base de datos. Este procedimiento recibirá los
parámetros necesarios para insertar o actualizar los registros. (tipo de acción, datos); deberá
realizar las validaciones pertinentes del lado de servidor y devolver los mensajes correspondientes.
De esta manera el manejo de información y la mayoría de la lógica de la aplicación quedara del
lado del servidor de base de datos.
Ejemplo:
un_siain_gestion_inventario_auditoria(accion character varying,
p_cod_auditoria integer,
p_nombre character varying,
p_cod_estado numeric)
• P
 ara eliminar registros se debe crear un procedimiento almacenado el cual realice la operación en
el servidor de base de datos. Este procedimiento recibirá los parámetros necesarios para insertar o
actualizar los registros.
Ejemplo:
fun_siain_eliminar_inventario_auditoria(p_cod_auditoria numeric)
• En los casos que amerite no debería de borrase los registros de la tablas con DELETE solo
debería de actualizarse los registros con la sentencia UPDATE modificando la columna cod_estado
(ACTIVO, INACTIVO, u otro, estos estarán en dato_general). Además se debe mantener una traza
del registro si es necesario. Por ejemplo la tabla tbl_gral_empleado, la cual por sus características
amerita guardar las trazas de las operaciones.
14.8 FUNCIONES GENÉRICAS
• validar_form(): Función de javascript ubicada en /js/generales.js, con la cual se valida Campos

vacíos, Rango de valores, Correos electrónicos, valores numéricos y otras funcionalidades que se
puedan ir agregando.
• llenar_combos(): Función php ubicada en /funciones/funcionesFomulario.php, se deberá usar la
función para llenar los objetos html tipo select .
• listar_datos(): Función utilizada para listar datos en pantalla se debe usar la función Ubicado en
/clases/listarDatos.php
• enviar_correo: función para envió de correo electrónico ubicado en: /clases/enviarCorreo.php
15. ESTÁNDARES DE INTERFAZ

Para la construcción de la interfaz de las aplicaciones de CVG Venalum, se cuenta con una serie de plantillas
utilizadas en el desarrollo y construcción de las pantallas, estos archivos/ plantillas se encuentran en el servidor
de desarrollo (aluminiolx10) en la ruta /data1/webapp/aplicaciones/plantilla/, como se muestra a continuación:
15.1 ENCABEZADO O BANNER
Ruta Física
/data1/webapp/aplicaciones/plantilla/encabezado.php
15.2 PIE DE PÁGINA
Ruta Física
/data1/webapp/aplicaciones/plantilla/pie_pagina.php
15.3 MENÚ
Ruta Física
/data1/webapp/aplicaciones/plantilla/menu.php
Para la creación del menú se utilizó una librería en javaScript implementada con prototype, la ubicación
física de la librería esta en /data1/webapp/menu_arbol/dtree.js
15.4 PANTALLA PRINCIPAL

La página principal de la aplicación debe llamarse index.php, la cual tiene la siguiente distribución gráfica:
Fig. i-01 Interfaz de la Pagina Principal
Fig. i-02 Código fuente de la Pagina Principal
15.5 HOJA DE ESTILOS

La Hoja de estilo de las aplicaciones se referencia desde el archivo encabezado.php, es decir, que para
usar la hoja de estilo en nuestra aplicación, simplemente se agrega el encabezado y automáticamente se
cargan los estilos.
Ruta Física
/data1/webapp/css/estilos.css
15.6 BARRA DE OPCIONES
Para hacer uso de la barra de opciones, solo hay que hacer referencia a la clase listarDatos.php, y luego al
método cabeceraListar(), como se muestra a continuación:
Para revisar este ejemplo ver archivo servidor web de desarrollo (aluminiolx10) en
/data1/webapp/aplicacaciones/plantilla/ejemplo/listarTipo_proyecto.php
15.7 LISTAR REGISTROS
Para hacer uso del listar registro, solo hay que hacer referencia a la clase listarDatos.php, y luego al
método listarRegistros(), como se muestra a continuación:
15.8 CREACIÓN DE MÓDULOS EN UNA APLICACIÓN
Es importante tener como regla, que para crear cada modulo siempre debe existir mínimo dos archivos los
cuales deben contener las siguientes condiciones:
listar + Nombre Modulo.php

gestion + Nombre Modulo.php
Ejemplo:
El archivo listarNombreModulo.php muestra la siguiente información:
El archivo gentionNombreModulo.php muestra la siguiente información:
16. SEGURIDAD EN LAS APLICACIONES DEL AMBIENTE PHP/POSTGRESQL
16.1.- CONTROL DE ACCESO / AUTORIZACIÓN A LA URL

Para evitar el acceso a la URL de personal no autorizado y la ejecución de funciones pertenecientes a las
aplicaciones privadas hay que validar los siguientes puntos en código php:
• El inicio de sesión en cada página de la aplicación

<?php
include_once('../../../../bd/funciones_bd.inc');
include_once('../../../../mod_admin/seguridad/con_seguridad.php');
include_once('../../../../aplicaciones/funciones/funcionesFormulario.php');
$cedula = UsuValorIdentidad('cedula');
validarSesion($cedula);
?>
• El rol del usuario autorizado en cada página de la aplicación

<?php
include_once('../../../../bd/funciones_bd.inc');
include_once('../../../../aplicaciones/funciones/funcionesFormulario.php');
validarPerfilUsuario($empresa,$usuario,$rol)
?>
16.2.- INYECCIÓN SQL
Las fallas de inyección, tales como SQL, ocurren cuando datos no confiables son enviados a través de la
entrada de datos y/o solicitud de búsqueda como parte de un comando o consulta.
Ejemplo:
La aplicación utiliza datos no confiables en la construcción de la siguiente consulta

vulnerable SQL:
String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") +"'";
El atacante modifica el parámetro ‘id’ en su navegador para enviar: ' or '1'='1. Esto cambia el significado de
la consulta devolviendo todos los registros de la tabla ACCOUNTS en lugar de solo el cliente solicitado.
http://example.com/app/accountView?id=' or '1'='1
Para este punto es importante tomar en cuenta y validar el siguiente punto:
Previo a la ejecución de cada sentencias sql (select, update, delete) en el código php validar el tipo de dato
de los parámetros. No permitir el uso de caracteres especiales tales como: &, = , / , > , < .
16.3.- EL DESBORDAMIENTO DE BUFFER.
Si la columna en la base de datos tiene un tamaño n, el objeto de entrada de datos debe tener un tamaño
menor o igual a n.
16.4.- VALIDACIÓN DE ENTRADA DE DATOS.
La entrada de datos se validan para evitar que fallen las operaciones de de base de datos por tipo de datos
errados.
Validar los siguientes puntos:

El tipo de dato a registrar como entrada y para realizar las consultas
• Si el dato es numérico entero solo se debe permitir números.

Ejemplo 64537
• Si el dato es numérico real solo se debe permitir números y el carácter de separación de decimal
(,)
Ejemplo 7654,34
• Si el dato es texto corto no se deben permitir números ni caracteres especiales (& , /, = )

Ejemplo Lugar Nacimiento : San Felix
16.5.- PASE DE PARÁMETRO ENTRE PÁGINAS
Para evitar que cualquier persona envié datos no confiables a la aplicación validar los siguientes puntos en
el código php:
• No utilizar nombres de variables explícitos que den pistas relacionadas con su funcionalidad.
• Realizar el pase de las variables estrictamente necesarias.
• En la página destino validar el tipo de dato recibido por el $_GET o por $_POST.

Manuel Web

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Manuel Web

Încărcat de

Drepturi de autor:

Formate disponibile

MANUAL DE ESTÁNDARES DE PROGRAMACIÓN

Gerencias de Sistema y Organización

ALUMINIOLX5 y ALUMINIOLX14: Servidores de Aplicaciones para el ambiente de producción el cual tiene

PDO(PHP), PDO(PHP), PDO(PHP),

Puerto: 5435 Puerto: 5432

Servidor de Base de datos Servidor de Base de datos

• PHP: Lenguaje del lado de servidor

3. CRITERIOS PARA DEFINIR EL NEMONICO DE UNA APLICACIÓN.

4. PAUTAS Y FUNCIONAMIENTO PARA EL DESARRROLLO.

4.1 CONEXIÓN A LA BASE DE DATOS (ALUMINIOLX45).

4.2 DEFINICIÓN DE GRUPOS

Para crear estos usuarios se realiza de la siguiente forma:

Para crear un esquema en la base de datos de desarrollo se procede de la siguiente manera:

Ruta:: \\aluminiolx4\Sistemas y Organizacion\docum_sa\Documentación de Sistemas y

6. CONFIGURACIÓN DEL MENÚ Y USUARIOS DE UNA APLICACIÓN WEB.

6.1 CONFIGURACIÓN DEL MENU

Para la configuración de las opciones de búsqueda de un módulo de una aplicación es necesario

8. DECLARACION DE OBJETOS Y USUARIOS

8.1 DEFINICIÓN DEL OBJETO

Object Objeto Prefijo

8.2 Definición del propietario del objeto

Clave Primaria: Su nombre debe cumplir con la siguiente regla:

Clave Foránea: Su nombre debe cumplir con la siguiente regla:

Clave de Chequeo: Su nombre debe cumplir con la siguiente regla:

Clave Única: Su nombre debe cumplir con la siguiente regla:

10. DECLARACION DE INDICES

11. DECLARACION DE ATRIBUTOS

A continuación, el listado de abreviaturas a ser utilizadas para los atributos comunes:

12. CONEXIÓN AL SERVIDOR DE APLICACIONES WEB (ALUMINIOLX10).

Al presionar se mostrara la siguiente ventana:

Al introducir el usuario FTP y la clave y presionar Aceptar se muestra la siguiente pantalla:

• administración: Contiene todas las aplicaciones relacionadas con el área

• clases: Se almacenan todas las clases propias de la aplicación.

Fecha de Creación: 29 de mayo de 2007

• gestion_nombre_modulo.php: este archivo contiene el formulario

13.1 CRITERIOS PARA CREAR ARCHIVOS EN EL ESQUEMA GENERAL O EN EL NIVEL 1 DE LA

14. ESTÁNDARES DE PROGRAMACIÓN

14.1 REGLAS DE PROGRAMACIÓN

1.La página principal de la aplicación debe llamarse index.php o index.html

Parámetros de la Función: Los parámetros de la función deben seguir la siguiente regla:

//Si la acción seleccionada ha sido editar, se busca el consecutivo en BD

$sql = "SELECT consecutivo

3. Las condiciones demasiado extensas se tabulan de la siguiente manera:

NOTA: TODAS Y CADA UNA DE LAS MODIFICACIONES DEBEN SER REGISTRADAS Y

14.5 RE UTILIZACIÓN DE CÓDIGO

14.6 ESTRUCTURA DEL ARCHIVO PHP

14.7 EJECUCIÓN DE OPERACIONES EN LA BASE DE DATOS.

• ejecutar_ pdo(): Función utilizada para realizar ejecución de procedimientos almacenados o

14.8 FUNCIONES GENÉRICAS

• validar_form(): Función de javascript ubicada en /js/generales.js, con la cual se valida Campos

15. ESTÁNDARES DE INTERFAZ

15.2 PIE DE PÁGINA

15.4 PANTALLA PRINCIPAL

Fig. i-01 Interfaz de la Pagina Principal

15.5 HOJA DE ESTILOS

listar + Nombre Modulo.php

El archivo listarNombreModulo.php muestra la siguiente información:

El archivo gentionNombreModulo.php muestra la siguiente información:

16.1.- CONTROL DE ACCESO / AUTORIZACIÓN A LA URL

• El inicio de sesión en cada página de la aplicación

• El rol del usuario autorizado en cada página de la aplicación

16.2.- INYECCIÓN SQL

La aplicación utiliza datos no confiables en la construcción de la siguiente consulta