Anda di halaman 1dari 30

UNMSM

Documento de Arquitectura de Software


SAPEA
Versin 0.2

SAPEA
Documento de Arquitectura de Software
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

Quilca Castaeda, Andreli


Santos Saldaa, Judith

Arquitectura del Sistema

11/02/2015

0.4

Quilca Castaeda, Andreli


Santos Saldaa, Judith

Arquitectura del Sistema

12/02/2015

0.5

Quilca Castaeda, Andreli


Santos Saldaa, Judith
Paz, Carlos

Requisitos No Funcionales
Vista Lgica
Vista de CUS

27/02/2015

0.6

Quilca Castaeda, Andreli


Santos Saldaa, Judith
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
Documento de Arquitectura de Software
Arquitectura de Software.doc

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
Documento de Arquitectura de Software
Arquitectura de Software.doc

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
Documento de Arquitectura de Software
Arquitectura de Software.doc

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
Documento de Arquitectura de Software
Arquitectura de Software.doc

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
Documento de Arquitectura de Software
Arquitectura de Software.doc

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
Documento de Arquitectura de Software
Arquitectura de Software.doc

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
Documento de Arquitectura de Software
Arquitectura de Software.doc

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
Documento de Arquitectura de Software
Arquitectura de Software.doc

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
Documento de Arquitectura de Software
Arquitectura de Software.doc

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
Rendimiento, Confiabilidad
Rendimiento, Confiabilidad
Rendimiento, Confiabilidad

Confidencial

UNMSM FISI, 2015

Pgina 11 de 30

SAPEA
Documento de Arquitectura de Software
Arquitectura de Software.doc

Versin: 0.2
Fecha: 12/02/2015

5. VISTA LGICA DEL SISTEMA


5.1. Generalidades

Confidencial

UNMSM FISI, 2015

Pgina 12 de 30

SAPEA
Documento de Arquitectura de Software
Arquitectura de Software.doc

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
Documento de Arquitectura de Software
Arquitectura de Software.doc

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
Documento de Arquitectura de Software
Arquitectura de Software.doc

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
Documento de Arquitectura de Software
Arquitectura de Software.doc

Versin: 0.2
Fecha: 12/02/2015

ASISTENCIA
Nombre

Descripcin

NOM_CURSO
MOD_CURSO
GRUPO_CURSO
FECHA
HORA

Clave fornea de la entidad curso


Clave fornea de la entidad curso
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

Clave fornea de la entidad curso


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


Clave fornea de la entidad curso
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
Documento de Arquitectura de Software
Arquitectura de Software.doc

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
Documento de Arquitectura de Software
Arquitectura de Software.doc

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
Documento de Arquitectura de Software
Arquitectura de Software.doc

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
Documento de Arquitectura de Software
Arquitectura de Software.doc

Versin: 0.2
Fecha: 12/02/2015

6. VISTA DE PROCESOS

Confidencial

UNMSM FISI, 2015

Pgina 20 de 30

SAPEA
Documento de Arquitectura de Software
Arquitectura de Software.doc

Versin: 0.2
Fecha: 12/02/2015

6.1. Web Services

6.2. Navegador

Confidencial

UNMSM FISI, 2015

Pgina 21 de 30

SAPEA
Documento de Arquitectura de Software
Arquitectura de Software.doc

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
Documento de Arquitectura de Software
Arquitectura de Software.doc

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
Documento de Arquitectura de Software
Arquitectura de Software.doc

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
Documento de Arquitectura de Software
Arquitectura de Software.doc

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
Documento de Arquitectura de Software
Arquitectura de Software.doc

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
DESCRIPCION Y OBJETIVO DEL SERVIDOR
En este servidor estarn todos los servicios va web.

Servidor_Web

Entorno de Base de Datos


NOMBRE DEL SERVIDOR
Servidor_BD
DESCRIPCION Y OBJETIVO DEL SERVIDOR
En este servidor se almacenara toda nuestra base de datos que necesite nuestro sistema.

Confidencial

UNMSM FISI, 2015

Pgina 26 de 30

SAPEA
Documento de Arquitectura de Software
Arquitectura de Software.doc

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
Documento de Arquitectura de Software
Arquitectura de Software.doc

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
Documento de Arquitectura de Software
Arquitectura de Software.doc

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
Documento de Arquitectura de Software
Arquitectura de Software.doc

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