ESTÁNDAR DE DESARROLLO “LEONCITO”

Unidad de TI Fecha Emisión: 24/09/2019

Revisión: 2
ESTÁNDAR DE DESARROLLO

La Unidad de TI de Leoncito S.A, tiene como uno de sus objetivos fundamentales

la promoción de la integración y estandarización de herramientas y procedimientos
en el desarrollo de los Sistemas software.
Uno de los aspectos clave de esta integración es la definición y uso homogéneo
de todas las herramientas de desarrollo. Los objetivos de dicha normalización son:
 Aumentar la confianza del usuario final en las aplicaciones desarrolladas,
ofreciéndole un entorno familiar, sin sorpresas ni excepciones.
 Promover la colaboración entre los diferentes grupos de desarrollo
permitiendo que soluciones elaboradas para una aplicación se utilicen en el
desarrollo de otras.
 Facilitar el mantenimiento de aplicaciones haciendo que un módulo no esté
ligado al programador del mismo.
La Unidad de TI es el área responsable de promover esta normalización y de
verificar su cumplimiento. Para ello, se elaborará un conjunto de documentos que
sirvan como base para dicha normalización, ofreciendo un punto de referencia en
la discusión sobre la misma. Una vez aprobados, los Analistas responsables de
cada aplicación cuidarán de que los estándares se lleven a la práctica y el Jefe de
Proyecto verificará la implantación de los mismos. Este documento contiene
normas para el desarrollo de software en sus aspectos fundamentales: estándares
de nomenclatura, entornos de explotación y desarrollo, uso de las herramientas,
Los principales destinatarios son los analistas y programadores responsables del
desarrollo y mantenimiento de aplicaciones de gestión. Se supone un
conocimiento básico de todas las herramientas comentadas. El documento no
pretende ser completo. Muchos aspectos del desarrollo de software quedarán
fuera de estas especificaciones.
Este documento no contiene estándares sobre todos los aspectos relacionados
con el desarrollo de software. Se prepararán documentos adicionales que
estandaricen aspectos como:
 Metodología de análisis.
 Desarrollo de pruebas unitarias y de integración.
 Administración de Sistemas.
 Administración de Bases de Datos.
 Documentación.
 Sistema de Gestión de Código.
ESTÁNDAR DE DESARROLLO “LEONCITO”
Unidad de TI Fecha Emisión: 24/09/2019
Revisión: 2

I. GENERALIDADES
I.1. Definiciones
Introducimos en este apartado algunos conceptos generales que nos serán de utilidad en la
definición de estándares.
a. Aplicaciones
Llamaremos aplicación a cualquier desarrollo software funcionalmente independiente
que, no obstante, puede interconectarse, puntualmente, a otros desarrollos. Ejemplos de
aplicaciones son Sistema de Compras, Sistema de Planillas, Sistema de Contabilidad,
etc. A cada aplicación se le asocia un código único de 2 letras que denominamos
código de aplicación
b. Funciones.
Las aplicaciones se dividen en funciones con poca relación entre sí cada una de las
cuales cubre un aspecto del organigrama funcional de la aplicación. Una aplicación
típica no tendrá más de una docena de tales funciones. Las funciones se descomponen, a
su vez, en subfunciones. La comunicación entre las diferentes subfunciones de una
misma función será, en general, elevada. La subdivisión funcional puede continuar,
pero solo será significativa a propósitos de estandarización un máximo de cinco niveles
funcionales. Funciones y subfunciones se codifican empleando un carácter para cada
nivel hasta un máximo de cinco caracteres, formando una combinación única dentro de
cada aplicación.
c. Módulos
El nivel más bajo de esta jerarquía está formado por el módulo. Una subfunción emplea
uno o más módulos para realizar la tarea que tiene encomendada.
d. Identificador
Por ultimo definiremos el concepto de identificador, el cual emplearemos
frecuentemente en la normalización de los nombres de los diferentes objetos

