Arquitectura de Software

UNMSM
Documento de Arquitectura de Software

SAPEA
Versin 0.2
SAPEA
Arquitectura de Software.doc
Versin: 0.2
Fecha: 12/02/2015
HISTORIAL DE CAMBIOS
Versin
Autor
Descripcin
Fecha de Elaboracin
0.2
Quilca Castaeda, Andreli

Santos Saldaa, Judith
Arquitectura del Sistema
10/02/2015
0.3

11/02/2015
0.4

12/02/2015
0.5

Paz, Carlos
Requisitos No Funcionales
Vista Lgica
Vista de CUS
27/02/2015
0.6

Castro Quispe, Hans
Paz, Carlos
Vista Lgica
Vista de Implementacin
Vista de Procesos
Vista de Despliegue
Tamao y Desempeo
Calidad
28/02/2015
Confidencial
UNMSM FISI, 2015
Pgina 2 de 30
SAPEA
Versin: 0.2
Fecha: 12/02/2015
INDICE
1.
INTRODUCCIN
1.1. Propsito
1.2. Alcance
1.3. Definiciones, acrnimos y abreviaturas
1.4. Referencias
1.5. Visin General
2. VISTA GENERAL DE LA ARQUITECTURA
2.1. Capa de presentacin
2.2. Capa de Lgica de Negocio
2.3. Capa de acceso a datos
3. METAS Y RESTRICCIONES DE LA ARQUITECTURA
4. VISTA CASOS DE USO
4.1. Diagrama de Caso de Uso
4.2. Casos de Uso Significativos de la Arquitectura
5. VISTA LGICA DEL SISTEMA
5.1. Generalidades
5.2. Paquetes de Diseo Arquitectnico Significativos
5.3. Interpretaciones de los Casos de Uso
6. VISTA DE PROCESOS
6.1. Web Services
6.2. Navegador
6.3. Email
7. VISTA DE IMPLEMENTACIN
7.1. Generalidades
7.2. Capas
8. VISTA DE DESPLIEGUE
9. VISTA DE DATOS
9.1. Modelo de Base de Datos Lgico y Fsico
10. TAMAO Y DESEMPEO
11. CALIDAD
Confidencial
UNMSM FISI, 2015
Pgina 3 de 30
SAPEA
Versin: 0.2
Fecha: 12/02/2015
DOCUMENTO DE ARQUITECTURA DEL SISTEMA

1. INTRODUCCIN
1.1. Propsito
Este documento tiene como propsito exponer la vista general de la
arquitectura del Sistema de Apoyo al Proceso de Enseanza y aprendizaje
(SAPEA), para lo cual se utilizan diferentes vistas que nos proporciona UML
en el Rational Unified Process.
El presente documento tiene como objetivo.
Plasmar mediante diagramas, modelos y artefactos del RUP, las

consideraciones tcnicas y tecnolgicas (plataforma) en la que ser
implementada la solucin.
Esbozar los aspectos funcionales de la aplicacin.
Definir los mecanismos de despliegue y distribucin del sistema.
Esbozar el modelo entidad relacin de la arquitectura de datos a

desarrollar.
1.2. Alcance
Detalla la arquitectura propuesta por el equipo de desarrollo y contempla la
interrelacin entre el SUM y la FISI, modelos de dominio y datos, adems de
los diagramas de diseo necesarios para comprender el comportamiento de
los componentes.
1.3. Definiciones, acrnimos y abreviaturas
OAALD: Oficina de Atencin y apoyo Logstico docente.
UNMSM: Universidad Nacional Mayor de San Marcos.
Integrante de la Comunidad FISI: Docentes, Alumnos, encargado de
Atencin y apoyo Logstico al docente y otros que pertenezcan a la
FISI.
Reporte: Informe, conjunto de datos o informacin sobre algo o
alguien.
Coordinador: Profesor encargado de hacer el seguimiento al curso
asignado.
EAPIS: Escuela Acadmico Profesional de Ingeniera de Sistemas.
EAPSW: Escuela Acadmico Profesional de Ingeniera de Software.
SUM: Sistema nico de Matricula.
FISI: Facultad de Ingeniera de Sistemas e Informtica.
SAPEA: Sistema de apoyo al proceso de Enseanza y Aprendizaje.
DACC: Departamento Acadmico de Ciencias de la Computacin.
DAISW: Departamento Acadmico de Ingeniera de Software.
UAOE: Unidad de Asesora y orientacin al Estudiante.
1.4. Referencias
Los siguientes documentos han sido usados como base para elaborar el
presente documento:
SRS
Anlisis del Proyecto Visin
Confidencial
UNMSM FISI, 2015
Pgina 4 de 30
SAPEA
Versin: 0.2
Fecha: 12/02/2015
1.5. Visin General

