Convenciones Proyectos Software

CONVENCIONES PARA EL DESARROLLO DE SOFTWARE

1. INTRODUCCIÓN

Es frecuente en el medio escuchar a estudiantes y profesionales de la programación

confesar, no sin cierta preocupación, que no están en capacidad de documentar un
programa, o de siquiera escribirlo bien. Aunque en algunos casos puede que el
interlocutor realmente sea ignorante, en realidad lo que le falta es decorar el programa
sistemáticamente, para que el resultado sea un buen programa. Una manera de lograrlo
es siguiendo las convenciones de programación.
 Las convenciones de programación son reglas para hacer la documentación interna del
programa1. El seguirlas no garantiza que todo programa quede correctamente
documentado, pero el programador cuidadoso logrará de ellas gran provecho. Después
de todo representan la experiencia de muchos programadores, que han contribuido con
diversos detalles, que juntos forman un todo bastante armonioso y útil.

 Estas convenciones no son las más agradables a primera vista. Sin embargo, después de
un tiempo de usarlas, el cerebro se acostumbra a ellas, y las acepta. Al tiempo,
programas que no siguen las convenciones se ven mal.

Adoptar estas convenciones es difícil, pues requiere mucho trabajo, con la desventaja de
tener que sincronizar unos gustos con los de otros. Pero después de un corto tiempo se
logra, y paradójicamente las convenciones se tornan más agradables de lo que uno
quisiera aceptar. Además, si todos las usan, todos estarán más contentos compartiendo
nuestros programas.

Este documento contiene normas para el desarrollo de software en sus aspectos

fundamentales: estándares de nomenclatura, entornos de explotación y desarrollo, uso
de las herramientas. Los principales destinatarios son los analistas y programadores
responsables del desarrollo y mantenimiento de aplicaciones de gestión

2. OBJETIVOS

 Estandarizar la forma de programar e interpretar documentos para el desarrollo

de un software.
 Mantener en línea la comunicación entre todos los desarrolladores de un
proyecto de software.
 Permitir que el mantenimiento de la información sea más efectivo.

1
http://www.di-mare.com/adolfo/p/convpas.htm
 Convenciones Proyectos Software

3. RESPONSABILIDADES

Cada programador deberá disponer de sus propios directorios de trabajo, así como de
datos independientes para realizar pruebas unitarias de los módulos que vaya
desarrollando.

Es responsabilidad del programador la organización de su directorio de trabajo, así

como el mantenimiento de sus datos de prueba.

Se favorecerá el traspaso de módulos en desarrollo entre programadores con la única

condición que no pueda modificar el trabajo del otro (se sugiere crea una nueva versión)

4. CONVENCIONES

Diseño de datos

a. Objetos de la Base de Datos

Tablas

 Todas las tablas de la base de datos, iniciarán su nombre anteponiendo la letra t

al nombre de la tabla. Deberá existir como máximo tres palabras por cada
nombre de la tabla, de la siguiente manera:
tNombreDeTabla ejm: tHistoriaClinicaGeneral

Tablas de relación

 Los nombres de las tablas de relación, empezará con la letra r. No existirá un

número máximo de palabras para el nombre de la tabla de relación, de la
siguiente manera:
rNombreRelacion ejm: rHistoriaClinicaGeneralxPaciente

Índices

 Llamaremos índices primarios a aquellos que identifican unívocamente a cada

fila de una tabla (clave primaria o clave candidata2).
 Los índices primarios se nombrarán anteponiendo la letra i al nombre del índice,
de la siguiente manera:
iNombreIndice ejm: iCedula

Vistas

 Los nombres de las vistas, empezará con la letra v y a continuación el nombre de

la vista, de la siguiente manera:
vNombreVista ejm: vCedxPac

2
La clave primaria de un relación es aquella clave candidata que se escoge para identificar sus tuplas de
modo único
 Convenciones Proyectos Software

A cada tabla, vista o secuencia se le asignará una abreviatura de no más de tres

caracteres que se empleará en la cualificación de campos en sentencias SQL que
involucren a más de una tabla.
Por ejemplo, la abreviatura asignada a la tabla
ejm: tHistotiaClinicaGeneeral podría ser hcg

Atributos o Campos

 Los atributos o campos pertenecientes a una tabla, deberán escribirse utilizando

las primeras letras del nombre de la tabla y a continuación el nombre respectivo
del atributo. Además el nombre de los campos no deberá exceder de 16
caracteres, de la siguiente manera:
pac_codigo Donde la abreviatura pac viene de la tabla paciente.
hc_codigo Donde la abreviatura hc viene de la tabla historia_ clínica

Los atributos de las tablas de relación, deben empezar con el prefijo que se forma de las
primeras letras del nombre de la tabla de la relación.