I.2. Entornos
Desde un punto de vista lógico se distinguirán tres entornos bien diferenciados: Desarrollo
(DEV), Pruebas (QAS) y Producción (PRD).
a. Desarrollo (DEV)
El Entorno de Desarrollo comprende todos los módulos sobre los cuales trabaja el
grupo de programación en las primeras fases del desarrollo de una nueva aplicación:
desarrollo y pruebas unitarias. Existirá un Entorno de Desarrollo por cada nueva
aplicación que se empiece.
b. Pruebas (QAS)
El Entorno de Pruebas se compone de los módulos y escenarios de datos necesarios
para realizar las pruebas de integración previas a la puesta en servicio de una
aplicación. Una vez entregada a los usuarios (clientes), el grupo de mantenimiento
realizará su labor sobre este entorno. Cada aplicación dispondrá de su propio
Entorno de Pruebas siendo posible disponer simultáneamente de más de una versión
de la misma aplicación.
c. Producción (PRD)
El Entorno de Producción consta de los datos y módulos ejecutables que emplean
los usuarios (clientes) finales así como de todos los módulos necesarios para
reconstruir la versión actual de los ejecutables.
ESTÁNDAR DE DESARROLLO “LEONCITO”
Unidad de TI Fecha Emisión: 24/09/2019
Revisión: 2
I.3. Responsabilidades
a. Desarrollo (DEV)
Cada programador dispondrá de sus propios directorios de trabajo en su
equipo local así como de datos independientes para realizar pruebas unitarias
de los módulos que vaya desarrollando.
Es responsabilidad del programador la organización de su directorio de
trabajo así como el mantenimiento de sus datos de prueba. Se favorecerá el
traspaso de módulos en desarrollo entre programadores con la única
limitación de que un programador no pueda modificar el trabajo de otro.
b. Pruebas (QAS)
Desde el primer momento que se necesite probar la integración de dos o más
módulos se creará un Entorno de Pruebas (QAS) para la aplicación
correspondiente. A este entorno se pasarán los módulos que hayan superado
las pruebas unitarias y sobre los que se vayan a realizar las pruebas de
integración. El Área de Infraestructura creará los Entornos de Pruebas
necesarios pasando, a continuación, la responsabilidad del mantenimiento de
los escenarios de pruebas y de la coherencia del Entorno de Pruebas al
Analista responsable de la aplicación. Hasta la puesta en servicio de la
aplicación, existirán simultáneamente los Entornos de Desarrollo y Pruebas
para una misma aplicación.
Para las aplicaciones en explotación es posible mantener varias versiones de
la misma en el Entorno de Pruebas (por ejemplo, una para mantenimiento y
otra para desarrollar nuevas funcionalidades). Los Entornos de Pruebas de
las diferentes aplicaciones estarán aislados. Con el acuerdo previo de los
Analistas responsables, la Unidad de TI facilitará la colaboración entre los
diferentes grupos de desarrollo.
c. Producción (PRD)
Las aplicaciones se distribuirán en el Entorno de Producción (PRD)
atendiendo a consideraciones de seguridad y de rendimiento. La integridad y
seguridad de los datos y módulos en el Entorno de Producción serán
responsabilidad exclusiva del Área de Infraestructura. Se debe definir un
procedimiento de pase a producción, para permitir a los grupos de
mantenimiento de aplicaciones el pase a producción de módulos
modificados o nuevos al Entorno de Producción.

II. ESTÁNDARES DE DISEÑO Y CODIFICACIÓN DEL SOFTWARE

II.1. INTERFAFACES DE USUARIO

LISTA DE BOTONES E IMÁGENES ESTANDARES

BOTONES (Caption) ICONOS

Nuevo
Editar
ESTÁNDAR DE DESARROLLO “LEONCITO”
Unidad de TI Fecha Emisión: 24/09/2019
Revisión: 2
Eliminar
Guardar
Imprimir
Cancelar
Salir del Formulario
Buscar
Buscar en Lista
Visualizar
Aceptar Lista
Cancelar Lista
Actualizar
Avanzar
Retornar
Procesar
Salir la aplicación
Botones para manejo de listas
Botones para manejo de listas