El presente documento empieza por mostrar una vista general de la
arquitectura del sistema. Luego, se presenta la vista funcional que est
representada por el modelo de casos de uso. Ms adelante, se muestra la
vista lgica del sistema que contiene el modelo de datos, donde estn
incluidos los diagramas de clases y paquetes. Luego, la vista de
implementacin que est representada mediante el diagrama de
componentes del sistema, la vista de despliegue y finalmente la vista de
integracin del software.
2. VISTA GENERAL DE LA ARQUITECTURA
Subsistema Presentacin de Resultados
Subsistema
Calificacin y
Evaluacin
Subsistema Asistencia Docente

Subsistema Asistencia Alumno
Subsistema Aula Virtual

Subsistema Autentificacin
del Sistema
Base de Datos del Sistema
Capa de
Presentacin
Capa de
Aplicacin y
Lgica de
Negocio
Capa de Base
de Datos
La figura muestra la distribucin de los mdulos del software que tendr el

sistema, adems de brindar una visin general del sistema. En el grfico, se
observa la distribucin en tres capas de la arquitectura, las cuales se describen a
continuacin:
2.1. Capa de presentacin
En esta capa se encuentra la aplicacin Web dedicada a la presentacin de
resultados de SAPEA, la cual estar conformada por las pantallas de
presentacin al usuario, tales como: Estas aplicaciones Web sern pginas
PHP y JSP.
2.2. Capa de Lgica de Negocio
Esta capa provee todo lo que es la lgica del negocio, es decir la
funcionalidad del sistema, ya sea Registro de asistencia docente o alumno,
calificaciones y evaluaciones, reportes y consultas, y el aula virtual.
2.3. Capa de acceso a datos
Esta capa provee los servicios y conexiones a la base de datos requeridos
por la capa de lgica de Negocio. Por otro lado, el manejador de base de
datos utilizado para este sistema ser Mysql 5.5.
Confidencial
UNMSM FISI, 2015
Pgina 5 de 30
SAPEA
Versin: 0.2
Fecha: 12/02/2015
3. METAS Y RESTRICCIONES DE LA ARQUITECTURA

Se han identificado los siguientes requerimientos no funcionales que definen las
metas y restricciones arquitectnicas:
1. Requerimientos no funcionales:
a.
b.
c.
d.
e.
Estructura en capas de la arquitectura

La arquitectura del producto deber disearse de acuerdo a la arquitectura
en 3-capas: Presentacin, Aplicacin, Acceso a Datos.
Lenguaje de programacin
El lenguaje de programacin a emplear para el desarrollo de la capa de
presentacin ser el PHP Y JSP.
Servidor Web
El servidor web a emplear ser Apache Tomcat, que es un contenedor web.
Requerimientos de Entorno
Navegadores como Chrome, Firefox, Internet Explorer.
Plataforma: Windows XP/7/8.
Rendimiento
La especificacin de la carga soportado por el sistema, sern; el nmero
de transacciones sern realizados.
Se garantiza que el 90% de las consulta al sistema deben realizarse en
menos de 3 segundo debido a que su soporte es un buen motor de Bases
de Datos MySql.
Seguridad
Especificacin de elementos que protegern al software de accesos, usos
y sabotajes maliciosos, as como de modificaciones o destrucciones
maliciosas o accidentales.
El sistema deber contar con los siguientes requisitos de seguridad a nivel
de software:
-
Los usuarios del sistema tienen un identificarse nico (cuenta) y un

password, para poder acceder a la aplicacin.
El sistema deber contar con niveles de seguridad a nivel de

usuarios, es decir no todos accedern a la misma interfaz del
sistema.
Se podr crear backups de seguridad en fechas determinadas para

asegurar el resguardo de la informacin.
Cualquier actualizacin realizados por los usuarios del sistema,

quedara registrado en la Base de Datos.
Restricciones de comunicacin entre determinados mdulos.
Asignacin de determinadas funcionalidades a determinados

mdulos.
Se deber realizar un mantenimiento cada cierto tiempo del soporte

de software del sistema preferentemente semestral.
Disponibilidad
El aplicativo se encontrara disponible en todo momento desde su
lanzamiento, deteniendo su acceso solo en casos de reparacin, mejora o
-
f.
Confidencial
UNMSM FISI, 2015
Pgina 6 de 30
SAPEA
Versin: 0.2
Fecha: 12/02/2015
por sucesos externos o accidentales. Se tomaran todas las medidas

posibles para garantizar el acceso continuo.
g.
Confiabilidad
La probabilidad de que el sistema desarrolle una determinada funcin, bajo
ciertas condiciones y durante un perodo de tiempo determinado es
garantizada debido a las herramientas usadas para su desarrollo.
h.
Mantenibilidad
Garantizamos el mantenimiento del sistema 2 veces al ao para actualizar
algunos puntos que se requiera. El mantenimiento se debe de hacer con
brevedad para no afectar el desarrollo del trabajo; no debe tomar ms
tiempo que 5 horas o segn se evale necesario.
i.
Portabilidad
Debido a que es un sistema web, su acceso es posible desde cualquier
dispositivo con acceso a un navegador web: PCs, laptops, tablets,
smartphones, etc.
2. Riesgos Principales
a.
El uso de tecnologa nueva podra ocasionar retrasos y/o baja