Ejm: hcg_codigo Donde la abreviatura hcg viene de la tabla

HistoriaClinicaGeneral

b. SQL (Negocios)

Procedimientos Almacenados

 Los nombres de los procedimientos almacenados iniciarán con las letras sp y a

continuación se escribirá el nombre del procedimiento, de la siguiente manera:

spNombreProcedimeinto

Disparadores

 Los nombres de los disparadores deberán empezar con las letras tr y a

continuación se escribirá el nombre del disparador, de la siguiente manera:

trNombreDisparador

Funciones

 Los nombres de las funciones deben empezar con la letra f y a continuación se

escribirá el nombre de la función, de la siguiente manera:

fNombreFuncion

c. Interfaz

Formulario Principal
 Convenciones Proyectos Software

 Para la identificación de un formulario principal, se antepondrá el prefijo fp al

nombre del formulario, de la siguiente manera

fpMenuPrincipal

 Para identificar a los formularios modales, antepondremos el prefijo fm al

nombre del formulario, de la siguiente manera:

fmNombreFormulario

 Para identificar a los formularios no modales, antepondremos el prefijo fn al

nombre del formulario, de la siguiente manera:

fnNombreFormulario

Consultas (queries)

Las consultas se nombrarán anteponiendo el prefijo c al nombre de la consulta

(identificador) de no más de 20 caracteres. El identificador se derivará de la
tabla sobre la que se realiza la consulta. Para consultas complejas, esto es, joins
de varias tablas, el identificador se derivará de la tabla más significativa. Si la
elección no estuviese clara, se procurará asignar nombres de forma justificada,
de la siguiente manera:
cNombreConsulta ejm: cExamenxPaciente
Reportes
 Para identificar los reportes anteponemos la letra r, al nombre del identificador.
Como se muestra a continuación:
rNombreReporte ejm: rExamenPacientePeriodo
d. Manipulación de datos
Batch
Será utilizado para realizar acciones comunes en procesamientos batch 3 (lectura/
escritura de archivo, acceso a base de datos, etc.).
 Para poder utilizar lotes de información, se creará sentencias transactsql. El
nombre que se le asignará a la información creada (batch), se lo denotará:
Nombre.sql ejm: InsertarPaciente.sql
 Cada archivo creado, deberá tener la documentación necesaria para su
utilización (comentarios).

5. COMENTARIOS
Los comentarios serán utilizados para comentar las acciones que se realicen en el
código de la programación, así como en las sentencias sql.

Cometarios de una línea

3
Archivo de procesamiento por lotes
 Convenciones Proyectos Software


Para comentar el código o sentencia sql, en una sola línea, se utilizará dos barras
inclinadas a la derecha (//).
Ejm: // Esto es un comentario de una línea
Comentarios de más de una línea
 Para comentar el código o sentencia sql de más de una línea se deberá abrir y
cerrar el comentario, para abrir se utilizarán los símbolos una barra inclinada
hacia la derecha seguida de un asterisco y para cerrar el comentario deberá
utilizar un asterisco y una barra inclinada.

Los comentarios deberán escribirse de acuerdo a la siguiente nomenclatura:

/* fecha_realiza_correccion Nombre_programador razón */

Por ejemplo:
/* 09-11-21 Pedro López Para truncar el cálculo del impuesto IVA a dos dígitos*/

Si en el código existente realizamos una modificación no mayor a diez líneas,

realizamos un comentario en le mismo archivo explicando la función que cumple el
código o también realizando un nuevo comentario si el código ha sido alterado.
Si el código excede a diez líneas pasar al punto 5.

6. NOMBRES DE ARCHIVOS
Existirán dos tipos de archivos:
 Datos
 Interfaz
Datos
Entre los archivos de datos existirán:
Archivos de datos lógicos, archivos de datos físicos, archivos de datos sql y catálogos,
archivos de sql de mantenimiento, archivos de datos sps4 y para triggers5
 En los archivos lógicos tendremos archivos tipo cdm y bitacoras.
 En los archivos físicos tendremos archivos como pdm.
Además de los archivos antes mencionados tendremos archivos sps y triggers que están
almacenados en un formato txt.

Bitácora
Será utilizada para registrar los cambios en el código de la programación así
como en las sentencias sql de la base de datos. Para registrar cada bitácora
creada se deberá utilizar la siguente nomenclatura:

nombreArchivo_fecha_version ejm: bddproyhsvp`_09112009_1.cdm

4
Store Procedure (procedimiento almacenado)
5
Es un procedimiento que se ejecuta cuando se cumple una condición establecida
 Convenciones Proyectos Software

Interfaz
De acuerdo al diseño de módulos