Nota:
1. El control de los botones es CommandButton
2. El nombre para los botones se mantendrá como se ha venido trabajado
(cmdNombredeControl).
3. Los botones de los formularios se podían dentro de un Frame sin borde y estarán
juntos con el botón Salir ligeramente separado de los demás y estarán en el orden
siguiente según se necesiten: Nuevo, Editar, Eliminar, Guardar, Cancelar,
Búsqueda / Imprimir, Salir.
4. Los botones Nuevo, Búsqueda y Salir siempre estarán activos al momento de
cargar el formulario si este es un formulario de mantenimiento o se muestran de
acuerdo a los permisos que tiene el Usuario.
5. Los demás botones se activaran según el usuario los requiera.
6. El botón Salir estará inactivo al presionar Nuevo, Editar, Eliminar y se volverá a
activar al presionar Guardar o Cancelar.
7. Si el mantenimiento es en una Grilla se trabajara con 2 botones (+) Agregar un
Item , (-) Eliminar un item (Si es nuevo se elimina de la lista, caso contrario se
pinta el Item de color rojo indicando este que va a ser eliminado, cuando un item
esta eliminado el botón (-) cambia a (R) para que el usuario retornen este item a
ala lista). Si no se utiliza los botones + y – utilizar los botones alineados a la
derecha de la grilla en forma vertical en el mismo orden e iconos del
mantenimiento general.

2.1. CODIFICACIÓN (PROGRAMACIÓN)

Se definen estándares de codificación porque un estilo de programación homogéneo en un
proyecto permite que todos los participantes lo puedan entender en menos tiempo y que el
código en consecuencia sea mantenible.
ESTÁNDAR DE DESARROLLO “LEONCITO”
Unidad de TI Fecha Emisión: 24/09/2019
Revisión: 2
Directiva 1 Puede ser que el estándar de documentación definido no sea perfecto para
todas las situaciones. Si esto es así y cree que debe salirse de la norma: Documente los
motivos

II.1.1. Nombres de ficheros

Sufijos de ficheros en Java:
o Código fuente: .java
o Código compilado: .class
Nombres de ficheros comunes:
o README: Resumen de información importante relativa al
directorio en el que está ubicado
II.1.2. Organización de ficheros
Un fichero consta de secciones separadas por líneas en blanco y
líneas de comentario, ningún fichero debe tener más de 2000 líneas
de código
2.1.2.1. Ficheros de código fuente Cada fichero contiene una única
clase o interface. Si hay una clase privada o una interfaz asociada a
una clase pública se puede poner en el mismo fichero. La clase
pública debe ser la primera
Ordenación de las secciones en un fichero de código fuente
Estas secciones deben ir separadas por una línea en blanco
o Sentencia: package xxx.yyy;
o Sentencias de importación. Ej: import java.util.ArrayList; No
hay líneas en blanco entre ellas
o Código de la clase. Va precedido por comentarios tipo
javadoc con la siguiente información:
o Prólogo explicativo de la clase (opcional),autor,
versión, referencias a otros elementos de código si se
considera que debe haberlas
II.1.3. Indentación
La unidad de indentación de bloques de sentencias son 4 espacios
2.1.3.1. Líneas largas
Cuando una línea no quepa en una única línea se debe fraccionar
atendiendo a estos principios generales
o Fraccionar después de una coma
o Fraccionar después de un operador Es mejor romper unidades
de alto nivel que de bajo nivel. Ejemplo:
longName1 = longName2 * (longName3 + longName4 -
longName5) + 4 * longname6; // Mejor
longName1 = longName2 * (longName3 + longName4 -
longName5) + 4 * longname6; // Peor
o Si las reglas anteriores producen código confuso utilizar
indentación de 8 caracteres. Ejemplo:
ESTÁNDAR DE DESARROLLO “LEONCITO”
Unidad de TI Fecha Emisión: 24/09/2019
Revisión: 2

// NO USAR ESTA INDENTACIÓN

if ((condition1 && condition2)
|| (condition3 && condition4)
||!(condition5 && condition6)) {
doSomethingAboutIt(); // SE CONFUNDE CON LAS
ANTERIORES }

// USAR ESTA INDENTACIÓN

if ((condition1 && condition2)
|| (condition3 && condition4)
||!(condition5 && condition6)) {
doSomethingAboutIt(); } //