calidad del producto.
Debido a que no han existido experiencias anteriores respecto a llevar un
control de la asistencia de los docente en clase y de los alumnos as como
teniendo en cuenta que el usuario no posee mucha experiencia en ese
aspecto, se corre el riesgo de no cumplir las metas sealadas y/o que el
producto resultante no tenga la calidad mnima exigible.
b.
La poca o nula experiencia en el desarrollo de Sistemas que
involucren simultneamente la utilizacin de recursos Hardware y
Software de plataforma hosting VPS como de la plataforma OPEN,
podra generar problemas de Integracin y por tanto un pobre
aprovechamiento de recursos.
Debido a que el aplicativo utilizar tanto la plataforma HOST, como la
Plataforma OPEN, existe el riesgo de interaccin o falta de integracin
entre ambas, lo que redundara en el incumplimiento de metas sealadas
y/o que el producto resultante no tenga la calidad mnima exigible.
c. Uso de la Arquitectura Cliente/Servidor
El uso de esta arquitectura generara mayor conste en el mantenimiento
debido a las aplicaciones que construiremos.
3. Restricciones especiales
a.
Estrategias de diseo e implementacin

Se ha definido una arquitectura de capas que incluya una capa de
presentacin, una capa de negocio, una capa de integracin y una capa de
datos. Adicionalmente nuestro sistema est conformado por un subsistema
aula virtual. Esto significa que en cada una de las capas mencionadas
anteriormente tendr implementaciones para ambas plataformas.
b.
Restricciones de conectividad
c.
Este proyecto solo abarcara bsicamente a la FISI
d.
Conectividad con el Sistema nico de Matricula (SUM)
Confidencial
UNMSM FISI, 2015
Pgina 7 de 30
SAPEA
Versin: 0.2
Fecha: 12/02/2015
4. VISTA CASOS DE USO

A continuacin se muestra el diagrama del modelo de casos de uso agrupados en
paquetes.
El modelo de casos de uso se han dividido en 5 paquetes para un mejor anlisis,
el caso de uso del Mdulo Autentificacin del Sistema, contiene los perfiles de los
usuarios de la FISI; los casos de uso del Mdulo Asistencia-Docente, que
contiene la actualizacin de las tablas de asistencia docente; los casos de uso del
Mdulo Asistencia-Alumno contiene la actualizacin de la asistencia alumno,
adems de las consultas de las asistencias; en los casos de uso del Mdulo
Calificacin y Evaluacin, permite el ingreso de las notas de los alumnos; y por
ltimo los casos de uso del Mdulo Aula Virtual permite la gestin del Aula virtual y
la actualizacin de esta por parte de los alumnos.
En las siguientes secciones se mostrara el modelo de casos de uso que estn
incluidos en los paquetes Autentificacin del sistema, Asistencia-Docente,
Asistencia-Alumno, Aula Virtual y Calificacin y Evaluacin, los cuales son de
inters para la implementacin del Software. As tambin, se detallara ms sobre
la funcionalidad de estos casos de uso.
4.1. Diagrama de Caso de Uso

1.1.1.
Casos de Uso Autentificacin del Sistema
El objetivo de este mdulo es asegurar que el sistema cuente con el

adecuado soporte en cuanto a seguridad y control de acceso a las
diferentes funcionalidades del sistema.
Se tiene definidos los siguientes parmetros de acceso al sistema:
Permite tres intentos de ingreso al sistema.

Permitir cambiar el nmero de clave mximo diez (10) veces. De
requerirse un nuevo cambio deber solicitarse la clave asociada a un
cdigo que ser brindada por miembros de Soporte del Sistema.
Confidencial
UNMSM FISI, 2015
Pgina 8 de 30
SAPEA
Versin: 0.2
Fecha: 12/02/2015
La longitud de la clave es de ocho (8) caracteres.

Los derechos de acceso y los perfiles sern concedidos segn el cargo
en la FISI.
1.1.2.
Casos de Uso Asistencia Docente
El objetivo es permitir registrar la Asistencia del Docente cuando este ya se

encuentre en el aula, en un determinado curso, grupo y modalidad. Adems
de controlar el cumplimiento del Docente mediante las consultas.
El sistema permitir un listado de todas las asistencias del docente,
indicando el estado de la asistencia, fecha y hora.
El sistema permitir confirmar la asistencia del docente en el aula.
Confidencial
UNMSM FISI, 2015
Pgina 9 de 30
SAPEA
1.1.3.
Versin: 0.2
Fecha: 12/02/2015
Casos de Uso Asistencia Alumno
El objetivo de este mdulo es registrar la asistencia de los alumnos en un

determinado curso, grupo y modalidad, as como tambin la consulta de la
asistencia.
Tambin el sistema permitir generar reporte de la asistencia del alumno
para que estos puedan ser evaluados.
1.1.4.
Casos de Uso Calificacin y Evaluacin
El objetivo de este mdulo es registrar las notas del alumno en un curso,

