Académique Documents
Professionnel Documents
Culture Documents
Revisores
Distribución
Nombre Posición
Elemento Detalle
Beneficios
1. Facilidad en la lectura del código, reduciendo la complejidad del mismo.
2. La mantenibilidad del código, donde se pueda modificar fácilmente y agregarle nuevas
características.
ARQUITECTURA Y COMPONENTES
La arquitectura de desarrollo a utilizar para el proyecto SIGOB-SIMAT es la de tres capas, la cual
describimos a continuación:
La capa de presentación
Contiene el código que define lo que el usuario debe ver en la pantalla, incluyendo los campos con
formato y los menús de navegación. A continuación presentamos la matriz de controles a utilizar,
cualquier otra opción debe ser consultada con el equipo completo del proyecto.
Pantallas.
Realizacion de un plantilla para las pantallas.
Todos los labels de la pantalla se colocarán encima de los textboxs.
La capa de Negocios.
El código buscado, insertado o actualizado por la capa de datos es expuesto a la capa de presentación
usando esta capa.
La capa de Datos
Para conectarnos a la base de datos vamos a utilizar los componentes nativos de Microsoft.
Imagen de la estructura
Consideraciones especificas en el diseño
y programación del sistema
Procesamiento de Peticiones.
El procesamiento de las peticiones al servidor deben ser las necesarias, es decir, cada control en donde
no se necesite hacer postback debe tener esta opción deshabilitada (False) y para cada página en donde
las peticiones sean necesarias vamos a tener una funcionalidad para poder medir el tiempo de las
mismas, esta rutina será colocada en el archivo Global.asax, y es la siguiente:
Sub Application_BeginRequest(ByVal sender As Object, ByVal e As EventArgs)
Context.Items.Add("FechaHoraCarga", DateTime.Now)
End Sub
tDuracion = DateTime.Now.Subtract(Context.Items("FechaHoraCarga"))
End Sub
En las pruebas de calidad, que se deben hacer en ambientes parecidos a los de producción, debemos de
medir este tiempo para poder tener una métrica del tiempo de duración entre las peticiones de las
páginas más usadas en el portal, garantizando así la calidad de las respuestas una vez puesta en punto la
aplicación en producción.
Los tiempos de respuestas tienen factores importantes que se deben tomar en cuenta:
La autenticación en el sistema se debe hacer contra los usuarios definidos en las tablas para estos fines.
PARA EL PORTAL.
La forma de manejar la seguridad de entrada al portal es la autenticación mediante un WEB FORM, para
esto en el WEB.CONFIG pondremos:
<authentication mode="Forms">
<forms name=".BANCO" loginUrl="Login.aspx" protection="All" timeout="10" path="/">
</forms>
</authentication>
Las páginas del portal que requieran autenticación se van a definir en el WEB.CONFIG, la rutina para
hacer esto la detallamos a continuación (la página especificada es un ejemplo):
<location path="frmNuevoCliente.aspx">
<system.web>
<authorization>
<deny users="?"/>
</authorization>
</system.web>
</location>
El rol de cada usuario, después de ser autenticado en el portal se manejara en el evento LOAD de cada
página con las rutinas siguiente.
- Rutina para verificar si el usuario pertenece al rol defino y puede usar esta página, Autorización,
(Utilizamos el rol de supervisor como ejemplo, esto puede cambiar y es configurable.)
'Creando la conexion
Try
If objConn.State = ConnectionState.Closed Then
objConn.Open()
End If
rdr = oCmd.ExecuteReader()
CollRole.Clear()
Do While rdr.Read
CollRole.Add(Trim(rdr("Rol")))
Loop
objConn.Close()
'Copiando al String De Retorno los valores devueltos
ReDim strRole(CollRole.Count - 1)
CollRole.CopyTo(strRole, 0)
Return strRole
Catch oErr As Exception
EventLog(oErr)
End Try
Return strRole
End Function
Encriptación de Claves (HASH)
Las claves de los usuarios deben ser guardado mediante un hash, propios del framework de Microsoft
.NET son los que vamos a usar:
End Function
Gestión de Excepciones y Página General de Mensajes.
El manejo de las excepciones se trabajarán basadas en mensajes, los mismos ubicados en un archivo
XML y se desplegaran, para algunos, en una página llamada “frmMensajes”, la misma recibirá como
parámetro el ID del mensaje vía URL.
<Mensajes>
<Mensaje>
<idMensaje>1</idMensaje>
<Titulo>Acceso no Autorizado para esta página</Titulo>
<CuerpoMensaje>No tiene autorización para autilizar este recurso,favor verificar o
contactar a uno de los administradores</CuerpoMensaje>
<ImagenMensaje>Imagenes/fail.jpg</ImagenMensaje>
<TituloPrimeraAccion>Reintentar Operación</TituloPrimeraAccion>
<TituloSegundaAccion>Enviar Correo a Soporte Técnico</TituloSegundaAccion>
<PaginaPrimeraAccion>VolverALaPaginaOriginal.aspx</PaginaPrimeraAccion>
<PaginaSegundaAccion>HelpDesk.Aspx</PaginaSegundaAccion>
<EnviarCorreo>S</EnviarCorreo>
</Mensaje>
</Mensajes>
Para los mensajes que ameriten enviar un correo al personal técnico, en el archivo WEB.CONFIG
definiremos el o los mismos.
Try
Catch ex As Exception
End Try
Nota : La aplicacion debe grabar el log, subir el formato del log en este
documento.
Cualquier otra operación que el programador considere pertinente, siempre y cuando no altere la
secuencia del programa. Ej. Disparar excepciones para romper el flujo.
Validaciones.
En la entrada de datos tendremos dos niveles de validaciones, los primeros realizados por los controles
propios de .NET, el segundo nivel consiste en validaciones usando Expresiones Regulares.
Todos los campos tendrán como longitud máxima, el valor mayor del mismo en la base de datos, la
validación del tamaño se debe hacer también del lado del servidor, no solamente especificando la
longitud máxima en el control.
Las validaciones que aquí especificamos están del lado de la aplicación, en la base de datos debemos
también contar con los constraints necesarios para mantener los datos íntegros.
1. Los nombres de todas las variables, estructuras, clases y namespaces deben ser en español.
2. El nombre de los NameSpaces deben empezar con las siglas, BB (Banco Binario)
3. Los nombres de las clases y del archivo deben ser iguales
4. Los nombres de los formularios deben empezar con el prefijo “frm”
5. Los nombres de los reportes deben empezar con el prefijo “rpt”
6. Los nombres de los labels deben empezar con el prefijo “lbl”
7. Los nombres de los textbox deben empezar con el prefijo “txt”
8. Los nombres de los listview deben empezar con “lv”
9. Los nombres de los formularios que son para consultas o listas deben empezar con “lst”
10. La primera letra de cada Nombre de las clases debe ser Mayuscula, ej. ClsPersona
11. Todas las variables deben empezar con su tipo de datos, ej. sNombreClliente para denotar que
la variable es de tipo string.
12. Los nombre de las variables (atributos) de cada clase deben empezar con un (undescore , _) ,
ej. _NombrePersona
13. Todos los nombres de los parámetros usados en funciones y/o procedimientos deben estar
precedidos de la letra P, en minúscula.
14. Los nombres de las variables y atributos de las clases deben ser en singular.
15. Una clase debe estar definida en orden descendente de la siguiente manera: Variables
Miembro, Constructores, Enumeraciones, Estructuras o Clases anidadas, Propiedades y por
último los Métodos.
16. La secuencia de declaración de acuerdo a los modificadores de acceso debe ser la siguiente:
public
protected
private
Cualquier otro control que no esté especificado de con que prefijo debe iniciar, favor recomendarlo y
agregarlo a este documento después del acuerdo de todo el equipo.