II.1.4. Comentarios
Normas generales a seguir en toda documentación:
a. Los comentarios deben añadir claridad al código. Deben contar el
por qué y no el cómo.
b. Deben ser concisos.
c. Idealmente hay que escribir la documentación antes que el código.
Hay dos tipos de comentarios: Comentarios de implementación y
comentarios de documentación. Los comentarios de implementación
son del tipo: // ... o /* ... */. Los comentarios de documentación son del
tipo: /** ... */. Los comentarios de implementación describen el
código, los de documentación una visión de más alto nivel para gente
que no tiene el código a mano y que sólo quiere usarlo. La información
de los comentarios no debe ser evidente, deben ser cosas que no están
contenidas en el código Los comentarios no deben estar en cajas
dibujadas con asteriscos o similar ni deben incluir caracteres extraños
2.1.4.1. Comentarios de implementación
Comentarios de bloque: Al comienzo de cada fichero o bloque. No se
usan en este proyecto Comentarios de línea: Son comentarios
explicativos de una parte pequeña del código. Sintaxis: // ... o /* ... */
2.1.4.2. Comentarios de documentación
Son los comentarios destinados a ser procesados por javadoc.
Importante: No se pueden usar comentarios de documentación para
bloques de código dentro de métodos porque javadoc los asigna a la
primera declaración que encuentre detrás de ellos

La indentación correcta según Sun es:

/**
* Comentario sobre la clase A
*/
public class A { ... }
ESTÁNDAR DE DESARROLLO “LEONCITO”
Unidad de TI Fecha Emisión: 24/09/2019
Revisión: 2

Otras normas que se siguen en el proyecto son:

o No se documentará lo que sea evidente
o Siempre se usarán los tags de javadoc para documentar los
parámetros y valores de retorno, aunque sólo sea para poner
su nombre

2.1.5. Declaraciones
2.1.5.1. Número de declaraciones por línea
Se debe declarar cada variable en una línea distinta, de esta forma cada
variable se puede comentar por separado. Ejemplo:
int level, size; // Mal
int level; // Indentation level
int size; // Size of table
Los arrays se deben declarar de este modo:
double[] table; // Bien
double []table; // Mal
2.1.5.2. Inicialización
Inicializar cada variable en su declaración a menos que su valor inicial
dependa de algún cálculo
2.1.5.3. Localización
En el comienzo de los bloques. La única excepción es el bucle for. No
se deben declarar variables con el mismo nombre que otras en un
método.
2.1.5.4. Declaraciones de clases e interfaces
Se siguen estas reglas:
o No hay espacio entre el nombre del método, el paréntesis y la
lista de parámetros
o Se abre la llave { al final de la misma línea que la declaración
o La llave de } debe aparecer en línea aparte con la misma
indentación que el método o clase que cierra
2.1.6. Sentencias
2.1.6.1. Sentencias simples
Cada línea debe contener una sola sentencia. Ejemplos
argv++; // Bien
argc++; // Bien
argv++; argc++; // Mal
2.1.6.2. Sentencias compuestas
Son las que están entre llaves { y }
o Deben estar indentadas a un nivel superior que el precedente
o Todas las sentencias del tipo if o for, while, do ... while deberán
tener llaves aunque sólo contengan una sentencia, de esta forma
se evita la introducción accidental de errores si se añaden
posteriormente sentencias
ESTÁNDAR DE DESARROLLO “LEONCITO”
Unidad de TI Fecha Emisión: 24/09/2019
Revisión: 2

2.1.6.3. Ejemplos: Sentencias if, for, while, do ... while, switch y

try ... catch

Sentencia if
if (condition) {
statements;
}

if (condition) {
statements;
} else {
statements;
}

if (condition) {
statements;
} else if (condition) {
statements;
} else {
statements;
}

Sentencia for y su nueva versión

for ( initialization; condition; update) {
statements;
}

for ( initialization; condition; update);

La nueva versión del for tiene el siguiente formato

For (Declaration : List) {
statements;
}

Ejemplo. Antes:
void cancelAll(Collection c) {
for (Iterator i = c.iterator(); i.hasNext(); ) {
TimerTask tt = (TimerTask) i.next();
tt.cancel();
}
}
Después:
void cancelAll(Collection c) {
for (Object o : c) {
((TimerTask)o).cancel();
}
ESTÁNDAR DE DESARROLLO “LEONCITO”
Unidad de TI Fecha Emisión: 24/09/2019
Revisión: 2
}

Sentencia while:

while (condition) {
statements;
}

while (condition);

Sentencia do-while:
do {
statements;
} while ( condition);

La sentencia switch tiene este formato e indentación

switch ( condition) {
case ABC:
statements;
/* El comentario tambien indentado */
case DEF:
statements;
break;
case XYZ:
statements;
break;
default:
statements;
break;
}

La sentencia try ... catch

try {
statements;
} catch (ExceptionClass e) {
statements;
}