grupo y modalidad.
El sistema permitir calcular el promedio final segn el sistema de
calificacin ya establecido.
El sistema permitir consultar y generar reportes de notas para evaluar el
rendimiento y desempeo del alumno.
El sistema permitir tambin generar la Pre-Acta a los docentes titulares.
1.1.5.
Casos de Uso Aula Virtual
El objetivo de este mdulo es gestionar el aula virtual, lo que involucra los

chats, carga de material del curso, carga del syllabus, etc.
El sistema permitir el ingreso al aula virtual, as como actualizar los
contenidos en el Aula segn el perfil del usuario.
Confidencial
UNMSM FISI, 2015
Pgina 10 de 30
SAPEA
Versin: 0.2
Fecha: 12/02/2015
El sistema permitir generar el reporte de docentes que no cumplen con el

plazo de entrega de Syllabus.
4.2. Casos de Uso Significativos de la Arquitectura

Los casos de uso significativos de la arquitectura son aquellos que tienen
restricciones es decir estn vinculados a requerimientos no funcionales y/o
riesgos.
Caso de Uso Significativo
Requerimientos No Funcionales
Validar en Sistema
Registrar Asistencia - Docente
Registrar Asistencia - Alumnos
Registrar Nota-Alumno
Generar reporte Syllabus Docente
Seguridad
Rendimiento, Confiabilidad
Confidencial
UNMSM FISI, 2015
Pgina 11 de 30
SAPEA
Versin: 0.2
Fecha: 12/02/2015
5. VISTA LGICA DEL SISTEMA

5.1. Generalidades
Confidencial
UNMSM FISI, 2015
Pgina 12 de 30
SAPEA
Versin: 0.2
Fecha: 12/02/2015
5.2. Paquetes de Diseo Arquitectnico Significativos
Los patrones que hemos utilizado para nuestro sistema SAPEA, son los siguientes:
Patrn Adapter
- Utilizaramos el patrn adaptador para la comunicacin con el Aula Virtual (AV). De
este modo, si te cambian el AV, el nico sitio donde tendramos que cambiar el
cdigo es en aquella clase que realiza el papel de adaptador. La diferencia es
sustancial: sin un adaptador probablemente tendramos que cambiar el cdigo de tu
aplicacin en varias lneas, dispersas en decenas o incluso cientos de clases.
Confidencial
UNMSM FISI, 2015
Pgina 13 de 30
SAPEA
Versin: 0.2
Fecha: 12/02/2015
Patrn Estado
- En el caso de obtener un usuario del sistema, primero se ingresara la cuenta y
contrasea, y se verificara en la base de datos si el usuario existe, entonces
verificaremos dos posibles estado Registrado y No registrado, en caso que el
usuario este registrado se cargara sus datos, en caso que no se mostraran
mensajes de que el usuario no est registrado.
- En el caso de hacer la confirmacin de la asistencia del docente en el aula, pueden

haber dos estados Confirmado y No confirmado, esta confirmacin solo se
puede hacer dentro del horario de clase en un intervalo de tiempo definido.
5.2.1. Subsistema Autentificacin del Sistema

5.2.1.1.
<Validar en Sistema>
Clases
Usuario
Atributos de la clase
USUARIO
Nombre
Descripcin
CUENTA
CONTRASEA
Identificador del usuario del sistema.

Contrasea nica del usuario.
Tipo Dato
Varchar2 (20)
Varchar2 (20)
Es
PK
SI
NO
Es
FK
NO
NO
Operaciones de las clases

getUser()
getContrasea()
Cargar()
Confidencial
UNMSM FISI, 2015
Pgina 14 de 30
Es
Null
NO
NO
SAPEA
Versin: 0.2
Fecha: 12/02/2015
5.2.2. Subsistema Asistencia Docente

5.2.2.1.
<Registrar Asistencia Docente>
Clases
U_Docente
Curso
Asistencia_D
Delegado
Atributos de la Clase
CURSO
Nombre
Descripcin
NOM_CURSO
MOD
GRUPO
N_ALUMNOS
COD_PROFESOR
COD_ALUMNO
Identificador de la entidad curso

Modalidad del curso (practica, teora o Lab.)
Grupo del curso (1,2,3)
Nmero de alumnos matriculados en el curso
Clave fornea de la entidad profesor
Clave fornea de la entidad alumno
Tipo Dato
Varchar2 (80)
Varchar2 (20)
Numeric (1,0)
Numeric (2,0)
Varchar2 (8)
Varchar2 (8)
Es
PK
SI
NO
NO
NO
NO
NO
Es
FK
NO
NO
NO
NO
SI
SI
Es
Null
NO
NO
NO
NO
NO
NO
Es
PK
NO
NO
Es
FK
NO
NO
Es
Null
NO
NO
ASISTENCIA_D
Nombre
Descripcin
ESTADO
CONFIRMACION
Estado de la Asistencia
Confirmacin del alumno delegado
Tipo Dato
Varchar2 (20)
Varchar2 (20)
Operaciones de las Clases

