Manual Estandares Vb6

MANUAL DE ESTÁNDARES PARA
EL DESARROLLO DE SISTEMAS
VB.6
http://todoingenieriasoft.blogspot.pe/
Código: AAA-BBB-CC001
Tipo: DOCUMENTO TÉCNICO
Versión: 02
Título: Fecha de Aprobación:
MANUAL DE ESTÁNDARES PARA EL DESARROLLO 00/00/0000
DE SISTEMAS Página 2 de 86
HOJA DE CONTROL DE CAMBIOS
ITEM TEXTO MODIFICADO VERSIÓN FECHA RESPONSABLE

División de Desarrollo
1 Elaboración inicial del documento 01 27/05/05 y Mantenimiento de
Sistemas
Carátula Se modifico el código del documento: 005-157- 02 05/10/06 Equipode Calidad
00000002/061 por el AAA-BBB-CC001
En la página 14 se actualizó Normas Generales 05/10/06 Equipo de Calidad
Item 2.1 de Nomenclatura por Normas Generales de 02
Codificación y Nomenclatura.
Item 2.3 En la página 19 se agregó Uso de Palabras 05/10/06 Equipo de Calidad
02
Reservadas.
Item 2.4 En la página 20 se agregó Tipos de Dato 02 05/10/06 Equipo de Calidad
Item En la página 27 se agregó Uso de la sentencia 05/10/06 Equipo de Calidad
02
2.4.17 – use.
Item 3 En la página 29 se agregó Pistas de Auditoria 02 05/10/06 Equipo de Calidad
Item 4 En la página 31 se agrego Optimización y 05/10/06 Equipo de Calidad
02
Revisión de Códigos
Item En la página 50 se actualizó Estructura de 02 05/10/06 Equipode Calidad
7.1.3 Directorios de Trabajo.
Item En la página 52 se actualizó funciones según 02 05/10/06 Equipode Calidad
7.1.3 Metodología de Desarrollo de Software.
Item 9 En la página 55 se agregó Notación UML en la 02 05/10/06 Equipode Calidad
Metodología de Desarrollo de Software.
Copia No Controlada. Es responsabilidad del usuario asegurarse de que el presente documento corresponde a la versión
vigente publicada en TODOINGENIERIASOFT.BLOGSPOT.PE
Versión: 02
INDICE
1. ESTANDARES DE VISUAL BASIC 6.0 .................................................................................................... 6
1.1. NOMENCLATURA PARA LOS ELEMENTOS DE PROGRAMACIÓN .......................................................... 6
1.1.1. PREFIJOS DE VARIABLES............................................................................................................. 6
1.1.2. PREFIJOS DE CONTROLES .......................................................................................................... 7
1.1.3. PREFIJOS DE VARIABLES PARA OBJETOS DE BASE DE DATOS:............................................ 8
1.1.4. PREFIJOS DE ÁMBITO Y UTILIZACIÓN: ....................................................................................... 8
1.2. DECLARACIONES ....................................................................................................................................... 8
1.2.1. NOMBRES DE VARIABLES ............................................................................................................ 9
1.2.2. NOMBRES DE MODULOS.............................................................................................................. 9
1.2.3. NOMBRES DE FORMULARIOS...................................................................................................... 9
1.2.4. NOMBRES DE REPORTES ............................................................................................................ 9
1.2.5. OBJETOS ADO.............................................................................................................................. 10
1.2.6. FUNCIONES .................................................................................................................................. 10
1.2.7. PROCEDIMIENTOS ...................................................................................................................... 11
1.2.8. PARAMETROS .............................................................................................................................. 12
1.2.9. VARIABLES GLOBALES ............................................................................................................... 12
2. ESTANDARES DE BASE DE DATOS CON SQL SERVER................................................................... 14
2.1. NORMAS GENERALES DE CODIFICACION Y NOMENCLATURA........................................................... 14
2.2. NOMENCLATURA PARA OBJETOS DE LAS BASES DE DATOS............................................................. 18
2.3. USO DE PALABRAS RESERVADAS ......................................................................................................... 19
2.4. TIPOS DE DATOS ...................................................................................................................................... 20
2.4.1. NUMÉRICOS EXACTOS ............................................................................................................... 21
2.4.2. NUMÉRICOS CON APROXIMACIÓN ........................................................................................... 22
2.4.3. DATETIME Y SMALLDATETIME................................................................................................... 22
2.4.4. CADENAS DE CARACTERES ...................................................................................................... 22
2.4.5. CADENAS DE CARACTERES UNICODE..................................................................................... 22
2.4.6. CADENAS BINARIAS .................................................................................................................... 22
2.4.7. OTROS TIPOS DE DATOS ........................................................................................................... 23
2.4.8. NOMENCLATURA DE BASES DE DATOS................................................................................... 23
2.4.9. NOMENCLATURA DE TABLAS .................................................................................................... 23
2.4.10. NOMENCLATURA DE COLUMNAS.............................................................................................. 25
2.4.11. NOMENCLATURA DE CONSTRAINTS ........................................................................................ 25
2.4.12. NOMENCLATURA DE INDICES.................................................................................................... 26
2.4.13. NOMENCLATURA DE VISTAS ..................................................................................................... 26
2.4.14. NOMENCLATURA DE TIPOS DE DATOS .................................................................................... 26
2.4.15. NOMENCLATURA DE REGLAS.................................................................................................... 26
2.4.16. NOMENCLATURA DE DEFAULTS ............................................................................................... 26
2.4.17. USO DE LA SENTENCIA – USE ................................................................................................... 27
2.4.18. NOMENCLATURA DE PROCEDIMIENTOS ALMACENADOS Y FUNCIONES........................... 27
2.4.19. NOMENCLATURA DE TRIGGERS ............................................................................................... 28
2.5. EQUIVALENCIAS ENTRE TIPOS DE DATOS VISUAL BASIC Y SQL ....................................................... 29
3. PISTAS DE AUDITORIA:........................................................................................................................ 29
3.1. TABLAS AUDITABLES CON HISTÓRICO ................................................................................................. 29
3.2. TABLA AUDITABLES SIN HISTÓRICO...................................................................................................... 30
3.3. TABLA AUDITABLES POR SEGURIDAD................................................................................................... 30
4. OPTIMIZACION Y REVISION DE CODIGOS ......................................................................................... 31
5. COMPONENTES..................................................................................................................................... 33
5.1. DEFINICIÓN DE TIPOS DE COMPONENTES ........................................................................................... 33
5.1.1. ESTRUCTURA DE LA APLICACIÓN............................................................................................. 33
5.1.2. NOMENCLATURA DE COMPONENTES ...................................................................................... 33
Versión: 02
5.1.3. MODELAMIENTO DE COMPONENTES ....................................................................................... 34

5.2. CONSTRUCCION DE COMPONENTES.................................................................................................... 35
5.3. MANEJO DE TRANSACCIONES ............................................................................................................... 38
5.4. GENERACION DE COMPONENTES (COMPILACION)............................................................................. 40
6. TRATAMIENTO DE ERRORES .............................................................................................................. 41
6.1. REGISTRO DE ERRORES (ARCHIVO LOG) ............................................................................................. 41
6.2. NIVELES EN EL MANEJO DE ERRORES.................................................................................................. 44
7. DISEÑO DE PANTALLAS ...................................................................................................................... 48
6.1 ESTANDARES DE PANTALLAS...................................................................................................................... 48
7.1.1. BOTONES DE MANTENIMIENTO................................................................................................. 49
7.1.2. SECCION DE CRITERIOS DE BUSQUEDA Y ESTADO .............................................................. 50
7.1.3. SECCION DE DATOS ................................................................................................................... 50
8. DISEÑO DE REPORTES ........................................................................................................................ 52

8.1. ESTRUCTURA DE LOS REPORTES ......................................................................................................... 52
7.2. CARACTERISTICAS...................................................................................................................................... 52
7.3. MARGENES................................................................................................................................................... 53
7.4. DEL FORMATO.............................................................................................................................................. 53
7.5. CONSIDERACIONES .................................................................................................................................... 54
7.6. EXCEPCIONES ............................................................................................................................................. 55
9. NOTACION UML EN LA METODOLOGIA DE DESARROLLO DE SOFTWARE ................................. 55

9.1. DIAGRAMA DE CASO DE USO (NEGOCIO).............................................................................................. 56
9.1.1. ELEMENTOS Y NOTACIÓN DE CASO DE USO DE NEGOCIO .................................................. 56
9.1.2. ELEMENTOS Y NOTACIÓN DE DIAGRAMA DE ACTIVIDAD DE NEGOCIO:............................. 58
9.2. DIAGRAMA DE CASO DE USO (SISTEMA):.............................................................................................. 59
9.2.1. PROPÓSITO:................................................................................................................................. 59
9.2.2. ELEMENTOS (SISTEMA).............................................................................................................. 60
9.2.3. TIPOS DE ACTORES (SISTEMA) ................................................................................................. 62
9.2.4. TIPOS DE RELACIÓN Ó ESTEREOTIPOS (SISTEMA) ............................................................... 63
9.2.5. COMO IDENTIFICAR ACTORES .................................................................................................. 65
9.2.6. COMO IDENTIFICAR CASOS DE USO ........................................................................................ 65
9.2.7. PLANTILLA DE DIAGRAMA DE CASO DE USO (SISTEMA) ....................................................... 66
9.3. DIAGRAMA DE CLASES:........................................................................................................................... 66
9.3.1. PROPÓSITO.................................................................................................................................. 66
9.3.2. DEFINICIÓN DE OBJETO ............................................................................................................. 66
9.3.3. DEFINICIÓN DE CLASE - PERSPECTIVA CONCEPTUAL .......................................................... 67
9.3.4. DEFINICIÓN DE CLASE - PERSPECTIVA FÍSICA ....................................................................... 67
9.3.5. ELEMENTOS Y NOTACIÓN.......................................................................................................... 67
9.3.6. HERENCIA .................................................................................................................................... 68
9.4. DIAGRAMA DE ESTADOS......................................................................................................................... 70
9.4.1. PROPÓSITO.................................................................................................................................. 70
9.4.3. PLANTILLA DE DIAGRAMA DE ESTADO .................................................................................... 72
9.5. DIAGRAMA DE SECUENCIA: .................................................................................................................... 72
9.5.1. PROPÓSITO.................................................................................................................................. 72
9.5.2. ELEMENTOS Y NOTACIÓN DEL DIAGRAMA DE SECUENCIA .................................................. 73
9.5.3. TIPOS DE CLASE (DISEÑO) ........................................................................................................ 74
9.5.4. PLANTILLA DE DIAGRAMA DE SECUENCIA (ANÁLISIS)........................................................... 76
9.5.5. PLANTILLA DE DIAGRAMA DE SECUENCIA (DISEÑO): ............................................................ 77
9.6. DIAGRAMA DE COLABORACIÓN: ............................................................................................................ 78
9.6.1. PROPÓSITO.................................................................................................................................. 78
9.6.3. PLANTILLA DE DIAGRAMA DE COLABORACIÓN ...................................................................... 78
9.7. MODELO DE IMPLEMENTACIÓN ............................................................................................................. 79
Versión: 02
9.7.1. PROPÓSITO.................................................................................................................................. 79
9.7.3. PLANTILLA DE MODELO DE IMPLEMENTACIÓN:...................................................................... 81
9.8. MODELO DE DESPLIEGUE:...................................................................................................................... 82
9.8.2. PLANTILLA PARA MODELO DE DESPLIEGUE ........................................................................... 84
9.9. ASIGNACIÓN DE PREFIJOS A DIAGRAMAS, MODELOS Y ELEMENTOS .............................................. 85
9.10. IDENTIFICADOR DE DIAGRAMAS, MODELOS Y ELEMENTOS: ............................................................. 86
9.11. TRAZABILIDAD.......................................................................................................................................... 86
9.12. REFERENCIAS BIBLIOGRÁFICAS............................................................................................................ 86
Versión: 02
1. ESTANDARES DE VISUAL BASIC 6.0
1.1. NOMENCLATURA PARA LOS ELEMENTOS DE PROGRAMACIÓN
1.1.1. PREFIJOS DE VARIABLES
Prefijo Tipo de Variable Variable de ejemplo

Bln Boolean. blnDeuda
Byt Byte. bytNumMeses
Cur Currency curSoles
fec Date fecInicio
dbl Double dblMontoDeuda
err Error errEjecConsulta
int Integer intNumeroControles
Lng Long lngNumContri
Obj Objeto objContribuyente
Sng Single sngPorcentaje
Str Cadena strApeMaterno
Var Variant varSuma
Enu Enumerador enuTotalCliente
Tipos de Datos Visual Basic 6.0 a Utilizar en el Proyecto SIAT
Tipo Descripción Bytes Rango Uso Prefijo

String Cadena de caracteres str
Date Fecha (8 Bytes) 8 01/01/100 a fec
31/12/9999
Single Decimal[(p[, s])] +- 3.40 E+38 Para variables físicas con sng
decimales que no exijan
precisión
Numeric[(p[, s])] sng
Long Entero largo 4 +- 2,147,483,647 Para numerar los habitantes lng
de
una ciudad o los números de
teléfonos
Integer Entero corto 2 +-32,767 Para numerar las filas y int
columnas de una matriz no
muy grande
Variant Fecha/hora var
Números/enteros
Boolean Binario True / False Para variable con solo dos bln
valores (sí o no)
Versión: 02
1.1.2. PREFIJOS DE CONTROLES
Prefijo Objeto Control de Ejemplo
ESTANDARES
Lbl Label lblNomContri
Chk Check box chkCoactiva
Cbo Combo box cboMes
Cls Class clsContri

Cmd Command button cmdSalir
Dat Data datContri

Dir Directory list box dirSource
Drv Drive list box drvTarget
Fil File list box filSource
Frm Form frmUsuarios

Fra Frame fraTributo
Grd Grid grdMultas
Hsb Horizontal scroll bar hsbVolumen
Img Image imgLogoSAT

Lbl Label lblDescMulta
Lin Line linVertical
Lst List box lstCodDistrito
Mnu Menú mnuPrincipal
Mdl Modulo mdlConsulta
Ole Ole oleObjReporte
Opt Option buton optSexo
Pic Picture box picDiskSpace
Shp Shape shpCirculo

Txt Text box txtPassword
Versión: 02
Tmr Timer tmrAlarma