Si está seguida por finally:

try {
statements;
} catch (ExceptionClass e) {
statements;
} finally {
statements;
}
ESTÁNDAR DE DESARROLLO “LEONCITO”
Unidad de TI Fecha Emisión: 24/09/2019
Revisión: 2

2.1.6.4. Sentencias de retorno

No se pondrá la expresión de retorno entre paréntesis a menos que con
ello se gane en claridad

2.1.7. Espacio en blanco

2.1.7.1. Líneas en blanco
Se deben usar dos líneas en blanco entre:
o Diferentes secciones de un fichero de código fuente
o Entre clases y definiciones de interfaz
Se debe usar una línea en blanco:
o Métodos
o Variables locales de un método y la primera sentencia
o Antes de un bloque o un comentario de línea (para que se sepa
de un vistazo que es lo que comenta)
Entre diferentes secciones lógicas dentro de un fichero (más
legibilidad)
2.1.7.2. Caracteres de espacio
Se deben usar en las siguientes circunstancias:
o Entre un paréntesis cerrado y una llave
o Después de una coma en la lista de parámetros de un método
o Entre operadores binarios: +, -, =, etc. Nunca entre un operador
uno-ario y su operando
o La sentencia for y su paréntesis. Ejemplo: for (expr1, expr2,
expr3); Casts. Ejemplo: myMethod((int) (cp 5), ((int) (i + 3)) +
1);+

2.1.8. Asignación de nombres (Nomenclatura)

Esta es la sección más importante. Las normas genéricas son:
a. Se usan descriptores que dejen claro el cometido de la variable,
método o clase.
b. Se usa terminología aplicable al dominio.
c. Si se usan abreviaturas hay que mantener en algún sitio una
lista de lo que significan.
d. Evitar en lo posible los nombres largos (menos de 15 letras
sería lo ideal)
e. Evitar nombres que difieran en una letra o en el uso de
mayúsculas. 6. Un nombre no debería constar de más de dos
palabras.
f. No usar siglas en los nombres a menos que queden muy largos
o sean siglas conocidas por todos.

Cada tipo de elemento debe nombrarse con una serie de reglas

determinadas.
ESTÁNDAR DE DESARROLLO “LEONCITO”
Unidad de TI Fecha Emisión: 24/09/2019
Revisión: 2

Tipo de Datos Abreviatura

Bolean Bol
Byte Int
Integer Int
Long Integer Int
Single Dec
String Str
Date Dtm
Variant Var
Object Obj
Arreglos Ejm intTotal () as Integer
Objetos ADO rs, cmd, cn, param
ParamArray Parametros()
Declaración de Variables
Ámbito : Ejemplos :
Local (Privado a nivel de Form, Dim a nivel lvstrApellidosNombres as String
de Método) lvintTotalAcumulado as Long

Público (Public a nivel de Aplicación o a pvintIDContrato as Long

nivel de Form)

Declaración de Constantes
Ambito : Ejemplos :
Local (Constante a Nivel de Form) lcstrEstadoEmbarque as String = “E”
Publico (Constante a Nivel de Aplicación) pcdecPorcentaje as Single = “1.25”
Declaración de Funciones y Procedimientos
Función: <Ámbito> <f> <Tipo de Ejemplo :
Dato><Nombre Función> lfrsDevuelveTipoEnvase
Procedimiento <p><Nombre> psLlenarDatos
Declaración de Parámetros
Parámetros Funciones y Procedimientos Ejemplos :
<prm> <Tipo de Dato><Nombre> prmstrApellidosNombres as String

Controles de Interfaz de Usuario