getCurso()
getGrupo()
getModalidad()
BuscarCurso()
setHora()
setFecha()
setEstado()
setConfirmacion()
marcarAsistencia()
5.2.3. Subsistema Asistencia Alumno

5.2.3.1.
<Registrar Asistencia-Alumnos>
Clases
U_Docente
Curso
U_Alumno
Asistencia_A
Confidencial
Atributos de las Clases
UNMSM FISI, 2015
Pgina 15 de 30
SAPEA
Versin: 0.2
Fecha: 12/02/2015
ASISTENCIA
Nombre
Descripcin
NOM_CURSO
MOD_CURSO
GRUPO_CURSO
FECHA
HORA
Clave fornea de la entidad curso

Fecha que se registra la Asistencia
Hora que se registra la Asistencia
Tipo Dato
Varchar2 (80)
Varchar2 (20)
Numeric (1,0)
Timestamp(6)
Timestamp(6)
Es
PK
NO
NO
NO
NO
NO
Es
FK
SI
SI
SI
NO
NO
Es
Null
NO
NO
NO
NO
NO
Operaciones de Clase
getCurso()
getGrupo()
getModalidad()
BuscarAlumnos()
marcarAsistencia()
setHora()
setFecha()
5.2.4. Subsistema Calificacin y Evaluacin

5.2.4.1.
<Registrar Nota Alumno>
Clases
Curso
U_Docente
U_Alumno
Sistema_Calificacion
Notas_A
Atributos de Clase
SISTEMA_CALIFICACION
Nombre
Descripcin
NOM_CURSO
PORCENTAJE_PARCIAL
PORCENTAJE_FINAL
PORCENTAJE_PRACTICA
PORCENTAJE_LAB

Porcentaje del examen parcial
Porcentaje del examen Final
Porcentaje del promedio practicas
Porcentaje del promedio laboratorio
Tipo Dato
Varchar2 (80)
Numeric (2,0)
Numeric (2,0)
Numeric (2,0)
Numeric (2,0)
Es
PK
SI
NO
NO
NO
NO
Es
FK
SI
NO
NO
NO
NO
Es
Null
NO
NO
NO
NO
SI
Es
PK
SI
NO
NO
NO
NO
NO
NO
NO
NO
Es
FK
SI
SI
NO
NO
NO
NO
NO
NO
NO
Es
Null
NO
NO
NO
SI
NO
NO
SI
NO
SI
NOTAS_A
Nombre
Descripcin
COD_ALUMNO
NOM_CURSO
PROM_PRACTICA
LABORATORIO
E_PARCIAL
E_FINAL
E_SUSTITUTORIO
PROM_FINAL
ESTADO
Clave fornea de la entidad alumno

Promedio de prctica del alumno
Promedio de laboratorio del alumno
Examen parcial del alumno
Examen final del alumno
Examen sustitutorio del alumno
Promedio Final del alumno
Estado del alumno (aprobado, desaprobado)
Tipo Dato
Varchar2 (8)
Varchar2 (80)
Numeric (2,0)
Numeric (2,0)
Numeric (2,0)
Numeric (2,0)
Numeric (2,0)
Numeric (2,0)
Varchar2 (20)
Operaciones de las Clases

getCurso()
getGrupo()
getModalidad()
BuscarAlumnos()
calcularPromedio()
Confidencial
UNMSM FISI, 2015
Pgina 16 de 30
SAPEA
Versin: 0.2
Fecha: 12/02/2015
guardar()
modificar()
setNota()
getNota()
5.2.5. Subsistema Aula Virtual
5.2.5.1.
<Generar reporte Syllabus Docente >
Clases
Usuario (Director de Escuela)
Atributos de Clase
USUARIO
Nombre
CUENTA
CONTRASEA
Descripcin
Identificador del usuario del sistema.
Contrasea nica del usuario.
Tipo Dato
Varchar2 (20)
Varchar2 (20)
Es
PK
SI
NO
Es
FK
NO
NO
Operaciones de la Clase
cargarAulaVirtual()
mostrarContenidos()
generarReporte()
5.3. Interpretaciones de los Casos de Uso