Vsb Vertical scroll bar vsbRate
Tvw Treeview tvwOrg

Pgb Progress Bar pgbAvance
Stb SSTab stbApariencia

Tbd Tabbed dialog tbdUsuarios
Tsp TabStrip tspMantenimiento

PERSONALIZADOS
Ctl Control ctlBuscaPlaca
1.1.3. PREFIJOS DE VARIABLES PARA OBJETOS DE BASE DE DATOS:
Prefijo Uso de la variable Variable de ejemplo

cnn Connection cnnBDMultas
rst Recordset rstContribuyente
cmm Command cmmMultas
fld Field fldCodigo
1.1.4. PREFIJOS DE ÁMBITO Y UTILIZACIÓN:
Prefijo Descripción
g Creado en módulos de declaración
k Constante que no pertenece a una función o procedimiento
l Variable de Formulario para uso Local
p Variable Publica del Formulario
(sin prefijo) Variable no estática, prefijo local para el procedimiento
1.2. DECLARACIONES
La declaración de todas las variables se deben hacer al principio del Procedimiento

Almacenado, siendo esta declaración el primer bloque de código del mismo. No se
permitirá que se declaren variables en otro lugar.
La declaración de variables deberá ser una por línea, las mismas que deberán estar
correctamente indentadas y también deberán ser comentadas explicando su uso en la
medida de lo posible.
Versión: 02
Ejemplo:
Declare
@siCodMun smallint ,
@iCodPer int ,
@iNumCor int ,
@siCodMot smallint ,
1.2.1. NOMBRES DE VARIABLES
Para variables que hacen referencia a campos de la base de datos
<Prefijo tipo de dato VB><Nombre de Campo BD>
strccodper, intsinumvalor, lnginumtel
Para variables usadas en formularios ó módulos
<Prefijo tipo de dato VB><Nombre de Variable>
strNumRuc, strDigVer, intNumFil
1.2.2. NOMBRES DE MODULOS
Variable mdl<Prefijo sistema>Variable mdlFrVariable

Funciones mdl<Prefijo sistema>Función mdlFrFunción
1.2.3. NOMBRES DE FORMULARIOS
frm<Entidad><Acción>
frmTramite Mantenimiento de
frmTramiteConsultarEstados Consulta Estados de Trámite
frmTramiteImprimirEstados Impresión de Estados de Trámite
(Form. deSelección del Reporte)
frmTramiteImprimirEstadosRpt Impresión de Estados de Trámite
(Form. Visor del Reporte)
1.2.4. NOMBRES DE REPORTES
Diseñadores (Reportes embebidos en el Proyecto)

 Crystal Reports
crRpt<nombre>
crRptGravamen
Versión: 02
 Archivos TTx, Usar el mismo nombre que el reporte.

crRpt<nombre>
crRptGravamen
 DataReport
Rpt<nombre>
RptCoparticipacionPagos
1.2.5. OBJETOS ADO
<Tipo de objeto ADO><Nombre de variable>
<Tipo de objeto ADO> cnn : Conexión cnnBase

cmm : Command cmmVehiculo
rst : Recordset rstvehiculo
1.2.6. FUNCIONES
Las funciones van a ser declaradas en módulos o formularios.
Tienen el siguiente formato:
f[tipo de dato]_[Nombre de la función](Parámetros)
Las variables de las funciones son declaradas al inicio de las mismas y debe indicarse el
tipo de parámetro (por Valor o por Referencia).
Toda función deberá ser documentada con la siguiente estructura.
'********************************************************************************
**
'* <Descripción de la función>
'* Input : <Parámetro> - Descripción del parámetro
'* Output : <Descripción de la Salida>
'* Creado por : <Responsable>
'* Fec Creación : <Fecha Creación>
'* Fec Actualización: <Fecha de Actualización> Responsable : Analista.
‘* Motivo : <Motivo de la Modificación>
'********************************************************************************
**
Versión: 02
Función de Ejemplo:
Function fbln_ExisteFile(byval msRutaFile As String) as Boolean

'********************************************************************************
**
'* Función que determina si existe o no un archivo en una ruta dada
'* Input : msRutaFile - ruta del archivo a verificar
'* Output : Verdadero - Existe archivo
'* Falso - No existe archivo
'* Creado por : Juan Pérez
'* Fec. Creación : 20/04/2000
'* Fec. Actualización: <Fecha de Actualización> Responsable : Analista.
'********************************************************************************
**
Dim RutaFile As String
RutaFile = Dir(msRutaFile)
If RutaFile <> "" Then
fbln_ExisteFile = True
Else
fbln_ExisteFile = False
End If
End Function
Observación: En este caso RutaFile es una variable estática de uso solo como parámetro
de la Función de modo que no lleva prefijo.
1.2.7. PROCEDIMIENTOS
Los procedimientos van a ser declaradas en módulos ó formularios.

Tienen el siguiente formato (excepto para métodos de una clase):
p[Nombre del procedimiento](Parámetros)
Las variables de las funciones son declaradas al inicio de los mismos y debe indicarse el
tipo de parámetro (por valor o por referencia)
Toda Procedimiento deberá ser documentada con la siguiente estructura.