Controles ActiveX Visual Basic
Nombre Nomenclatura Propiedades
Form formNombreDelControl Font=Tahoma
Size= 8
BorderStyle= 2,3,4
Label lblNombreDelControl Caption
Autosize=True
TextBox txtNombreDelControl Appearance=Flat
Heigh=285
cmdButton cmdNombreDelControl Style=1
Caption =””
Height=375
ESTÁNDAR DE DESARROLLO “LEONCITO”
Unidad de TI Fecha Emisión: 24/09/2019
Revisión: 2
Width=1125
Tag=NombreImagen
CheckBox chkNombreDelControl
OptionButton optNombreDelControl
ComboBox cboNombreDelControl
ListBox lstNombreDelControl
Frame fraNombreDelControl
Picture picNombreDelControl
Image imgNombreDelControl
Shape shpNombreDelControl
DTPicker dtpNombreDelControl
MonthView mvwNombreDelControl
TreeView tvwNombreDelControl Appearance=Flat
FlatScrollBar=True
FullRowSelect=True
HideSeleccion=False
ListView lvwNombreDelControl Appearance=Flat
FlatScrollBar=True
FullRowSelect=True
HideSeleccion=False
View=lvwReport
ImageCombo imgcboNombreDelControl Appearance=Flat
Enabled=True
Locked=True
Toolbar tlbNombreDelControl
StatusBar stbNombreDelControl
CoolBar clbNombreDelControl
ProgressBar pgbNombreDelControl
Common Dialog cmdlgNombreDelControl
SSTab sstNombreDelControl Style=1
ScriptControl ScriptNombreDelControl Lenguaje=VBScript
CommondDialog cmdlgNombreDelControl CancelError=False
Controles ActiveX Terceros
Nombre Nomenclatura Propiedades
VSFlexGrid vsfNombreDelControl

ProgressBar prgbNombreDelControl BorderStyle=2

CaptionType=2
Elastic elaNombreDelControl
CITab eTabNombreControl

Nombramiento de Archivos
Tipo de Archivo Nomenclatura Propiedades
Grupo grpNombreGrupo
Proyecto EXE prjNombreProyecto
ESTÁNDAR DE DESARROLLO “LEONCITO”
Unidad de TI Fecha Emisión: 24/09/2019
Revisión: 2
Proyecto Datos DLL datNombreProyecto  Ejecución desatendida
 Actualizar controles ActiveX
 Conservado en Memoria
Proyecto Negocio DLL negNombreProyecto  Ejecución desatendida
 Actualizar controles ActiveX
 Conservado en Memoria
Proyecto Útiles DLL utlNombreProyecto  Ejecución desatendida
 Actualizar controles ActiveX
 Conservado en Memoria
Proyecto Control OCX ctlNombreProyecto
Formulario formAreaNombreFormulario Font=Tahoma
Size= 8
BorderStyle= 2,3,4
Módulo modAreaNombreModulo
Clase clsNombreClase Instancing=5-MultiUse
MTSTransaccionMode=0-
NotAnMTSObject
Archivo de Recursos resNombreArchivo
Nombramiento de Clases
Tipo de Clase Nomenclatura Propiedades
Clase de Datos datNombreClase Instancing=5- MultiUse
MTSTransaccionMode=3-
Requiere transaccion
Clase de Negocios negNombreClase Instancing=5- MultiUse
MTSTransaccionMode=3-
Requiere transacción
Clase de Usuario o clsNombreClase Instancing=5-MultiUse
Cliente MTSTransaccionMode=1-
NoTransacctions
Clase de Útiles utlNombreClase Instancing=5-MultiUse
MTSTransaccionMode=1-
NoTransacctions
Métodos y Propiedades Inician con mayúscula y no
usan caracteres de tipo.
Public Property Let
Text(New_Text As String)
ESTÁNDAR DE DESARROLLO “LEONCITO”
Unidad de TI Fecha Emisión: 24/09/2019
Revisión: 2

III. DE LA APLICACIÓN

III.1. Modelo de Aplicación

 Un modelo de aplicación es una vista conceptual de una aplicación que establece

las definiciones, reglas, y relaciones que estructuran la aplicacion.
 Muestra como está estructurada una aplicación y como será implementada.
 Las aplicaciones serán implementadas un esquema de capas y servicios.
o “Tier (capa) es un concepto lógico que proporciona una manera de
describir como las aplicaciones pueden ser segmentadas en servicios.”
o “Un Servicio es una unidad de lógica de la aplicación que implementa
operaciones, funciones, o transformaciones que son aplicadas a objetos.”

III.1.1. Servicios en el modelo de Aplicación:

 Los servicios pueden:

o realizar reglas de negocio,
o realizar cálculos o manipular datos,
o exponer características para ingresar, extraer, mostrar, o modificar datos.
 Se definen tres tipos de servicios:
o Servicios de Usuario (First Tier),
o Servicios de Negocio (Second or Middle Tier).
o Servicios de Datos (Third Tier).

III.1.1.1. Servicios de Usuario:

o Son unidades de lógica de aplicación que proporcionan la interfaz con ella.
o El usuario de una aplicación puede ser una persona u otra aplicación.
o La interfaz puede ser una GUI (graphical user interface) a una API
(application programmatic interface).

III.1.1.2. Servicios de Negocio:

o Controlan la secuencia y realizan las reglas de negocio y la integridad
transaccional de las operaciones.
o Transforman los datos en información para el usuario a través de la
aplicación de las reglas apropiadas.
o La meta de un diseño apropiado es aislar las reglas de negocio y la lógica
de transformación de datos de sus consumidores (usuarios u otras
servicios de negocio).
Ventajas:
o Flexibilidad en decidir cómo y dónde distribuir los servicios de negocio:
Application Server, Stored Procedures o en cualquier cliente.
o La habilidad para localizar diferente lógica de interfaz de usuario frente a
un conjunto de servicios de negocio.
o Gran facilidad en mantener aisladas las reglas de negocio de las
aplicaciones y servicios de datos.
ESTÁNDAR DE DESARROLLO “LEONCITO”
Unidad de TI Fecha Emisión: 24/09/2019
Revisión: 2
o La habilidad de reemplazar implementaciones de servicios de negocio.

III.1.1.3. Servicios de Datos

o Proporcionan el más alto nivel de abstracción usada para manipular data.
o Mantienen la disponibilidad e integridad de datos persistentes y no
persistentes.
o Controlan y proporcionan acceso a los datos en la forma que los servicios
de negocio lo requieren sin conocer su localización, cómo esta
implementado el servicio o cómo es accedido.

Arquitectura del modelo de aplicación

Bases de datos

Sistemas propietarios

Aplicaciones
Cliente externas
delgado

Cliente
grueso

Tecnología y herramientas
ESTÁNDAR DE DESARROLLO “LEONCITO”
Unidad de TI Fecha Emisión: 24/09/2019
Revisión: 2

Estrategia de Desarrollo Corporativo

Aplicación en 3 capas:

Modelo Físico:
ESTÁNDAR DE DESARROLLO “LEONCITO”
Unidad de TI Fecha Emisión: 24/09/2019
Revisión: 2

Modelo de despliegue:

Modelo de Componentes:
ESTÁNDAR DE DESARROLLO “LEONCITO”
Unidad de TI Fecha Emisión: 24/09/2019
Revisión: 2

Arquitectura de componentes:

Arquitectura de despliegue de componentes:

ESTÁNDAR DE DESARROLLO “LEONCITO”
Unidad de TI Fecha Emisión: 24/09/2019
Revisión: 2

Distribución de los componentes en Fase de Desarrollo:

Estándar para programar servicios de componentes en PHP:

o Minimizar la cantidad de idas y vueltas al servidor

o Usar objetos ADO Recordsets para devolver grandes cantidades de data
o Evitar pasar parametros por referencia
o Evitar generar eventos
o En general, obtener recursos tarde y liberarlos pronto
o Hacer objetos apartment-threaded
o Usar SetComplete y SetAbort
o El acceso a la base de datos es totalmente encapsulado por el Servicio de
Componentes
o El Servicio de Componentes puede usar Connection Pooling para reducir la
carga del Servidor de Base de Datos
o Reduce la Administración para configurar el acceso a una aplicación
o La seguridad esta basada en roles que los individuos juegan en una
organización
ESTÁNDAR DE DESARROLLO “LEONCITO”
Unidad de TI Fecha Emisión: 24/09/2019
Revisión: 2
o Minimizar la construcción de cadenas con &
o Anular la construcción de cadenas con +
o Evitar la construcción dinámica de la cadena de conexión
o No usar Clases State Full
o Evitar el uso de Variant
o Minimizar la construcción de cadenas con &
o Anular la construcción de cadenas con +
o Evitar la construcción dinámica de la cadena de conexión
o No usar Clases State Full
o Evitar el uso de Variant

Para Capa de Datos:

o Desarrollar un componente genérico de acceso a datos
o Desarrollar un componente de primitivas de acceso a datos para la aplicación
o Utilizar connection pooling
o Si se desea llevar un log de acciones por usuario considerar el pasar como
parámetro el usuario al Store Procedure

Capa de usuario:
o Crear una clase en el cliente (capa usuario) que guarde los datos del usuario
conectado
o No leer la fecha del servidor (solo enn Store procedures)