5.3.1. <Valida en Sistema>
Confidencial
UNMSM FISI, 2015
Pgina 17 de 30
Es
Null
NO
NO
SAPEA
Versin: 0.2
Fecha: 12/02/2015
5.3.2. <Registrar Asistencia Docente>
5.3.3. <Registrar Asistencia-Alumnos>
Confidencial
UNMSM FISI, 2015
Pgina 18 de 30
SAPEA
Versin: 0.2
Fecha: 12/02/2015
5.3.4. <Registrar Nota Alumno>
5.3.5. <Generar reporte Syllabus Docente >
Confidencial
UNMSM FISI, 2015
Pgina 19 de 30
SAPEA
Versin: 0.2
Fecha: 12/02/2015
6. VISTA DE PROCESOS
Confidencial
UNMSM FISI, 2015
Pgina 20 de 30
SAPEA
Versin: 0.2
Fecha: 12/02/2015
6.1. Web Services
6.2. Navegador
Confidencial
UNMSM FISI, 2015
Pgina 21 de 30
SAPEA
Versin: 0.2
Fecha: 12/02/2015
6.3. Email
7. VISTA DE IMPLEMENTACIN
7.1. Generalidades
7.2. Capas
7.2.1. Capa de Presentacin
Confidencial
UNMSM FISI, 2015
Pgina 22 de 30
SAPEA
7.2.1.1.
Versin: 0.2
Fecha: 12/02/2015
<Gestor Web>
Este componente se encargara de la gestin del portal de la
FISI, donde se podr acceder al sistema SAPEA. As como
tambin este componente podr acceder a nuestro servidor web
y a la red del sistema.
7.2.2. Capa de Lgica del Negocio
7.2.2.1.
7.2.2.2.
7.2.2.3.
7.2.2.4.
7.2.2.5.
7.2.2.6.
7.2.2.7.
Confidencial
<Peticin del Usuario>

Este componente tiene que ver con cualquier peticin por parte
del usuario, como el ingreso al sistema, alguna consulta o
actualizacin de los datos. Esto siempre y cuando se cumpla
con las restricciones del sistema.
<Gestor Web>
Este componente podr acceder a nuestro servidor web y a la
red del sistema.
<Receptor de Peticin>
Este componente es el encargado de recepcionar las peticiones
del usuario y darle un significado a la peticin.
<Verificador de Restricciones>
Este componente es el encargado de verificar los permisos del
usuario de acuerdo a su peticin, tambin brinda el permiso de
respuesta de la peticin. Este componente tiene una
comunicacin con el servidor de desarrollo de nuestro sistema
como tambin al servidor de base de datos.
<Recolector de Informacin>
Este componente se encarga de recolectar la informacin de las
base de datos, tiene comunicacin con el componente de
empaquetamiento. Este componente tiene comunicacin con el
servidor de base de datos.
<Empaquetamiento>
Este componente se encarga del formateo y procesamiento de
la informacin, tiene comunicacin con el componente
generador de respuestas.
<Generador de Respuestas>
Este componente es el encargado de generar respuestas
concernientes al procesamiento de la informacin que son
presentadas al usuario.
UNMSM FISI, 2015
Pgina 23 de 30
SAPEA
Versin: 0.2
Fecha: 12/02/2015
7.2.3. Capa de Base de Datos
7.2.3.1.
<Gestor de Base de Datos>

Este componente es el encargado de gestionar los datos de la
base de datos del propio sistema SAPEA como tambin de la
base de datos del SUM. Este componente tiene comunicacin
con el componente recolector de informacin y de
empaquetamiento.
8. VISTA DE DESPLIEGUE
Configuraciones fsicas de red:
Utilizaremos la topologa tipo rbol ya que combina
caractersticas de la topologa de estrella con la BUS.
Consiste en un conjunto de subredes estrella
conectadas a un BUS. Esta topologa nos facilita el
crecimiento de la red. Utilizaremos cable UTP catg 6A
Infraestructura de la red:
Primer Piso:
Confidencial
UNMSM FISI, 2015
Pgina 24 de 30
SAPEA
Segundo Piso:
Tercer piso:
Versin: 0.2
Fecha: 12/02/2015
Caractersticas requeridas para el correcto funcionamiento de los componentes

software:
1.- Memoria: Kingston 8 GB
2.- CPU: Intel core i3
3.- HDD: 1 Tera cigarette
4.- SERVIDORES: INTEL XEON E5 64GB de RAM.
Confidencial
UNMSM FISI, 2015
Pgina 25 de 30
SAPEA
Versin: 0.2
Fecha: 12/02/2015
Diagrama de Despliegue de UML
Entorno de Desarrollo
NOMBRE DEL SERVIDOR
Servidor_D
DESCRIPCION Y OBJETIVO DEL SERVIDOR
En este servidor se almacenar el cdigo fuente de nuestro Sistema, en este entorno
trabajaran los desarrolladores.
Entorno Web
NOMBRE DEL SERVIDOR
En este servidor estarn todos los servicios va web.
Servidor_Web
Entorno de Base de Datos

NOMBRE DEL SERVIDOR
Servidor_BD
En este servidor se almacenara toda nuestra base de datos que necesite nuestro sistema.
Confidencial
UNMSM FISI, 2015
Pgina 26 de 30
SAPEA
Versin: 0.2
Fecha: 12/02/2015
9. VISTA DE DATOS
9.1. Modelo de Base de Datos Lgico y Fsico
En la implementacin de la base de datos en memoria secundaria. Se incluye las

estructuras de almacenamiento y los mtodos de acceso que se utilizarn para
conseguir un acceso eficiente a los datos. Todo esto nos ayuda a:
Mejorar el rendimiento
Espacio en memoria y en disco
Tiempo de procesador
Tiempo de disco
Contencin
Coste de los procesos auxiliares
Escalabilidad
Volumen de usuarios y datos
Sobre el almacenamiento:
Tablas y registros
Para aumentar el al rendimiento en el acceso a los datos se utilizara los siguientes
mtodos:
ndices n ( Arboles B+)
Estructuras auxiliares para mejorar el tiempo de bsqueda n ordenacin n ORDER BY,
GROUP BY, DISTINCT.
Backup, ficheros de logs de transacciones, ficheros de configuracin y logs
binarios.
Limpiar los logs binarios: Se realiza