'********************************************************************************
'* <Descripción del Procedimiento>
'* Input : <Parámetros> - Descripción del parámetro
'********************************************************************************
Versión: 02
Procedimiento de Ejemplo
Sub pReparaBase (ByVal vstrdbContri As String)
'******************************************************************************
'* Procedimiento que repara una base de datos en Access
'* Input : db_Contri - nombre de la base mdb a reparar
'* Output : Proceso de reparación
'* Creado por : Juan Pérez
'* Fec Creación : 20/04/2000
'* Fec Actualización : <Fecha de Actualización> Responsable : Analista.
'*******************************************************************************
If ExisteFile(g_strRutaDB & "\" & db_Contri & ".mdb") Then
DBEngine.RepairDatabase g_strRutaDB & "\" & db_Contri & ".mdb"
MsgBox "Su base de Datos ha sido reparada"
Else
MsgBox "Error con la ruta o no existe la base de datos"
Exit Sub
End If
End Sub
1.2.8. PARAMETROS
Pasado por Valor v<tipodedato><Nemonico> vstrNumDoc

Pasado por Referencia r<tipodedato><Nemonico> rstrNumDoc
Tanto para las funciones como para los procedimientos debe de definirse el Tipo de
Parámetro con las palabras reservadas "ByVal" o "ByRef" según sea el caso, por
ejemplo:
Function fbln_ExisteFile(ByVal vstrRutaFile As String, _

ByRef rstrDescErr as String) as Boolean
Sub pReparaBase (ByVal vstrdbContri As String)
1.2.9. VARIABLES GLOBALES
La declaración de las variables globales se hace en el módulo de declaraciones.
Ejemplo: mdlFrvariable
En (General) - (Declaraciones)
'*******************Declaración de variables públicas*************************
'---------Boolean----------
Public gblnActivo As Boolean 'Indica si estado es activo o no
'-----------String-------------
Versión: 02
Public gstrRutaAplic As String 'Nombre de la ruta de la

aplicación
Public gstrRutaBase As String 'Ruta de la Base de Datos
'---------Registros---------
Public Type RegContri
Nombre As String * 15
Apellido As String * 15
Codigo As String * 10
Password As String * 8
Distrito As String * 2
End Type
'*****************Constantes*********************
Nomenclatura
Ámbito + "K" + Tipo de dato + Nombre
Ámbito : Global(G) , Privado(P), Local (L)

Constante : K (Identificador de constante)
Tipo de Dato : String(str), Integer(int), Long(lng) (Ver 1.1)
Nombre : Nombre de la Variable
Además del prefijo de ámbito de las variables, se debe especificar su naturaleza. Solo el
ámbito de las variables se escribe en minúscula y el resto del nombre de la constante en
mayúscula.
Ejemplo: gKSTRCODIGO
(Esta variable es global al proyecto y de tipo string)
Global Const gKSTRTITULO = "Sistema de Validación de Usuarios"
'***************** Declaración de Variables *********************
strNumDoc String Número de Documento

intNumFac Integer Número de Factura
fecFecCob Date Fecha de Cobro
Versión: 02
2. ESTANDARES DE BASE DE DATOS CON SQL SERVER
2.1. NORMAS GENERALES DE CODIFICACION Y NOMENCLATURA
Las sentencias From al incluir varias tablas deberán ser complementadas con las sentencias
Inner Join, Left Join o Right Join según sea el caso.
Considerar que el Ancho de Columnas para la codificación no debe exceder de 140 columnas.
Este grupo de sentencias no debe usarse:
From RDMaeDeu a, RDMovDeu b, SGMaeUsu c

Where a.sicodmun = b.sicodmun And a.cnumdoc = b.cnumdoc
And a.sicodusu *= c.sicodusu
La codificación correcta sería:
From RDMaeDeu a
Inner Join RDMovDeu b On (a.sicodmun = b.sicodmun And a.cnumdoc = b.cnumdoc)
Left Join SGMaeUsu c On (a.sicodusu = c.sicodusu)
Considerar el uso de la Sugerencias de Bloqueo cuando las tablas involucradas dentro de las
mismas tenga un alto nivel transaccional, pero tomando en cuenta las posibilidades de las
LECTURAS FANTASMAS que pudieran ocurrir.
Las sugerencias de bloqueo que se recomienda en la lectura es NoLock.
From RDMaeDeu a (NoLock)

Inner Join RDMovDeu (NoLock) b On (a.sicodmun = b.sicodmun And a.cnumdoc =
b.cnumdoc)
Left Join SGMaeUsu (NoLock) c On (a.sicodusu = c.sicodusu)
La indentación debe de ser de (03 espacios). El ancho del tabulador en los editores para las
sentencias SQL como el Analizador de Consultas debe establecer a 3 espacios y debe también
establecerse que los tabuladores deben guardarse como espacios.
Versión: 02
If Exists (Select a.sicodmun

From RDMaeDeu Where a.sicodmun = @psicodmun And a.cNumDoc =
@pcnumdoc)
Begin
Select .. ..
From
Inner Join .. ..
Left Join .. ..
Where .. .. And .. ..
End
Else
Begin
Select .. ..
From
Inner Join .. ..
Left Join .. ..
Where .. .. And .. ..
End
Las palabras reservadas Begin - Else - End deberán estar en la misma columna de indentación
de la sentencia lógica que las origina.
Cuando los identificadores correspondientes Begin – End se extiendan demasiado en el código
deberá comentarse en el identificador End la línea de la cual proviene, esto hará más fácil el
seguimiento de la codificación.
 Cada sentencia debe ir en una línea diferente

Select...
From...
Where...
Versión: 02
 Los Case deben estar alineados así : (El Case en una línea y los When y el Else en otras
diferentes)
Case
When .... Then .....
Else ......
End
 Si el Then del Case fuera demasiado largo se indentará el Then 3 espacios adicionales al When
al que pertenece
Case
When ....
Then .....
Else ......
End
 Los grupos de claves para los Join también deben estar indentados si el ancho supera las 140
columnas
 En el Where cada condicionante debe ir en una línea aparte y el And deberá estar alineado a la
derecha de la sentencia Where, ejemplo
Where sicodmun = @psicodmun
And cnumdoc = @psicodmun
And sitipedo = 1
And sicodusu = 457
En cuanto a identificadores
 Su tamaño puede variar desde 1 hasta 50 caracteres, incluyendo letras, símbolos y

números.
 El primer carácter del identificador puede ser una letra o uno de los siguientes símbolos:
Carácter Uso
@ Representa a una variable local
(*) # Representa el nombre de un objeto temporal
En el caso de una tabla o stored procedure : Representa a un objeto temporal
local
(*) ## Representan a un objeto temporal global
_ Carácter general
(*) Se recomienda que los nombres de los objetos temporales no excedan de los 20
caracteres, incluyendo al # o ##, debido a que SQL Server les agrega un sufijo numérico
interno. Las tablas temporales deberán en lo posible tener el mismo nombre de la tabla que se
extraen los datos o un nombre explícito sobre el proceso para la cual es necesitada. El prefijo
para cualquier tabla temporal deberá ser
#Tmp_nombre_tabla
##Tmp_nombre_tabla
Nota: Al utilizar nombres de objetos con espacios o caracteres especiales, se debe utilizar los
corchetes [ ] como identificador del nombre. Esta consideración debe ser contemplada para el
uso de cualquier objeto dentro de la base de datos
Versión: 02
La nomenclatura con caracteres especiales puede ser:
[#Tmp-nombre-tabla]
[##Tmp—nom bre tabla]
 Los caracteres posteriores al primer carácter pueden incluir letras, dígitos o los símbolos #,
$ o _.
 No se permiten espacios en blanco en el nombre del identificador.
 Los nombres serán representados por 3 o 6 caracteres, dependiendo de la frecuencia de
uso de la palabra y de la representatividad o significancia de la cantidad de caracteres
para cada una de las palabras
 Los nombres y prefijos para los tipos de dato estándar de SQL Server son:
Variables internas dentro de los Procedimientos Almacenados, Vistas, Desencadenadores,

Funciones y/o DTS :
o Bit @bnombre_variable (b)
o Tinyint @tinombre_variable (ti)
o Int @inombre_variable (i)
o Smallint @sinombre_variable (si)
o Char @cnombre_variable (c)
o Varchar @vnombre_variable (v)
@nvnombre_variable (nv)
o NVarchar
@nnombre_variable (n)
o Numeric @rnombre_variable (r)
o Real @sdnombre_variable (sd)
o Smalldatetime @dtnombre_variable (dt)
o Datetime
 Para los parámetros usados en los Procedimientos Almacenados, Funciones y/o DTS :
o Se les añadirá la letra (p) en minusculas :
Bit @pbnombre_variable
Tinyint @ptinombre_variable
Int @pinombre_variable
Smallint @psinombre_variable
Char @pcnombre_variable
Varchar @pvnombre_variable
NVarchar @pnvnombre_variable
Numeric @pnnombre_variable
Real @prnombre_variable
Smalldatetime @psdnombre_variable
Datetime @pdtnombre_variable
Versión: 02
2.2. NOMENCLATURA PARA OBJETOS DE LAS BASES DE DATOS
Tipo de Dato Tipo de dato de SQL Server

Binary binary[(n)]
varbinary[(n)]
Character Char[(n)]
varchar[(n)]
Date and time Datetime
Smalldatetime
Exact numeric decimal[(p[, s])]
numeric[(p[, s])]
Approximate numeric Float[(n)]
Real
Integer Int
Smallint
Tinyint
Monetary Money
Smallmoney
Special Bit
Timestamp
Long Identity
Text and image Text
Sysname
Image
Sinónimos que deben evitarse
Tipo de Dato Sinónimo (Evitar)

Varbinary Binary varying
Char Character
Char (1) Character
Char (n) Character (n)
varchar (n) Character varying (n)
Decimal Dec
Int Integer
Float Double precision
Real Float [(n)] for n = 1–7
Float Float [(n)] for n = 8–15
Versión: 02
2.3. USO DE PALABRAS RESERVADAS
 Se usaran Mayúsculas / Minúsculas en todas las palabras reservadas. Estas se hacen

extensivas a las funciones propias del SQL. Ejemplo
Select - From - Where - Group By - Having - If - Else - Begin - End - And - Or -

Inner Join - On. Getdate(), Rtrim(), Ltrim(),
Add Except Percent

All Exec Plan
Alter Execute Precision
And Exists Primary
Any Exit Print
As Fetch Proc
Asc File Procedure
Authorization Fillfactor Public
Backup For Raiserror
Begin Foreign Read
Between Freetext Readtext
Break Freetexttable Reconfigure
Browse From References
Bulk Full Replication
By Function Restore
Cascade Goto Restrict
Case Grant Return
Check Group Revoke
Checkpoint Having Right
Close Holdlock Rollback
Clustered Identity Rowcount
Coalesce Identity_insert Rowguidcol
Collate Identitycol Rule
Column If Save
Commit In Schema
Compute Index Select
Constraint Inner Session_user
Contains Insert Set
Containstable Intersect Setuser
Continue Into Shutdown
Convert Is Some
Create Join Statistics
Cross Clave System_user
Versión: 02
Current Kill Table

Current_date Left Textsize
Current_time Like Then
Current_timestamp Lineno To
Current_user Load Top
Cursor National Tran
Database Nocheck Transaction
Dbcc Nonclustered Trigger.
Deallocate Not Truncate
Declare Null Tsequal
Default Nullif Union
Delete Of Unique
Deny Off Update
Desc Offsets Updatetext
Disk On Use
Distinct Open User
Distributed Opendatasource Values
Double Openquery Varying
Drop Openrowset View
Dummy Openxml Waitfor
Dump Option When
Else Or Where
End Order While
Errlvl Outer With
Escape Over Writetext
2.4. TIPOS DE DATOS
En Microsoft® SQL Server™, cada columna, variable local, expresión y parámetro dispone
de un tipo de datos relacionado, que es un atributo que especifica el tipo de datos (integer,
character, money, etc.) que el objeto puede contener. SQL Server suministra un conjunto
de tipos de datos del sistema que define todos los tipos de datos que pueden utilizarse con
SQL Server. El conjunto de tipos de datos suministrados por el sistema se muestra debajo.
También se pueden utilizar tipos de datos definidos por el usuario, que son en realidad
alias de los tipos de datos suministrados por el sistema. Para obtener más información
acerca de los tipos de datos definidos por el usuario, consulte sp_addtype y Crear tipos de
datos definidos por el usuario.
Cuando dos expresiones que disponen de tipos de datos diferentes, intercalaciones,

precisión, escala o longitud los combina un operador:
Versión: 02
 El tipo de datos de los valores resultantes viene determinado al aplicar las reglas de
precedencia de tipos de datos a los tipos de datos de las expresiones de entrada. Para
obtener más información, consulte Precedencia de los tipos de datos.
 Si el tipo de datos del resultado es char, varchar, text, nchar, nvarchar o ntext, la
intercalación del valor del resultado viene determinado por las reglas de precedencia de
la intercalación. Para obtener más información, consulte Precedencia de intercalación.
 La precisión, escala y longitud del resultado dependen de la precisión, escala y longitud

de las expresiones de entrada. Para obtener más información, consulte Precisión,
escala y longitud.
SQL Server proporciona sinónimos de tipos de datos para la compatibilidad con SQL-92.
Para obtener más información, consulte Sinónimos de tipos de datos. Sin embargo estos
sinónimos no deben emplearse.
2.4.1. NUMÉRICOS EXACTOS
Integers
bigint
Datos enteros (números enteros) comprendidos entre -2^63 (-9223372036854775808) y
2^63 -1 (9223372036854775807).
int
Datos enteros (números enteros) comprendidos entre -2^31 (-2.147.483.648) y 2^31 - 1
(2.147.483.647).
smallint
Datos enteros comprendidos entre 215 (-32.768) y 215 - 1 (32.767).
tinyint
Datos enteros comprendidos 0 y 255.
Bit
bit
Datos enteros con valor 1 ó 0.
Decimal y Numeric
decimal
Datos de precisión y escala numérica fijas comprendidos entre -1038 +1 y 1038 – 1.
numeric
Funcionalmente equivalente a decimal.
Money y Smallmoney
money
Valores de moneda comprendidos entre -263 (-922.337.203.685.477,5808) y 263 - 1
(+922.337.203.685.477,5807), con una precisión de una diezmilésima de la unidad
monetaria.
smallmoney
Valores de moneda comprendidos entre -214.748,3648 y +214.748,3647, con una
precisión de una diezmilésima de la unidad monetaria.
Versión: 02
2.4.2. NUMÉRICOS CON APROXIMACIÓN

float
Números con precisión de coma flotante comprendidos entre -1,79E + 308 y 1,79E +
308.
real
Números con precisión de coma flotante comprendidos entre -3,40E + 38 y 3,40E + 38.
2.4.3. DATETIME Y SMALLDATETIME

datetime
Datos de fecha y hora comprendidos entre el 1 de enero de 1753 y el 31 de diciembre
de 9999, con una precisión de 3,33 milisegundos.
smalldatetime
Datos de fecha y hora comprendidos entre el 1 de enero de 1900 y el 6 de junio de
2079, con una precisión de un minuto.
2.4.4. CADENAS DE CARACTERES

char
Datos de caracteres no Unicode de longitud fija con una longitud máxima de 8.000
caracteres.
varchar
Datos no Unicode de longitud variable con un máximo de 8.000 caracteres.
text
Datos no Unicode de longitud variable con una longitud máxima de 231 - 1
(2.147.483.647) caracteres.
2.4.5. CADENAS DE CARACTERES UNICODE

nchar
Datos Unicode de longitud variable con una longitud máxima de 4.000 caracteres.
nvarchar
Datos Unicode de longitud variable con una longitud máxima de 4.000 caracteres.
sysname es el tipo de datos suministrado por el sistema y definido por el usuario que
es funcionalmente equivalente a nvarchar(128) y que se utiliza para hacer referencia a
nombres de objetos de bases de datos.
ntext
Datos Unicode de longitud variable con una longitud máxima de 230 - 1 (1.073.741.823)
caracteres.
2.4.6. CADENAS BINARIAS

binary
Datos binarios de longitud fija con una longitud máxima de 8.000 bytes.
varbinary
Datos binarios de longitud variable con una longitud máxima de 8.000 bytes.
image
Datos binarios de longitud variable con una longitud máxima de 231 - 1 (2.147.483.647)
bytes.
Versión: 02
2.4.7. OTROS TIPOS DE DATOS

cursor
Una referencia a un cursor.
sql_variant
Un tipo de datos que almacena valores de varios tipos de datos aceptados en SQL
Server, excepto text, ntext, timestamp y sql_variant.
table
Un tipo de datos especial que se utiliza para almacenar un conjunto de resultados para
un proceso posterior.
timestamp
Un número único para toda la base de datos que se actualiza cada vez que se actualiza
una fila.
uniqueidentifier
Un identificador exclusivo global (GUID).
2.4.8. NOMENCLATURA DE BASES DE DATOS
Prefijo <Proyecto><Código de Distrito>

Ejemplo SIAT0001
Comentarios  Cada distrito contará con una base de datos.
Proyecto:
SIAT
Código de Distrito:
0001 = Lima , 0003=Ate, 0013 = La Victoria
2.4.9. NOMENCLATURA DE TABLAS
Nomenclatura:
Prefijo <Prefijo Módulo><Tipo de Tabla><Prefijo Tabla>
Ejemplo RDMAEEXP
Comentarios Para tablas temporales físicas, siempre que sea posible, el nombre de
la tabla será el mismo de la tabla a la cual se hace referencia, de no
ser posible, se utilizará otro nombre, pero siempre dentro de los
estándares definidos. A este nombre de la tabla temporal, se le
pospone el sufijo Tmp . 1
1 17/01/2005: Actualizado por Mónica Manchego Lombardi.
Versión: 02
Valores para el Proyecto.

Prefijo
CC = Control y Cobranza
RE = Recaudación
FI = Fiscalización
GE = Gestión de Expedientes
RD = Registro y determinación de deuda
FR = Fraccionamiento
SG = Sistema General
NO = Notificaciones
DM= Data Mart
MG= Modulo Genera
Tipo de Tabla:
MAE = Maestro
MOV = Movimiento
DET = Detalle
TAB = Tabla
Prefijo Tabla:
Diseño Estándar
EXP = Expediente
CON = Convenio
DJ = DeclaraciónJurada
Diseño Data Mart
Dim= Dimensión (Donde se tienen los atributos de sistema, por lo general es

una tabla maestra del OLAP)
Hec = Hecho (Donde se tiene el detalle del negocio, pueden ser los maestros,
movimientos o detalles del OLAP)
Lkp = Look Up (Permite mapear los códigos principales de las bases OLAP
con los códigos principales del Data Mart)
Txs =Transaccional (Tablas cargadas al Data Mart que son extraídas

directamente desde las bases de datos OLAP)
Ejemplo. RDMAECONT
DMDimPer (Tabla Dimensional de Personas)
07/05/2005: Actualizado por Lucas Alvarado Aguado.

Versión: 02
Observaciones:
 El llenado de las tablas parámetros (Descripciones) es en minúsculas y la primera letra
es mayúscula.
 Las tablas de Históricos finalizan con H
 Sólo para el caso de las tablas transaccionales para Data Mart se agregaría antes de
colocar el nombre de la tabla referenciada (aunque en realidad es el nombre del tipo de
tabla o información que se está extrayendo el tipo de base de datos de dónde se
extrae la información, en nuestro caso serían dos tipos: Tributario (Tri) y Tránsito (Tra)
<Prefijo Módulo><Tipo de Tabla><Prefijo Tabla>H
2.4.10. NOMENCLATURA DE COLUMNAS
Prefijo <Tipo de datos><Prefijo campo1><Prefijo campo2>
Ejemplo CDESVIA Descripción de vía

CCODEST Código de Estado
INUMDOC Número de Documento
NPLACA Número de placa
Comentarios Si el campo está formado por una sola palabra, el prefijo de campo será de 6
caracteres, si está formado por 2 palabras, se usaran dos prefijos de campo,
cada uno de 3 caracteres. Y si está formado por más de dos palabras, se
combinaran las siguientes longitudes, 3-1-2; siempre tratando de respetar el
uso de 6 caracteres. La longitud máxima del Identificador, en algún caso
extremo, será de 9 caracteres.
2.4.11. NOMENCLATURA DE CONSTRAINTS
Prefijo Primary Key PK_<TABLA>

Altern Key AK_<TABLA>_<CORREL.TABLA>
Foreign Key FK_<TAB. ORIGEN>_<TAB. REFER.>
Default DF_<TABLA>_<CAMPO>
Check :
De Campo CKC_<TABLA>_<CAMPO>
De Tabla CKT_<TABLA>_<NOMBRE>
Ejemplo PK_RDMAEPER Clave Primaria RDMAEPER.

AK_RDMAEPER_001 Clave Alterna RDMAEPER.
FK_SGTABDOC_RDMAEPER
CKC_RDMAEPER_CODPER
Comentarios  Todo constraint debe tener un nombre de acuerdo al estándar
especificado.
 La Tabla Referencia es aquella cuyos campos deben existir en la tabla
origen (existe una relación de referencia)
 No puede incluir al #.
Versión: 02
 El Constraint Primary Key Genera un índice clustered, Unique con el

mismo nombre
 El Constraint Alternate Key Genera un índice nonclustered, Unique
con el mismo nombre
 El Constraint Foreign Key Genera un índice nonclustered, con el
mismo nombre
2.4.12. NOMENCLATURA DE INDICES
Prefijo IX_<TABLA>_<CORRELATIVO POR TABLA>

Ejemplo IX_RDMAEPER_001
Comentarios  Usar esta nomeclatura para índices que no dependen de un
constraint
 El Correlativo a usar es de 3 dígitos
2.4.13. NOMENCLATURA DE VISTAS
Prefijo <PrefijoSistema>_VW_<NombreVista>
Ejemplo FR_VW_ConsultaPersona
Comentarios En el caso que la vista sea sobre una única tabla, se adopta el
nombre de la tabla, en caso contrario se utiliza los criterios para
nombrar tablas.
2.4.14. NOMENCLATURA DE TIPOS DE DATOS
Prefijo T_<NombreTipoDato>
Ejemplo T_IMPORTE
Comentarios Usar TIPOS DE DATOS cuando se hayan definidos Dominios
2.4.15. NOMENCLATURA DE REGLAS
Prefijo R_<NombreRegla>
Ejemplo R_IMPORTE
Comentarios Usar RULES solo para user defined data types, en caso de
columnas usar CHECKS.
2.4.16. NOMENCLATURA DE DEFAULTS
Prefijo D_<Nombre_Default>
Ejemplo D_IMPORTE
Comentarios Usar DEFAULT (Procedural) solo para user definied data types, en
caso de columnas usar DEFAULT (Declarativo).
Versión: 02
2.4.17. USO DE LA SENTENCIA – USE
Uso:
USE se ejecuta en tiempo de compilación y de ejecución y surte efecto inmediatamente. Por
lo tanto, las instrucciones que aparecen en un lote después de la instrucción USE se ejecutan
en la base de datos especificada.
Use <Nombre de Base de Datos>
Ejemplo:
USE SIAT001
Consideraciones:
Esta sentencia se debe incluir antes de la cabecera en todos los Procedimientos, funciones y
Scripts que se vayan a crear y/o actualiza en la base de datos.
2.4.18. NOMENCLATURA DE PROCEDIMIENTOS ALMACENADOS Y FUNCIONES
Prefijo Procedimientos :
sp<PrefijoSistema>_<NombreObjeto>_<Acción>
spT<PrefijoSistema>_<NombreObjeto>_<Acción>
Funciones:
fn<PrefijoAplicativo>_<NombreObjeto>_<Acción>
fnT<PrefijoAplicativo>_<NombreObjeto>_<Acción>
Ejemplo  spRd_CALCULA_IV
 spTRd_RECALCULO
 fnRd_CALCULA_IV
 fnTRd_CALCULA_IV
Comentarios
El uso del prefijo (T) se utiliza solo cuando el objeto se vaya instalar en el
servidor Tributario.
Todo Procedimiento Almacenado deberá ser documentado con la siguiente estructura.
'********************************************************************************
**
'* <Descripción del Procedimiento Alamacenado>
'* Input : <Parame4tro> - Descripción de los parámetros
'********************************************************************************
**
Versión: 02
2.4.19. NOMENCLATURA DE TRIGGERS
Prefijo  Para Inserción: ti<PrefijoSistema>_<NombreTabla>

 Para Actualización: tu<PrefijoSistema>_<NombreTabla>
 Para Eliminación: td<PrefijoSistema>_<NombreTabla>
 Para Auditoria: tu<PrefijoSistema>_<NombreTabla>
 tiRd_RDMAEDEU
 tuRd_RDMAEDEU
 tdRd_RDMAEDEU
 taRd_RDMAEDEU
Comentarios Solo los Triggers de Auditoría pueden tener todas las operaciones
(Inserción, Actualización y Eliminación).
Todo Trigger deberá ser documentado con la siguiente estructura.
'********************************************************************************
**
'* <Descripción del Trigger>
'********************************************************************************
**
Versión: 02
2.5. EQUIVALENCIAS ENTRE TIPOS DE DATOS VISUAL BASIC Y SQL
TIPO DE DATOS SQL VISUAL BASIC

Tipo de Dato Tipo de dato de SQL Server Bytes Prefijo Tipo Prefijo
Dato
Character Char[(n)] C String Str
Vchar(n) V
Date and time Datetime 8 D Date Fec
Smalldatetime 4 SD
Exact numeric decimal[(p[, s])] N Single Sng
numeric[(p[, s])] N
Integer Int 4 I Long
Smallint 2 SI Int
Bit 1 B -- --
Boolean Bln
3. PISTAS DE AUDITORIA:
Las Pistas de Auditoria tendrán un alcance a todas las bases de datos creadas para los
diversos sistemas desarrollados en la Gerencia de Informática del SAT.
El Objetivo es el registro cronológico de todas las incidencias (modificaciones) que se
vayan a realizar en las bases de datos, conteniendo información como fecha, hora, usuario,
terminal y dato modificado.
Se rigen bajo tres criterios:
3.1. TABLAS AUDITABLES CON HISTÓRICO

Se aplica al registro completo de las tablas donde los sistemas de información realizan
transacciones de actualización y eliminación de datos en algún registro. Estas tablas
contarán obligatoriamente con los Desencadenadores (Trigger) que permitan dejar las
pistas de auditoria en las tablas creadas para tal fin; no hay excepción a la regla.
Las tablas que se clasifiquen Con Histórico contemplan de manera obligatoria los
siguientes campos:
 Usuario de actualización. (siCodUsu)
 Fecha y Hora de actualización. (sdFecAct)
 Terminal de actualización. (cNomTer)
Versión: 02
Para tal fin se creará una Tabla Histórica de Movimientos (Auditoria) generada por un
Desencadenador (Trigger), el cual genera el histórico de auditoria.
3.2. TABLA AUDITABLES SIN HISTÓRICO
Se aplica sobre aquellas tablas de los sistemas de información donde solamente se

realicen transacciones de inserción de datos.
Excepción: La actualización (ejecución de sentencias Delete o Update) sobre los registros
de la base de datos siempre será a través de scripts de ejecución ya sea estático ó
programado. (Scripts, Jobs ó DTS).
Estas actualizaciones se reflejarán en las tablas de auditoria correspondiente.
Las tablas que se clasifican Sin Histórico deben contemplar de manera obligatoria los
siguientes campos:
 Usuario de actualización. (siCodUsu)
 Fecha y Hora de actualización. (sdFecAct)
 Terminal de actualización. (cNomTer)
3.3. TABLA AUDITABLES POR SEGURIDAD
Para las tablas cuyo registro sea modificado y requieran de una autorización especial, se
debe contemplar un campo especial donde se almacena el código de usuario quien
autoriza dicho cambio. La identificación de las tablas será a través de la seguridad cuando
necesiten acceso a nivel de súper usuario.
Las tablas en mención deben contemplar de manera obligatoria los siguientes campos:
 Usuario de actualización. (siCodUsu)
 Fecha y Hora de actualización. (sdFecAct)
 Terminal de actualización. (cNomTer)
 Usuario que Autoriza. (siCodUsuA)
Versión: 02
4. OPTIMIZACION Y REVISION DE CODIGOS
Dentro del proceso de optimización de los códigos de los objetos de la Base Datos como los
Procedimientos Almacenados, Vistas , Desencadenadores y*o DTS. Se han determinado a la
fecha los siguientes errores comunes y que no existir en el sistema puesto que generan
lentitud y degradan la performance del Servidor:
Where a.sicodmun = 1
Declare @psicodmun Smallint

Set @psicodmun=1
Where a.sicodmun = @psicodmun
(Donde el parámetro esta definido como Int en vez de Smallint)
Estas condiciones ocasiona una conversión de datos implícita puesto que la columna
sicodmun en todas las tablas es un campo del tipo smallint, el SQL Server interpreta el
número 1 como un Entero y realiza una conversión implícita lo cual degrada la performance del
Servidor. De forma similar funciona con el parámetro mal definido.
En las pruebas que se puedan realizar en los Servidores de Desarrollo y Pre – Producción
estas sentencias no suelen ocasionar lentitud, sin embargo en el Servidor de Producción cuyo
nivel transaccional es muy alto la diferencia es notaria.
Las sentencias From al incluir varias tablas deberán ser complementadas con las sentencias
Inner Join, Left Join o Right Join sea el caso.
Este grupo de sentencias no debe usarse:
From RDMaeDeu a, RDMovDeu b, SGMaeUsu c

Where a.sicodmun = b.sicodmun And a.cnumdoc = b.cnumdoc
And a.sicodusu *= c.sicodusu
La codificación correcta sería:
From RDMaeDeu a
Inner Join RDMovDeu b On (a.sicodmun = b.sicodmun And a.cnumdoc = b.cnumdoc)
Left Join SGMaeUsu c On (a.sicodusu = c.sicodusu)
Asimismo los Join debe usar los índices declarados en las tablas y deben ser probados y
verificados mediante una PLAN DE EJECUCION (herramienta propia del SQL Server).
Considerar el uso de la Sugerencias de Bloqueo cuando las tablas involucradas dentro de las
mismas tenga un alto nivel transaccional, pero tomando en cuenta las posibilidades de las
LECTURAS FANTASMAS que pudieran ocurrir.
Las sugerencias de bloqueo que se recomienda en la lectura es NoLock.
From RDMaeDeu a (NoLock)

Inner Join RDMovDeu (NoLock) b On (a.sicodmun = b.sicodmun And a.cnumdoc =
b.cnumdoc)
Left Join SGMaeUsu (NoLock) c On (a.sicodusu = c.sicodusu)
Versión: 02
Al momento de realizar los Insert o Updates especificar que el bloqueo debe ser por registro:
RowLock
La tabulación de indentación a usar será de tres (03) espacios y se deberá conservar aparte
de la indentación un ORDEN en la codificación.
If Exists (Select a.sicodmun

From RDMaeDeu Where a.sicodmun = @psicodmun And a.cNumDoc =
@pcnumdoc)
Begin
Select .. ..
From
Inner Join .. ..
Left Join .. ..
Where .. .. And .. ..
End
Else
Begin
Select .. ..
From
Inner Join .. ..
Left Join .. ..
Where .. .. And .. ..
End
Tenga en consideración la optimización de los códigos descritos
Se debe emplear el Procedimiento Almacenado del sistema sp_executesql para disparar

cadenas de código SQL, he aquí un ejemplo:
declare @vsql1 varchar(1000)

declare @vsql2 nvarchar(1000)
declare @sicodmun smallint
declare @cnumdoc char(13)
--
select @sicodmun = 1
select @cnumdoc = '01M220558'
--
select @vsql1 = 'select * from rdmaedeu where sicodmun = ' + ltrim(str(@sicodmun)) +
' and cnumdoc = ' + char(39) + rtrim(ltrim(@cnumdoc)) + char(39)
--select @vsql1
exec (@vsql1)
--
select @vsql2 = N'select * from rdmaedeu where sicodmun = @p_sicodmun and cnumdoc =
@p_cnumdoc '
exec sp_executesql @vsql2, N'@p_sicodmun smallint, @p_cnumdoc char(13)', @p_sicodmun =
@sicodmun, @p_cnumdoc = @cnumdoc
-- select top 10 * from rdmaedeu where sicodmun = 1 and sdfecemi >= '01/06/2005 00:00'
Versión: 02
5. COMPONENTES
5.1. DEFINICIÓN DE TIPOS DE COMPONENTES
5.1.1. ESTRUCTURA DE LA APLICACIÓN
Los Componentes se definen de acuerdo al uso y función que cumplan dentro del Proceso
que van a realizar.
Dentro de un desarrollo de 3 capas se debe de considerar tres aspectos importantes

(Estructura de la Aplicación), dividiendo toda la lógica de la aplicación en Servicios de
Negocio y de Datos; separados de los Servicios de Usuario (Interfaz de Usuarios).
Servicios de Usuario (lógica de Presentación): Los elementos de la lógica de

Presentación incluyen la interfaz del usuario y otras lógicas básicas que deciden como se
mostraran los datos al usuario. Se debe de codificar separándolo siempre de la lógica de
Negocios, un cambio en los servicios de negocio "no debe de implicar" la redistribución
de ninguna interfaz de usuario (ejecutable)
Ejemplos:
FrmMantenimientoUsuarios.frm
FrmConsultaPagos.frm
Servicios de Negocio (lógica de Negocio): Son una combinación de políticas, reglas y

Algoritmos que reflejan la manera en que la empresa hace negocio.
Ejemplo:
En una aplicación de Pedidos, los descuentos dependen de volumen de la compra, esta
condición debe de ser evaluada antes de acceder a los datos
Servicios de Datos: Aquí se programaran todos los componentes que accederán a Base
de datos Consultas, Inserciones, Actualizaciones, y Eliminaciones)
5.1.2. NOMENCLATURA DE COMPONENTES
Se definen por la función que cumplen dentro de una Transacción es decir, si estas clases
tienen métodos que desencadenen o aperturen una Transacción.
Servicios de Negocio:
COMT<PrefijoSistema><NombreComponente>B
Ejemplo: ComRePagosBT, ComRdDeudaB
Servicios de Datos:
COMT<PrefijoSistema><NombreComponente>D
Ejemplo: ComRePagosD, ComRdDeudaD
Versión: 02
5.1.3. MODELAMIENTO DE COMPONENTES
Se ha optado para el diseño y modelamiento de componentes el Visual Modeler, el cual

permite una integración directa con la herramienta de programación que se esta usando.
Diagrama del Modelo de Servicio de Tres Capas del Visual Modeler
Versión: 02
5.2. CONSTRUCCION DE COMPONENTES
3.2.1 PROPIEDADES DE PROYECTO ACTIVEX DLL
Al crear un Proyecto Activex DLL se tienen que tener las siguientes consideraciones en la
configuración de sus Propiedades.
3.2.2. NOMENCLATURADE CLASES
Siguen la nomenclatura de los componentes que los contienen y se definen por la

función que cumplen dentro de una Transacción.
Servicios deNegocio:
 Clase Transaccional:
CLS<NombreClase>BT
Ejemplo: ClsPagosBT, ClsDeudaBT
 Clase No Transaccional:
CLS<NombreClase>BN
Ejemplo: ClsPagosBN, ClsNotasBN
Versión: 02
Servicios de Datos:
 Clase Transaccional:
CLS<NombreClase>DT
Ejemplo: ClsPagosDT, ClsNotasDT
 Clase No Transaccional:
CLS<NombreClase>DN
Ejemplo: ClsGeneralDN
3.2.3. PROPIEDADES DE CLASES
Las Propiedades principales que deben de configurarse en las clases dependen

del uso que estas tengan y su papel dentro de una Transacción.
 Instancing : Nos Indica si se puede crear instancias de una clase pública fuera
de un proyecto.
Valor Descripción
Prívate Si se tiene una clase dependiente de otra (véase una relación
"Padre-Hijo") en donde esta depende de otra y solo puede ser
accesada desde su "padre" (es decir, no será accesada por ninguna
otra clase que no pertenezca al proyecto Activex DLL del
"Padre")
PublicNoCreatable Si se desea crear Interfaces
MultiUse Si se va a Usar una clase para que pueda ser "llamada" por otras
Clases pertenecientes a otros proyectos (Activex DLL, Exe
Estándar, etc.)
GlobalMultiUse Igual que MultiUse pero con la diferencia que las propiedades de
esta clase pueden se accesadas como si fuesen Métodos.
Versión: 02
 MTSTransactionMode : Nos especifica el nivel de compatibilidad con el

Component Services.
Valor Descripción
NotAnMTSObject No tendrán ninguna de las mejoras que el Servicio de
Componentes brinda. Por mas que este registrado en
este.
NoTransactions No tendrá un control de Transacciones pero si se le
aplicara las ventajas del Servicio de Componentes (JIT,
Administración eficientes de recursos, etc.)
Usado para componentes de Consulta
RequiresTransaction Quiere decir que cada vez que se instancia a este
componente (entiéndase Proyecto.Clase) se apertura una
Transacción y si ya existe una Transacción activa
formara parte de esta.
UsesTransaction Esta propiedad nos indica que la clase usara una
transacción ya aperturada por otra clase. Se usa
básicamente en los esquemas de dependencia "Padre-
Hijo(s)"
RequiresNewTransaction Quiere decir que cada vez que se instancia a este

componente se apertura una nueva transacción.
Versión: 02
5.3. MANEJO DE TRANSACCIONES
Los Objetos instanciados dentro de los métodos de las clases siempre tiene que ser
destruidos:
Set nombreObjeto = Nothing
Previa confirmación de la transacción (SetComplete, EnableCommit, SetAbort o

DisableCommit) sea el caso
Estas confirmaciones están dadas por funciones ya definidas: y deben de ser colocadas
antes de "destruir el Objeto" siempre y cuando este forme parte de la transacción.
CtxSetComplete: Debe de Colocarse únicamente al final de los Proceso del método que
invoco la Transacción, en caso todos los procesos se ejecutaron correctamente
CtxSetAbort: Para Anular la instancia de la Transacción aperturada, "deshace" todos los

cambios que se produjeron en los métodos inmersos en la transacción. Se coloca igual
antes de destruir el Objeto que Inicio la Operación (Tx).
Ejemplo: Veamos la siguiente estructura de ejemplo
 COMPagosBT
 ClsPagosBT
 GrabarPago()
Function GrabarPago() as Boolean
On Error Goto ErrGrabar

Dim as Object
'Instanciando al Componente de Datos

Set ObjPagos = CreateObject("COMPagosDT.ClsPagosDT")
'Llamado al Método del Componente de Datos
ObjPagos.GrabarPagos
…
…
…
CtxSetComplete 'Confirmación de la Transacción
Set Nothing 'Destrucción del Objeto
Exit Function
ErrGrabar:
CtxSetAbort 'Anulación de la Transacción
Set Nothing 'Destrucción del Objeto
End Function
Versión: 02
CtxEnableCommit:
Función que se encarga de realizar Confirmación Parcial de una Transacción, se usa entre Métodos
de diferentes Clases participantes de una Tx .
CtxDisableCommit:
Función que se encarga de realizar Anulación Parcial de una Transacción, se usa entre
Métodos que se encuentran en diferentes Clases que participan en un Proceso
Transaccional. La Ejecución de esta según la lógica de Programación podría desencadenar
la ejecución de un CtxSetAbort.
Analicemos el Ejemplo anterior adecuándolo a estas funciones
 COMPagosBT 'Proyecto
 ClsPagosBT 'Clase
 GrabarPago() 'Método
 COMPagosDT 'Proyecto
 ClsPagosDT 'Clase
 GrabarPagos() 'Método
Function GrabarPagos() as Boolean
On Error Goto ErrGrabar

Dim ObjDetallePagos as Object
'Instanciando al Componente 'Hijo'
' Al generar una Instancia dentro de una Transacción Activa
' esta llamada forma parte del Proceso a realizar
Set ObjDetallePagos = CreateObject("COMPagosDT.ClsPagosDT")
ObjDetallePagos.RegistrarDetallePagos
…
…
…
CtxEnableCommit 'Confirmación Parcial de la Transacción
Set ObjDetallePagos = Nothing 'Destrucción del Objeto
Exit Function
ErrGrabar:
CtxDisableCommit 'Anulación de la Transacción
Set ObjDetallePagos = Nothing 'Destrucción del Objeto
End Function

 ClsDetallePagosDT 'Clase
 RegistrarDetallePagos() 'Método
Function RegistrarDetallePagos () as Boolean
On Error Goto ErrRegistrarDetallePagos

…
…
…
CtxEnableCommit 'Confirmación Parcial de la Transacción
Versión: 02
RegistrarDetallePagos = True
Exit Function
ErrRegistrarDetallePagos:
CtxDisableCommit 'Anulación de la Transacción
End Function
5.4. GENERACION DE COMPONENTES

(COMPILACION)
Se debe de tener las siguientes consideraciones al compilar o generar Proyectos Activex

DLL.
Compatibilidad de Versión: Si nunca antes se ha generado una DLL del proyecto debe
se seleccionarse generar "Sin Compatibilidad".
Una vez compilado el Archivo este

debe de generarse nuevamente
seleccionado Compatibilidad
Binaria y referenciado a la DLL
anteriormente creada. En la fase de
desarrollo o mantenimiento y
posterior a una primera generación
se debe de trabajar usando
compatibilidad de Proyectos para el
sistema busque compatibilidad con
los cambios realizados y no directamente con el archivo ya compilado seleccionado en la casilla de
ubicación del archivo DLL
Versión: 02
Observación: Así como se debe de tomar cuidado de algunas propiedades al momento

de Compilar los proyectos Activex DLL, se tiene que tener en cuenta algunas otras para el
Proyecto Exe Estándar.
Al momento de Trabajar en el Mantenimiento o Modificación de los Ejecutables debe de

configurarse en Opciones del Proyecto lo que es el manejo de Interceptación de Errores
6. TRATAMIENTO DE ERRORES
Dentro de este esquema se tienen que contemplar el darle un trato adecuado cuando se
produzca un error dentro del programa, podemos distinguir los errores de tipos lógicos (propios
de nuestra lógica de programación) y los errores externos al flujo normal del programa
(problemas de Acceso, en la red, de Impresión, etc.) que si bien no tienen que ver con el
desempeño normal del sistema no deben de ser causales caídas del programa sino deben de
ser contempladas y manejadas.
Dentro de este tema se debe de tener en cuenta los siguientes Puntos
6.1. REGISTRO DE ERRORES (ARCHIVO LOG)
Sirven de ayuda al Programador para registrar los errores producidos para su posterior
revisión y Corrección. Este manejo se aplicara básicamente en los componentes de Datos
que son donde se pueden producir los errores que son menos fáciles de manejar y cuyos
mensajes no son nada claros para los usuarios pero si descriptivos para un desarrollador.
Versión: 02
Se manejara un Componente No Transaccional que se encargara de registrar estos errores

este manejo trabajara de la mano con los mensajes de Errores anteriormente tratado (un
mensaje "amigable" para el usuario y un mensaje descriptivo y puntual para un
programador)
Existe un método "RegistrarLog" que tiene los siguientes parámetros:
strAppPath : Ruta Aplicativo + Nombre Proyecto

p.e.: App.Path & "\ComPagosDT"
strNomClase : Nombre de la Clase desde donde se invoco el error

strNomMetodo : Nombre del Método que generó el Error
lngErrNumber : Id. del Error Generado (Err.Number)
strErrDesc : Descripción del Error
[strUsuarioRed] : Usuario de Red de donde se generó el Error

[intSiCodUsu] : Código de Usuario del Sistema
[strcNomTer] : Nombre del Terminal que generó el Error
[blnSeparador] : Indica si se considerara separador de bloque. Este se dará o utilizara para separar
los errores producidos dentro de una Transacción, facilitando su identificación y futura corrección
Uso: El uso de esta clase se recomienda utilizarlo en los métodos de los componentes de
datos.
 COMPagosD
 ClsPagosDT
 GrabarPagos
 ClsDetallePagos
Public Function GrabarPagos(ByVal vRst As Object, _

ParamArray sParams() As Variant) _
As Boolean
On Error Goto ErrPagos

Dim strUserRed As String, intCodModulo As Integer
Dim intSiCodUsu As Integer, strcNomTer As String
Dim Params As Variant, intError As Integer
'Clase se encuentra en el Proyecto ComPagosD

'podemos utilizar "Early Binding" para instanciarlo
Dim ObjDetalle As ComPagosD.ClsDetallePagos
Set ObjDetalle = New ComPagosD.ClsDetallePagos
…
…
…
CtxEnableCommit
Set ObjDetalle = Nothing
GrabarPagos = True
Exit Function
ErrLoad:
CtxDisableCommit
Versión: 02
Params = sParams(0)
intError = err.Number
strUserRed = IIf(Params(0)(0) = "", "", Params(0)(0))

intSiCodUsu = IIf(Params(0)(1) = "", "", Params(0)(1))
strcNomTer = IIf(Params(0)(2) = "", "", Params(0)(2))
IntCodModulo = IIf(Params(0)(3) = "", "", Params(0)(3))
' Registro de Error Producido

Set ComError = CreateObject("ComErrorLog.ClsErrorLog")
ComError.RegistrarLog App.Path & "\ComPrueba", kNombreClase, _

"GrabarPago", Err.Number, _
Err.Description, strUserRed, _
intSiCodUsu, strcNomTer, True
strErrDescripcion = ComError.MetododeMsgError(intCodMod, _
intError)
Set ComError = Nothing

'Generación de Error Personalizado para Cliente
Err.Raise vbObjectError + 100, kNombreClase, _
strErrDescripcion
End Function
El cual generara un archivo con la siguiente estructura:
Como se ve, engloba los errores producidos en el método de "Procesar" indicando donde
se origino el error (ProcesarDetalle).
Versión: 02
6.2. NIVELES EN EL MANEJO DE ERRORES
Existen diversas maneras de tratar un error ya sea en el lado del usuario (interface) o en
los módulos de clase de los componentes, pero es aquí donde se tomaran y especificaran
algunas pautas para poder asegurar un correcto "registro" y "manipulación", tratando de
evitar inconvenientes al momento de implantarlos.
Vamos a centrarnos solamente en lo que respecta a registro y manejo de errores, el

manejo personalizado de mensajes no se tomara en cuenta en este ejemplo.
Servicio de Datos: Se Tiene
 ComPruebaD 'Componente
 ClsPruebaDT 'Clase
 Procesar 'Método
 ClsDetallePruebaDT 'Clase
 ProcesarDetalle 'Método
Function Procesar(ByVal blnErrPadre As Boolean, _

ByVal blnErrDetalle As Boolean, _
ParamArray sParams() As Variant) As Boolean
On Error GoTo ErrProcesar
Dim BlnOk As Boolean

Dim ObjError As ComErrorLog.ClsErrorLog
Dim params As Variant, strUsuarioRed As String,
Dim strcNomTer As String, intA As Integer, intB As Integer
Dim strDesc As String, intSiCodUsu As Integer
params = sParams(0)
'"Early Binding"
Dim ObjDetalle As ComPruebaD.ClsDetallePruebaDT
Set ObjDetalle = New ComPruebaD.ClsDetallePruebaDT
IntB = 0
If blnErrPadre Then intA = 10 / intB
ObjDetalle.ProcesarDetalle blnErrDetalle, params
CtxEnableCommit
Procesar = True
Exit Function
ErrProcesar:
CtxDisableCommit
strDesc = Err.Description
Versión: 02
strUsuarioRed = sParams(0)(0)
intSiCodUsu = sParams(0)(1)
strcNomTer = sParams(0)(2)
Set ObjError = CreateObject("ComErrorLog.ClsErrorLog")
ObjError.RegistrarLog App.Path & "\ComPruebaD", _

kNombreClase, "Procesar", _
Err.Number, Err.Description, _
strUsuarioRed, intSiCodUsu, _
strcNomTer, True
Set ObjError = Nothing
Err.Raise vbObjectError + 100, kNombreClase, strDesc
End Function
Function ProcesarDetalle(ByVal blnError As Boolean, _

ParamArray sParams() As Variant) _
As Boolean
On Error GoTo ErrProcDetalle
Dim strUsuarioRed As String, intSiCodUsu As Integer

Dim strcNomTer As String, strDesc As String
Dim ObjError As ComErrorLog.ClsErrorLog, intA As Integer
'Generando un Error: "13 - No Coinciden los Tipos"

If blnError Then intA = "Una Cadena Cualquiera"
ProcesarDetalle = True
CtxEnableCommit
Exit Function
ErrProcDetalle:
CtxDisableCommit
strDesc = Err.Description
strUsuarioRed = sParams(0)(0)
intSiCodUsu = sParams(0)(1)
strcNomTer = sParams(0)(2)
Set ObjError = CreateObject("ComErrorLog.ClsErrorLog")
ObjError.RegistrarLog App.Path & "\ComPruebaD", _

kNombreClase, "Procesar", _
Err.Number, Err.Description, _
strUsuarioRed, intSiCodUsu, _
strcNomTer, False
Set ObjError = Nothing

Versión: 02
Err.Raise vbObjectError + 100, kNombreClase, strDesc
End Function
Servicio de Negocio: Se tiene
 ComPruebaB 'Componente
 ClsPruebaBT 'Clase
 Procesar() 'Método
Function Procesar(ByVal blnErrorPadre As Boolean, _

ByVal blnerrDetalle As Boolean, _
ParamArray sParams() As Variant) As Boolean
On Error GoTo ErrProcesar
Dim ObjPruebaDT As Object

Dim blnOk As Boolean
Dim params As Variant
params = sParams(0)
Set ObjPruebaDT = CreateObject("ComPruebaD.ClsPruebaDT")
blnOk = ObjPruebaDT.Procesar(blnErrorPadre, blnerrDetalle, params)
CtxSetComplete
Set ObjPruebaDT = Nothing
Exit Function
ErrProcesar:
CtxSetAbort
Set ObjPruebaDT = Nothing
Err.Raise vbObjectError + 100, kNombreClase, Err.Description
End Function
Servicios de usuario: El Manejo es transparente para el lado del cliente el cual

simplemente muestra el error de la sgte. Manera: Err.Description
Nota: Debe de tomarse en cuenta que este manejo es independiente del que puede
programarse para controlar errores de impresión o algún otro algoritmo en el lado del
Cliente, es solo para tratar los errores devueltos en la invocación de los métodos de
nuestros componentes.
Versión: 02
Private Sub cmdErrores_Click()
On Error GoTo ErrPrueba
Dim ObjPrueba As Object
Set ObjPrueba = CreateObject("ComPruebaB.ClsPruebaBT")

ObjPrueba.Procesar _
IIf((chkErrPadre.Value = 1), True, False), _
IIf((chkErrDet.Value = 1), True, False), _
Array("RPACHAS", 431, "RICARDOP")
Set ObjPrueba = Nothing
Exit Sub
ErrPrueba:
Set ObjPrueba = Nothing
MsgBox Err.Description
End Sub
Versión: 02
7. DISEÑO DE PANTALLAS
6.1 ESTANDARES DE PANTALLAS
Existen diversos tipos de pantallas a trabajar, cada una con

un propósito y fin determinado como por ejemplos las pantallas de Mantenimiento, Proceso,
Consultas y Reportes, y en algunos casos pantallas con propósitos particulares p.e. Pantalla
del MAP (Modulo de Atención al Público) la cual tiene un manejo con mucha mayor
"complejidad"
Empezaremos definiendo los estándares en el diseño de pantallas para un Mantenimiento

estándar
En la siguiente imagen se muestra una pantalla típica de un mantenimiento la cual esta

compuesta por 4 secciones principales:
 (1) Botones de Mantenimiento.
 (2) Criterios de Búsqueda y Estado.
 (3) Sección de Datos.
 (4) Sección de Botones de Proceso.
Versión: 02
7.1.1. BOTONES DE MANTENIMIENTO
En esta sección van todos los botones que tienen que ver con el proceso en si del
mantenimiento: Adicionar, Modificar, Eliminar, Restaurar, Vista Preliminar, Imprimir, Ayuda
y Salir. Sub Agrupados de acuerdo a su funcionalidad.
Todos los botones de comando considerados de consultas se configurara su propiedad
"Tag" el valor "C" y las de actualización, Inserción o procesos con una "A"
Tabla de Botones de Comando y Búsqueda

Icono Función TAG
[F1] : Botón de Ayuda -
[F2] : Botón de Nuevo A
[F3] : Botón de Edición A*
[F4] : Botón de Eliminar A
[F5] : Botón de Refrescar o Actualizar Datos -
[F6] : Botón de Grabación / Actualización A
[F7] : Botón de Deshacer o Restablecer del estado de Edición -
[F8] : Vista Preliminar C
[F9] : Botón de Imprimir C*
[F10] : Botón de Procesar A
[F12] : Botón de Búsqueda C
[ESC] : Botón de Salir -
Versión: 02
* Algunos de estos botones depende de permisos especiales los cuales se trabajaran de

manera separada de manera conjunta con el modulo de Seguridad
7.1.2. SECCION DE CRITERIOS DE BUSQUEDA Y ESTADO
En esta sección se definen todos los filtros o criterios de búsqueda de datos agrupados
dentro de un Objeto de tipo Frame, para facilitar la ubicación de los mismos. Además
contiene una etiqueta de ayuda para el usuario respecto al estado del mantenimiento
(Consulta, Edición y Nuevo)
Consideraciones y Ubicación
 Distancia de separación entre botones de mantenimiento y frames y/o Tabs : 75.
 No se usara la propiedad Caption del Objeto Frame para definir el Titulo de este sino
se hará uso de una Etiqueta (esto es para efectos de no "ensombrecerlo" cuando el
frame se "inhabilite" (en los casos de "Edición o Adición")
7.1.3. SECCION DE DATOS
En esta parte se mostrara el resultado de la búsqueda realizada por el usuario, esta

sección esta formada por el objeto SSTAB, el cual contiene "tabs" o "separadores" en
mayor o menor cantidad dependiendo del tipo de mantenimiento que se este dando, en
principio se reconocen dos: Área de datos Generales y la de Detalles
Versión: 02
Ejemplo de Estructura de Directorios de Trabajo:
FUENTES
FUENTES
FR
RE
GE
IX
CC
DOCUMENTOS
FR
FASE INCEPCION
RE
FASE ELABORACION
GE
FASE CONSTRUCCION
IX
FASE TRANSICION
CC
INSTALADORES
EJECUTABLES
Versión: 02
Según documento “GIN-DDM-DT001: Metodología de Desarrollo Software” El Jefe de Proyecto,

Especialista ó Analista según corresponda es el responsable de controlar y actualizar los
documentos en los directorios especificados. Se recomienda que cada Analista Programador
desarrolle sus programadas ó formularios en sus discos locales y una vez verificados y probados
por el Analista de Sistema, éstos serán almacenados (copiados) en los directorios respectivos del
proyecto SIAT. Los archivos se guardarán en el directorio X:\
8. DISEÑO DE REPORTES
8.1. ESTRUCTURA DE LOS REPORTES
ESTRUCTURA DESCRIPCION
ENCABEZADO Campos requeridos para identificar el reporte
CONTENIDO Contenido, agrupaciones, sub totales del reporte
PIE DE PAGINA Valores de emisión, páginas, fecha, hora.
LINEAS DE DIVISION Separa en tres secciones el reporte(Solo Impresora láser)
7.2. CARACTERISTICAS
NOMBRE DESCRIPCION FUENTE FUENTE TAMAÑO NEGRITA MAYUS ALINEACION

LASER MATRICIAL
ENCABEZADO
Logotipo Logotipo Institucional - - 1.5 x 1.5 - - Izquierda

Titulo Titulo del reporte Arial Draft 17 CPI 8 Si Si Centrado
Sub Titulo Sub Titulo del reporte Arial Draft 17 CPI 8 No Si Centrado
Institución Nombre de la Institución Arial Draft 17 CPI 6 No Si Izquierda
Filtro Criterio de Selección Arial Draft 17 CPI 8 No Si Centrado
CONTENIDO
Total Totalizador Arial Draft 17 CPI 6 Si Si Inferior

Columna Nombre de Columna Arial Draft 17 CPI 8 Si Si Centrado
Sub Total Totalizador Arial Draft 17 CPI 6 Si Si Inferior
Líneas Líneas Continuas - Draft 17 CPI 8 - - Centrado
Dato Datos del reporte Arial Draft 17 CPI 6 No - Centrado
USUARIO
Usuario Nombre de Usuario Arial Draft 17 CPI 5 No Si Inferior

Hora Hora de emisión Arial Draft 17 CPI 5 No Si Inferior
(hh:mm:ss)
Fecha Fecha de Arial Draft 17 CPI 5 No Si Inferior
emisión(dd/mm/yyyy)
Terminal Nombre del Equipo Arial Draft 17 CPI 5 No Si Inferior
Páginas Pagina N de M Arial Draft 17 CPI 5 No Si Inferior /
Derecha
Versión: 02
Código Nombre o Código del Arial Draft 17 CPI 5 No No Izquierda

Reporte
Modulo Nombre del Modulo Arial Draft 17 CPI 5 No No Izquierda
Agencia Nombre de Agencia Arial Draft 17 CPI 5 No Si Centrado
UOR Unidad Organizativa Arial Draft 17 CPI 5 No Si Izquierda
7.3. MARGENES
Margen Tamaño
Superior 1 cm.
Inferior 1 cm.
Derecho 2 cm.
Izquierdo 1 cm.
7.4. DEL FORMATO
Encabezado Cuerpo Pie de Página
Logotipo Total Usuario

Titulo Sub Total Fecha y Hora
Sub Titulo Columna Terminal
Filtro Dato Paginas
Institución Agencia
UOR
Versión: 02
PROTOTIPO DE REPORTE
<<INSTITUCION>>
Servicio de Administración Tributaria
<<INSTITUCION>>
LOGOTIPO <<TITULO DEL
REPORTE>>
<<SUB TITULO>>
<<FILTRO>>
<<COLUMNA>> <<COLUMNA>>
… <<COLUMNA>> <<COLUMNA>>
… … … …
… <<DATO>> … …
… … …
<<SUB TOTAL>> … … … …
… … <<DATO>> …
… … … …
… … … …
<<SUB TOTAL>> ….. ….. ….. …..

<<TOTAL>> …… …… …… ……
<<MODULO>> <<UOR>>
<<USUARIO>> <<TERMINAL>> <<AGENCIA>> <<FECHA Y

HORA>>
<<CODIGO>> <<PAGINAS>>
7.5. CONSIDERACIONES
 Para el Pase a Producción de cualquier reporte y/ó formato, se debe adjuntar al

pase, el sustento de aprobación de la Gerencia de Organización y Racionalización
(copia de reporte y/ó formato aprobado).
 El Logotipo Institucional debe de estar en Escala de Grises por cuestiones de
rapidez en las emisiones masivas.
 El Dato cuando sea de tipo numérico debe de estar alineado a la derecha y cuando
sea de tipo de texto se debe de alinear en forma centrada.
 Considerar 2 decimales para datos numéricos.
No se debe consignar ningún valor en el reporte, cuando en la base de datos
esta el valor Cero(0) o tiene registrado Null.
 Para una impresora matricial no se utiliza el Logotipo Institucional, las líneas deben
ser punteadas (-) y el tamaño de fuente a utilizar es 7
 Considerar las mismas características cuando el formato sea horizontal o vertical.
 Usar como separador de miles una coma (,) y (.) como símbolo decimal.
Versión: 02
 Utilizar 2 decimales para valores de tipo porcentual

 En el caso del dato se debe tomar como se encuentre registrado en la base de
datos.
 En los cuadros, cada ítem se numerará en forma correlativa.
7.6. EXCEPCIONES
 Los reportes pueden ser modificados pero siempre respetando el diseño y formato
básico propuesto.
 No utilizar líneas, negritas ni sombreados adicionales a los ya establecidos,
excepcionalmente y en caso de ser necesario, se podrán utilizar líneas, negritas o
sombreados no establecidos.
 Cuando la cantidad de columnas excede el tamaño permitido por el tipo de hoja, el
reporte se puede ajustar y variar el tamaño de fuente pero se debe considerar una
visualización y organización optima para el reporte.
9. NOTACION UML EN LA METODOLOGIA DE DESARROLLO DE SOFTWARE
El presente ítem otorga lineamientos para la elaboración de los diversos diagramas

utilizados en el desarrollo de entregables, según hace mención el documento: “GIN-DDM-
DT001_Metodología de Desarrollo Software”. Si bien por cada entregable se tiene definido
una plantilla a seguir, para la elaboración de algunos insumos tales como diagramas se
tendrá como referencia los diversos diagramas descritos por la Notación UML
Notación: Sistema de signos convencionales que se adopta para expresar conceptos

sistémicos, matemáticos, físicos, químicos, etc.
UML: Unified Modeling Language – Lenguaje de Modelado Unificado
Notación UML: Es un estándar para modelar todos aquellos elementos que configuran la
arquitectura de un software y por extensión de los procesos de una organización. De la
misma manera que los planos de un arquitecto disponen el esquema director a partir del
cual levantamos un edificio, los diagrama UML suministran un modelo de referencia para
formalizar los procesos, reglas de negocio, objetos y componentes de una organización. La
interacción de todos estos elementos es una representación de nuestra realidad.
Versión: 02
9.1. DIAGRAMA DE CASO DE USO (NEGOCIO)
9.1.1. ELEMENTOS Y NOTACIÓN DE CASO DE USO DE NEGOCIO
8.1.1.1. Actor de Negocio:
Es la persona o ente externo que al interactuar con el negocio genera la

ejecución de procesos.
 Notación:
Actor de Negocio
(f rom Business Use-Case Model)
 Criterios para nombrar un Actor de Negocio:

Para definir actores se tomará el nombre asignado por función
institucional definido en el MOF-SAT.
Para generalizar actores que cumplan un rol común, se definirá un
nombre que represente el rol y el máximo de caracteres permitido es de
veinte (20).
Ejemplo:
Deudor Tributario
8.1.1.2. Trabajador de Negocio:
Es la Persona o área del negocio que realiza las actividades internas

del proceso de negocio
 Notación:
Trabajador de Negocio
(f rom Actors)
 Criterios para nombrar un Trabajador de Negocio:

Para definir actores se tomará el nombre asignado por función
veinte (20).
Versión: 02
Ejemplo:
Ejecutor
8.1.1.3. Caso de Uso de Negocio:
Proceso de negocio que beneficia o perjudica a uno o más actores de negocio.
 Notación:
Caso de Uso de Negocio

(from Business Use-Case Model)
 Criterio para nombrar un Caso de Uso de Negocio:

Para nuevos casos de uso se definirá el nombre según el proceso de
negocio que estos representen. La cantidad máxima de caracteres para
el nombre es de cincuenta (50) caracteres.
Ejemplo:
Suspensión del procedimiento de ejecución coactiva
8.1.1.4. Asociación:
Asociación
Versión: 02
8.1.1.5. Plantilla de Diagrama de Caso de Uso de Negocio:
Nombre de Diagrama de Caso de Uso de Negocio
Actor de Caso de Uso de Negocio 1

Negocio
Caso de Uso de Negocio 2 Trabajador de Negocio

<<extend>>
Caso de Uso de Negocio 3
9.1.2. ELEMENTOS Y NOTACIÓN DE DIAGRAMA DE ACTIVIDAD DE NEGOCIO:
8.1.1.6. Actividad:
Actividades de negocio que pueden ser implementadas como

requerimientos funcionales.
 Notación:
Actividad 1
 Criterio para nombrar una Actividad:

Se definirá el nombre según la actividad que represente, apoyándose
en el procedimiento alusivo al proceso de negocio en mención.
Ejemplo:
Identificar Causales proporcionadas por el administrado
Versión: 02
8.1.1.7. Condición:
 Notación:
 Criterio para nombrar una condición:

Se definirá una condición a manera de pregunta, entre símbolos de
interrogación: “¿?”.La cantidad máxima de caracteres es de veinte (20)
caracteres.
Ejemplo:
¿Deuda u obligación esta prescrita?
8.1.1.8. Plantilla de Diagrama de Actividad de Negocio:
Unidad Organizacional 1 Unidad Organizacional 2 Unidad Organizacional 3
Nombre de Diagrama de Actividad

(Negocio)
Inicio
Actividad 1 Condición 1
No
Si
Actividad 2 Actividad 3
Sincronizador 1
Actividad 4 Actividad 5
Fin
9.2. DIAGRAMA DE CASO DE USO (SISTEMA):
Los Casos de Uso son una técnica para capturar información de cómo un software o
negocio trabaja o de cómo se desea que trabaje.
9.2.1. PROPÓSITO:
Para los diagramas de casos de uso (sistema) es presentar los requerimientos

funcionales y los actores de sistema que interactúan con estos.
Versión: 02
9.2.2. ELEMENTOS (SISTEMA)
8.1.1.9. Paquete:
Es utilizado cuando el software en desarrollo, este distribuido por

módulos ó procesos de negocio claramente establecidos. Cada paquete
contendrá un conjunto de casos de uso que trabajan estrechamente.
 Notación:
Paquete 1
 Criterios para nombrar un Paquete:

Un paquete si esta definido por una sola palabra, debe tener un
máximo de quince (15) caracteres.
Un paquete si esta definido por palabras compuestas, debe contener
máximo cuarenta (40) caracteres.
Sintaxis:
<<Nombre>> ó <<nombre1_nombre2>>
Ejemplo:
Control y Cobranza Tributario
8.1.1.10. Actor de Sistema:
 Notación:
Actor de Sistema
(f rom Use Cases)
 Criterios para nombrar un Actor de Sistema:

Para nombrar un actor se tomará el nombre original de los actores de
negocio definidos en el Modelo de Negocio.
Para nuevos actores se tomará el nombre asignado por función
veinte (20).
Versión: 02
8.1.1.11. Caso de Uso:
 Notación:
Caso de Uso
(from Use Cases)
 Criterio para nombrar Casos de Uso:

Para nuevos casos de uso se definirá el nombre según el requerimiento
definidos por los usuarios y la funcionalidad que estos representen,
anteponiendo un verbo en infinitivo. La cantidad máxima de caracteres
para el nombre de una funcionalidad es de cuarenta (40) caracteres.
La siguiente tabla asigna verbos estándares por funcionalidades

tradicionales:
Verbo Funcionalidad
Definir Personal, Contribuyente, Parámetros de
Aplicación, Articulo, Catalogo de, Cuenta,
Cartera de, Lote…
Consultar Personal, Contribuyente, Parámetros de
Aplicación, Articulo, Catalogo de Artículo,
Cuenta, Lote, Nota de Crédito…
Seleccionar Personal, Contribuyente, Parámetros de
Aplicación, Articulo, Catalogo de Artículo, Lote,
Detalle de Remesa, Detalle de Petición…
Realizar Un proceso de: Venta, Arqueo, Inicio de Día, Fin
de Día, Declaración Anual, Pedido, Inventario,
Apertura de, Cierre de, Regularización de Stock,
Devolución de Ítem, Pago, Abono, Orden de
Transferencia, Notificación de, Configuración
de…
Entrar Línea de Venta, Calificaciones, Línea de
Transacción, Lote de, Factura de Agente,
Variable, Regla de Negocio, Ítem en una Cartera,
Clave Contable, Incidencia…
Imprimir Documento: Ticket de, Contrato, Expediente,
Cuenta, Formulario…
Actualizar Catalogo de, Plan de Cuentas, Personal,
Contribuyente, Resultados, Transacciones…
Calcular Importe de Línea, Descuento de, Impuesto de,
Total Factura, Riesgo Comercial, Retribuciones,
Número de Lotes…
Versión: 02
Procesar Movimientos de Cuentas, Pedidos, Facturas,

Generación de Asientos, Paquetes de Datos…
Validar Entrada de un Campo, Regla de Negocio, Nivel
de Acceso,
Vincular Personal relacionado, Cobros, Expedientes,
Diagnósticos, Prestaciones, Servicios,
Procedimientos…
Autorizar Transacción, Acceso, Habilitación, Afiliación,
Solicitud, Prestación, Pago, Transferencia…
Solicitar Requerimiento, Catalogo de Artículos, Lotes…
8.1.1.12. Relación:
 Notación:
Relación
 Criterio para nombrar Relaciones:

Ver ítem 8.1.6
9.2.3. TIPOS DE ACTORES (SISTEMA)
8.1.5.1. Actores Principales: Son los actores que interactúan directamente con
el software. Se identificará al actor con el color
marrón:
Actor
(f rom Use Cases)
8.1.5.2. Actores Secundarios: Son los actores que administran y dan soporte al
software. Se identificará al actor con el color
plomo:
Actor
(f rom Use Cases)
Versión: 02
8.1.5.3. Material Externo: Son los actores que representan a otros materiales
tipo hardware que interactúan con el software que se
encuentra en desarrollo. Se identificará al actor con
el color verde:
Actor
(f rom Use Cases)
8.1.5.4. Otros Sistemas: Son los actores que representan a otros software que
interactúan (consultan o brindan información) con el
software que se encuentra en desarrollo. Se
identificará al actor con el color azul:
Actor
(f rom Use Cases)
9.2.4. TIPOS DE RELACIÓN Ó ESTEREOTIPOS (SISTEMA)
8.1.6.1. Relación de Comunicación: Relación entre un actor y un caso de uso.

La relación entre ambos estará dada por la
representación de una flecha continua.
Caso de Uso
Actor (from Use Cases)
(f rom Use Cases)
Versión: 02
Ejemplo:
Personal SAT Dar Conformidad
(f rom Use Cases)

(from Use Cases)
8.1.6.2. Relación de Inclusión: Relación que indica el uso de un caso de uso

destino compartido, por el llamado de un caso
de uso origen. La relación entre ambos caso de
uso estará dada por la representación de una
flecha discontinua apuntando de caso de uso
origen a destino.
<<include>>
Caso de Uso Origen Caso de Uso Destino

(from Use Cases) (from Use Cases)
Ejemplo:
<<include>>
Registrar Requerimiento Enviar Correo

8.1.6.3. Relación de Extensión: Relación donde el caso de uso origen extiende

el comportamiento al caso de uso destino. La
relación entre ambos caso de uso estará dada
por la representación de una flecha discontinua
apuntando de caso de uso destino a origen.
Versión: 02
<<extend>>
Caso de Uso Origen Caso de Uso Destino

Ejemplo:
<<extend>>
Consultar Requerimiento Consultar Detalle Requerimiento

9.2.5. COMO IDENTIFICAR ACTORES
Una alternativa para la identificación de Actores es dar respuesta a la siguiente

lista de preguntas:
¿Quién esta interesado en un requerimiento concreto?
¿Quién será beneficiario de la nueva funcionalidad?
¿Quién proveerá, usará y/o retirará información?
¿Quién dará soporte y administrará el software?
¿Usará el software un recurso externo?
¿Un usuario actuará con diferentes roles?
¿Diferentes usuarios actuarán con un mismo rol?
¿Interaccionará el nuevo software con un software antiguo?
9.2.6. COMO IDENTIFICAR CASOS DE USO
Una alternativa para la identificación de Casos de Uso es dar respuesta a la

siguiente lista de preguntas:
¿Cuáles son las tareas y responsabilidades de cada actor?
¿Algún actor creará, almacenará, cambiará, borrará o leerá información del
software?
¿Qué casos de uso crearán, almacenarán, cambiarán, borrarán ó leerán esta
información?
¿Es necesario que un actor informe al software sobre cambios externos?
¿Es necesario que un actor sea informado sobre ciertas incidencias del
software?
¿Qué casos de uso darán soporte y mantendrán el software?
¿Pueden ser realizados por los casos de uso todos los requerimientos
funcionales documentados?
Versión: 02
9.2.7. PLANTILLA DE DIAGRAMA DE CASO DE USO (SISTEMA)
Nombre de Diagrama de Caso de Uso
Actor 1 Caso de Uso 1

Actor 3
Caso de Uso 2
Caso de Uso 3
<<extend>> <<include>> Actor 2
Caso de Uso 4 Caso de Uso 5
9.3. DIAGRAMA DE CLASES:
9.3.1. PROPÓSITO
Presenta el dominio del sistema por medio de sus clases, relaciones
estructurales yherencia.
9.3.2. DEFINICIÓN DE OBJETO

Un objeto representa una entidad del mundo real ó inventado. Su estructura es
la siguiente, por cada uno se muestra la función que desempeñan:
 Identidad ¿Quién Soy? = Atributos
 Propósito ¿Cuál es mi misión? = Justificación
 Responsabilidades ¿Qué debo hacer? = Métodos
 Procedencia ¿De que clase provengo? = Origen
 Relaciones ¿Qué mensajes entiendo?=Comportamiento
Versión: 02
9.3.3. DEFINICIÓN DE CLASE - PERSPECTIVA CONCEPTUAL

Una clase representa un conjunto de objetos que comparten atributos, métodos
y
9.3.4. DEFINICIÓN DE CLASE - PERSPECTIVA FÍSICA

Una clase es una pieza de software que actúa como un molde para fabricar
tipos particulares de objetos que disponen de los mismos atributos y métodos.
9.3.5. ELEMENTOS Y NOTACIÓN
8.2.5.1. Clase:
 Notación:
Clase Nombre de Clase
Atributo Publico
Nombre de Atributo. Adicional
Atributo Protegido
según la herramienta de
Atributo Privado
modelado seleccionar icono que
Atributo Implementacion indique el tipo de atributo.
Metodo Publico()
Metodo Protegido() Nombre de Método. Adicional
Metodo Privado() según la herramienta de
Metodo Implementación()
modelado seleccionar icono que
indique el tipo de método.
 Criterios para nombrar una Clase:

El nombre de una clase debe definirse siempre en singular y debe
representar a un sustantivo dentro de una oración, debe tener un
máximo de veinte (20) caracteres.
Para el caso de clases que necesiten tener un nombre compuesto
de dos palabras, el máximo será de treinta (30) caracteres.
Sintaxis:
<<Nombre>> ó <<nombre1_nombre2>>
Ejemplos:
 Unidadorganizacional
 Requerimiento
8.2.5.2. Asociación: Es la relación entre dos clases y se recomienda que el

nombre de la relación inicie con un verbo en infinitivo.
Puede presentar alguna de las siguiente calrdinalidades:
Versión: 02
 Notación:
Uno a Uno
Clase 1 Nombre de la Relacion Clase 2
1 1
Uno a Muchos
1 n
Muchos a Muchos
n n
 Criterio para nombrar una Asociación:

El nombre de una asociación debe ser un verbo simple ó compuesto.
A continuación se lista verbos estándares a utilizar para nombrar a
una asociación:
Verbos Tipos
Contiene Verbo Simple
Tiene Verbo Simple
Realiza Verbo Simple
Pertenece a Verbo Compuesto
Esta asociado Verbo Compuesto
Solicita Verbo Simple
9.3.6. HERENCIA
Es el mecanismo por el cual una clase puede ser definida como un caso
especial de otra clase más genérica. Los casos especiales de una clase se
denominan Subclases. La clase más genérica se conoce como Superclase de
todos sus casos especiales.
Además de todos sus métodos y atributos que heredan, las Subclases definen
sus propios métodos y atributos.
Versión: 02
SuperClase
es un
Subclase 1 Subclase 2
Ejemplo:
Vehiculo de Carga
es un
Vehiculo Carga Papeles Vehiculo Carga Bobinas
8.1.2. Plantilla de Diagrama de Clases:
Nombre de Diagrama de Clases
contiene Clase 1 tiene Clase 2

Superclase
n 1 1 1
1
es un realiza
n
Subclase 1 Subclase 2 Clase 3
Versión: 02
9.4. DIAGRAMA DE ESTADOS
En el diagrama de estado a partir de una clase se muestra el comportamiento de un

objeto durante su ciclo de vida. Se debe resaltar que estos diagramas son muy útiles
para describir el comportamiento de un objeto a través de múltiples casos de uso.
9.4.1. PROPÓSITO
Presentar el funcionamiento interno de clases individuales.
8.1.2.1. Inicio:
 Notación:
 Criterio para nombrarlo:

Por estándar se definirá la siguiente etiqueta: “Inicio”
8.1.2.2. Estado Final:
 Notación:

Por estándar se definirá la siguiente etiqueta: “Estado Fin”
8.1.2.3. Estado:
 Notación:
Nombre de
Estado
 Criterio para nombrar un Estado:

El nombre de un estado será compuesto.
Se antepone el nombre de la Clase, seguido del símbolo underline
“_”, y finalmente el estado por el cual pasa dicha clase. En este
último caso debe contener un máximo de quince (15) caracteres.
Sintaxis:
<<nombreclase>>_<<nombreestado>>
Versión: 02
Ejemplo:
Requerimiento_En Proceso
8.1.2.4. Transición / Evento:
 Notación:
Transición: Procesos que ocurren de manera rápida dentro de un

ciclo continúo sin interrupción. Colocar nombre de
transición sobre flecha continua.
Evento: Desencadenado siempre por la Transición. Colocar nombre

del evento sobre flecha continua.
 Criterios para nombrarlo:

El nombre de una Transición será una acción identificada, que
permitirá que la clase tenga un estado determinado, el nombre debe
contener un máximo de treinta (30) caracteres. De manera opcional
irá entre corchetes un indicador, resultado de la acción.
Sintaxis:
<<nombretransicion>>/[indicador]
Ejemplo:
Se atiende Requerimiento
El nombre de un Evento será el proceso desencadenado por una

transición, el nombre debe contener un máximo de treinta (30)
caracteres.
Sintaxis:
<<nombreevento>>
Ejemplo:
Recibe conformidad
8.1.2.5. Auto Transición:
 Notación:
Nombre de Auto-Transicion
Nombre de
Estado
Versión: 02

El nombre de una Auto-Transición será el proceso identificado, que
permitirá que un estado permanezca tal cual hasta el cumplimiento
de la auto-transicion respectiva, el nombre debe contener un máximo
de treinta (30) caracteres.
Sintaxis:
<<nombreautotransicion>>
Ejemplo:
Actualizar avance
9.4.3. PLANTILLA DE DIAGRAMA DE ESTADO

Nombre de Diagrama de Estado
Nombre de Auto-Transicion
Nombre de Transacion 1 Nombre de

Estado 1
Nombre de Transacion 2
Nombre de Nombre de Evento Estado Final

Estado 2
9.5. DIAGRAMA DE SECUENCIA:
Representa la interacción de clases y/o objetos ordenados en una serie temporal que
muestra su ciclo de vida.
9.5.1. PROPÓSITO
En un escenario concreto de caso de uso, describe los mensajes que
intercambian los objetos definidos por sus métodos.
Versión: 02
9.5.2. ELEMENTOS Y NOTACIÓN DEL DIAGRAMA DE SECUENCIA
8.1.2.6. Actor:
Actor
(f rom Use Cases)
8.1.2.7. Línea de Vida:
8.1.2.8. Clase:
Clase 1
8.1.2.9. Mensaje:
 Notación:

El nombre de un mensaje será el método identificado e asignado a
una clase en particular, el nombre debe contener un máximo de
treinta (30) caracteres.
Sintaxis:
<<nombremensaje>>()
Ejemplo:
Buscar Requerimiento(numero rq, código estado, tipo estado)
8.1.2.10. Auto Mensaje:
 Notación:
Versión: 02

El nombre de un Auto mensaje será el método identificado e
asignado a una clase en particular, el nombre debe contener un
máximo de treinta (30) caracteres.
Sintaxis:
<<nombreautomensaje>>()
Ejemplo:
Validar estado()
9.5.3. TIPOS DE CLASE (DISEÑO)
8.1.2.11. Clase Interfaz: llamada también clase boundary. Representan las

interfaces que el usuario usará para interactuar con el software.
 Notación:
: Clase Interfaz
 Criterio para nombrar Clase Interfaz:

El nombre de una clase interfaz debe definirse siempre en singular,
debe tener un máximo de veinte (20) caracteres.
Sintaxis:
<<nombre clase interfaz>>
8.1.2.12. Clase Controladora: Modelan el comportamiento específico de los

casos de uso.
 Notación:
: Clase Controladora
 Criterio para nombrar Clase controladora:
Versión: 02
El nombre de una clase controladora debe definirse siempre en

singular, debe tener un máximo de veinte (20) caracteres.
Sintaxis:
<<nombre de clase controladora>>
8.1.2.13. Clase Persistente: llamada clase entity. Representan la estructura

lógica de los datos, teniendo como responsabilidad almacenar y
manejar la información en el software.
 Notación:
: Clase Persistente
 Criterios para nombrar Clase Persistente:

El nombre de una clase persistente debe definirse siempre en
singular y debe representar a un sustantivo dentro de una oración,
debe tener un máximo de veinte (20) caracteres.
Para el caso de clases que necesiten tener un nombre compuesto
de dos palabras, el máximo será de treinta (30) caracteres.
Sintaxis:
<<nombre>> ó <<nombre1_nombre2>>
Ejemplo:
 Unidad_Organizacional
 Requerimiento
Versión: 02
9.5.4. PLANTILLA DE DIAGRAMA DE SECUENCIA (ANÁLISIS)
Nombre de Diagrama de Secuencia

(Analisis)
Clase 1 Clase 2
: Actor
Mensaje 1
Auto Mensaje 1
Mensaje 2
Mensaje 3
Mensaje 4
Versión: 02
9.5.5. PLANTILLA DE DIAGRAMA DE SECUENCIA (DISEÑO):
Nombre de Diagrama de Secuencia

(Diseño)
: Actor : Clase Interfaz : Clase Controladora : Clase Persistente
Mensaje 1
Mensaje 2
Auto Mensaje 1
Mensaje 3
Auto Mensaje 2
Mensaje 4
Mensaje 5
Mensaje 6
Versión: 02
9.6. DIAGRAMA DE COLABORACIÓN:
9.6.1. PROPÓSITO
Ofrece una visión diferente (con respecto al diagrama de secuencia) del
escenario al analista, cuando esta intentando comprender la participación de un
objeto en el software.
8.1.2.14. Mensaje:
8.1.2.15. Auto Mensaje:
Nombre de Auto Mensaje
Clase 1
8.1.2.16. Actor / Clase / Objeto:
Clase 1
9.6.3. PLANTILLA DE DIAGRAMA DE COLABORACIÓN
Nombre de Diagrama de Colaboraciones

3: Auto Mensaje 1
1: Mensaje 1 2: Mensaje 2
Actor 1 Clase 1 Clase 2
5: Mensaje 4 4: Mensaje 3
Versión: 02
9.7. MODELO DE IMPLEMENTACIÓN
El modelo de implementación esta planteado para una arquitectura a tres capas. La

capa de Aplicaciones (Interfaz), la capa lógica de negocios (donde se comparten
procedimientos, funciones y sp para su respectiva reutilización) y la capa lógica de
datos (la cual contiene métodos propios); esta ultima capa es la que se conectará
directamente con la base de datos respectiva.
El modelo muestra la relación de componentes a través de las tres capas de
desarrollo.
Un componente es un grupo de clases que trabajan estrechamente en el desarrollo de
un conjunto de interfaces, lógica de negocio y lógica de datos respectivamente.
Los componentes pueden ser código fuente, binario o ejecutable.
Un paquete es un grupo de componentes que trabajan estrechamente.
9.7.1. PROPÓSITO
Presenta la estructura del software y la dependencia entre sus componentes.
8.1.2.17. Paquete:
 Notación:
Paquete 1
 Criterio para nombrar un Paquete:

Un paquete si esta definido por una sola palabra, debe tener un
máximo de quince (15) caracteres.
Un paquete si esta definido por palabras compuestas, debe contener
máximo de cuarenta (40) caracteres, separados por el símbolo
underline: “_”.
Sintaxis:
<<nombre>> ó <<nombre1_nombre2>>
Ejemplos:
o Paquete de Aplicaciones
o Paquete Lógica de Negocios
o Paquete Lógica de Datos
Versión: 02
8.1.2.18. Componente:
 Notación:
Componente 1
 Criterio para nombrar un Componente:

Ver item 5.1.2.
8.1.2.19. BasedeDatos:
 Notación:
Base de Datos
 Criterio para nombrar una Base de Datos

Ver item 2.4.8.
Versión: 02
MANUAL DE ESTÁNDARES PARA EL 00/00/0000
DESARROLLO Página 81 de 86
DE SISTEMAS
9.7.3. PLANTILLA DE MODELO DE IMPLEMENTACIÓN:
Nombre de Modelo de Implementación
Capa de Aplicaciones
Componente 1
Logica de Negocios
Componente 2 Componente 3
Componente 4 Componente N Logica de Datos
Base de Datos
Versión: 02
9.8. MODELO DE DESPLIEGUE:
Un diagrama de despliegue modela la distribución en tiempo de ejecución de los

elementos de procesamiento y componentes de software, junto a los procesos y
objetos asociados.
Se modelan por nodos y dispositivos, los cuales se comunican entre ellos.
Cada nodo puede contener instancias de componentes.
8.1.2.20. Nodo:
Representa un recurso informático, puede ser un servidor o una pc.
 Notación:
Nodo
 Criterios para nombrar un Nodo:

Servidor, en este caso la sintaxis para aquellos servidores que se
instalan desde la fecha de aprobación del presente documento en
adelante es:
<<aplicativo>>-<<función>>-<<ambiente>>
Donde:
aplicativo : nombre abreviado del aplicativo.
función. ..: nombre de la función que cumple el servidor (BD,
MTS ó IIS).
ambiente : (Desarrollo / PRE / Producción)
Ejemplo:
SIAT-BD-PROD
Pc Cliente, en este caso la sintaxis será la siguiente:

<<P>><<numero>><<identificador>>-<<unidad
organizacional>><<correlativo>>
Donde:
P : piso
número : número de piso (1,2,…..9)
identificador : identificador de edificio (A ó B)
unidad organizacional : abreviatura de unidad organizacional
correlativo : número de correlativo iniciado en 00
Ejemplo:
P7A-DSP04
Versión: 02
8.1.2.21. Dispositivo:
Puede ser un dispositivo X de hardware.
 Notación:
Dispositivo
 Criterios para nombrar un Dispositivo:

Un dispositivo debe llevar el nombre del hardware que representa, el
máximo será de veinte (20) caracteres.
Ejemplo:
Swicth
8.1.2.22. Conexión:
Tipo de comunicación utilizada en la red.
 Notación:
 Criterio para nombrar una Conexión:

Una conexión debe llevar el nombre de la tipología que representa,
el máximo será de veinte (20) caracteres.
Versión: 02
9.8.2. PLANTILLA PARA MODELO DE DESPLIEGUE
Nombre de Modelo de Despliegue
<<nombre pc>>
Caracteristicas del Hardware:
Cliente de Procesador:
Aplicaciones Memoria:
Capacidad
<<Tipo de Conexion de Red>> Red Ethernet 1,0 Gbps
<<dispositivo>>
swicth
<<Tipo de Conexion de Red>>
<<nombre servidor>> Caracteristicas del Hardware:
Logica de Negocios Procesador:

Memoria:
Capacidad:
<<Tipo de Conexion de Red>>
<<nombre de servidor>> Caracteristicas del Hardware:
Base de Datos Procesador:

Memoria:
Capacidad:
Versión: 02
9.9. ASIGNACIÓN DE PREFIJOS A DIAGRAMAS, MODELOS Y ELEMENTOS
Por cada modelo, diagrama ó elementos se tiene asignado los siguientes prefijos:
Tipo Descripción Prefijo

Diagrama Diagrama de Caso de Uso de Negocio DCUN
Elemento Actorde Negocio ACTN
Elemento Trabajador deNegocio TRAN
Elemento Caso de Uso de Negocio CUN
Diagrama Diagrama de Actividad de Negocio DACN
Elemento Actividad de Negocio ACTN
Elemento Condiciónde Negocio CONN
Elemento Stakeholder STK
Diagrama Diagrama de Caso de Uso de Sistema DCUS
Elemento Actorde Sistema ACTS
Elemento Caso de Uso de Sistema CUS
Diagrama Diagrama deClases DCLS
Elemento Clase CLS
Elemento Atributo ATR
Elemento Método MET
Diagrama Diagrama deEstado DEST
Elemento Estado EST
Elemento Transición TRA
Elemento Auto Transición ATRA
Elemento Evento EVE
Diagrama Diagrama deSecuencia DSEC
Elemento ClaseInterfaz CINT
Elemento ClaseControladora CCON
Elemento ClasePersistente CPER
Elemento Mensaje MEN
Elemento Auto Mensaje AMEN
Diagrama Diagrama deColaboraciones DCOL
Modelo Modelo de Implementación MIMP
Elemento Paquete PAQ
Elemento Componente COM
Elemento Base de Datos BD
Modelo Modelo de Despliegue MDES
Elemento Nodo NOD
Elemento Dispositivo DIS
Versión: 02
9.10. IDENTIFICADOR DE DIAGRAMAS, MODELOS Y ELEMENTOS:
Cada diagrama, modelo ó elemento definido debe tener un identificador para

manejar una trazabilidad del proyecto en desarrollo.
Sintaxis:
<<Prefijo>>-<<Correlativo>>
Donde:
Prefijo : Obtenido del item 8.9
Correlativo: Serie numérica iniciada en 000.
Ejemplo de Identificador:
CUS-001
9.11. TRAZABILIDAD
ACTN
CUN DACN
TRAN
STK EST DEST
ACTS CUS CLS COM PAQ
PAQ DCUS DSEC DCLS MIMP
DCOL BD MDES
9.12. REFERENCIAS BIBLIOGRÁFICAS
 J. Rumbaugh, I. Jacobson, G. Booch. El Lenguaje Unificado de Modelado.

Manual de Referencia. Addison Wesley, 2000.
 G. Booch, J. Rumbaugh, I. Jacobson. El Lenguaje Unificado de Modelado.
Guía del Usuario. Addison Wesley, 2000.
 Documento Técnico: GIN-DDM-DT001 Metodología de Desarrollo Software.

Manual Estandares Vb6

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Manual Estandares Vb6

Cargado por

Copyright:

Formatos disponibles

MANUAL DE ESTÁNDARES PARA

HOJA DE CONTROL DE CAMBIOS

ITEM TEXTO MODIFICADO VERSIÓN FECHA RESPONSABLE

5.1.3. MODELAMIENTO DE COMPONENTES ....................................................................................... 34

8. DISEÑO DE REPORTES ........................................................................................................................ 52

9. NOTACION UML EN LA METODOLOGIA DE DESARROLLO DE SOFTWARE ................................. 55

1. ESTANDARES DE VISUAL BASIC 6.0

1.1. NOMENCLATURA PARA LOS ELEMENTOS DE PROGRAMACIÓN

1.1.1. PREFIJOS DE VARIABLES

Prefijo Tipo de Variable Variable de ejemplo

Tipos de Datos Visual Basic 6.0 a Utilizar en el Proyecto SIAT

Tipo Descripción Bytes Rango Uso Prefijo

1.1.2. PREFIJOS DE CONTROLES

Prefijo Objeto Control de Ejemplo

Cbo Combo box cboMes

Cls Class clsContri

Dat Data datContri

Drv Drive list box drvTarget

Fil File list box filSource

Frm Form frmUsuarios

Img Image imgLogoSAT

Pic Picture box picDiskSpace

Shp Shape shpCirculo

Tmr Timer tmrAlarma

Tvw Treeview tvwOrg

Stb SSTab stbApariencia

Tsp TabStrip tspMantenimiento

1.1.3. PREFIJOS DE VARIABLES PARA OBJETOS DE BASE DE DATOS:

Prefijo Uso de la variable Variable de ejemplo

1.1.4. PREFIJOS DE ÁMBITO Y UTILIZACIÓN:

La declaración de todas las variables se deben hacer al principio del Procedimiento

1.2.1. NOMBRES DE VARIABLES

Para variables que hacen referencia a campos de la base de datos

<Prefijo tipo de dato VB><Nombre de Campo BD>

strccodper, intsinumvalor, lnginumtel

Para variables usadas en formularios ó módulos

<Prefijo tipo de dato VB><Nombre de Variable>

strNumRuc, strDigVer, intNumFil

1.2.2. NOMBRES DE MODULOS

Variable mdl<Prefijo sistema>Variable mdlFrVariable

1.2.3. NOMBRES DE FORMULARIOS

1.2.4. NOMBRES DE REPORTES

Diseñadores (Reportes embebidos en el Proyecto)

 Archivos TTx, Usar el mismo nombre que el reporte.

1.2.5. OBJETOS ADO

<Tipo de objeto ADO><Nombre de variable>

<Tipo de objeto ADO> cnn : Conexión cnnBase

Las funciones van a ser declaradas en módulos o formularios.

Tienen el siguiente formato:

f[tipo de dato]_[Nombre de la función](Parámetros)

Toda función deberá ser documentada con la siguiente estructura.

Function fbln_ExisteFile(byval msRutaFile As String) as Boolean

Los procedimientos van a ser declaradas en módulos ó formularios.

p[Nombre del procedimiento](Parámetros)

Toda Procedimiento deberá ser documentada con la siguiente estructura.

Sub pReparaBase (ByVal vstrdbContri As String)

Pasado por Valor v<tipodedato><Nemonico> vstrNumDoc

Function fbln_ExisteFile(ByVal vstrRutaFile As String, _

Sub pReparaBase (ByVal vstrdbContri As String)

1.2.9. VARIABLES GLOBALES

La declaración de las variables globales se hace en el módulo de declaraciones.

'*******************Declaración de variables públicas*************************

Public gstrRutaAplic As String 'Nombre de la ruta de la

Ámbito + "K" + Tipo de dato + Nombre

'*Declaración de variables públicas*******

'* Declaración de Variables *****