mediante my.conf usando expire_logs_days o mediante la sentencia PURGE
MASTER LOGS. Eso s, no purgar los logs que necesiten los esclavos, ni borrarlos
mediante un comando de un fichero (rm bin-log.*).
Confidencial
UNMSM FISI, 2015
Pgina 27 de 30
SAPEA
Versin: 0.2
Fecha: 12/02/2015
Optimizar las tablas: despus de inserts y updates las tablas se llenan de espacio
intil, por lo que es necesario optimizar las tablas usando OPTIMIZE TABLE.
Vaciar la cach: al ejecutarse selects con
tamaos diferentes de resultados, el cache se defragmenta, lo cual hace necesario
que se vacie la cache (FLUSH QUERY CACHE).
Uso de Procedimientos Almacenados : Para la seleccin de datos ms rpida por
parte del motor de base datos
Uso de disparadores: Al cumplirse una condicin establecida.
10. TAMAO Y DESEMPEO

El Sistema SAPEA se puede catalogar como un sistema de mediana envergadura, en
vista de que sus usuarios objetivos son alumnos y docentes, las cuales cuentan (a lo
sumo) con una cantidad de 1100 personas (de los cuales se puede asumir que el
nmero de usuarios ser estrictamente menor a esa cantidad) donde el sistema Web
permitir el acceso concurrente a varios usuarios, de modo que puedan realizar
transacciones simultneas. Sin embargo, no se puede medir a priori el volumen de
informacin que ser cargada en el sistema debido a que esto depender de manera
directamente proporcional a las actividades de cada usuario y el tamao de las
rdenes que ingresen en el sistema. La cantidad mxima de informacin que pueda
alojarse en el sistema depender de la capacidad de alojamiento del servidor en el
cual se implante el Sistema SAPEA.
El sistema a ser ejecutado en las computadoras terminales clientes del sistema Web,
no debe de demandar ms recursos que los que tendra una computadora como la
especificada dentro de los requisitos de hardware mnimos para las computadoras
clientes definidas en el Documento del Diseo del Sistema.
El Sistema SAPEA tambin puede considerarse como un sistema de alta portabilidad,
debido a sus bajos requerimientos de sistema: un servidor con soporte de PHP y
MySQL, un explorador Web (Microsoft Internet Explorer, Mozilla Firefox o Google
Chrome) y una conexin de Internet. Adicionalmente, el patrn de arquitectura
utilizado para su desarrollo garantiza reducir a un mnimo la complejidad del diseo de
la arquitectura y maximizar la flexibilidad y mantenimiento del cdigo. El sistema est
diseado para que cumpla acciones y peticiones en un periodo de 1 a 3 segundos,
dado que se cuente con una buena velocidad de Internet y que no ocurran fallas en el
servidor de implantacin.
El Sistema encuentra su mayor restriccin en el estado de la conexin de Internet
entre la mquina cliente y el servidor que aloja al sistema. Una baja velocidad de
conexin en la red puede afectar los tiempos de respuesta del sistema o, en su peor
caso, impedir hacer uso del sistema.
11. CALIDAD
En esta seccin se describirn los atributos de calidad que se busca cumplir por medio
de la arquitectura planteada en este documento.
Usabilidad
Las interfaces del SAPEA han sido desarrolladas para ser bastante amigables para
los usuarios ya que incluyen grficos para su mayor entendimiento en cada una de
estas.
Confidencial
UNMSM FISI, 2015
Pgina 28 de 30
SAPEA
Versin: 0.2
Fecha: 12/02/2015
Debido a que el SAPEA est orientado solo para los usuarios de la FISI, su uso est
destinado nicamente para estos. Se podra hacer factible su uso para otras
facultades y/o instituciones las cuales estn orientadas al rubro de la educacin y que
sus reglas del negocio se aproximen a las de la FISI.
Eficiencia
El sistema tendr una respuesta casi inmediata (entre 1 y 3 segundos), debido a que
realiza servicios en lnea, por lo que depende del internet. Su rendimiento esta
solamente limitado a la velocidad del internet.
Seguridad
El sistema permitir el uso de sus distintas funcionalidades dependiendo del perfil con
el que el usuario accede al sistema, validando su ingreso a travs de su usuario y
contrasea (ya sea Alumno, Docente o Personal Administrativo). Por lo tanto no puede
haber filtro de informacin de un usuario a otro ya que cualquier accin realizada por
uno de estos ser registrada en el sistema como un historial junto con los datos
personales.
Los datos no pueden ser visualizados o manipulados desde el exterior ya que se usa
un motor de base de datos Oracle 11g al cual solo se puede acceder si es que loguea
el usuario registrado en el sistema.
Confiabilidad
El sistema siempre validara los datos ingresados y mostrara mensajes indicando la
posible solucin en caso de presentar errores. En varios formularios se han
restringidos la digitacin de ciertos caracteres para asegurar la validacin de los datos
a la hora de ser guardados en el sistema.
En caso de que sucedan errores en el sistema, se mostraran mensajes indicando los
detalles de estos errores para que el usuario tome las medidas adecuadas ante estos.
Adems el sistema dar a conocer el resultado de las acciones de los usuarios,
mediante mensajes de confirmacin o variaciones en pantalla.
Mantenimiento
El mantenimiento estar regido de acuerdo a las necesidades de la FISI y los posibles
fallos que surjan y que no se hayan identificado. Debido a que el sistema no es de
gran envergadura y solo est orientado a web, su mantenimiento futuro no tendr
muchas dificultades incluso si el personal de desarrollo fuese diferente al inicial, ya
que adems el cdigo es bastante flexible.
Estndares
Se usar un estndar para todas las ventanas e interfaces. Asimismo se tendr un
estndar para el nombre de los formularios, clases, variables, mtodos y los cdigos.
Integridad
El sistema mantiene la informacin de los usuarios consistente con lo que stos
diligencian al ingresar a ste. Para lograr esto, se mantiene el almacenamiento de la
informacin como un mdulo aparte el cual no es accedido directamente por ningn
tipo de agente externo.
Escalable
El sistema permite la adhesin de nuevos componentes con el fin de dar ms
funcionalidades al sistema. En el caso de agregar un nuevo componente en la
Confidencial
UNMSM FISI, 2015
Pgina 29 de 30
SAPEA
Versin: 0.2
Fecha: 12/02/2015
arquitectura, esto se hace de manera transparente adicionando una interfaz del nuevo
mdulo para que sea utilizada por los ya existentes.
Confidencial
UNMSM FISI, 2015
Pgina 30 de 30

Arquitectura de Software

Cargado por

Copyright:

Formatos disponibles

Arquitectura de Software

Cargado por

Información del documento

Descripción original:

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

Arquitectura de Software

Cargado por

Copyright:

Formatos disponibles

UNMSM

Documento de Arquitectura de Software

Quilca Castaeda, Andreli

Arquitectura del Sistema

Quilca Castaeda, Andreli

Arquitectura del Sistema

Quilca Castaeda, Andreli

Arquitectura del Sistema

Quilca Castaeda, Andreli

Quilca Castaeda, Andreli

UNMSM FISI, 2015

UNMSM FISI, 2015

DOCUMENTO DE ARQUITECTURA DEL SISTEMA

Plasmar mediante diagramas, modelos y artefactos del RUP, las

Esbozar los aspectos funcionales de la aplicacin.

Definir los mecanismos de despliegue y distribucin del sistema.

Esbozar el modelo entidad relacin de la arquitectura de datos a

UNMSM FISI, 2015

1.5. Visin General

Subsistema Asistencia Docente

Subsistema Aula Virtual

Base de Datos del Sistema

La figura muestra la distribucin de los mdulos del software que tendr el

UNMSM FISI, 2015

3. METAS Y RESTRICCIONES DE LA ARQUITECTURA

Estructura en capas de la arquitectura

Los usuarios del sistema tienen un identificarse nico (cuenta) y un

El sistema deber contar con niveles de seguridad a nivel de

Se podr crear backups de seguridad en fechas determinadas para

Cualquier actualizacin realizados por los usuarios del sistema,

Restricciones de comunicacin entre determinados mdulos.

Asignacin de determinadas funcionalidades a determinados

Se deber realizar un mantenimiento cada cierto tiempo del soporte

UNMSM FISI, 2015

por sucesos externos o accidentales. Se tomaran todas las medidas

El uso de tecnologa nueva podra ocasionar retrasos y/o baja

Estrategias de diseo e implementacin

UNMSM FISI, 2015

4. VISTA CASOS DE USO

4.1. Diagrama de Caso de Uso

Casos de Uso Autentificacin del Sistema

El objetivo de este mdulo es asegurar que el sistema cuente con el

Permite tres intentos de ingreso al sistema.

UNMSM FISI, 2015

La longitud de la clave es de ocho (8) caracteres.

Casos de Uso Asistencia Docente

El objetivo es permitir registrar la Asistencia del Docente cuando este ya se

UNMSM FISI, 2015

Casos de Uso Asistencia Alumno

El objetivo de este mdulo es registrar la asistencia de los alumnos en un

Casos de Uso Calificacin y Evaluacin

El objetivo de este mdulo es registrar las notas del alumno en un curso,

Casos de Uso Aula Virtual

El objetivo de este mdulo es gestionar el aula virtual, lo que involucra los

UNMSM FISI, 2015

El sistema permitir generar el reporte de docentes que no cumplen con el

4.2. Casos de Uso Significativos de la Arquitectura

UNMSM FISI, 2015

5. VISTA LGICA DEL SISTEMA