UNIVERSIDAD AMAZÓNICA DE PANDO

ÁREA DE CIENCIAS Y TECNOLOGÍA

CARRERA DE INGENIERÍA DE SISTEMAS

PROYECTO

“SISTEMA BIOMÉTRICO DACTILAR CLIENTE/SERVIDOR DE CONTROL DE

AMBIENTES Y ASISTENCIA DE PERSONAL DEL ACYT”

UNIV: Paulina Irene Velasquez Ferrufino

UNIV. Erin Boris Valdivia Balderrama

UNIV. Rodrigo Cruz Mendoza

ASESOR: Lic. Javier Patty Magne

Cobija - Pando – Bolivia

2018

i
 AGRADECIMIENTOS

A los compañeros universitario Jefferson

Mendoza Marino, Luis Enrique Villca
Mamani y al universitario Jesús Israel
Condori Choquehuanca por sus
colaboraciones en el transcurso del desarrollo
del sistema.

ii
 RESUMEN

En el presente proyecto tiene como propósito el desarrollo de un sistema informático con

estructura biométrica dactilar cliente/servidor para el control de ambientes y asistencia de
docentes, estudiantes y becarios del ACyT el cual surgió base de la problemática identificada
en los procesos que existe en el área para el respectivo control de asistencia. De acuerdo a la
metodología proceso unificado se desarrolló el sistema analizando los procesos que existen
dentro del área plasmándolo de acuerdo al lenguaje visual UML, diseñando la estructura del
sistema para la respectiva construcción del mismo, como también se obtuvo una propuesta
de red simulada para el sistema funcional.

El sistema desarrollado es una herramienta de utilidad para el Área de Ciencias y

Tecnologías, permite realizar registros de asistencias ya que le permite, acceso de
información y manejo de la información de forma rápida y confiable; facilitando a los
directores superiores en realizar sus reportes (diarios, mensuales, anuales). Los procesos
comprendidos en esta área son gestión de asistencias, retrasos, faltas y permisos de docentes
y becarios como también la gestión de asistencia de los estudiantes.

iii
 ABSTRACT

The purpose of this project is to develop a computer system with a biometric client / server
structure to control the environments and assistance of teachers, students and scholarship
holders of the ACyT, which emerged as the basis for the problems identified in the processes
that exist in the area for the respective attendance control. According to the unified process
methodology, the system was developed by analyzing the processes that exist within the area,
according to the UML visual language, designing the structure of the system for the
respective construction of the system, as well as a simulated network proposal for the
functional system.

The developed system is a tool of utility for the Sciences and Technologies Area, it allows
to make attendance records since it allows, information access and management of the
information in a fast and reliable way; facilitating senior managers in making their reports
(daily, monthly, annual). The processes included in this area are assistance management,
delays, faults and permits for teachers and interns as well as student attendance management.

iv
 ÍNDICE

1. INTRODUCCION .......................................................................................................... 1
1.1. ANTECEDENTES .................................................................................................. 2
1.2. DESCRIPCIÓN DEL PROBLEMA ........................................................................ 3
1.3. OBJETIVOS ............................................................................................................ 4
1.3.1. Objetivo general ............................................................................................... 4
1.3.2. Objetivos Específicos ....................................................................................... 5
1.4. METODOLOGÍA Y HERRAMIENTAS UTILIZADAS ....................................... 5
1.5. JUSTIFICACION .................................................................................................... 7
1.6. ALCANCES ............................................................................................................ 7
2. MARCO TEÓRICO ........................................................................................................ 9
2.1. FUNDAMENTACIÓN TEÓRICA ....................................................................... 10
2.1.1. Sistema biométrico ......................................................................................... 10
2.1.2. Sistema de información .................................................................................. 11
2.1.3. Tecnología de información. ............................................................................ 11
2.1.4. Control administrativo. ................................................................................... 11
2.1.5. Paradigma orientado a objetos........................................................................ 12
2.1.6. Base datos ....................................................................................................... 12
2.1.7. Modelo Vista Controlador .............................................................................. 12
2.1.8. Mapeo objeto relacional ................................................................................. 13
2.1.9. Aplicación web ............................................................................................... 13
2.1.10. Intranet ........................................................................................................ 13
2.1.11. Red de computadoras .................................................................................. 14
2.1.12. Protocolo IP ................................................................................................ 14
2.1.13. Direccionamiento IP ................................................................................... 15
2.1.14. Formato de Dirección IP versión 4 ............................................................. 15
2.1.15. Broadcast .................................................................................................... 15
2.1.16. Host ............................................................................................................. 16
2.2. UML (Lenguaje de Modelado Unificado) ............................................................. 16
2.3. Herramientas Utilizadas. ........................................................................................ 20
v
 2.4. CONTEXTO INSTITUCIONAL DEL AREA DE CIENCIAS Y TECNOLOGIA
DE LA UNIVERSIDAD AMAZONICA DE PANDO .................................................... 22
2.4.1. Misión ............................................................................................................. 22
2.4.2. Visión ............................................................................................................. 22
2.4.3. Objetivo .......................................................................................................... 22
2.4.4. Estructura Orgánica del Área de Ciencias y Tecnología. ............................... 24
2.5. DESCRIPCIÓN DE LA METODOLOGÍA .......................................................... 25
2.5.1. Fase I: Inicio ................................................................................................... 26
2.5.2. Fase II: Elaboración ........................................................................................ 26
2.5.3. Fase III: Desarrollo ......................................................................................... 26
2.5.4. Fase IV: Transición ........................................................................................ 26
3. DESARROLLO DEL SISTEMA ................................................................................. 28
3.1. FASE DE INICIO .................................................................................................. 29
3.1.1. Modelo del proceso de negocios .................................................................... 29
3.1.2. Requerimientos ............................................................................................... 35
3.2. FASE DE ELABORACIÓN .................................................................................. 38
3.2.1. Diagrama de Casos de Uso General ............................................................... 39
3.2.2. Diagrama de secuencia ................................................................................... 41
3.2.3. Diagrama de clases ......................................................................................... 45
3.2.4. Diagrama de la Base de datos ......................................................................... 47
3.3. FASE DE CONSTRUCCION ............................................................................... 47
3.3.1. Código fuente: ................................................................................................ 48
3.3.2. Diagramas de Redes: ...................................................................................... 49
3.3.3. Diagrama de componentes.............................................................................. 50
3.3.4. Diagrama de Despliegue ................................................................................. 53
3.3.5. Diagrama de desaplique de software .............................................................. 54
3.4. FASE DE TRANSICIÓN ...................................................................................... 55
4. CONCLUSIONES ........................................................................................................ 68
5. RECOMENDACIONES ............................................................................................... 71
6. BIBLIOGRAFÍA ........................................................................................................... 73
7. ANEXOS ....................................................................................................................... 76

vi
Anexo A: Análisis de involucrados ............................................................................... 77
Anexo B: Análisis de problema .................................................................................... 78
Anexo C: Análisis de objetivo ...................................................................................... 79
Anexo D: Análisis de alternativa .................................................................................. 80
Anexo E: Matriz de marco lógico ................................................................................. 81
Anexo F: Casos de uso .................................................................................................. 82
Anexo G: Diagrama de clases ....................................................................................... 90
Anexo H: Manual de Usuario........................................................................................ 96
Anexo I: Auditoria de Seguridad al sistema biométrico dactilar cliente/servidor de
control de ambientes y asistencia de personal del acyt. .............................................. 100

vii
 ÍNDICE DE FIGURAS
Ilustración 1: Descripción del UML ..................................................................................... 17
Ilustración 2: UML ............................................................................................................... 18
Ilustración 3: Metodología de Proceso Unificado ................................................................ 27
Ilustración 4: Diagrama Contexto ........................................................................................ 30
Ilustración 5: Diagrama de procesos .................................................................................... 31
Ilustración 6: Diagrama de captura de información ............................................................. 32
Ilustración 8: Diagrama de actividades capturar información personal ............................... 34
Ilustración 9: Diagrama caso de uso general ........................................................................ 39
Ilustración 10: Diagrama de secuencias ............................................................................... 41
Ilustración 11: Diagrama de secuencia ocupación persona .................................................. 42
Ilustración 12: Diagrama de secuencia registrar huella ........................................................ 43
Ilustración 13: Diagrama de secuencia registrar horario ...................................................... 44
Ilustración 14: Diagrama de secuencia capturar asistencia .................................................. 45
Ilustración 15: Diagrama de clases ....................................................................................... 46
Ilustración 16: Diagrama de la base de datos ....................................................................... 47
Ilustración 17: Código fuente ............................................................................................... 48
Ilustración 18: diagrama de redes ......................................................................................... 49
Ilustración 19: diagrama de componentes 1 ......................................................................... 50
Ilustración 20: diagrama de componentes 2 ......................................................................... 51
Ilustración 21: diagrama de componentes 3 ......................................................................... 53
Ilustración 22: Diagrama de despliegue ............................................................................... 53
Ilustración 23: diagrama de despliegue de software ............................................................. 54
Ilustración 24: Panel de inicio .............................................................................................. 55
Ilustración 25: Insertar persona ............................................................................................ 56
Ilustración 26: Ocupación persona ....................................................................................... 57
Ilustración 27: Registro de huella ......................................................................................... 58
Ilustración 28: Buscar persona ............................................................................................. 58
Ilustración 29: Registro de horario docente .......................................................................... 59
Ilustración 30: Asignación de materia a estudiante .............................................................. 60
Ilustración 31: Control de asistencia .................................................................................... 61
Ilustración 32: Inicio Sesión ................................................................................................. 62
Ilustración 33: Datos de perfil .............................................................................................. 63
Ilustración 34: Editar datos ................................................................................................... 63
Ilustración 35: Materias ........................................................................................................ 64
Ilustración 36: Horario.......................................................................................................... 64
Ilustración 37: Información Asistencia ................................................................................ 65
Ilustración 38: Carrera .......................................................................................................... 65
Ilustración 39: Registrar Carrera .......................................................................................... 66
Ilustración 40: Información Asistencia ................................................................................ 66
viii
Ilustración 41: Registrar Nueva Persona .............................................................................. 67
Ilustración 42: Diagrama caso de uso registrar persona ....................................................... 82
Ilustración 43: diagrama caso de uso registrar huella........................................................... 83
Ilustración 44: diagrama caso de uso marca asistencia ........................................................ 84
Ilustración 45: diagrama caso de uso asignar horario .......................................................... 86
Ilustración 46: Diagrama caso de uso habilitar asignatura ................................................... 87
Ilustración 47: Diagrama caso de uso generar reporte ......................................................... 88
Ilustración 48: Auditoria de Seguridad al Sistema ............................................................. 100

ÍNDICE DE TABLAS
Tabla 1: Metodología Procesos Unificado ............................................................................. 6
Tabla 2: Tabla de requerimientos funcionales ...................................................................... 37
Tabla 3: Requerimientos no funcionales .............................................................................. 38
Tabla 4: Diagrama de casos de uso general .......................................................................... 39
Tabla 5: Análisis de involucrados ........................................................................................ 77

ix
CAPITULO I
1. INTRODUCCION

1
1.1. ANTECEDENTES

El Área de Ciencias y tecnologías perteneciente a la Universidad Amazónica de Pando a

finales del año 2017 implemento un sistema de control de asistencia para docentes, con dos
procesos distintos, uno manual y el otro automatizado, en el caso del proceso automatizado
se registraba los horarios de entrada y de salida de los docentes, para lo cual el docente
marcaba su asistencia con un lector de huella dactilar. En el caso del proceso manual para
llevar a cabo el control de asistencia se obtenía los registros realizados por el sistema
procediendo a procesos de comparación para la emisión de informes a finales del mes.
El control de asistencia es una temática que fue revolucionando juntamente con el uso de la
biometría, sistemas que buscan la confiabilidad que es la persona correcta que está presente
en un cierto lugar o dentro de su fuente de trabajo. La identificación del individuo por huella
dactilar es una técnica que es utilizada en la mayoría de las empresas grandes o pequeñas,
debido a su bajo costo en comparación con las otras tecnologías biométricas, ya que permiten
realizar la identificación del individuo común margen de error mínimo.
La biometría es una tecnología que se dedica al estudio de las características únicas del
individuo para identificación como: huella dactilar, silueta de la mano, patrones de la retina,
iris, voz o la firma.
A continuación, se describen tesis similares en relación al proyecto que se está desarrollando
en el presente trabajo de investigación. El primer proyecto titula “REINGENIERIA DEL
SISTEMA DE CONTROL DE ASISTENCIA DEL PERSONAL DE LA UAP” ,”El presente
proyecto de grado aborda todo lo referente a la reingeniería y desarrollo del sistema de control
de asistencia del personal de la UAP, de acuerdo a los análisis de marco lógico se planteó el
deficiente control de asistencia del personal de la UAP, buscando la mejora del sistema
automatizado del control de asistencia aplicando la metodología de la reingeniería de
software, para coadyuvar en la mejor administración personal de la universidad. Empleando
las metodologías de reingeniería de software y métrica V. 3.0, las herramientas de análisis y
diseño UML y WAE. Desarrollando un sistema cuyo funcionamiento está bajo modelo
clientes/servidor el cual centraliza los datos en un servidor, para que los usuarios del sistema
puedan mediante internet”. (Freddy Morales, 2006)

2
El siguiente trabajo es un proyecto para el título de Ingeniería Electrónica y Redes de
Información el cual titula “DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA DE
CONTROL DE ASISTENCIA DE PERSONAL, MEDIANTE EL USO DE TECNOLOGÍA
DE HUELLA DACTILAR” cuto resumen es “El presente proyecto de titulación describe el
desarrollo del sistema de registro de horas de empleados, utilizando la tecnología biométrica
de huella dactilar, la cual cuenta con la documentación escrita en cinco capítulos más diez
anexos que contiene la información, para realizar el desarrollo de la aplicación biométrica;
así como las pruebas realizadas para el proceso de registro mediante la autenticación del
empleado”.(Luis Miguel Chuqui Chicaiza, 2014)

El siguiente trabajo es un proyecto de grado que titula “SISTEMA DE IDENTIFICACIÓN

MEDIANTE HUELLA DIGITAL PARA EL CONTROL DE ACCESOS A LA
UNIVERSIDAD LIBRE SEDE BOSQUE POPULAR SIMULADOEN UN ENTORNO
WEB” cuyo resumen es “A lo largo de la historia se ha forjado la seguridad como algo a
tener en cuenta y que sin darle la suficiente importancia nos ha marcado en todos los aspectos
que vivimos a diario. Con apoyo de la tecnología y la ciencia, se ha avanzado en este aspecto
de manera acelerada y brillante. Dentro de nuestra vida personal nos encontramos que al salir
de nuestra casa cerramos la puerta principal con llave, pero también dentro de nuestra casa
hay más puertas y sin ser conscientes del concepto de seguridad, sentimos la necesidad de
proteger nuestros objetos personales. Este proyecto surge de esa necesidad, de monitorear,
registrar, consultar y más que todo controlar los accesos a las personas que ingresan a la sede
bosque popular de la universidad libre.” (Daniel Felipe Montaña, 2017)

1.2. DESCRIPCIÓN DEL PROBLEMA

El Área de Ciencia y Tecnología perteneciente a la Universidad Amazónica de Pando opera

las carreras de Ingeniería Industrial, Ingeniería Sistemas e Ingeniería Civil. Cuenta con un
sistema de control de asistencia que posee ciertas deficiencias en la parte de control de
asistencia del personal docente el cual ocasiona molestias en el momento de realizar un
seguimiento de control para emisiones de informes finales del mes dando paso a
incertidumbres respecto a la fiabilidad de los informes finales.

3
Como efecto se aprecia ciertos problemas:

 Dificultad en obtener la información general de docentes en su asistencia.

 Dificultad en obtener la cantidad de retrasos o faltas de docentes.

 Riesgo a perdida de información

 Posibilidad de existencia de errores en informes finales

 Constante llamadas de atención por fallas técnicas

 Posibles alteraciones en los datos finales.

Los cuales surgen a causa:

 Inexistencia de registros de inasistencias.

 Inexistencia de registros de faltas o permisos.

 Deficiente validación en el registro de asistencia.

 Software de registro de asistencia descentralizado.

 Posibles alteraciones involuntarias o voluntarias al transcurso de obtener los datos.

Así mismo se toma en cuenta como problema principal el deficiente control de asistencia de
docentes, universitarios y becarios del Área de Ciencias y Tecnología (ACyT).

1.3. OBJETIVOS

1.3.1. Objetivo general

Desarrollar un Sistema Biométrico para el control y gestión de asistencia de personal

docentes, universitarios y becarios del Área de Ciencias y Tecnología (ACyT) utilizando las
tecnologías de Java2EE y la plataforma de digital persona 4500.

4
1.3.2. Objetivos Específicos

 Modelar el negocio para determinar el proceso de registro de asistencia del personal

mediante diagramas de procesos.
 Diseñar la arquitectura del sistema para definir la estructura de sus funcionalidades
y la estructura interna de cada una de ellas mediante diagramas de componentes.
 Desarrollar el sistema para implementar cada una de las especificaciones del diseño
mediante el patrón MVC, POO y modelo relacional.
 Proponer el sistema funcional en una red simulada del área de ciencias y tecnología
(ACyT) mediante Pack Tracer.
 Desplegar el sistema en un servidor Linux.

1.4. METODOLOGÍA Y HERRAMIENTAS UTILIZADAS

Dirigido por casos de uso, Centrado en la arquitectura, Iterativo e Incrementar es lo que lo

que caracteriza a la metodología empleada como es el Proceso Unificado en sus cuatro fases
de inicio, elaboración, construcción y transición donde los artefactos o entregables son
desplegados en función de los flujos de trabajo de análisis, diseño, implementación, pruebas
e implantación.

El nombre Proceso Unificado se usa para describir el proceso genérico que incluye aquellos
elementos que son comunes a la mayoría de los refinamientos existentes. Es una metodología
orientada a conducir el proceso de desarrollo de software en sus aspectos técnicos; los flujos
y productos de trabajo de UP no incluyen la administración del proyecto.
OBJETIVOS HERRAMIENTAS O
FASES PRODUCTOS
ESPECIFICOS TECNICAS
TECNICAS
 Modelar el negocio
para determinar el  Cuestionarios (lápiz  Documentación de
proceso del control de papel) la visión y metas del
proyecto.
 Entrevistas
INICIO

asistencia.
 Modelado de los
 Analizar los procesos procesos de
que se ejecutan en el HERRAMIENTAS negocios
control de asistencia  Diagrama de Penker
en el ACyT.  (BPMN, Penker,
DFD)
 Enterprise Architect

5
 TECNICAS
 Casos de uso
 Diagramas de clases
 Diagrama de casos de
ELABORACION
 Diseñar la arquitectura  Modelo de uso
del sistema para requerimientos  Diagrama de
definir la estructura de
actividades
sus funcionalidades y HERRAMIENTAS
 Diagrama de
la estructura interna de secuencia
cada una de ellas  Enterprise Architect  Diagrama de clases
(Version libre)

TECNICAS
 Diseño de la base
 Patrón MVC datos
CONSTRUCCION

 POO  Codificación del

 Construir el sistema  Modelo relacional software
para implementar
todas las
HERRAMIENTAS  Pruebas de
especificaciones del  Power Designer integración
 MySQL  Diagrama de
diseño componentes
 JavaEE
 Prototipo del
 Servidor Glassfish
Software
5.1.0
TECNICAS

 Diagrama de
componentes
 Proponer el sistema
 Documento de
TRANSICIÓN

funcional en una red

aceptación del
simulada del área de  Documento de
ciencias y tecnología software
aceptación del
(ACyT). producto de Software
HERRAMIENTAS
 Desplegar el sistema
 Pack Tracer
en un servidor Linux
 Servidor Ubuntu
16.04
 Manual de
usuario

Tabla 1: Metodología Procesos Unificado

Fuente: Elaboración propia

Para forjar un lenguaje visual común utilizaremos el Lenguaje Unificado de Modelado

(UML), es un lenguaje gráfico que permite visualizar, especificar, construir y documentar
cada una de los elementos que forman un sistema software orientado a objetos. La notación
6
gráfica de UML se utiliza para visualizar el sistema y la especificación se utiliza para expresar
los detalles de dicho sistema. (Aaron, 2018)

Se consideró el diagrama de casos de uso y el diagrama de clases para dar a conocer la

estructura general del sistema, para ello se usó herramientas y técnicas como ser entrevistas,
observaciones y cuestionarios.

El diseño de la base de datos, codificación del software, pruebas de integración, diagrama

de componentes, prototipo del Software fueron desarrollados para implementar todas las
especificaciones del diseño dentro de la fase de construcción de acuerdo a la metodología
aplicada usando el proceso unificado dentro del patrón MVC y las herramientas de
MySQL, JavaEE y DigitalPersona U ARE U 4500.

1.5. JUSTIFICACION

En la actualidad Área de Ciencias y Tecnología cuenta con personal docente, estudiante y

becario los cuales desempeñan su tarea en forma dinámica dentro de la institución, los cuales
solo los docentes se registran su entrada y salida en diferentes sistemas de registro
descentralizados. Con este sistema de biométrico se beneficiará a todo el personal del Área
de Ciencia y Tecnología, los beneficios hacia la sociedad serán visibles y accesibles mediante
el sistema propuesto, ya que será completamente dinámico y centralizado a la hora de
registrar y gestionar los registros de entradas y salidas dentro de la institución.

1.6. ALCANCES

El desarrollo del presente proyecto está sujeto a cumplir con actividades de la Metodología.
El sistema que abarca las fases de inicio, elaboración, construcción y transición de la
metodología Proceso Unificado, proporcionando una completa idea de lo que hace y lo que
es el sistema, respondiendo a los requerimientos obtenidos, como la agilización en el flujo
de proceso del control de asistencia, la centralización de la información, la integridad segura
de la información.
 Registro de la asistencia de los docentes, estudiantes y becarios.
 Control del tiempo de llegada y salida de los docentes y becarios del Área de
Ciencias y Tecnología.
 Controlar el cumplimiento de la carga horaria de los docentes y becarios.

7
 Brindar la información de la asistencia acumulada de docentes, estudiantes y
becarios.
 Generar reportes para la auditoria de asistencia de los docentes y becarios.

8
CAPITULO II
2. MARCO TEÓRICO

9
2.1. FUNDAMENTACIÓN TEÓRICA

2.1.1. Sistema biométrico

La biometría es un excelente sistema de identificación de la persona que se aplica en muchos

procesos debido a dos razones fundamentales, la seguridad y la comodidad, la biometría es
una tecnología de identificación basada en el reconocimiento de una característica física e
intransferible de las personas, como, por ejemplo, la huella digital, el reconocimiento del
patrón venoso del dedo o el reconocimiento facial.

Entre las aplicaciones de identificación con biometría están el control de acceso biométrico,
el control de presencia biométrico, el logon biométrico para aplicaciones de software a
sistemas operativos o cualquier otra aplicación de identificación mediante la incorporación
de un lector biométrico para integración.

Biometría es un sistema automatizado de reconocimiento humano basado en las

características físicas y comportamiento de las personas, se trata del mismo sistema que
utiliza el cerebro humano para reconocer y distinguir una persona de otra.

La biometría es un sistema que reconoce a la persona basándose en “quién” es, no importando

“lo que lleva puesto” o “lo que conoce”, cosas que puedan llevar, como las llaves y tarjetas
de identificación, pueden ser perdidas, sustraídas y/o duplicadas. Cosas que conoce, como
passwords y códigos, pueden ser olvidados, sustraídos y/o duplicados.

En lugar de eso, la tecnología biométrica se fija en “quién” es la persona, basándose en una

única e inalterable característica humana que no puede ser perdida, olvidada, sustraída o
duplicada, así pues, la biometría proporciona el máximo nivel de seguridad, conveniencia y
facilidad de uso. (Kimaldi Electronics)

Los sistemas biométricos se han desarrollado como respuesta a la creciente demanda de

seguridad existente en la actualidad y aunque algunos de ellos son altamente fiables,
ningún sistema es efectivo al 100%, y estos sistemas también son susceptibles de ser
10
engañados.

2.1.2. Sistema de información

Un sistema de información es un conjunto de elementos que interactúan entre sí con el fin de

apoyar las actividades de una empresa o negocio. En un sentido amplio, un sistema de
información no necesariamente incluye equipo electrónico (hardware). Sin embargo, en la
práctica se utiliza como sinónimo de “sistema de información computarizado” (vigilancia
para SAN).

Un Sistema de Información realiza cuatro actividades básicas:

 Entrada de información: proceso en el cual el sistema toma los datos que requiere.
 Almacenamiento de información: pude hacerse por computadora o archivos físicos
para conservar la información.
 Procesamiento de la información: permite la transformación de los datos fuente en
información que puede ser utilizada para la toma de decisiones

 Salida de información: es la capacidad del sistema para producir la información

procesada o sacar los datos de entrada al exterior (vigilancia para SAN).

2.1.3. Tecnología de información.

Este término hace referencia todas aquellas tecnologías que permiten y dan transporte a las
construcción y operación de los sistemas de información (Noguer, 2001) .

2.1.4. Control administrativo.

El control es la función administrativa por medio de la cual se evalúa el rendimiento. El

control es un elemento del proceso administrativo que incluye todas las actividades que se
emprenden para garantizar que las operaciones reales coincidan con las operaciones
planificadas.

11
Para Robbins (1996) el control puede definirse como “el proceso de regular actividades que
aseguren que se están cumpliendo como fueron planificadas y corrigiendo cualquier
desviación significativa”.

Sin embargo, Stoner (1996) lo define de la siguiente manera: “El control administrativo es el
proceso que permite garantizar que las actividades reales se ajusten a las actividades
proyectadas”.

Mientras que, para Fayol, citado por Melinkoff (1990), el control “Consiste en verificar si
todo se realiza conforme al programa adoptado, a las ordenes impartidas y a los principios
administrativos…Tiene la finalidad de señalar las faltas y los errores a fin de que se pueda
repararlos y evitar su repetición”. (Derkra, 2011)

2.1.5. Paradigma orientado a objetos

Es el paradigma que define objetos y clases como la base para la programación. Cada objeto
está definido por sus atributos y sus comportamientos están definido por las operaciones que
dichos objetos puedan hacer. La programación orientada a objetos expresa un programa como
un conjunto de estos objetos, que colaboran entre ellos para realizar tareas. Esto permite hacer
los programas y módulos más factibles de escribir, mantener y reutilizar. Su uso se popularizo
en los años 90. Actualmente son muchos los lenguajes de programación que soportan la
orientación a objetos, ejemplos: java, C++, Smalltalk, PHP y Ruby (FCA-UNAM, 2015).

2.1.6. Base datos

Colección compartida de datos relacionadas desde el punto de vista lógico junto con una
descripción de esos datos (metadatos), diseñado para satisfacer las necesidades de
información de una organización (Korth, 2006).

2.1.7. Modelo Vista Controlador

El patrón MVC es una arquitectura de diseño software para separar los componentes de
aplicación en tres niveles, interfaz de usuario, lógica de control y lógica de negocio.

12
Es una especialización de un modelo de capas, con la diferencia que se usa para entornos
web como patrón por excelencia. Ejemplo: Struts, Spring, Asp.NET (Gómez, 2010).

2.1.8. Mapeo objeto relacional

El mapeo objeto-relacional es una técnica de programación para convertir datos del sistema
de tipos utilizado en un lenguaje de programación orientado a objetos al utilizado en una base
de datos relacional. En la práctica esto crea una base de datos virtual orientada a objetos sobre
la base de datos relacional. Esto posibilita el uso de las características propias de la
orientación a objetos (esencialmente la herencia y el polimorfismo).

Las bases de datos relacionales solo permiten guardar tipos de datos primitivos (enteros,
cadenas de texto, etc.) por lo que no se pueden guardar de forma directa los objetos de la
aplicación en las tablas, sino que estos se deben de convertir antes en registros, que por lo
general afectan a varias tablas. En el momento de volver a recuperar los datos, hay que hacer
el proceso contrario, se deben convertir los registros en objetos (ORM, 2011).

2.1.9. Aplicación web

En la ingeniería de software se denomina aplicación web a aquellas herramientas que los

usuarios pueden utilizar accediendo a un servidor web a través de internet o de una intranet
mediante un navegador. En otras palabras, es un programa que se codifica en un lenguaje
interpretable por los navegadores web en la que se confía la ejecución al navegador.

Las aplicaciones web son populares debido a lo práctico del navegador web como cliente
ligero, a la independencia del sistema operativo, así como a la facilidad para actualizar y
mantener aplicaciones web sin distribuir e instalar software a miles de usuarios potenciales.
Existen aplicaciones como los correos web, wikis, blogs, tiendas en línea y la propia
Wikipedia que son ejemplos bastante conocidos de aplicaciones web (Mateu, 2004).

2.1.10. Intranet

Una intranet es una red informática que utiliza la tecnología del protocolo de Internet para
compartir información, sistemas operativos o servicios de computación dentro de una

13
organización. Suele ser interna, en vez de pública como internet, por lo que solo los miembros
de esa organización tienen acceso a ella (Mateu, 2004).

2.1.11. Red de computadoras

Una red de computadoras, también llamada red de ordenadores o red informática, es un

conjunto de equipos (computadoras y/o dispositivos) conectados por medio de cables,
señales, ondas o cualquier otro método de transporte de datos, que comparten Información
(archivos), recursos (CD-ROM, impresoras), servicios (acceso a internet, E-mail, chat,
juegos).

Una red de comunicaciones es un conjunto de medios técnicos que permiten la comunicación

a distancia entre equipos autónomos (no jerárquica -master/slave-). Normalmente se trata de
transmitir datos, audio y vídeo por ondas electromagnéticas a través de diversos medios de
transmisión (aire, vacío, cable de cobre, Cable de fibra óptica).

Para simplificar la comunicación entre programas (aplicaciones) de distintos equipos, se

definió el modelo OSI por la ISO, el cual especifica 7 distintas capas de abstracción. Con
ello, cada capa desarrolla una función específica con un alcance definido (Ecured, 2017).

2.1.12. Protocolo IP

El Protocolo de Internet es un protocolo de capa de red (Capa 3) diseñado en 1981 para usarse
en sistemas interconectados de redes de comunicación computacional de conmutación de
paquetes. El Protocolo de Internet y el Protocolo de Control de Transmisión (TCP,
Transmission Control Protocol) son la base de los protocolos de Internet. El IP tiene dos
funciones principales:

- Entrega de datagramas a través de la interred en la modalidad de mejor esfuerzo

- Fragmentación y reensamblado de datagramas

Se considera al IP un protocolo de “mejor esfuerzo”, ya que no garantiza que un paquete

transmitido realmente llegue al destino ni que los datagramas transmitidos sean recibidos en
el orden en que fueron enviados. La función principal de IP es llevar paquetes de datos de un

14
nodo fuente a un nodo destino. Este proceso se logra identificando cada paquete enviado con
una dirección numérica llamada dirección IP.

El protocolo IP no tiene mecanismos de confiabilidad (RFC 791) a diferencia de los demás

protocolos. En vez de tener dichos medios, este protocolo no hace uso de ellos para que sean
implementados por protocolos de capa superior. El único mecanismo de detección de errores
es la suma de verificación para el encabezado IP. Si el procedimiento de la suma de
verificación falla, el datagrama será descartado y con ello no será entregado a un protocolo
de nivel superior (Garcia, 2016).

2.1.13. Direccionamiento IP

El esquema de direccionamiento IP es integral al proceso de enrutamiento de datagramas IP

a través de la interred. Cada dirección IP tiene componentes específicos y un definido formato
básico.

Existen dos estándares de direccionamiento IP: la versión 4 (IPv4) y la versión 6 (IPv6).

Actualmente la mayoría del tráfico IP es realizado con direccionamiento IPv4, y aunque se
pretende que IPv6 reemplace a IPv4 en un futuro, ambos protocolos coexistirán durante algún
tiempo (Garcia, 2016).

2.1.14. Formato de Dirección IP versión 4

En una red TCP/IP a cada computadora se le asigna una dirección lógica de 32-bits que se
divide en dos partes: el número de red y el número de computadora. Los 32 bits son divididos
en 4 grupos de 8 bits, separados por puntos, y son representados en formato decimal.

Cada bit en el octeto tiene un peso binario. El valor mínimo para un octeto es 0 y el valor
máximo es 255. La siguiente figura muestra el formato básico de una dirección IP con sus 32
bits agrupados en 4 octetos (S.C., 2006).

2.1.15. Broadcast

En Informática, la difusión amplia, difusión ancha o broadcast, es una forma de transmisión

de información donde un nodo emisor envía información a una multitud de nodos receptores

15
de manera simultánea, sin necesidad de reproducir la misma transmisión nodo por nodo
(Garcia, 2016).

2.1.16. Host

El término host o anfitrión se usa en informática para referirse a las computadoras u otros
dispositivos conectados a una red que proveen y utilizan servicios de ella. Los usuarios deben
utilizar anfitriones para tener acceso a la red. En general, los anfitriones son computadores
monousuario o multiusuario que ofrecen servicios de transferencia de archivos, conexión
remota, servidores de base de datos, servidores web, etc. Los usuarios que hacen uso de los
anfitriones pueden a su vez pedir los mismos servicios a otras máquinas conectadas a la red.
De forma general un anfitrión es todo equipo informático que posee una dirección IP y que
se encuentra interconectado con uno o más equipos. Un host o anfitrión es un ordenador que
funciona como el punto de inicio y final de las transferencias de datos. Comúnmente descrito
como el lugar donde reside un sitio web. Un anfitrión de Internet tiene una dirección de
Internet única (dirección IP) y un nombre de dominio único o nombre de anfitrión (host
name) (Garcia, 2016).

2.2. UML (Lenguaje de Modelado Unificado)

UML es un lenguaje de modelado que se usa para especificar, visualizar, construir y

documentar los elementos que forman un sistema software orientado a objetos. Es utilizado
para entender, diseñar, configurar, mantener y controlar la información sobre los sistemas a
construir (Díaz, 2004).

16
 ESPECIFICAR

DOCUMENTAR UML CONSTRUIR

VISUALIZAR

Ilustración 1: Descripción del UML

Fuente: Elaboración propia

Es un estándar para la representación de procesos o esquemas de software basado en notación

gráfica, que nos permite:

Básicamente UML posee cierto número de vistas y por cada ella varios diagramas que son
los que se emplean para modelar las aplicaciones:

17
Ilustración 2: UML
Fuente: (Vilalta, 2008)

2.2.1.1. Diagrama de casos de uso.

Los casos de uso es una técnica para capturar información de cómo un sistema o negocio
trabaja, o de cómo se desea que trabaje, en palabras de Ivar Jacobson, “describen bajo la
forma de acciones y reacciones el comportamiento de un sistema desde el punto de vista del
usuario (Díaz, 2004).

2.2.1.2. Diagrama de clases.

El mismo autor, presenta los elementos más estables del sistema, estos son los dispositivos
de control de datos e información, correspondientes a las clases del sistema, con sus
relaciones estructurales y de herencia. El modelo de casos de uso aporta información para
establecer las clases, objetos, atributos y operaciones (Díaz, 2004).

18
2.2.1.3. Diagrama de estados.

Traduciendo “es usado para describir el comportamiento de las instancias y elementos de un

modelo. Específicamente describen las posibles secuencias de estados y acciones a través de
las cuales las instancias puedes proceder durante su ciclo de vida, como resultado de eventos
discretos, tales como señales externas y, mensajes” (Díaz, 2004).

2.2.1.4. Diagrama de actividad.

Es un caso especial del diagrama de estados, este puede especificar, el comportamiento de

los objetos de una clase, la lógica de una operación (método), y parte o toda la descripción
de un caso de uso (Díaz, 2004).

2.2.1.5. Diagrama de secuencia.

Presenta una interacción, la cual es un conjunto de mensajes entre un conjunto de instancias

interactuando, estas son un grupo de estímulos entre instancias con el efecto de determinar
el funcionamiento deseado de un proceso o un resultado (Díaz, 2004).

2.2.1.6. Diagrama de paquetes.

Ofrecen un mecanismo general para la organización de los modelos/subsistemas agrupando

elementos de modelado, esta agrupación se realiza por operaciones comunes o por divisiones
de la organización (Díaz, 2004)..

2.2.1.7. Diagrama de componentes.

Muestra las dependencias entre los diferentes componentes de software, incluyendo las
clasificaciones que se puedan realizar, estas implementaciones son de diferentes tipos entre
ellas se encuentra archivos de código fuente, archivos binarios, archivos ejecutables, scripts,
entre otros (Díaz, 2004)..

2.2.1.8. Diagrama de despliegue.

Modela la distribución en tiempo de ejecución de los elementos de procesamiento y

componentes de software, junto a los procesos y objetos asociados. “Muestra las relaciones

19
físicas entre los componentes software y hardware asociados, en el desempeño del sistema
(Díaz, 2004).

2.3. Herramientas Utilizadas.

2.3.1.1. NetBeans

NetBeans es un entorno de desarrollo integrado libre, hecho principalmente para el lenguaje

de programación Java. Existe además un número importante de módulos para extenderlo.
NetBeans IDE2 es un producto libre y gratuito sin restricciones de uso (Vazques, 2017 ).

2.3.1.2. MySQL

E MySQL es un sistema de gestión de base de datos relacional (RDBMS) de código abierto,

basado en lenguaje de consulta estructurado (SQL).

MySQL se ejecuta en prácticamente todas las plataformas, incluyendo Linux, UNIX y

Windows. A pesar de que se puede utilizar en una amplia gama de aplicaciones, MySQL se
asocia más con las aplicaciones basadas en la web y la publicación en línea y es un
componente importante de una pila empresarial de código abierto llamado LAMP.

MySQL, que fue concebido originalmente por la compañía sueca MySQL AB, fue adquirida
por Oracle en 2008. Los desarrolladores todavía pueden usar MySQL bajo la Licencia
Pública General de GNU (GPL), pero las empresas deben obtener una licencia comercial de
Oracle.

2.3.1.3. Power Designer

Es una herramienta para el análisis, diseño inteligente y construcción sólida de una base de
datos y un desarrollo orientado a modelos de datos a nivel físico y conceptual, que da a los
desarrolladores Cliente/Servidor la más firme base para aplicaciones de alto rendimiento.

Ofrece un acercamiento de diseño para optimizar las estructuras de las bases de datos.
Capturando el flujo de datos de su organización, puede crear un modelo conceptual y físico
de la base de datos (Salazar, 2017).

20
2.3.1.4. Mybatis

MyBatis es un framework de persistencia que soporta SQL, procedimientos almacenados y

mapeos avanzados. MyBatis elimina casi todo el código JDBC, el establecimiento manual
de los parámetros y la obtención de resultados. MyBatis puede configurarse con XML o
anotaciones y permite mapear mapas y POJOs con registros de base de datos (mybatis.org,
2017).

2.3.1.5. Enterprise Architect

Es una plataforma de modelado, diseño y administración, colaborativa, basada en UML 2.5

y estándares relacionados. Ágil, intuitiva y extensible, con poderosas características para
dominios específicos totalmente integrados, a una fracción del costo de muchos
competidores. Una solución para toda la empresa que permite visualizar, analizar, modelar,
probar y mantener un amplio rango de sistemas, software, procesos y arquitectura (Ltd.,
2017).

2.3.1.6. Packet Tracer

Es una herramienta de aprendizaje y simulación de redes interactiva. Esta herramienta

permite crear topologías de red, simular una red con múltiples representaciones visuales,
principalmente es una herramienta de apoyo didáctico.

Permite a los estudiantes crear redes con un número casi ilimitado de dispositivos y
experiencias de solución de problemas sin tener que comprar routers o switches reales.

Esta herramienta les permite a los usuarios crear topologías de red, configurar dispositivos,
insertar paquetes y simular una red con múltiples representaciones visuales. Packet Tracer se
enfoca en apoyar mejor los protocolos de redes que se enseñan en el currículum de la
certificación cisco. En este programa se crea la topología física de la red simplemente
arrastrando los dispositivos a la pantalla. Luego clickando en ellos se puede ingresar a sus
consolas de configuración. Allí están soportados todos los comandos del Cisco OS e incluso
funciona el "intérprete de línea de comandos". Una vez completada la configuración física y
lógica del net, también se puede hacer simulaciones de conectividad (pings “Buscador o

21
rastreador de paquetes en redes”, traceroutes” consola de diagnóstico de redes de Linux”,
etc.) todo ello desde las mismas consolas incluidas (Manizales, 2011).

2.4. CONTEXTO INSTITUCIONAL DEL AREA DE CIENCIAS Y TECNOLOGIA

DE LA UNIVERSIDAD AMAZONICA DE PANDO

2.4.1. Misión

Es formar recursos humanos en ciencias y tecnología altamente capacitados, con espíritu

crítico y de acuerdo a las exigencias de la demanda regional y nacional, generar conocimiento
científico y tecnológico, estudiando problemas del medio y contribuir a la innovación y
desarrollo de tecnologías apropiadas, a través de tres funciones básicas integradas:
Enseñanza-Aprendizaje, Investigación Científica y Tecnológica e Interacción Social.

2.4.2. Visión

Formar profesionales en el pregrado con calidad y excelencia, adecuados a la demanda

nacional y en el tiempo previsto, que estén en la capacidad de producir tecnología y generar
conocimiento para el estudio y tratamiento de los problemas del medio. Ser un Área con
reconocimiento Nacional e Internacional, con estructura matricial que permita responder
rápidamente a los cambios y a las necesidades regionales y nacionales en forma eficiente y
efectiva. Formar recursos humanos altamente especializados con infraestructura necesaria y
equipamiento adecuado, para ejecutar satisfactoriamente las actividades de formación y de
investigación.

2.4.3. Objetivo

 Formar recursos humanos altamente capacitados, con espíritu crítico y de acuerdo a

las exigencias de la demanda regional y nacional actual.

 Generar conocimiento científico y tecnológico, a través del estudio de la problemática

actual y contribuir a la innovación y desarrollo de tecnologías apropiadas.

 Capacitar continuamente a los docentes para que se encuentren compenetrados a la

vanguardia educativa actual a nivel nacional y mundial.
22
 Formar investigadores de alto nivel capaces de generar nuevos conocimientos
versados al campo de las ciencias sociales y humanas para poder brindar soluciones
a problemáticas en la sociedad boliviana.

 Interactuar con otras instituciones a nivel nacional e internacional para poder generar
nuevos espacios de diálogo, intercambio de ideas, análisis y reflexiones para poder
formular nuevas políticas públicas capaces de mejorar las condiciones universitarias
y potencializar el nivel académico.

 Constituir una comunidad académica y científica inmersa en temas vinculados con el

entorno social, político, cultural y económico que interactúe con la sociedad con el
fin de priorizar la búsqueda de investigaciones para resolver problemas de la
Amazonía boliviana en base a mecanismos idóneos de planificación.

23
2.4.4. Estructura Orgánica del Área de Ciencias y Tecnología.

CONSEJO DE
AREA

DIRECTOR DE
TÉCNICO ADM.
ÁREA SECRETARIA LIMPIEZA
TÉCNICO ADM.
FINANCIERO 1 FINANCIERO 2

PLANIFICACIÓN CARRERA CARRERA CARRERA

ACADÉMICA INGENIERÍA DE SISTEMAS INGENIERÍA INDUSTRIAL
INGENIERÍA CIVIL

BIBLIOTECA TÉCNICO AUXILIAR

ACYT PEDAGÓGICO ACADÉMICO
DEL ACYT
RESP. ACREDITACIÓN Y
CERTIFICACIÓN INVESTIGACIÓN E INVESTIGACIÓN E INVESTIGACIÓN E
INTERACCIÓN SOCIAL INTERACCIÓN SOCIAL INTERACCIÓN SOCIAL
ING. DE SISTEMAS ING. INDUSTRIAL ING. CIVIL
ACREDITACIÓN ACREDITACIÓN
Y CERTIFICACIÓN ING. Y CERTIFICACIÓN ING. ACREDITACIÓN
ING. DE SISTEMAS ING. INDUSTRIAL Y CERTIFICACIÓN ING.
RESP. INVESTIGACIÓN, ING. CIVIL
INNOVACIÓN Y
DESARROLLO
TECNOLÓGICO

RESP. INTERACCIÓN
SOCIAL Y EXTENSIÓN PLANTA
UNIVERSITARIA CETIC PILOTO LABORATORIO
de SUELOS

COMERCIALI
VINCULACIÓN TÉCNICO DE
LABORATORIO ZACIÓN
NACIONAL E REDES
INTERNACIONAL TÉCNICO SUELOS

TÈCNICO DE
SUPERVISOR DE
LABORATORIO TÉCNICO
HARDWARE PLANTA
HORMIGONES
GESTIÓN DE PROY. DE
COOPERACIÓN TÉCNICO OPERARIO DE
INTERNACIONAL PUBLICIDAD Y
PRODUCCIÓN
REDES
SOCIALES 1 TÉCNICO
TOPOGRAFÍA
HIDRÁULICA
UNIDAD DE
DESARROLLO DE
SISTEMAS

Ilustración 3: Organigrama del ACyT

Fuente: Dirección Académica del ACyT

24
2.5. DESCRIPCIÓN DE LA METODOLOGÍA

La metodología de Proceso Unificado, es un método iterativo de diseño de software que

describe cómo desarrollar software de forma eficaz, utilizando técnicas probadas.
El Proceso Unificado de Desarrollo de Software o simplemente Proceso Unificado es un
marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso,
centrado en la arquitectura, enfocado en el riesgo, y por ser iterativo e incremental.
El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que
puede ser adaptado a organizaciones o proyectos específicos.
El nombre Proceso Unificado se usa para describir el proceso genérico que incluye aquellos
elementos que son comunes a la mayoría de los refinamientos existentes. Es una metodología
orientada a conducir el proceso de desarrollo de software en sus aspectos técnicos; los flujos
y productos de trabajo de Proceso Unificado no incluyen la administración del proyecto.
El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un
sistema. Cada ciclo concluye con una versión del producto para los clientes.
Cada ciclo consta de cuatro fases: inicio, elaboración, construcción y transición. Cada fase
se subdivide a su vez en iteraciones.

Ilustración 4: Fases de la metodología RUP

Fuente: (METODOSS, 2017)

25
2.5.1. Fase I: Inicio

Esta fase tiene como propósito definir y acordar el alcance del proyecto con los
patrocinadores o alumnos de un proyecto en el cual tenemos que, identificar los riesgos
asociados al proyecto, y producir el plan de las fases y el de iteraciones posteriores.

2.5.2. Fase II: Elaboración

En la fase de elaboración se seleccionan los casos de uso que permiten definir la arquitectura
base del sistema y se desarrollaran en esta fase, se realiza la especificación de los casos de
uso seleccionados y el primer análisis del dominio del problema, se diseña la solución
preliminar.

2.5.3. Fase III: Desarrollo

El propósito de esta fase es completar la funcionalidad del sistema, para ello se deben
clarificar los requisitos pendientes, administrar los cambios de acuerdo a las evaluaciones
realizados por los usuarios y se realizan las mejoras para el proyecto.

2.5.4. Fase IV: Transición

El propósito de esta fase es asegurar que el software esté disponible para los usuarios finales,
ajustar los errores y defectos encontrados en las pruebas de aceptación, capacitar a los
usuarios y proveer el soporte técnico necesario. Se debe verificar que el producto cumpla con
las especificaciones entregadas por las personas involucradas en el proyecto (OBOLOG,
2016).

Proceso Unificado
UML RESUMEN
Fase Actividad Entregable
Documento de Extensión para  Documento de
visión modelado de negocio visión
Plan del  Plan de
desarrollo del desarrollo de
INICIO

Modelamiento del Software Software

negocio Modelo de caso  Modelado de
de uso de negocio caso de uso del
negocio
Entorno de
 Entorno del
trabajo
trabajo
26
 Modelo de casos Diagrama de casos de Diagrama de casos
Requerimientos
de uso uso de uso
Modelo del Diagrama de Diagrama de
análisis colaboraciones colaboraciones
Diseño de Diagrama de Diagrama de
ELABORACIÓN interfaces secuencia secuencia
Diagrama de clases
Diseño de clases Diagrama de clases
Diagrama de vistas
Análisis y diseño Planilla de clases Planilla de clases
Diseño de la base Diseño de la base
de datos datos
Modelo de Modelo de
Modelo de despliegue
despliegue despliegue
Prototipo Prototipo
arquitectónico arquitectónico
Diagrama de
CONSTRUCCIÓN

Modelo de Diagrama de componentes

Implementación
componentes componentes Vistas de
componentes
Método de caja Método de caja
Negra Negra
Prueba
Prototipo del Prototipo del
Software Software
TRANSICIÓN

Documento de
Prueba de aceptación del
Despliegue
aceptación producto de
Software

Ilustración 3: Metodología de Proceso Unificado

Fuente: Elaboración propia

27
CAPITULO III
3. DESARROLLO DEL SISTEMA

28
3.1. FASE DE INICIO

En esta primera fase se realiza lo que son el proceso de modelo de negocios y los
requerimientos del Área de Ciencias y Tecnologías respecto al control de asistencia.

3.1.1. Modelo del proceso de negocios

La orientación y la estructura orgánica del negocio se explican con detalle en el marco

institucional del presente documento y en lo que sigue básicamente se describe la estructura
funcional y apoyada en un conjunto de diagramas que dan luz de forma clara y precisa toda
la estructura funcional de la organización. La Ilustración 6 muestra el contexto del sistema,
en el que pueden observarse la relación directa de los involucrados con el sistema que se
aborda en el presente trabajo.

3.1.1.1. Diagrama de proceso de negocios

dfd Data Flow Diagram

Administrador
UDS
Genera reporte
detallado de la
Registra datos y asistencia y
crea categoria de actividades del
personas sistema

DIRECTOR
Habilita estudiantes a
DE AREA asignatura, marca asistencia

Reporte general de asistencia DOCENTE

por carrera y tipos de personas
SISTEMA
BIOMETRICO Informacion de su estado de
asistencia y de los estudiantes
DACTILAR PARA deacuerdo a sus asignatura
Reporte detallado de la asistencia EL CONTROL DE
del personal y habilitacion de
estudiante por asignatura
ASISTENCIA DEL Informacion del estado
ACyT de asistencia

Asigna horario, realiza

COORDINADOR Marca BECARIO
procesos de CRUD del
asistencia
DE CARRERA personal
Marca
Informacion de su estado de asistencia
asistencia por asignatura

ESTUDIANTE

29
Ilustración 4: Diagrama Contexto
Fuente: Elaboración propia

El diagrama básicamente refleja el modelo actual del negocio, identificando las

entidades interesadas que interactúan directa o indirectamente con el sistema:

Existe un sistema que de control de docentes que es administrado por la Unidad de

Desarrollo de Sistemas (U.D.S) del Área de Ciencias y Tecnología (ACyT) donde se
registran, actualizan y eliminan datos, como también se generan reportes:
operaciones que son denominados (C.R.U.D.). Los reportes generados cubren el
seguimiento al cumplimiento de la carga horaria de los docentes y el control de
asistencia de estudiantes y becarios, pero existe una relación en el sentido que a
los estudiantes se le controlan en listas indiscriminadamente según el docente y lo
propio con los becarios que son dependientes de DISEU.

30
3.1.1.2. Diagrama de los procesos del control de asistencia en el ACyT

e-p Diagrama de procesos

Datos del
coordinador
«input»

Ingresa Datos y
Opera los procesos roles del
datos del «output»
CRUD de coordinador
coordinador
Administrador coordinadores
«resource» «resource»
Datos generales del Huella del
personal «input» personal
«input»

Ingresa Capturar
datos Informacion
de una Personal
Coordinador persona
«output»

Informacion Captura Informacion

del personal Horario del horario
categorizada del del personal
personal

Estado de
Capturar validacion de
asistencia asistencia del
«output»
peronal

Ilustración 5: Diagrama de procesos

Fuente: Elaboración propia

El diagrama de Edisson Penker permite mostrar el funcionamiento interno del control de

asistencia dentro del Área de Ciencias y Tecnología.

El diagrama logra mostrar procesos y sus sub procesos donde interactúan las entidades.

31
El administrador (USD) crea y administra los roles y datos de los coordinadores a los cuales
son los encargados de registrar personas y sus respectivos horarios de acuerdo a la categoría
que pertenezcan, para que pueda ser realizado el respectivo control de asistencia por persona.

3.1.1.3. Diagrama procesos captura información personal

e-p Capturar Informacion Personal

personal ACyT Personal ACyT

Datos generales Huella

«input»
«input»

Ingresar Capturar Informacion

Registrar Informacion
datos Huella completa de
Datos del datos del
Coordinador del los datos del
Personal personal
personal personal

Definicion
del tipo de
personal

Informacion del
personal
categorizada

Ilustración 6: Diagrama de captura de información

Fuente: Elaboración propia

El diagrama de Edisson Penker permite mostrar el funcionamiento interno del control de

asistencia dentro del Área de Ciencias y Tecnología.

En el diagrama de proceso capturar información personal refleja las acciones que sufre al
capturar los datos personales y la huella de cada persona, dentro de este proceso interactúa
directamente con la persona perteneciente al ACyT independientemente a que categoría de
persona pertenece.

32
3.1.1.4. Diagrama de los procesos capturar horario y asistencia del personal

e-p Capturar horario y asistencia del personal

Informacion del
personal
categorizada
Proceso capturar horario

Registrar Habilitacion Registrar

horario del de horario de horario del
docente estudiante becario

Informacion del Informacion del Informacion del

horario del horario del horario del
docente estudiante becario
«input» «input» «input»
Proceso Capturar Asistencia

Compara Estado de
informacion validacion
Capturar Huella con el horario de asistencia
Huella
huella «output»
almacenada del personal
«input»

Informacion
Verificar Datos del
completa de
personal personal
los datos del «input»
confirmado
personal
Personal ACyT

Ilustración 7: Diagrama de captura horario y asistencia del personal

Fuente: Elaboración propia

En el diagrama de proceso capturar horario y asistencia del personal, da a conocer

los sub procesos que existen al capturar los horarios como también por parte del
proceso capturar asistencia refleja las acciones que sufre al capturar una huella
donde básicamente introduce su huella para capturarlo y obtener la huella
procesada, dentro del subproceso de la verificación de la identidad del personal se
realiza la comparación con los datos existentes en la bd obteniendo los datos del
personal que marco confirmados. Se realiza la búsqueda de los registros de datos
del personal con sus horarios que pertenecen a la salida del proceso de captura

33
horario del personal y así confirmando su asistencia de acuerdo a validaciones de
estados: (Verificado, No verificado y Fuera de horario).

3.1.1.5. Diagrama de actividades

Este modelo de diagrama su función es de modelar el comportamiento mediante flujo de

actividades.

Capturar la información personal

act Captura Informacion Personal

Coordinador Personal

Recibe datos Datos Entrega datos

personales personales personales
Inicio

Registrar
persona

Si esta registrado Asigna Coloca su huella

No
huella dactilar en el
dactilar sensor
Si

Asignar el
tipo de Codigo de
persona segun identificacion
su codigo
personal

Persona
registrada segun
un tipo

Final

Ilustración 7: Diagrama de actividades capturar información personal

Fuente: Elaboración propia

34
 Capturar horario del docente
act Capturar Horario del Personal

Coordinador Sistema
Personal Docente

Datos del Habilitacion de horario

personal No de estudiante
Inicio Si

Materia habilitada Accion de

Asignar materia No asignacion
al docente de materia
Si
denegada
Regitrar un horario
al docente respecto a
la materia Terminar
Fin

3.1.2. Requerimientos

En el cuadro de abajo se puede observar los requerimientos obtenidos de las entrevistas con
el cliente

3.1.2.1. Requerimientos funcionales

Prioridad Rol

FR1 El sistema debe permitir al coordinador y Media Administrador

administrativo crear categorías de tipos de
persona ej. (becario, administrativo)

FR2 El sistema debe permitir mostrar la Media Usuario

información general de la persona que
accedió.

35
FR3 El sistema debe ser capaz generar reporte de Alto Administrador
asistencia por tipo de persona de acuerdo a
un tiempo determinado

El sistema debe ser capaz de controlar la Alto Administrador

asistencia de acuerdo al tipo de persona ej.

(observar justificaciones de inasistencias,

atrasos, faltas, eventos extracurriculares, si
es necesario un archivo adjunto)

FR4 El sistema debe ser capaz de mostrar la Alto Usuario

verificación del cumplimiento de la carga
horaria del docente

FR5 El sistema debe ser capaz que el docente Medio Usuario

pueda generar reporte de la asistencia de sus
estudiantes

FR6 El sistema debe permitir que el estudiante Medio Usuario

obtenga el reporte de su asistencia por
asignaturas.

FR7 El sistema debe ser capaz que el coordinador Medio Usuario

asigne estudiantes a materias de acuerdo a
su de plan de estudio de su carrera.

FR8 El sistema debe ser capaz de mostrar el Medio Usuario

horario de cada estudiante

FR9 El sistema debe tener la opción que el Alto Administrador

coordinador u administrativo pueda editar,
eliminar, modificar los datos de cualquier
persona.

36
 FR10 El sistema tendrá la opción de vaciar todas las Alto Administrador
asistencias de la base de datos de acuerdo a
un tiempo determinado.

FR11 El sistema deberá generar un calendario de Medio Usuario

estados de asistencia, atrasos, etc., por
persona.

FR12 En caso de pérdida de luz, debe tener la Medio Usuario

opción de registrar asistencia mediante
formularios opcionalmente.
FR13 El sistema deberá permitir que el coordinador Alto Administrador
asigne los horarios estándar a docentes,
becarios y estudiantes.

Tabla 2: Tabla de requerimientos funcionales

Fuente: Elaboración propia

3.1.2.2. Requerimientos no funcionales

Prioridad Rol

FR1 El sistema debe funcionar en un equipo de 64 Alto Administrador

bits

FR2 El sistema debe permitir el registro de 1000 Alto Usuario

registros por periodo de clase

FR3 El sistema debe funcionar en una PC Alto Administrador

conectada en red

FR4 El sistema debe ser capaz de cifrar la Alto

información en una red interna.
Administrador

37
 FR5 El sistema debe operar en un servidor virtual Medio Usuario
Glassfish 4.4.1

FR6 El sistema tiene que tener un manual de Alto Usuario

usuario.

Tabla 3: Requerimientos no funcionales

Fuente: Elaboración propia
Los requerimientos que se muestran fueron obtenidos mediante entrevistas con el cliente para
poder enfatizar las necesidades primarias y las necesidades segundarías para ver cuales tiene
una mayor prioridad al momento de realizar el sistema.

3.2. FASE DE ELABORACIÓN

En esta se podrá observar los diagramas de casos de uso en general, diagrama de clases, los
diagramas de secuencia, diagramas de actividades y la base de datos

38
3.2.1. Diagrama de Casos de Uso General

Ilustración 8: Diagrama caso de uso general

Fuente: Elaboración propia

El lenguaje de modelado unificado, un diagrama de casos de uso en una forma de diagrama

de comportamiento UML mejorado, define una notación grafica pera representar casos de
uso.
Este diagrama representa esquemáticamente operaciones secuenciales donde hay una
interacción física con uno de los procesos
Nombre: General

39
 Erín Boris Valdivia – Rodrigo Cruz Mendoza – Paulina Irene
Autor:
Velasquez Ferrufino
Fecha: 24-09-2018
Administrador(UDS), Coordinador, Docente, Estudiante,
Actor:
Becario
Este Diagrama de caso de uso nos permite describir las
Descripción: acciones del sistema desde el punto de vista de los
usuarios (Personas).
Eventos del Actor Eventos del Sistema
1. El usurario(persona) deberá 1. El Sistema valida los datos
autentificarse como ingresados de
administrador para poder usuario(Persona)
ingresar al Sistema. 2. El Sistema valida el tipo de
Flujo Principal:
2. El usuario de pertenecer a usuario(persona) para
un tipo de persona. utilizar el sistema
3. El Sistema muestra menú
de opciones de acuerdo al
perfil del usuario
1. El sistema debe estar encendido.
Precondición:
2. El usuario(persona) debe iniciar cesión en el sistema.
Postcondición: Ingresar en alunas opciones del menú según el tipo de usuario
Situaciones 1. Fallo de usuario contraseña
Excepcionales 2. Usuario no existe

Tabla 4: Caso de uso - General

Fuente: Elaboración propia

40
3.2.2. Diagrama de secuencia

En los diagramas de secuencia se puede observar la representación de la secuencia que se

ejecutan en cada uno del diagrama de casos de uso en general.

sd DS Registro Persona

Coordinador
MenuPrincipal Registro Persona Formulario de Seleccionar
Persona Registrar Fotografia
ingresar()
Persona
click submenRP()

selec submenPers()

ingresar datos()

cargarfoto()

click
siguiente()

Ilustración 9: Diagrama de secuencias

Fuente: Elaboración propia

El diagrama de secuencia es un tipo de diagrama usado para modelar interacción entre

objetos en un sistema. Como podemos observar para iniciar con el funcionamiento del
control de asistencia de una persona añadimos sus datos personales en el formulario
registrar persona, añadiendo una fotografía de la persona registrado, hecho el llenado del
formulario registrar persona al apretar siguiente se realiza el guardado de los datos.

41
Registrar la ocupación del personal
sd DS Ocupacion Persona

Tipo Perfil Carrera

Persona Usuario
Coordinador
Registro Ocupacion Formulario
Persona Persona OP
ingresa()

click()

muestra
formulario()

setTipoPersona
(ID_TIPO)

return
(TIPO)

setPerfilUsuario(ID_PERFIL)

return(PERFIL)

setCarrera
(ID_CARRERA)

return(NOMBRE_CARRERA)

siguiente()

Ilustración 10: Diagrama de secuencia ocupación persona

Fuente: Elaboración propia

Al registrar los datos generales del personal da abertura a la acción de registrar la

ocupación de la persona como también la asignación de a que carrera pertenece, las
acciones que se realizan dentro de este proceso se dan a conocer en el diagrama de
secuencia.

Registro de Huella

42
 sd DS Registro Huella

Seleccionar Listado de
Posicion de dedo Registro Huella
Coordinador
Registro Formulario Dedo
ingresa() Huella RH
muestra
formulario()

click selectOpcion()

verifica huella
de dedos()

prueba
dedo1()

prueba
dedo2()

prueba
dedo3()

prueba
dedo4()

guardar registro()

Borrar()

Ilustración 11: Diagrama de secuencia registrar huella

Fuente: Elaboración propia

Dentro del formulario registro de huella se mantiene la secuencia desde la opción registrar
persona, el cual el sistema mantiene los datos del personal y así saber a quien se esta
asignando la huella, el sistema permite registrar cinco distintas huellas de una persona para
validar la fiabilidad de su funcionamiento al reconocer su asistencia, se trabaja con un
margen de error mínimo de acuerdo a las distintas posiciones que se coloca ante el sensor
es por eso que se realiza por cada registro cuatro identificaciones de la huella dactilar.

43
Registro horario
sd DS Asignacion Materia - Registro Horario

Asignatura Cursa Listado Periodo Asignatura Listado Dia Detalle Hora

OcupaPersona
== Estudiante
Docente Materia Horario Asignatura Entrada
Coordinador Salida
Registro Registro Asignacion Formulario Formulario
ingresa() Persona Horario Materia AM Reg-Hra

si()
entonces()

muestra
formulario()

no()
setAsignatura
setDocente()

guarda()

click agregar
materia()

click
terminar()

muestra formulario()

select()

setAsignatura()

click agregar
asignatura()

select()

select()

agrega()

click agregar horario()

click terminar()

Ilustración 12: Diagrama de secuencia registrar horario

Fuente: Elaboración propia

En el siguiente diagrama de secuencia da a conocer sobre el proceso capturar horario del

personal ya que depende de que tipo de persona es para ingresar a distinta interfaz o
formulario para el respectivo ingreso de horario, si el personal el cual se hace la secuencia
de registro es estudiante se le asigna materias con el docente respectivo que esta registrado
y toma como horario el horario registrado para ese docente en esa materia, el personal al ser
docente se tendrá primeramente que asignar la materia el cual el dictara y luego el día, aula
y hora de entrada y salida el cual el docente llevara a cabo la materia.

Control de asistencia

44
 sd DS Asistencia

Huella == Estado de
Horario == asistencia
Personal Datos del Horario
Interfas Ingresa personal "Validacion" registrado
Asistencia huella dactilar horario
ingresa()

Coloca
dedo en el
sensor()

si()
entonces()

no(No existen registros)

Si()

entonces()

Fuera de horario()

click salir()

Ilustración 13: Diagrama de secuencia capturar asistencia

Fuente: Elaboración propia

Al momento de interactuar el personal con el sistema para el respectivo control de

asistencia estas son las actividades secuenciales que se realiza, algunas de ellas son
manuales y otras automatizadas como ser el ingreso del dedo ante el sensor dactilar y las
automatizadas como ser la validación de la huella con los datos anteriormente registrados y
el horario registrado con los datos actuales del sistema.

3.2.3. Diagrama de clases

En la imagen de abajo de muestra la Representación de la estructura del sistema entorno a

clases, y en la forma en que estas se relacionan entre clases, los nombres de las clases y

45
cuáles son sus atributos y métodos.
class Diagrama de Clases
Area
- ID_AREA: Integer
- ID_USUARIO: Integer
- NOMBRE_AREA: String
- TELEFONO_AREA: Integer
- CORREO_AREA: String
- FECHA_REGAREA: Timestamp
- ESTADO_AREA: Integer
+ Area(Integer, String, Integer, String, Integer, Integer, Timestamp)
«property get»
+ getNOMBRE_AREA(): String
+ getTELEFONO_AREA(): Integer
+ getCORREO_AREA(): String
+ getID_USUARIO(): Integer
+ getFECHA_REGAREA(): Timestamp
«property set»
+ setNOMBRE_AREA(String): void
+ setTELEFONO_AREA(Integer): void
+ setCORREO_AREA(String): void
+ setID_USUARIO(Integer): void
+ setFECHA_REGAREA(Timestamp): void
Dedo
- ID_DEDO: Integer
- DEDO: String
- ESTADO_DEDO: Integer
+ Dedo(Integer, String, Integer)
«property set»
+ setID_DEDO(Integer): void
+ setDEDO(String): void
+ setESTADO_DEDO(Integer): void
«property get»
+ getID_DEDO(): Integer
+ getDEDO(): String
+ getESTADO_DEDO(): Integer
1 + setID_USUARI(Integer): void
1..*
Huella
- ID_HUELLA: Integer
- ID_DEDO: Integer
- ID_PERSONA: Integer
- ID_USUARIO: Integer
- HUELLA: byte ([])
- FECHA_REG_HUELLA: Timestamp
- ESTADO_HUELLA: Integer
+ Huella(Integer, Integer, Integer, byte[], Timestamp, Integer, Integer)
«property get»
+ getID_HUELLA(): Integer
+ getID_PERSONA(): Integer
+ getID_DEDO(): Integer
+ getHUELLA(): byte[]
+ getFECHA_REG_HUELLA(): Timestamp
+ getID_USUARIO(): Integer
+ getESTADO_HUELLA(): Integer
«property set»
+ setID_HUELLA(Integer): void
+ setID_PERSONA(Integer): void
+ setID_DEDO(Integer): void
+ setHUELLA(byte[]): void
+ setFECHA_REG_HUELLA(Timestamp): void
+ setID_USUARIO(Integer): void
+ setESTADO_HUELLA(Integer): void
Estado_civil
- ID_CIVIL: Integer
- NOMBRE_CIVIL: String
- ID_USUARIO: Integer
- ESTADO_CIVIL: Integer
+ Estado_civil(Integer, String, Integer, Integer)
«property get»
+ getESTADO_CIVIL(): Integer
+ getID_CIVIL(): Integer
+ getID_USUARIO(): Integer
+ getNOMBRE_CIVIL(): String
«property set»
+ setESTADO_CIVIL(Integer): void
+ setID_CIVIL(Integer): void
+ setID_USUARIO(Integer): void
+ setNOMBRE_CIVIL(String): void
Tipo_ambiente
- ID_TIPO_AMBIENTE: Integer
- ID_USUARIO: Integer
- TIPO_AMBIENTE: String
- FECHA_REG_AMBIENTE: Timestamp
- ESTADO_TIPO_AMBIENTE: Integer
+ Tipo_ambiente(Integer, String, Integer, Timestamp, Integer)
«property get»
+ getID_TIPO_AMBIENTE(): Integer
+ getTIPO_AMBIENTE(): String
+ getID_USUARIO(): Integer
+ getFECHA_REG_AMBIENTE(): Timestamp
+ getESTADO_TIPO_AMBIENTE(): Integer
«property set»
+ setID_TIPO_AMBIENTE(Integer): void
+ setTIPO_AMBIENTE(String): void
+ setID_USUARIO(Integer): void
+ setFECHA_REG_AMBIENTE(Timestamp): void
+ setESTADO_TIPO_AMBIENTE(Integer): void
Area_infraestructura
- ID_AREAINFRA: Integer
- ID_LOCAL: Integer
- ID_USUARIO: Integer
- AREA_INFRA: String
- SIGLA_AREAINFRA: String
- ESTADO_AREAINFRA: Integer
+ Area_infraestructura(Integer, Integer, String, String, Integer, Integer)
«property get»
+ getID_AREAINFRA(): Integer
+ getID_LOCAL(): Integer
+ getSIGLA_AREAINFRA(): String
+ getAREA_INFRA(): String
+ getID_USUARIO(): Integer
+ getESTADO_AREAINFRA(): Integer
«property set»
+ setID_AREAINFRA(Integer): void
+ setID_LOCAL(Integer): void
+ setSIGLA_AREAINFRA(String): void
+ setAREA_INFRA(String): void
+ setID_USUARIO(Integer): void
+ setESTADO_AREAINFRA(Integer): void
Ilustración 14: Diagrama de clases
Fuente: Elaboración propia
Diagrama de Clases según la arquitectura del sistema:
Un diagrama de clases es una representación gráfica que sirve para representar la estructura
de un sistema que será implementado utilizando un lenguaje orientado a objetos, para mayor
entendimiento de las clases se adjunta en anexo el diagrama por partes.
Carrera Plan_estudio Asignatura
Menu_principal
Agrupa
- ID_CARRERA: Integer - ID_PLAN: Integer - ID_ASIG: Integer
- ID_MENU_PRINCIPAL: Integer
- ID_AREA: Integer - ID_CARRERA: Integer - ID_PLAN: Integer - ID_AGRUPA: Integer
- MENU_PRINCIPAL: String
- ID_USUARIO: Integer - ID_USUARIO: Integer - ID_USUARIO: Integer - ID_PERFIL: Integer
- RUTA_MENU_PRINCIPAL: String
- ID_BLOQUE: int - PLAN: String - SIGLA_ASIG: String - ID_MENU_PRINCIPAL: Integer
- DESCRIPCION_MENU_PRINCIPAL: String
- NOMBRE_CARRERA: String - ARCHIVO: String - NOMBRE_ASIG: String
Perfil_usuario + Agrupa(Integer, Integer, Integer) - ESTADO_MENU_PRINCIPAL: Integer
- TELEFONO_CARRERA: String - ESTADO_PLAN: Integer - FECHA_REGASIG: Timestamp
«property get» - ID_USUARIO: Integer
- CORREO_CAR: String - ID_PERFIL: Integer
+ Plan_estudio(Integer, Integer, String, String, Integer, Integer) - CARGA_HOR: Integer + getID_AGRUPA(): Integer
- FECHA_REGCARRERA: Timestamp - PERFIL: String «property get»
«property set» + Asignatura(Integer, Integer, Integer, String, String, Timestamp, Integer) - DESCRIPCION_PERFIL: String + getID_MENU_PRINCIPAL(): Integer 1
1 + getID_MENU_PRINCIPAL(): Integer
+ Carrera(int, int, int, String, String, String) + setID_PLAN(Integer): void «property set» - ID_USUARIO: Integer + getID_PERFIL(): Integer
+ getMENU_PRINCIPAL(): String
«property set» + setID_CARRERA(Integer): void + setID_ASIG(Integer): void - ESTADO_PERFIL: Integer 1 «property set»
1 + getRUTA_MENU_PRINCIPAL(): String
11..*
+ setID_AREA(Integer): void
1 + setID_USUARIO(Integer): void 1 + setID_PLAN(Integer): void + setID_AGRUPA(Integer): void
*
+ Perfil_usuario() 1 + getDESCRIPCION_MENU_PRINCIPAL(): String
+ setNOMBRE_CARRERA(String): void + setPLAN(String): void + setID_USUARIO(Integer): void + setID_MENU_PRINCIPAL(Integer): void
+ Perfil_usuario(Integer, String, String, Integer, Integer) + getESTADO_MENU_PRINCIPAL(): Integer
+ setTELEFONO_CARRERA(String): void + setARCHIVO(String): void + setSIGLA_ASIG(String): void + setID_PERFIL(Integer): void
1 + getID_USUARIO(): Integer
+ setCORREO_CAR(String): void + setESTADO_PLAN(Integer): void «property get»
+ setNOMBRE_ASIG(String): void
+ getID_PERFIL(): Integer «property set»
+ setFECHA_REGCARRERA(Timestamp): void «property get» + setFECHA_REGASIG(Timestamp): void
+ getPERFIL(): String + setID_MENU_PRINCIPAL(Integer): void
+ setID_USUARIO(Integer): void + getID_PLAN(): Integer + setCARGA_HOR(Integer): void
+ getDESCRIPCION_PERFIL(): String + setMENU_PRINCIPAL(String): void
«property get» + getID_CARRERA(): Integer «property get»
1
+ getID_USUARIO(): Integer + setRUTA_MENU_PRINCIPAL(String): void
+ getNOMBRE_CARRERA(): String + getID_USUARIO(): Integer + getID_ASIG(): Integer Privilegio
+ getESTADO_PERFIL(): Integer + setDESCRIPCION_MENU_PRINCIPAL(String): void
+ getTELEFONO_CARRERA(): String + getPLAN(): String + getID_PLAN(): Integer
1 - ID_PRIVILEGIO: Integer + setESTADO_MENU_PRINCIPAL(Integer): void
+ getCORREO_CAR(): String + getARCHIVO(): String «property set»
+ getID_USUARIO(): Integer - ID_USUARIO: Integer + setID_USUARIO(Integer): void
+ getFECHA_REGCARRERA(): Timestamp + getESTADO_PLAN(): Integer + setID_PERFIL(Integer): void
1
+ getSIGLA_ASIG(): String - ID_COMPUESTO: Integer
+ getID_USUARIO(): Integer
1 + setPERFIL(String): void 1
1 + getNOMBRE_ASIG(): String - PRIORIDAD_SUBMENU: Integer
1 + setDESCRIPCION_PERFIL(String): void
+ getFECHA_REGASIG(): Timestamp - DESCRIP_PRIVILEGIO: String *
+ setID_USUARIO(Integer): void
* Usuario 1..* + getCARGA_HOR(): Integer - ESTADO_PRIVILEGIO: Integer
+ setESTADO_PERFIL(Integer): void
Tipo_semestral 1
Compuesto
- ID_USUARIO: Integer + Privilegio(Integer, Integer, Integer, Integer, String, Integer)
- ID_DETASIG: Integer - ID_PERFIL: Integer 1 - ID_COMPUESTO: Integer
«property get»
- ID_PLAN: Integer - ID_OCUPA: Integer - ID_MENU_PRINCIPAL: Integer
+ getDESCRIP_PRIVILEGIO(): String
- ID_USUARIO: Integer - USUARIO: String - ID_SUBMENU: Integer
Justificacion_tolerancia + getESTADO_PRIVILEGIO(): Integer
- TIPO_SEMESTRE: String - CLAVE: String
* + getID_COMPUESTO(): Integer + Compuesto(Integer, Integer, Integer)
- ESTADO_DETASIG: Integer * - FECHA_REGUSUARIO: Timestamp 1 - ID_JUST_TOLERANCIA: Integer 0..* *
+ getID_PRIVILEGIO(): Integer 1 «property get»
- ESTADO_USUARIO: Integer - ID_USUARIO: Integer
+ Tipo_semestral(Integer, Integer, String, Integer, Integer) 1 + getID_USUARIO(): Integer + getID_COMPUESTO(): Integer
- JUSTIFIACION_TOLERANCIA: String
«property set» + Usuario(Integer, Integer, Integer, String, String, Timestamp) + getPRIORIDAD_SUBMENU(): Integer + getID_MENU_PRINCIPAL(): Integer
- DOCUMENTO_JUSTIFICATIVO: String
+ setID_DETASIG(Integer): void 1 + getID_SUBMENU(): Integer
«property get» - EST_TIP_TOL_REM: Integer «property set»
+ setID_PLAN(Integer): void + getID_USUARI(): Integer + setDESCRIP_PRIVILEGIO(String): void
1 - TOL_ANTES_ENTRADA: Integer «property set»
+ setID_USUARIO(Integer): void + getID_PERFIL(): Integer 1
Ocupacion_persona + setESTADO_PRIVILEGIO(Integer): void
1 - ESTADO_JUSTIFICACION: Integer + setID_COMPUESTO(Integer): void
+ setTIPO_SEMESTRE(String): void + getID_OCUPA(): Integer + setID_COMPUESTO(Integer): void
- ID_OCUPA: Integer - TOL_DESPUES_ENTRADA: Integer + setID_MENU_PRINCIPAL(Integer): void
+ setESTADO_DETASIG(Integer): void + getUSUARIO(): String + setID_PRIVILEGIO(Integer): void
- ID_PERSONA: Integer - FECHA_REG_JUST: Timestamp + setID_SUBMENU(Integer): void
«property get» + getCLAVE(): String + setID_USUARIO(Integer): void
- ID_TIPO: Integer - TOL_ANTES_SALIDA: Integer *
+ getID_DETASIG(): Integer + getFECHA_REGUSUARIO(): Timestamp + setPRIORIDAD_SUBMENU(Integer): void
- ID_USUARIO: Integer - TOL_DESPUES_SALIDA: Integer
+ getID_PLAN(): Integer + getESTADO_USUARIO(): Integer 1
- COD_PER_OCUPA: String 1
+ getID_USUARIO(): Integer «property set» 1
- FECHA_REGOCUP: Timestamp
+ getTIPO_SEMESTRE(): String 1
1..* - ESTADO_OCUP: Integer 1
+ getESTADO_DETASIG(): Integer + setID_PERFIL(Integer): void 1
+ setID_OCUPA(Integer): void + Ocupacion_persona(Integer, Integer, Integer, Integer, String, Integer)
Tipo_persona Sub_menu
+ setUSUARIO(String): void «property get»
+ setCLAVE(String): void + getID_OCUPA(): Integer - ID_TIPO: Integer - ID_SUBMENU: Integer
+ setFECHA_REGUSUARIO(Timestamp): void + getID_PERSONA(): Integer - ID_USUARIO: Integer - DESCRIPCION: String
1
+ setESTADO_USUARIO(Integer): void + getID_TIPO(): Integer - TIPO: String - ORDEN: Integer
1
- RUTA_SUB_MENU: String
+ getCOD_PER_OCUPA(): String - FECHA_REGTIPO: Timestamp
1 1 1 1 1..* 1
- SUB_MENU: String
+ getFECHA_REGOCUP(): Timestamp - ESTADO_TIPO: Integer
- ESTADO_SUBMENU: Integer
+ getID_USUARIO(): Integer 1
1..* + Tipo_persona(String, Integer, Timestamp, Integer)
Persona + getESTADO_OCUP(): Integer 1
+ Sub_menu(Integer, String, String, String, Integer)
«property get»
1 «property set» «property get»
- ID_PERSONA: Integer + getESTADO_TIPO(): Integer
+ setID_OCUPA(Integer): void + getID_SUBMENU(): Integer
- ID_CIVIL: Integer + getFECHA_REGTIPO(): Timestamp
+ setID_PERSONA(Integer): void 1..* + getSUB_MENU(): String
- ID_USUARIO: Integer + getID_TIPO(): Integer
+ setID_TIPO(Integer): void + getRUTA_SUB_MENU(): String
- CI: Integer + getID_USUARIO(): Integer
+ setCOD_PER_OCUPA(String): void Periodo + getDESCRIPCION(): String
- NOMBRES: String + getTIPO(): String
+ setFECHA_REGOCUP(Timestamp): void + getORDEN(): Integer
- PATERNO: String «property set» - ID_PERIODO: Integer
+ setID_USUARIO(Integer): void + getESTADO_SUBMENU(): Integer
- MATERNO: String + setESTADO_TIPO(Integer): void - ID_GESTION: Integer
+ setESTADO_OCUP(Integer): void
- DIRECCION: String + setFECHA_REGTIPO(Timestamp): void - ID_USUARIO: Integer «property set»
- CELULAR_PER: String 1 1
+ setID_TIPO(Integer): void - PERIODO: String + setID_SUBMENU(Integer): void
- CORREO_PER: String + setID_USUARIO(Integer): void - EXTRA: String + setSUB_MENU(String): void
- FECHA_NACIMIENTO: Date + setTIPO(String): void - FECHA_REGPERI: Timestamp + setRUTA_SUB_MENU(String): void
- SEXO: String - ESTADO_PERI: Integer + setDESCRIPCION(String): void
1..*
- ESTADO_PER: Integer + setORDEN(Integer): void
+ Periodo(Integer, Integer, String, String, Integer, Timestamp)
+ Persona(Integer, String, String, String, String, String, String, Date, Integer, String) + setESTADO_SUBMENU(Integer): void
«property get»
1 «property set» + getID_PERIODO(): Integer
+ setID_PERSONA(Integer): void + getID_GESTION(): Integer
+ setID_CIVIL(Integer): void + getPERIODO(): String
1 0..*
+ setID_USUARIO(Integer): void + getEXTRA(): String
+ setCI(Integer): void Detalle_asig_periodo 1
+ getID_USUARIO(): Integer
+ setNOMBRES(String): void + getFECHA_REGPERI(): Timestamp
+ setPATERNO(String): void - ID_DET_ASIG_PAR: Integer + getESTADO_PERI(): Integer
1
+ setMATERNO(String): void - ID_PERIODO: Integer
«property set»
+ setDIRECCION(String): void - ID_ASIG: Integer
+ setID_PERIODO(Integer): void
+ setCELULAR_PER(String): void - ID_OCUPA: Integer
+ setID_GESTION(Integer): void
+ setCORREO_PER(String): void
1 + Detalle_asig_periodo(Integer, Integer, Integer, Integer) + setPERIODO(String): void
+ setFECHA_NACIMIENTO(Date): void *
«property get» + setEXTRA(String): void
+ setSEXO(String): void
+ getID_ASIG(): Integer + setID_USUARIO(Integer): void
+ setESTADO_PER(Integer): void
+ getID_DET_ASIG_PAR(): Integer + setFECHA_REGPERI(Timestamp): void
1 «property get» + getID_OCUPA(): Integer + setESTADO_PERI(Integer): void
+ getID_PERSONA(): Integer + getID_PERIODO(): Integer 1..*
+ getID_CIVIL(): Integer 1
«property set»
+ getID_USUARIO(): Integer
+ setID_ASIG(Integer): void Gestion
+ getCI(): Integer
+ setID_DET_ASIG_PAR(Integer): void 1
+ getNOMBRES(): String - ID_GESTION: Integer
+ setID_OCUPA(Integer): void 1
+ getPATERNO(): String Horario - ID_USUARIO: Integer
+ setID_PERIODO(Integer): void
+ getMATERNO(): String - GESTION: Integer
*
+ getDIRECCION(): String 1 0..1 - ID_HORARIO: Integer - FECHA_REG_GESTION: Timestamp
+ getCELULAR_PER(): String - ID_USUARIO: Integer - ESTADO_GESTION: Integer
+ getCORREO_PER(): String * - ID_DIA: Integer
+ Gestion(Integer, Integer, Integer, Timestamp)
+ getFECHA_NACIMIENTO(): Date - ID_DET_ASIG_PAR: Integer
+ getSEXO(): String * * - ID_JUST_TOLERANCIA: Integer «property get»
1..*
+ getESTADO_PER(): Integer - FECHA_REGHOR: Timestamp + getID_GESTION(): Integer
Cursa - HORA_ENTRADA: Timestamp + getGESTION(): Integer
1..*
- ID_CURSA: Integer - HORA_SALIDA: Timestamp + getID_USUARIO(): Integer
- ESTADO_HOR_ENTRADA: Integer + getFECHA_REG_GESTION(): Timestamp
Aula - ID_DET_ASIG_PAR: Integer *
- ESTADO_HOR_SALIDA: Integer + getESTADO_GESTION(): Integer
- ID_OCUPA: Integer
- ID_AULA: Integer - ESTADO_HORARIO: Integer
- ID_USUARIO: Integer «property set»
- ID_BLOQUE: Integer 1..*
- FECHA_REG_CURSA: Timestamp + Horario(Integer, Integer, Integer, Integer, Timestamp, Timestamp, Integer) + setID_GESTION(Integer): void
- ID_TIPO_AMBIENTE: Integer
- ESTADO_CURSA: Integer + setGESTION(Integer): void
- ID_USUARIO: Integer «property get»
+ setID_USUARIO(Integer): void
- AULA: String + Cursa(Integer, Integer, Integer, Integer, Timestamp) + getID_HORARIO(): Integer
+ setFECHA_REG_GESTION(Timestamp): void
- ESTADO_AULA: Integer «property get» + getID_DET_ASIG_PAR(): Integer
+ setESTADO_GESTION(Integer): void
+ getID_CURSA(): Integer + getID_DIA(): Integer
+ Aula(Integer, Integer, Integer, String, Integer, Integer) 1 *
+ getID_DET_ASIG_PAR(): Integer + getID_JUST_TOLERANCIA(): Integer
«property get» + getHORA_ENTRADA(): Timestamp
* Asistencia + getID_OCUPA(): Integer
1 + getID_AULA(): Integer + getHORA_SALIDA(): Timestamp
- ID_ASISTENCIA: Integer + getID_USUARIO(): Integer
+ getID_TIPO_AMBIENTE(): Integer + getFECHA_REGHOR(): Timestamp Dia
- ID_USUARIO: Integer + getFECHA_REG_CURSA(): Timestamp
+ getID_BLOQUE(): Integer + getID_USUARIO(): Integer
- ID_CURSA: Integer + getESTADO_CURSA(): Integer - ID_DIA: Integer
+ getAULA(): String + getESTADO_HOR_ENTRADA(): Integer
+ getID_USUARIO(): Integer - ID_AULA: Integer «property set» - ID_USUARIO: Integer
+ getESTADO_HOR_SALIDA(): Integer
+ getESTADO_AULA(): Integer - ID_DET_ASIG_PAR: Integer + setID_CURSA(Integer): void - DIA: String
+ getESTADO_HORARIO(): Integer
- FECHA_MARCADOAS: Timestamp + setID_DET_ASIG_PAR(Integer): void * - FECHA_REGDIA: Timestamp
«property set» 1
«property set»
- HORA_ENTRADAAS: Timestamp + setID_OCUPA(Integer): void 1 - ESTADO_DIA: Integer
+ setID_AULA(Integer): void 1 1
+ setID_HORARIO(Integer): void
- HORA_SALIDAAS: Timestamp + setID_USUARIO(Integer): void
+ setID_TIPO_AMBIENTE(Integer): void + setID_DET_ASIG_PAR(Integer): void + Dia(Integer, String, Timestamp, Integer, Integer)
- ESTADO_SALIDA: Integer + setFECHA_REG_CURSA(Timestamp): void
+ setID_BLOQUE(Integer): void * + setID_DIA(Integer): void «property get»
- ESTADO_ENTRADA: Integer + setESTADO_CURSA(Integer): void
1
+ setAULA(String): void + setID_JUST_TOLERANCIA(Integer): void + getID_DIA(): Integer
+ setID_USUARIO(Integer): void - ESTADO_ASISTENCIA: Integer
+ setHORA_ENTRADA(Timestamp): void + getDIA(): String
+ setESTADO_AULA(Integer): void + Asistencia(Integer, Integer, Integer, Integer, Integer, Timestamp, Timestamp, Integer) + setHORA_SALIDA(Timestamp): void + getFECHA_REGDIA(): Timestamp
* «property get» + setFECHA_REGHOR(Timestamp): void + getID_USUARIO(): Integer
1 1..* + getID_ASISTENCIA(): Integer + setID_USUARIO(Integer): void + getESTADO_DIA(): Integer
+ getID_CURSA(): Integer + setESTADO_HOR_ENTRADA(Integer): void «property set»
Bloque + getID_DET_ASIG_PAR(): Integer + setESTADO_HOR_SALIDA(Integer): void + setID_DIA(Integer): void
- ID_BLOQUE: Integer + getID_AULA(): Integer + setESTADO_HORARIO(Integer): void + setDIA(String): void
- ID_AREAINFRA: Integer + getHORA_ENTRADAAS(): Timestamp + setFECHA_REGDIA(Timestamp): void
- ID_DIREC: Integer + getHORA_SALIDAAS(): Timestamp + setID_USUARIO(Integer): void
- ID_USUARIO: Integer + getFECHA_MARCADOAS(): Timestamp + setESTADO_DIA(Integer): void
+ getID_USUARIO(): Integer
- BLOQUE: String
+ getESTADO_ENTRADA(): Integer
- ESTADO_INFRA: Integer
+ getESTADO_SALIDA(): Integer
+ Bloque(Integer, Integer, Integer, String, Integer, Integer) + getESTADO_ASISTENCIA(): Integer
«property get»
1 «property set»
*
+ getID_BLOQUE(): Integer + setID_ASISTENCIA(Integer): void
+ getID_AREAINFRA(): Integer + setID_CURSA(Integer): void
+ getID_DIREC(): Integer + setID_DET_ASIG_PAR(Integer): void
+ getBLOQUE(): String + setID_AULA(Integer): void
+ getID_USUARIO(): Integer + setHORA_ENTRADAAS(Timestamp): void
+ getESTADO_INFRA(): Integer + setHORA_SALIDAAS(Timestamp): void
«property set» + setFECHA_MARCADOAS(Timestamp): void
+ setID_BLOQUE(Integer): void + setID_USUARIO(Integer): void
+ setID_AREAINFRA(Integer): void + setESTADO_ENTRADA(Integer): void
+ setID_DIREC(Integer): void + setESTADO_SALIDA(Integer): void
+ setBLOQUE(String): void + setESTADO_ASISTENCIA(Integer): void
+ setID_USUARIO(Integer): void
+ setESTADO_INFRA(Integer): void
46
3.2.4. Diagrama de la Base de datos

Una base de datos es una colección de información organizada de forma que programa de
ordenador pueda seleccionar rápidamente los fragmentos de datos que necesite y al base de
datos también es un sistema de archivos electrónico.

El diseño de la base de datos es un modelo obtenido de la convención del diagrama de

clases según el diseño y arquitectura del software.
carrera
area id_carrera <pi> Serial <M> tipo_persona
id_area <pi> Serial <M> id_area <fi1> Integer <M> id_tipo <pi> Serial <M>
id_usuario <fi> Integer id_bloque <fi3> Integer <M> id_tolerancia <fi2> Integer <M>
tipo_semestral nombre_area Variable characters (25) id_usuario <fi2> Integer id_usuario <fi1> Integer
tiene
id_detasig <pi> Serial <M> telefono_area Long integer nombre_carrera Variable characters (50) tipo Variable characters (50)
id_plan <fi1> Integer <M> correo_area Variable characters (50) telefono_carrera Variable characters (25) fecha_regtipo Date & Time
id_usuario <fi2> Integer estado_area Boolean correo_car Variable characters (25) estado_tipo Boolean
tipo_semestre Variable characters (50) fecha_regarea Date & Time fecha_regcarrera Date & Time
Identifier_1 <pi>
estado_detasig Boolean estado_carrera Boolean
Identifier_1 <pi>
adiciona
Identifier_1 <pi> Identifier_1 <pi> tieneee
U26
u8 se
pertenece tolerancia
dedo u7
id_tolerancia <pi> Serial <M> perfil_usuario
id_dedo <pi> Serial plan_estudio id_usuario <fi> Integer id_perfil <pi> Serial <M>
dedo Variable characters (35) id_plan <pi> Serial <M> antes Integer id_usuario <fi> Integer
estado_dedo Boolean incopora id_carrera <fi1> Integer <M> u2 u4 despues Integer perfil Variable characters (25)
es_del
huella id_usuario <fi2> Integer retraso Integer
Identifier_1 <pi> descripcion_perfil Variable characters (55)
id_huella <pi> Serial <M> plan Variable characters (15) sub_antes Integer estado_perfil Boolean
se_encuentra archivo Text sub_despues Integer
estado_civil id_persona <fi1> Integer <M>
Identifier_1 <pi>
id_dedo <fi2> Integer <M> estado_plan Boolean dicta Identifier_1 <pi>
id_civil <pi> Serial accede
id_usuario <fi3> Integer Identifier_1 <pi>
id_usuario <fi> Integer
huella Long binary <M>
nombre_civil Variable characters (25) u3 usuario u5
fecha_reg_huella Date & Time <M> asignatura
estado_civil Boolean u10 tiene_acceso
estado_huella Boolean id_usuario <pi> Serial <M>
u1 id_asig <pi> Serial <M>
Identifier_1 <pi> id_perfil <fi2> Integer <M>
Identifier_1 <pi> id_plan <fi1> Integer <M>
u21 id_ocupa <fi1> Integer <M>
tienen2 tienen id_usuario <fi2> Integer
u24 usuario Text <M>
Persona sigla_asig Variable characters (15) agrupa
clave Text
nombre_asig Variable characters (150)
id_persona <pi> Serial <M> u11 fecha_regusuario Date & Time id_agrupa <pi> Serial <M>
puede fecha_regasig Date & Time
id_civil <fi1> Integer Ocupacion_Persona estado_usuario Boolean id_perfil <fi1> Integer
carga_hor Integer
id_usuario <fi2> Integer id_ocupa <pi> Serial <M> u6 id_menu_principal <fi2> Integer <M>
Identifier_1 <pi> etado_asig Boolean
ci Long integer <M> id_persona <fi1> Integer <M> Identifier_1 <pi>
nombres Variable characters (50) <M> Identifier_1 <pi>
id_tipo <fi2> Integer u22
paterno Variable characters (50) <M> u27
id_carrera
representada <fi3> Integer u16 u20
materno Variable characters (50) <M> id_usuario <fi4> Integer privilegio
obtiene
direccion Variable characters (150) cod_per_ocupa Variable characters (21)
id_privilegio <pi> Serial <M>
celular_per Variable characters (25) fecha_regocup Date & Time dia u15 usu_id_usuario <fi1> Integer
telefono Variable characters (25) estado_ocup Boolean id_dia <pi> Serial <M>
id_compuesto <fi2> Integer <M> deacuerdo
correo_per Variable characters (25) Identifier_1 <pi> id_usuario <fi> Integer emerge
id_usuario <fi3> Integer
fecha_nacimiento Date dia Variable characters (25)
prioridad_submenu Integer
url_foto Text es_dictado_por fecha_regdia Date & Time
descrip_privilegio Variable characters (300)
_registrado Date & Time <M> estado_dia Boolean
estado_privilegio Boolean
_modificado Date & Time <M> detalle_asig_periodo
Identifier_1 <pi>
estado_per Boolean Identifier_1 <pi>
id_det_asig_par <pi> Serial <M>
Sexo Characters (100) id_periodo <fi2> Integer <M> sucede
Identifier_1 <pi> id_asig <fi1> Integer <M> u17 menu_principal
tienee horario
id_ocupa <fi3> Integer <M> id_menu_principal <pi> Serial <M>
u18 id_horario <pi> Serial <M>
tipo_ambiente Identifier_1 <pi> menu_principal Variable characters (55)
id_det_asig_par <fi2> Integer ruta_menu_principal Variable characters (350)
id_tipo_ambiente <pi> Serial <M> pasa_en aplicado
id_dia <fi1> Integer descripcion_menu_principal Variable characters (100)
tipo_ambiente Variable characters (25) docente_marca u23 id_just_tolerancia <fi3> Integer estado_menu_principal Boolean
id_usuario <fi> Integer id_usuario <fi4> Integer u19 id_usuario Integer
fecha_reg_ambiente Date & Time asistencia
id_aula <fi5> Integer
estado_tipo_ambiente Boolean Identifier_1 <pi>
id_asistencia <pi> Serial <M> hora_entrada Time u12
tien
Identifier_1 <pi> id_cursa <fi2> Integer deacuerdo hora_salida Time compuesto
id_det_asig_par <fi3> Integer fecha_reghor Date & Time
es_de_un id_compuesto <pi> Serial <M>
id_aula <fi1> Integer <M> estado_hor_entrada Boolean
aula marcaron id_menu_principal <fi1> Integer
id_usuario <fi4> Integer estado_hor_salida Boolean
id_aula <pi> Serial <M> id_submenu <fi2> Integer <M>
hora_entradaas Time estado_horario Boolean
id_tipo_ambiente <fi1> Integer <M> hora_salidaas Time Identifier_1 <pi>
Identifier_1 <pi>
id_bloque <fi2> Integer fecha_marcadoas Date incluyee
id_usuario <fi3> Integer estado_asistencia Integer
sub_menu
aula Variable characters (25) periodo
Identifier_1 <pi>
estado_aula Boolean id_submenu <pi> Serial <M>
estudiante_marca id_periodo <pi> Serial <M>
puede_tenersub_menu Variable characters (55)
Identifier_1 <pi> estudiante cursa id_gestion <fi1> Integer <M> ruta_sub_menu Variable characters (350)
abarca id_usuario <fi2> Integer
bloque id_cursa <pi> Serial <M> descripcion Variable characters (55)
id_det_asig_par <fi1> Integer periodo Variable characters (5) orden Integer
id_bloque <pi> Serial <M> extra Variable characters (15)
id_ocupa <fi2> Integer <M> estado_submenu Boolean
id_areainfra <fi1> Integer <M>
cursan_materia fecha_regperi Date & Time
id_usuario <fi3> Integer Identifier_1 <pi>
id_usuario <fi2> Integer estado_peri Boolean
fecha_reg_cursa Date & Time
bloque Variable characters (55)
estado_cursa Boolean Identifier_1 <pi>
estado_infra Boolean just_tol
Identifier_1 <pi> contiene
Identifier_1 <pi> id_just_tolerancia <pi> Serial <M>
gestion id_usuario <fi> Integer
pertence
id_gestion <pi> Serial <M> just_tol Variable characters (350)
area_infraestructura
id_usuario <fi> Integer doc_justifi Text
id_areainfra <pi> Serial <M> tol_antes_entra Integer
gestion Integer
id_usuario <fi> Integer tol_desp_entra Integer
fecha_reg_gestion Date & Time
sigla_areainfra Variable characters (15) tol_antes_sal Integer
estado_gestion Boolean
area_infra Variable characters (55) tol_desp_sal Integer
estado_areainfra Boolean Identifier_1 <pi>
estado_just Boolean
u25
Identifier_1 <pi> fecha_reg_just Date & Time
Identifier_1 <pi>

Ilustración 15: Diagrama de la base de datos

Fuente: Elaboración propia

3.3. FASE DE CONSTRUCCION

Registrar personas, categorizarlas y añadir sus respectivos horarios hasta realizar el

respectivo registro de control de asistencia. En esta etapa el objetivo son los respectivos
registros de datos de la persona y asistencia.
47
3.3.1. Código fuente:

Ilustración 16: Código fuente

Fuente: Elaboración propia

El código fuente de este sistema por ser muy voluminoso, se colocó solo una mínima parte.

48
3.3.2. Diagramas de Redes:

Propuesta de diagrama de Red de la planta alta y baja del bloque del Área de Ciencias y
Tecnologías.

Ilustración 17: diagrama de redes

Fuente: Elaboración propia

49
3.3.3. Diagrama de componentes

Muestra la organización y las dependencias entre un conjunto de componentes y también

muestra los dispositivos que se encuentran un sistema y su distribución en el mismo

cmp Componentes1

js assets

Boostrap.min.js icnos img

buttons.png fondo.jpg sideBar-font loginFont.jpg

jquery.dataTables.min.js

main.js css fonts

Material-
boostrap-
jquery.mCustomScrollbar.caoncatmin.js Dessign-Iconic-
material- boostrap.min.css
Font.eot
design.min.css

validator.min.js robotocondensed-
jquery.mCustomScrollbar.css main.css ligth.ttf

home.jsp conf_usuario.jsp insert_persona.jsp insert_asistencia.jsp horario.jsp

TestLibraries com.test

Contol.java
GlashFish
Server 4.1.1
pro.java

Ilustración 18: diagrama de componentes 1

Fuente: Elaboración propia

En ente diagrama podemos todos los componentes que se utilizan para poder hacer la
paginación web o las vistas que se le mostraran al cliente o usuario.

50
 cmp Componentes

com.data

Agrupa.xml Area_infraestrucutra.xml Asistencia.xml Asignatura.xml

Area.xml Compuesto.xml Cursa.xml Detalle_asig_periodo.xml

LeerHuella.xml Horario.xml Ocupacion_persona.xml Provincia.xml

Periodo.xml Gestion.xml Estado_civil.xml Justificacion_tolerancia.xml

Menu_principal.xml Plan_estudio.xml Persona.xml Sub_menu.xml

Tipo_semestral.xml Tipo_ambiente.xml Usuario.xml Privilegio.xml

Aula.xml Bloque.xml Localidad.xml Carrera.xml Dedo.xml

Dia.xml perfil_usuario.xml Tipo_persona.xml Huella.xml

Ilustración 19: diagrama de componentes 2

Fuente: Elaboración propia

51
cmp Componentes

Conf

Configuracion.properties
Dirver Password url Username

Com.dao

CompuestoDAO.java Area_infraestructuraDAO.java AsignaturaDAO.java

AsistenciaDAO.java AreaDAO.java AgrupaDAO.java CursaDAO.java

GestionDAO.java Ocupacion_personaDAO.java Estado_civilDAO.java

HorarioDAO.java Justificacion_toleranciaDAO.java ProvinciaDAO.java

PeriodoDAO.java Detalle_asig_periodoDAO.java
Sub_menuDAO.java
LeerHuellaDAO.java Menu_principalDAO.java PrivilegioDAO.java

Tipo_ambienteDAO.java Tipo_personaDAO.java perfil_usuarioDAO.java

HuellaDAO.java UsuarioDAO.java PersonaDAO.java DiaDAO.java

com.mode

Agrupa.java Area_infraestructura.java Asistencia.java Asignatura.java

Area.java Compuesto.java Cursa.java Detalle_asig_periodo.java

LeerHuella.java Horario.java Ocupacion_persona.java Provincia.java

Periodo.java Gestion.java Estado_civil.java Justificacion_tolerancia.java

Menu_principal.java Plan_estudio.java Persona.java Sub_menu.java

Tipo_semestral.java Tipo_ambiente.java Usuario.java Privilegio.java

Aula.java Bloque.java Localidad.java Carrera.java Dedo.java

Dia.java perfil_usuario.java Tipo_persona.java Huella.java

Librerias

Dirver JDBC mybatis- JDK 1.8 GlashFish

MySQL 3.2.6.jar Server 4.1.1.

52
 Ilustración 20: diagrama de componentes 3
Fuente: Elaboración propia

3.3.4. Diagrama de Despliegue

deployment Diagrama de despliegue

«device» «device»
RACK Enrutados
D - Link

Equipo Servidor de Pagina Web,Dell

«executionEnvironment» MySQL
Linux Ubuntu 16.04

Navegador
Chrome, Fire
Fox, Opera

Manual
Sistemas de control de Maquina Virtual de de
asistencia Java usuario
Cliente/Servidor

Ilustración 21: Diagrama de despliegue

Fuente: Elaboración propia

El diagrama muestra los componentes de hardware que se están tomando en cuenta y se estas
utilizando se hace se necesitara un servidor de mínimo un equipo de 8 GB de memoria RAM
y un disco duro de 1 Tera es necesario poseer un sistema operativo Linux Ubuntu 16.04, un
navegador CROME, FIRE FOX u OPERA también es necesario poseer una IP estática
entregado por el administrador de la red interna de Área de Ciencias y Tecnología.

53
3.3.5. Diagrama de desaplique de software

deployment Despliegue de despliegue - softw are

IBM 2T DE
Un nodo puede MEMORIA
representar un Servidor
equipo
Windows

Sistema de control de
asistencia Cliente/Servidor

IBM 2T DE MEMORIA
MySQL
Linux Ubuntu
16.04

Sistema de control de asistencia

Cliente/Servidor

Ilustración 22: diagrama de despliegue de software

Fuente: Elaboración propia

Es la parte de los requerimientos de software que debe tener un S.O. de 64 bits, en el equipo
de Linux Ubuntu 16.04 se instalará el sistema de control de asistencia en donde se podrá
realizar las diversas marcaciones de asistencia, como también pueden acceder los usuarios o
llamados personal del ACyT al sistema mediante equipos conectados a la red. Toda la
información generada por el sistema se guarda en una base de datos que tendrá que ser
MySQL.

54
3.4. FASE DE TRANSICIÓN

Ilustración 23: Panel de inicio

Fuente: Elaboración propia

Panel de inicio donde se puede optar las diferentes opciones de registros en el sistema,
registrar los datos de una nueva persona o modificarlos, registrar las huellas de una
respectiva persona y categorizarla si es docente, becario o estudiante para añadir sus
respectivos horarios como también modificarlas. Muestra la opción de control de asistencia
que una vez habilitada con la huella reconocida por el sensor registrara su asistencia de
acuerdo a datos análogos existencialmente.

Panel de inicio

Criterios de éxito La aceptación por el parte del usuario del diseño y los tiempos de
respuesta corto y específicos entre ventanas.
Herramientas JavaEE
necesarias
Táctica: Se iniciara la verificación de la interfaz gráfica a través de una
navegación completa por las diferentes secciones y funcionalidades que
componen el sistema.

55
 Se le pedirá a una persona que no haya tenido contacto con el sistema
que navegue, esto con el fin de poner a prueba la intuición, los tiempos
de respuesta, recibir los comentarios y críticas constructivas.
Consideraciones Realizar las pruebas en 3 computadoras con diferentes características de
especiales hardware.

Ilustración 24: Insertar persona

Fuente: Elaboración propia

La opción inserte persona nos lleva al siguiente marco donde podemos registrar los datos
personales de una persona.

Realizar el registro de personas

Criterios de éxito Se revisará la tabla de personas de la base de datos y se

Herramientas necesarias
Táctica:
Consideraciones especiales
verificará que es registro diligenciado en el formulario haya
sido registrado correctamente.
Ninguna.
Por medio del formulario de “registrar persona”, ingresar en
los campos los datos solicitados y presionar el botón de
“siguiente”.
La sección de seleccionar fotografía tiene que estar
habilitada para pasar a la siguiente interfaz.

56
Ilustración 25: Ocupación persona
Fuente: Elaboración propia

Luego de registrar los datos de una persona debemos definir su ocupación siendo esta
estudiante, docente o becario. Como también a que carrera pertenece y dando lugar a la
creación de un usuario y su password que con eso podrá acceder al sitio web donde le
brindará información detallada de sus horarios y cumplimiento de su asistencia.

57
Ilustración 26: Registro de huella
Fuente: Elaboración propia

El sistema permite la opción de registrar diversas huellas, este paso se debe realizar
cuidadosamente ya que las huellas que se registren serán las que deben ser identificadas por
el sensor para realizar los registros de asistencia, esta huella debe ser reconocida por el
sensor 4 vece para poder insertar como perteneciente a una persona.

Ilustración 27: Buscar persona

Fuente: Elaboración propia

En esta interfaz tiene las opciones de buscar personas existentes en la base de datos para
poder modificar su información registrada.

58
Ilustración 28: Registro de horario docente
Fuente: Elaboración propia

La siguiente interfaz permite asignar materias a un respectivo docente como también definir
qué días, aulas, horas de entrada y salida se dictará la clase, siendo parte de la habilitación
para realizar su registro de asistencia.

Realizar el registro de horarios a docentes

Criterios de éxito Se asigna horarios al docente teniendo opciones de verificar la

validación coherente de los horarios en el lado derecho de la
interfaz, para así finalizar con el llenado de datos del personal con
horarios.
Herramientas Ninguna
necesarias
Táctica: Se asigna la materia al docente de acuerdo al periodo apretando el
botón “Agregar asignatura”, asignando el día, la materia, la hora de
entrada y salida podremos añadir un horario al docente apretando
el botón “Agregar horario”, para finalizar la sección apretar en el
botón “Terminar”.
Consideraciones Todos los horarios añadidos son las que se analizaran para realizar
especiales el respectivo control de asistencia.

59
Ilustración 29: Asignación de materia a estudiante
Fuente: Elaboración propia

En esta parte es para añadir horarios a los estudiantes ya que ellos se adaptan a horarios
definidos de acuerdo a docente que lo dicta.

60
Ilustración 30: Control de asistencia
Fuente: Elaboración propia

La opción de control de asistencia nos lleva a esta interfaz el cual nos permite reconocer las
huella insertadas por el sensor y verificar la validación de la persona que pertenece con el
horario indicado, si no reconoce una huella registrada en la base de datos muestra el
siguiente menaje que esta e el grafico, si se encuentra pero no coincide con el horario
especificado lo pasa por desapercibido, toda huella reconocida por el sensor es mostrada en
el lado superior izquierdo del gráfico. si los datos especificados anteriormente coinciden el
sistema muestra que persona fue reconocida, con que ocupación está siendo su registro de
asistencia como también a que materia está siendo el ingreso y si es docente muestra
cuando hace su marcación de salida.

Registro de asistencia mediante sensor Digital Persona 4500

Criterios de éxito Al momento del reconocimiento de la huella si se encuentra dentro

del horario respectivo, el sistema realizara la validación para su
registro de asistencia.
Herramientas Ninguna
necesarias
Táctica: Colocar el dedo de la huella que fue anteriormente registrada en la
base de datos y permitir que el sensor haga la lectura, los datos
perteneciente a su estado y validación con la información registrada

61
 será mostrada inmediatamente como también algunos datos
personales y la materia a la que corresponde.
Consideraciones Realizar la postura adecuada para la lectura de la huella dactilar a
especiales través del sensor Digital Persona 4500.

Ilustración 31: Inicio Sesión

Fuente: Elaboración propia

Interfaz de inicio de sesión para usuarios, esta sección esta habilitada para las personas que
fueron registradas anteriormente e ingresaron su usuarios y password, con esos dos datos
podrán ingresar.
Inicio de sesión
Criterios de éxito La validación de ingreso al sistema
Herramientas Navegador Web
necesarias
Táctica: Ingresar los datos de usuario y password, estos datos son de acuerdo a
la identidad de ocupación de persona que está ingresando.
Consideraciones Si olvida el usuario y password podrá recuperarlo pasando por el
especiales administrador del sistema.

62
Ilustración 32: Datos de perfil
Fuente: Elaboración propia

Al entrar podrá observar los datos generales que ingreso al comienzo de los procesos del
sistema.

Ilustración 33: Editar datos

Fuente: Elaboración propia

En esta sección podrá alterar los datos de ella misma registrados anteriormente como también
el usuario y password para el respectivo ingreso.

63
Ilustración 34: Materias
Fuente: Elaboración propia

En esta área le mostrara las respectivas materias habilitadas como también su nivel de
asistencia.

Ilustración 35: Horario

Fuente: Elaboración propia

En la siguiente tabla se mostrará los horarios habilitados que tiene de acuerdo a la ocupación
que lleva dentro del sistema y a los cuales deberá asistir ya que de ello se llevara a cabo el
respectivo control de asistencia.

64
Ilustración 36: Información Asistencia
Fuente: Elaboración propia

Aquí le mostrara datos numéricos de la cantidad de asistencia, atrasos, permisos e inasistencia que
tiene.

Ilustración 37: Carrera

Fuente: Elaboración propia

La interfaz permite crear carreras dentro del área como también editar los datos que contiene, como
ser en que Bloque se encuentra, teléfono, correo, etc.

65
Ilustración 38: Registrar Carrera
Fuente: Elaboración propia

Permite Crear nueva Carreras dentro del área.

Ilustración 39: Información Asistencia

Fuente: Elaboración propia

La tabla lista los datos personales de todas las personas como también permite editar sus datos y
crear nuevo personal.
66
Ilustración 40: Registrar Nueva Persona
Fuente: Elaboración propia

En esta sección es para el administrador el cual podrá crear nuevas personas e ingresarlas como
personal del Área de Ciencias y Tecnología.

67
CAPITULO IV
4. CONCLUSIONES

68
El proyecto consistía en desarrollar un Sistema Biométrico para el control y gestión de
asistencia de personal docentes, universitarios y becarios del Área de Ciencias y Tecnología
(ACyT) utilizando las tecnologías de Java2EE y la plataforma de digital persona 4500
logrando la integridad segura de la información, de acuerdo al cumplimiento de las fases de
la metodología empleada Proceso Unificado se logró cumplir con cada una de ellas.

Se obtuvo los diagramas del modelo de proceso de negocios que se realiza dentro del Área
de Ciencias y Tecnologías para el control de asistencia del personal a base de un análisis
referente de la definición del análisis de involucrados, análisis de problema, análisis de
objetivo y análisis de alternativa siendo este uno de los puntos más decisivo ya que se define
el modo el cual se llevara a cabo algunos procesos dentro del área respecto al control de
asistencia. Mediante sondeos se logró identificar requerimientos funcionales y no
funcionales.

A través del lenguaje de modelado empleado y los procesos para el control de asistencia se
diseño la arquitectura del sistema definiendo la estructura de sus funcionalidades y la
estructura interna de cada una de ellas dando a cabo la construcción del sistema
implementando todas las especificaciones del diseño, siendo primordial para la construcción
el diagrama de secuencia el cual define la interacción entre los objetos dentro del sistema.

Se realizo la propuesta de un diagrama de Red abarcando la planta alta y baja del bloque del
Área de Ciencias y Tecnologías para realizar la respectiva implementación del sistema
biométrico dactilar de control de asistencia.

Así mismo se especifica que con la ejecución del proyecto del sistema biométrico dactilar
para para el control de asistencia del personal del área de ciencias y tecnología se logró
cumplir el objetivo general que es Desarrollar un Sistema Biométrico para el control y gestión
de asistencia de personal docentes, universitarios y becarios del Área de Ciencias y
Tecnología (ACyT) utilizando las tecnologías de Java2EE y la plataforma de digital persona
4500.

Cumpliendo con los objetivos específicos:

 Se modelo el negocio para determinar el proceso de registro de asistencia.

69
 Se diseño la arquitectura del sistema para definir la estructura de sus
funcionalidades y la estructura interna de cada una de ellas.
 Se construyo el sistema para implementar cada una de las especificaciones del
diseño.
 Se realizo la propuesta para el sistema funcional en la red del área de ciencias y
tecnología (ACyT).
 Fue desplegada el sistema en un servidor Linux.

70
CAPITULO V
5. RECOMENDACIONES

71
Para llevar a cabo la implementación del sistema se recomienda realizarlo de acuerdo a la
propuesta del sistema funcional en la red del área de ciencias y tecnología (ACyT) el cual
fue realizado mediante simulaciones en Pack Tracer.

En cuanto al funcionamiento se recomienda tener un personal establecido que realice la

administración del sistema como también los registros de los diversos datos que se precisa
para llevar a cabo su utilidad.

Los diversos equipos que se utilizaran como responsables de cada ambiente para realizar los
registros de asistencia se recomienda que sean en ordenadores de Raspberry Pi el cual sea de
una versión rentable a cubrir las necesidades del sistema.

Para supuestas fallas técnicas o requerimientos futuros se recomienda acudir a los

desarrolladores del sistema el cual están nombrados en la parte superior del proyecto.

72
CAPITULO VI
6. BIBLIOGRAFÍA

73
Aaron, Davi. 2018. Lenguaje de Modelado Unificado - UML. [En línea] GoldenEye
Criollo, 8 de mayo de 2018. [Citado el: 06 de octubre de 2018.] http://goldeneye-
criollo.blogspot.com/2011/05/lenguaje-de-modelado-unificado-uml.html.

Derkra. 2011. EL CONTROL ADMINISTRATIVO. SU IMPORTANCIA. [En línea]

Grandes Pymes, 18 de octubre de 2011. [Citado el: 07 de noviembre de 2018.]
https://www.grandespymes.com.ar/2010/03/10/el-control-administrativo-su-importancia/.

Díaz, Diana Patricia Botero. 2004. ANÁLISIS Y DISEÑO PARA EL SISTEMA DE

INFORMACIÓN DE LA UNIVERSIDAD DE MANIZALES . Colombia - Manizales : s.n.,
2004.

Ecured. 2017. ecured. [En línea] 9 de enero de 2017.

https://www.ecured.cu/Red_de_computadoras.

FCA-UNAM. 2015. FCA-UNAM. FCA-UNAM. [En línea] 2015.

https://auladejesus.milaulas.com/pluginfile.php/43/mod_folder/content/0/poo.pdf?forcedow
nload=1.

Garcia, Alejandro Garcia. 2016. Prácticas para la materia de. [En línea] febrero de 2016.
file:///C:/Users/Jeferson%20Jose/Downloads/Practicas_para_la_materia_de_Redes_de_Dat
os_II%20(1).pdf.

—. 2016. Prácticas para la materia de redes ii. [En línea] febrero de 2016.
file:///C:/Users/Jeferson%20Jose/Downloads/Practicas_para_la_materia_de_Redes_de_Dat
os_II%20(1).pdf.

—. 2016. Prácticas para la materia de redes ii. [En línea] febrero de 2016.
Downloads/Practicas_para_la_materia_de_Redes_de_Datos_II%20(1).pdf.

—. 2016. Prácticas para la materia de redes ii. [En línea] febrero de 2016.
Practicas_para_la_materia_de_Redes_de_Datos_II%20(1).pdf.

Gómez, José Jorge Márquez. 2010. ARQUITECTURAMVC. ARQUITECTURAMVC.

[En línea] 10 de 2010. http://metodologiasdesistemas.blogspot.com/.

Kimaldi Electronics, S.L. ¿Qué es la biometría? [En línea] [Citado el: 07 de noviembre de
2018.] https://www.kimaldi.com/blog/biometria/que_es_la_biometria/.

Korth, Henry F. 2006. Fundamentos de Bases de Datos. Fundamentos de Bases de Datos.

[En línea] 2006.
https://auladejesus.milaulas.com/pluginfile.php/43/mod_folder/content/0/poo.pdf?forcedow
nload=1.

74
Ltd., Sparx Systems Pty. 2017. sparx systems. sparx systems. [En línea] 2017.
http://www.sparxsystems.com.ar/products/ea.html.

Manizales, Unitecnica. 2011. PACKET TRACER. [En línea] 9 de noviembre de 2011.

http://luchotechnical.blogspot.com/2011/11/definicon.html.

Mateu, Carles. 2004. software libre. software libre. [En línea] marzo de 2004.
http://libros.metabiblioteca.org/bitstream/001/591/1/004%20Desarrollo%20de%20aplicacio
nes%20web.pdf.

—. 2004. Software libre. Software libre. [En línea] marzo de 2004.

http://libros.metabiblioteca.org/bitstream/001/591/1/004%20Desarrollo%20de%20aplicacio
nes%20web.pdf.

METODOSS. 2017. Metodología RUP. [En línea] 2017. [Citado el: 06 de octubre de
2018.] https://metodoss.com/metodologia-rup/.

mybatis.org. 2017. mybatis. mybatis. [En línea] 20 de agosto de 2017.

http://www.mybatis.org/mybatis-3/es/getting-started.html.

Noguer, Arregui. 2001. tecnologia. tecnologia. [En línea] 29 de 10 de 2001.

https://es.wikipedia.org/wiki/Tecnolog%C3%ADa.

OBOLOG. 2016. ingsoftware.es. ingsoftware.es. [En línea] OBOLOG, 2016. [Citado el:
03 de 06 de 2018.] http://ingsoftware072301.obolog.es/up-proceso-unificado-2010775.

ORM. 2011. Mapeo Objeto / Relacional (ORM). Mapeo Objeto / Relacional (ORM). [En
línea] 12 de 2011. Revista Telem@tica.

S.C., Network Information Center México. 2006. ipv6. [En línea] 1 de enero de 2006.
http://www.ipv6.mx/index.php/informacion/fundamentos/ipv4.

Salazar, Daniela. 2017. power desinger. power desinger. [En línea] 2017.
http://salazardaniela.galeon.com/.

Vazques, Pablo. 2017 . wikipedia. [En línea] 6 de noviembre de 2017 .

https://es.wikipedia.org/wiki/NetBeans.

vigilancia para SAN. www.incap. www.incap. [En línea] [Citado el: 07 de 05 de 2018.]
http://www.incap.int/sisvan/index.php/es/acerca-de-san/conceptos/sistema-de-vigilancia.

Vilalta, Josep. 2008. [En línea] 2008. [Citado el: 28 de noviembre de 2018.]
http://www.oocities.org/es/monsalvelaura/fase2/analisis.html.

75
CAPITULO VII
7. ANEXOS

76
Anexo A: Análisis de involucrados
Tabla 5: Análisis de involucrados

PROBLEMAS RECURSOS Y
GRUPOS INTERESES
PERCIBIDOS MANDATOS

Recursos humanos como

Obtener
personal académico dentro
Dirección ACyT

información
de las tres carreras del
inmediata No contiene datos
ACyT.
general del estadísticos de asistencia por
nivel de carreras.
asistencia por
Reglamento interno de la
carreras
UAP

Obtener
Recursos financiados a
información
Coordinación

Demora en percibir en través de ACyT

detallada de la
obtener información de la
asistencia de
asistencia e inasistencia de
docentes de su
los docentes. Reglamento interno de la
respectiva
ACyT
carrera.

Registro de asistencia en
Recursos Propios
sistemas descentralizados.
Administrativa(UDS)

El
administrador Registro de información de
vea todo el asistencia en hojas de papel
movimiento a
Reglamento interno del
través del
ACyT.
sistema. No existe registros exactos
de la asistencia de los
estudiantes.

77
Anexo B: Análisis de problema
Figura 1: Árbol de problemas Causa-Efecto
Fuente: Elaboración propia

Sistema de control de
asistencia descentralizado
E
F
E
C Demora en obtener Lentitud en percibir
T información general de información sobre el
O declive de asistencia
asistencia.
S del personal.

Control moroso en el flujo de información del proceso de cumplimiento de horario

respecto a docentes, becarios y estudiante del Área de Ciencias y Tecnologías.

C Inseguridad en
Registro de asistencia Registro de Control de
A el respaldo de la
de docentes en un asistencia de asistencia de
U información
sistema informático estudiantes en becarios validado
S asistencia de
decentralizado. hojas de papel a
A solo por
la deriva. docentes,
S responsables. becarios y
Fallas Técnicas.
Registros administrados estudiantes.
solamente por cada docente
Redundancia de Tendencia a perder las Falta de respaldo de la
datos. variadas hojas. validación de asistencia

78
 Anexo C: Análisis de objetivo
Figura 2: Árbol de objetivos Medios-Fin
Fuente: Elaboración propia

El administrador vea
todo el movimiento
mediante el sistema.

F
I
N
Obtener información Obtener información
inmediata de la inmediata sobre la
asistencia detallada. decadencia de
asistencias.

Implementar un Sistema Informático con acceso seguro para agilizar

el flujo de información de procesos de cumplimiento de horario
respecto a docentes, becarios y estudiante del Área de Ciencias y
Tecnologías, utilizando la metodología del proceso unificado y
tecnologías de Java2EE.

M
E
D Registro de datos Almacenamiento de Atomicidad de Datos Seguridad en el
I de todo el personal información de la en el registro de la respaldo de la
O en la base de asistencia en la Base asistencia de cada información del
S datos. de Datos personal. control de
asistencia.

Registros en el Registros mostrados Registro con

Back-Front numéricamente en el seguridad en la Base
sistema web de acuerdo de Datos
a usuario.

79
Anexo D: Análisis de alternativa

Figura 3: Análisis de alternativas Acciones-Medios

Fuente: Elaboración propia

Implementar un Sistema Informático con acceso seguro para agilizar el flujo de

información de procesos de cumplimiento de horario respecto a docentes,
becarios y estudiante del Área de Ciencias y Tecnologías, utilizando la
metodología del proceso unificado y tecnologías de Java2EE.

M
E
D Registro de datos de Almacenamiento de Atomicidad de Datos
4 en el registro de la
I todo el personal en la información de la
O base de datos. asistencia en la Base asistencia de cada
de Datos personal.
S

Seguridad en la Base
de Datos

A Puede resolverse con: Puede resolverse con: Puede resolverse con:

C
C a) Con la creación de a) Contratar personal a) Con el gestor de
I una base de datos para llenado de base de datos
O con un gestor como datos y/o MySQL y/o
N ser MySQL o b) Capacitación para el b) Con la encriptación
E
b) contratar personal uso del sistema. de las contraseñas
S
con conocimiento en la base de datos.
en sistemas

80
Anexo E: Matriz de marco lógico
Figura 4: Matriz de marco lógico
Fuente: Elaboración propia

MEDIOS DE
INDICADO
OBJETIVO VERIFICACIO SUPUESTOS
RES
N
Coadyuvar
FIN: satisfactoria  Informes de Agilización y
Contribuir al desarrollo de los mente en el desempeño datos validados
procesos de control de asistencia registro de  Reportes de de la asistencia
del personal del Área de Ciencias asistencia en funcionamient del personal de
y Tecnologías una mora o ACyT.
reducida.
PROPOSITO:
Implementar un Sistema
Informático con acceso seguro
Fortalecer el Optimización
para agilizar el flujo de procesos
de cumplimiento de horario
desempeño  Registro de del tiempo en
de asistencia asistencia la obtención de
respecto a docentes, becarios y
del personal  Reportes los datos de
estudiante del Área de Ciencias y
de ACyT. asistencia.
Tecnologías, utilizando la
metodología del proceso unificado
y tecnologías de java2EE.
Implantación
COMPONENTES:
de sistema en
Con la creación de una base de Capacitación al
datos gestionado por MySQL,
el tiempo  Supervisión personal sobre
establecido constante al
contratar personal para el llenado el sistema al
bajo el sistema
y capacitación para el uso del 1 ser
cronograma
sistema dando seguridad con el implementado
de
gestor de base de datos MySQL.
actividades
 Encuesta a
ACTIVIDADES: docentes y
1. Análisis de requerimientos. estudiantes del
2. Desarrollo del modelo físico y ACyT.
lógico.  Diagramas
3. Seleccionar participantes para que muestres
el manejo del sistema. la estructura
del sistema

81
Anexo F: Casos de uso

Caso de uso registrar persona

uc Registrar Usuario y Huella

Caso de Uso Registrar

Persona

Agregar

Modificar

Administrador
(UDS) Listar

Eliminar

Ilustración 41: Diagrama caso de uso registrar persona

Fuente: Elaboración propia

Nombre: Registrar Persona

Erín Boris Valdivia – Rodrigo Cruz Mendoza – Paulina Irene
Autor:
Velasquez Ferrufino
Fecha: 24-09-2018
Actor: Administrador(UDS) – Persona
Descripción: Permite el registro de datos del usuario(persona) en el sistema.
Eventos del Actor Eventos del Sistema
1. Ingresa al menú nuevo 1. Muestra el formulario para
usuario Registrar Usuario.
2. Registrar datos 2. Verificar que todos los
Flujo Principal:
3. Guarda los datos. campos y datos este
completos.
3. Actualizar base de datos.

1. Tener privilegios para ingresar a la interfaz

Precondición:
2. Ingresar datos y guardarlos en el sistema.
82
 1. Registrar Usuario
Postcondición:
2. Actualizar base de datos
1. Que todos los campos y datos estén completos y sean
correctos de lo contrario no se guardara la información.
Situaciones
2. Que el lector no reconozca la huella del Usuario.
Excepcionales
3. Que el usuario del sistema no tenga privilegios para ingresar
a la interfaz.

Caso de uso registrar huella

uc Registrar Huella

Caso de Uso Registrar Huella

Registrar

Administrador Coordinador
(UDS) Modificar

Eliminar

Ilustración 42: diagrama caso de uso registrar huella

Fuente: Elaboración propia

Nombre: Registrar Huella

Actores: Administrado, Coordinador
El Usuario(Persona) guarda su huella en la base de datos para
Descripción
que pueda ser identificado posteriormente
Eventos del Actor Eventos del Sistema

83
 1. Acceder a la opción
“Registrar mi huella” 1. Si las dos imágenes de la
2. Apoyar un dedo en el huella no coinciden, habrá
sensor y esperar a que que repetir el proceso
tome la imagen
3. Retirar el dedo del
Flujo Principal:
sensor
4. Apoyar nuevamente
el mismo dedo en el
sensor y esperar a
que tome la imagen
5. Retirar el dedo
Tener el lector de huellas operativo
Precondiciones:
Estar ya registrado en el Sistema
Postcondiciones:
Situaciones Datos incorrectos del usuario
Excepcionales Fallo en el registro de Huella

Caso de uso marca asistencia

uc Caso de Uso Marcar Asistencia

Caso de Uso Marcar Asistencia

Marcar
Docente
Entrada

Capturar
Huella
Becario

Marcar
Salida

Estudiante

Ilustración 43: diagrama caso de uso marca asistencia

Fuente: Elaboración propia

84
Nombre: Marcar Asistencia
Erín Boris Valdivia – Rodrigo Cruz Mendoza – Paulina Irene
Autor:
Velasquez Ferrufino
Fecha: 24-09-2018
Actor: Docente – Estudiante – Becario
Descripción: Registro de las horas de entrada y salida del Usuario(Persona)
Eventos del Actor Eventos del Sistema
1. Selecciona la marcación que 1. El Sistema solicita la
va a realizar. huella dactilar del
Flujo Principal: 2. Coloca su huella en el Usuario(Persona).
biométrico. 2. El sistema valida los datos
correspondiente al
usuario.
1. El Usuario debe estar registrado y debe pertenecer tipo
de Persona.
Precondición:
2. El sistema se encuentra encendido y funcionando.
3. El usuario previamente registra su huella en el sistema
1. El proceso de la marcación finaliza al colocar la huella en el
Postcondición: biométrico.
2. El registro de horario se realizó exitosamente.
1. Se registra la marcación en la Base de Datos correctamente.
Situaciones
2. No se registra la marcación en la Base de Datos
Excepcionales
correctamente.

85
Caso de uso asignar horario

uc Asignar Horario

Caso de Uso Asignar Horario

Agregar
Horario

Modificar
Horario

Listar Horario
Coordinador

Eliminar
Horario

Ilustración 44: diagrama caso de uso asignar horario

Fuente: Elaboración propia

Nombre: Asignar Horarios

Actores: Administrador(UDS) – Coordinador
1. Este caso de uso pretende modelar de manera general
la asignación de horarios según el tipo de horario. La
definición de los horarios consiste en la organización
de los días de labor registrando la hora de entrada y
Descripción salida a lo largo de la semana. Estos horarios son
definidos en base al plan anual de la ACyT.
2. La cantidad de horarios a asignar depende del tipo de
persona.

Eventos del Actor Eventos del Sistema

1. Opciones de horario en
el menú.
Flujo Principal: 2. Seleccionar tipo de
horarios
3. Asignar horarios
2. Si las dos imágenes de la
huella no coinciden, habrá
que repetir el proceso

El sistema debe estar conectado al servidor de la base de

Precondicione: datos para que se pueda almacenar la información, de la
misma manera el usuario autorizado se debe haber

86
 conectado al sistema para que se pueda generar la
información que el usuario requiere

Guardar los horarios generados.

Poscondicione: La información registrada en la Base de Datos se
actualiza.
Situaciones El administrador o el coordinador solicita imprimir los
Excepcionales horarios.

Caso de uso habilitar asignatura

uc Habitar Asignatura

Caso de Uso Asignar Horario

Rigistrar
Asignatura

Modificar
Docente Asignatura

Eliminar
Asignatura

Listar
Asignaturas

Ilustración 45: Diagrama caso de uso habilitar asignatura

Fuente: Elaboración propia

Nombre: Habilitar Asignatura

Actores: Docente
1. El Usuario(Persona) debe de estar registrado en la base de
Descripción
datos para poder habilitar una asignatura
Eventos del Actor Eventos del Sistema
1. El usuario(persona) 1. El sistema habilita al
selecciona al tipo de usuario en la Asignatura
Flujo Principal: persona

87
 1. Tener el Sistema Activo
Precondicione: 2. Estar ya registrado en el Sistema
3. Pertenecer a un tipo de Persona
Poscondicione: Asignatura Habilitado Exitoso

Situaciones
Excepcionales

Caso de uso generar reporte

uc Generar Reporte

Generar Reporte

Soliciatar Reporte

Administrador UDS

Director Coordinador

Ilustración 46: Diagrama caso de uso generar reporte

Fuente: Elaboración propia

Nombre: Generar Reporte

Administrado, Coordinador-
Actores:
Director
Descripción El caso de uso pretende modelar la obtención de los reportes.
Eventos del Actor Eventos del Sistema

88
 1. El actor selecciona del 1. El sistema presenta un
menú Principal la opción formulario que permite la
de Reportes. selección del tipo de reporte a
obtener.
Flujo Principal: 2. El actor selecciona el formato
que desea.
3. El sistema genera el reporte,
que puede ser visualizado y
apto a ser impreso.
El sistema debe estar conectado al servidor de la base de datos
para que se pueda almacenar la información, de la misma
manera el usuario autorizado se debe haber conectado al
Precondición:
sistema para que se pueda generar la información que el
usuario requiera.

postcondición: El reporte se generó exitosamente.

Situaciones
Excepcionales

Matriz de Trazabilidad

Casos de Uso
Requerimientos
CU2 CU3 CU4 CU5 CU6 CU7
R1 X
R2 X
R3 X
R4 X
R5 X
R6 X
R7 X
R8 X
R9 X
R10 X
R11
R12 X
R13 X
Tabla 7: Matriz de Trazabilidad

89
Anexo G: Diagrama de clases
class DC-1

Diagrama de Clases::Area Diagrama de Clases::Carrera

- ID_AREA: Integer - ID_CARRERA: Integer
- ID_USUARIO: Integer - ID_AREA: Integer
- NOMBRE_AREA: String - ID_USUARIO: Integer
- TELEFONO_AREA: Integer - ID_BLOQUE: int
- CORREO_AREA: String - NOMBRE_CARRERA: String
- FECHA_REGAREA: Timestamp - TELEFONO_CARRERA: String
- ESTADO_AREA: Integer - CORREO_CAR: String
- FECHA_REGCARRERA: Timestamp
+ Area(Integer, String, Integer, String, Integer, Integer, Timestamp)
«property get» + Carrera(int, int, int, String, String, String)
+ getNOMBRE_AREA(): String «property set»
1 1..*
+ getTELEFONO_AREA(): Integer + setID_AREA(Integer): void
+ getCORREO_AREA(): String + setNOMBRE_CARRERA(String): void
+ getID_USUARIO(): Integer + setTELEFONO_CARRERA(String): void
+ getFECHA_REGAREA(): Timestamp + setCORREO_CAR(String): void
«property set» + setFECHA_REGCARRERA(Timestamp): void
+ setNOMBRE_AREA(String): void + setID_USUARIO(Integer): void
+ setTELEFONO_AREA(Integer): void «property get»
+ setCORREO_AREA(String): void + getNOMBRE_CARRERA(): String
+ setID_USUARIO(Integer): void + getTELEFONO_CARRERA(): String
+ setFECHA_REGAREA(Timestamp): void + getCORREO_CAR(): String
+ getFECHA_REGCARRERA(): Timestamp
1
+ getID_USUARIO(): Integer
1

* *

Persona
Diagrama de Clases::Bloque
Diagrama de Clases::Usuario
- ID_BLOQUE: Integer
- ID_USUARIO: Integer
- ID_AREAINFRA: Integer
- ID_PERFIL: Integer
- ID_DIREC: Integer
- ID_OCUPA: Integer
- ID_USUARIO: Integer
- USUARIO: String
- BLOQUE: String
- CLAVE: String
- ESTADO_INFRA: Integer
- FECHA_REGUSUARIO: Timestamp
+ Bloque(Integer, Integer, Integer, String, Integer, Integer) - ESTADO_USUARIO: Integer
«property get» + Usuario(Integer, Integer, Integer, String, String, Timestamp)
+ getID_BLOQUE(): Integer
«property get»
+ getID_AREAINFRA(): Integer
+ getID_USUARI(): Integer
+ getID_DIREC(): Integer 1..* 1 + getID_PERFIL(): Integer
+ getBLOQUE(): String
+ getID_OCUPA(): Integer
+ getID_USUARIO(): Integer
+ getUSUARIO(): String
+ getESTADO_INFRA(): Integer
+ getCLAVE(): String
«property set» + getFECHA_REGUSUARIO(): Timestamp
+ setID_BLOQUE(Integer): void + getESTADO_USUARIO(): Integer
+ setID_AREAINFRA(Integer): void
«property set»
+ setID_DIREC(Integer): void
+ setID_USUARI(Integer): void
+ setBLOQUE(String): void
+ setID_PERFIL(Integer): void
+ setID_USUARIO(Integer): void
+ setID_OCUPA(Integer): void
+ setESTADO_INFRA(Integer): void
+ setUSUARIO(String): void
+ setCLAVE(String): void
+ setFECHA_REGUSUARIO(Timestamp): void
+ setESTADO_USUARIO(Integer): void

90
class DC-2

Diagrama de Clases::Carrera Diagrama de Clases::Plan_estudio

- ID_CARRERA: Integer - ID_PLAN: Integer
- ID_AREA: Integer - ID_CARRERA: Integer
- ID_USUARIO: Integer - ID_USUARIO: Integer
- ID_BLOQUE: int - PLAN: String
- NOMBRE_CARRERA: String - ARCHIVO: String
- TELEFONO_CARRERA: String - ESTADO_PLAN: Integer
- CORREO_CAR: String
- FECHA_REGCARRERA: Timestamp + Plan_estudio(Integer, Integer, String, String, Integer, Integer)
«property set»
+ Carrera(int, int, int, String, String, String)
+ setID_PLAN(Integer): void
«property set» + setID_CARRERA(Integer): void
+ setID_AREA(Integer): void 1 1
+ setID_USUARIO(Integer): void
+ setNOMBRE_CARRERA(String): void + setPLAN(String): void
+ setTELEFONO_CARRERA(String): void + setARCHIVO(String): void
+ setCORREO_CAR(String): void + setESTADO_PLAN(Integer): void
+ setFECHA_REGCARRERA(Timestamp): void
«property get»
+ setID_USUARIO(Integer): void
+ getID_PLAN(): Integer
«property get» + getID_CARRERA(): Integer
+ getNOMBRE_CARRERA(): String + getID_USUARIO(): Integer
+ getTELEFONO_CARRERA(): String + getPLAN(): String
+ getCORREO_CAR(): String 1 + getARCHIVO(): String
+ getFECHA_REGCARRERA(): Timestamp + getESTADO_PLAN(): Integer
+ getID_USUARIO(): Integer
1
1

* 1

Persona
Diagrama de Clases::Tipo_semestral
* Diagrama de Clases::Usuario
- ID_DETASIG: Integer
- ID_PLAN: Integer - ID_USUARIO: Integer
- ID_USUARIO: Integer - ID_PERFIL: Integer
- TIPO_SEMESTRE: String - ID_OCUPA: Integer
- ESTADO_DETASIG: Integer - USUARIO: String
- CLAVE: String
+ Tipo_semestral(Integer, Integer, String, Integer, Integer) - FECHA_REGUSUARIO: Timestamp
«property set» - ESTADO_USUARIO: Integer
+ setID_DETASIG(Integer): void
+ Usuario(Integer, Integer, Integer, String, String, Timestamp)
+ setID_PLAN(Integer): void
+ setID_USUARIO(Integer): void «property get»
+ setTIPO_SEMESTRE(String): void + getID_USUARI(): Integer
+ setESTADO_DETASIG(Integer): void + getID_PERFIL(): Integer
+ getID_OCUPA(): Integer
«property get»
+ getUSUARIO(): String
+ getID_DETASIG(): Integer
+ getCLAVE(): String
+ getID_PLAN(): Integer
+ getFECHA_REGUSUARIO(): Timestamp
+ getID_USUARIO(): Integer
+ getESTADO_USUARIO(): Integer
+ getTIPO_SEMESTRE(): String
+ getESTADO_DETASIG(): Integer «property set»
+ setID_USUARI(Integer): void
+ setID_PERFIL(Integer): void
+ setID_OCUPA(Integer): void
+ setUSUARIO(String): void
+ setCLAVE(String): void
+ setFECHA_REGUSUARIO(Timestamp): void
+ setESTADO_USUARIO(Integer): void

91
class DC-3 Asistencia

Diagrama de Clases::Plan_estudio Diagrama de Clases::Asignatura

- ID_PLAN: Integer - ID_ASIG: Integer
- ID_CARRERA: Integer - ID_PLAN: Integer
- ID_USUARIO: Integer - ID_USUARIO: Integer
- PLAN: String - SIGLA_ASIG: String
- ARCHIVO: String - NOMBRE_ASIG: String
- ESTADO_PLAN: Integer - FECHA_REGASIG: Timestamp
+ Plan_estudio(Integer, Integer, String, String, Integer, Integer) - CARGA_HOR: Integer
«property set» + Asignatura(Integer, Integer, Integer, String, String, Timestamp, Integer)
+ setID_PLAN(Integer): void «property set»
+ setID_CARRERA(Integer): void + setID_ASIG(Integer): void
+ setID_USUARIO(Integer): void 1 + setID_PLAN(Integer): void
*
+ setPLAN(String): void + setID_USUARIO(Integer): void
+ setARCHIVO(String): void + setSIGLA_ASIG(String): void
+ setESTADO_PLAN(Integer): void + setNOMBRE_ASIG(String): void
«property get» + setFECHA_REGASIG(Timestamp): void
+ getID_PLAN(): Integer + setCARGA_HOR(Integer): void
+ getID_CARRERA(): Integer «property get»
+ getID_USUARIO(): Integer + getID_ASIG(): Integer
+ getPLAN(): String + getID_PLAN(): Integer
+ getARCHIVO(): String + getID_USUARIO(): Integer
+ getESTADO_PLAN(): Integer + getSIGLA_ASIG(): String
1 + getNOMBRE_ASIG(): String
+ getFECHA_REGASIG(): Timestamp
+ getCARGA_HOR(): Integer
1..*
1

Persona
Diagrama de Clases::Usuario
1
- ID_USUARIO: Integer
- ID_PERFIL: Integer
- ID_OCUPA: Integer
- USUARIO: String
- CLAVE: String
- FECHA_REGUSUARIO: Timestamp
- ESTADO_USUARIO: Integer
+ Usuario(Integer, Integer, Integer, String, String, Timestamp)
«property get»
+ getID_USUARI(): Integer
+ getID_PERFIL(): Integer
+ getID_OCUPA(): Integer
+ getUSUARIO(): String
+ getCLAVE(): String
+ getFECHA_REGUSUARIO(): Timestamp
+ getESTADO_USUARIO(): Integer
«property set»
+ setID_USUARI(Integer): void
+ setID_PERFIL(Integer): void
+ setID_OCUPA(Integer): void
+ setUSUARIO(String): void
+ setCLAVE(String): void
+ setFECHA_REGUSUARIO(Timestamp): void
+ setESTADO_USUARIO(Integer): void

92
class DC-4 Perfil Usuario

Persona
Diagrama de Clases::Usuario
Diagrama de Clases::Perfil_usuario
- ID_USUARIO: Integer
- ID_PERFIL: Integer - ID_PERFIL: Integer
- ID_OCUPA: Integer - PERFIL: String
- USUARIO: String - DESCRIPCION_PERFIL: String
- CLAVE: String - ID_USUARIO: Integer
- FECHA_REGUSUARIO: Timestamp - ESTADO_PERFIL: Integer
- ESTADO_USUARIO: Integer + Perfil_usuario()
+ Usuario(Integer, Integer, Integer, String, String, Timestamp) + Perfil_usuario(Integer, String, String, Integer, Integer)
«property get» «property get»
+ getID_USUARI(): Integer + getID_PERFIL(): Integer
+ getID_PERFIL(): Integer 1
1 + getPERFIL(): String
+ getID_OCUPA(): Integer + getDESCRIPCION_PERFIL(): String
+ getUSUARIO(): String + getID_USUARIO(): Integer
+ getCLAVE(): String + getESTADO_PERFIL(): Integer
+ getFECHA_REGUSUARIO(): Timestamp «property set»
+ getESTADO_USUARIO(): Integer + setID_PERFIL(Integer): void
«property set» + setPERFIL(String): void
+ setID_USUARI(Integer): void + setDESCRIPCION_PERFIL(String): void
+ setID_PERFIL(Integer): void + setID_USUARIO(Integer): void
+ setID_OCUPA(Integer): void + setESTADO_PERFIL(Integer): void
+ setUSUARIO(String): void
+ setCLAVE(String): void
+ setFECHA_REGUSUARIO(Timestamp): void
+ setESTADO_USUARIO(Integer): void

class DC-5 Agrupa

Diagrama de Clases::Agrupa
- ID_AGRUPA: Integer
- ID_PERFIL: Integer
- ID_MENU_PRINCIPAL: Integer
+ Agrupa(Integer, Integer, Integer)
«property get»
+ getID_AGRUPA(): Integer
+ getID_MENU_PRINCIPAL(): Integer
+ getID_PERFIL(): Integer
«property set»
+ setID_AGRUPA(Integer): void
+ setID_MENU_PRINCIPAL(Integer): void
+ setID_PERFIL(Integer): void

1 1

1
1 Diagrama de Clases::Menu_principal
Diagrama de Clases::Perfil_usuario
- ID_MENU_PRINCIPAL: Integer
- ID_PERFIL: Integer - MENU_PRINCIPAL: String
- PERFIL: String - RUTA_MENU_PRINCIPAL: String
- DESCRIPCION_PERFIL: String - DESCRIPCION_MENU_PRINCIPAL: String
- ID_USUARIO: Integer - ESTADO_MENU_PRINCIPAL: Integer
- ESTADO_PERFIL: Integer - ID_USUARIO: Integer
+ Perfil_usuario()
+ Perfil_usuario(Integer, String, String, Integer, Integer) «property get»
+ getID_MENU_PRINCIPAL(): Integer
«property get» + getMENU_PRINCIPAL(): String
+ getID_PERFIL(): Integer + getRUTA_MENU_PRINCIPAL(): String
+ getPERFIL(): String + getDESCRIPCION_MENU_PRINCIPAL(): String
+ getDESCRIPCION_PERFIL(): String + getESTADO_MENU_PRINCIPAL(): Integer
+ getID_USUARIO(): Integer + getID_USUARIO(): Integer
+ getESTADO_PERFIL(): Integer
«property set»
«property set» + setID_MENU_PRINCIPAL(Integer): void
+ setID_PERFIL(Integer): void + setMENU_PRINCIPAL(String): void
+ setPERFIL(String): void + setRUTA_MENU_PRINCIPAL(String): void
+ setDESCRIPCION_PERFIL(String): void + setDESCRIPCION_MENU_PRINCIPAL(String): void
+ setID_USUARIO(Integer): void + setESTADO_MENU_PRINCIPAL(Integer): void
+ setESTADO_PERFIL(Integer): void + setID_USUARIO(Integer): void

93
class DC-6 Menu Principal

Persona
Diagrama de Clases::Usuario Diagrama de Clases::Menu_principal

- ID_USUARIO: Integer - ID_MENU_PRINCIPAL: Integer

- ID_PERFIL: Integer - MENU_PRINCIPAL: String
- ID_OCUPA: Integer - RUTA_MENU_PRINCIPAL: String
- USUARIO: String - DESCRIPCION_MENU_PRINCIPAL: String
- CLAVE: String - ESTADO_MENU_PRINCIPAL: Integer
- FECHA_REGUSUARIO: Timestamp - ID_USUARIO: Integer
- ESTADO_USUARIO: Integer
«property get»
+ Usuario(Integer, Integer, Integer, String, String, Timestamp) + getID_MENU_PRINCIPAL(): Integer
«property get» + getMENU_PRINCIPAL(): String
+ getID_USUARI(): Integer + getRUTA_MENU_PRINCIPAL(): String
1
+ getID_PERFIL(): Integer 1 + getDESCRIPCION_MENU_PRINCIPAL(): String
+ getID_OCUPA(): Integer + getESTADO_MENU_PRINCIPAL(): Integer
+ getUSUARIO(): String + getID_USUARIO(): Integer
+ getCLAVE(): String «property set»
+ getFECHA_REGUSUARIO(): Timestamp + setID_MENU_PRINCIPAL(Integer): void
+ getESTADO_USUARIO(): Integer + setMENU_PRINCIPAL(String): void
«property set» + setRUTA_MENU_PRINCIPAL(String): void
+ setID_USUARI(Integer): void + setDESCRIPCION_MENU_PRINCIPAL(String): void
+ setID_PERFIL(Integer): void + setESTADO_MENU_PRINCIPAL(Integer): void
+ setID_OCUPA(Integer): void + setID_USUARIO(Integer): void
+ setUSUARIO(String): void
+ setCLAVE(String): void
+ setFECHA_REGUSUARIO(Timestamp): void
+ setESTADO_USUARIO(Integer): void

class DC-7 Priv ilegio

Diagrama de Clases::Privilegio
- ID_PRIVILEGIO: Integer
- ID_USUARIO: Integer
- ID_COMPUESTO: Integer
- PRIORIDAD_SUBMENU: Integer
- DESCRIP_PRIVILEGIO: String
- ESTADO_PRIVILEGIO: Integer
+ Privilegio(Integer, Integer, Integer, Integer, String, Integer)
«property get»
+ getDESCRIP_PRIVILEGIO(): String
Persona + getESTADO_PRIVILEGIO(): Integer
Diagrama de Clases::Usuario + getID_COMPUESTO(): Integer
+ getID_PRIVILEGIO(): Integer
- ID_USUARIO: Integer + getID_USUARIO(): Integer
- ID_PERFIL: Integer + getPRIORIDAD_SUBMENU(): Integer
- ID_OCUPA: Integer
- USUARIO: String «property set»
+ setDESCRIP_PRIVILEGIO(String): void Diagrama de Clases::Compuesto
- CLAVE: String *
- FECHA_REGUSUARIO: Timestamp
0..* + setESTADO_PRIVILEGIO(Integer): void
- ID_COMPUESTO: Integer
- ESTADO_USUARIO: Integer 1 + setID_COMPUESTO(Integer): void
- ID_MENU_PRINCIPAL: Integer
+ setID_PRIVILEGIO(Integer): void 1 - ID_SUBMENU: Integer
+ Usuario(Integer, Integer, Integer, String, String, Timestamp) + setID_USUARIO(Integer): void
«property get» + setPRIORIDAD_SUBMENU(Integer): void + Compuesto(Integer, Integer, Integer)
+ getID_USUARI(): Integer «property get»
+ getID_PERFIL(): Integer + getID_COMPUESTO(): Integer
+ getID_OCUPA(): Integer + getID_MENU_PRINCIPAL(): Integer
+ getUSUARIO(): String + getID_SUBMENU(): Integer
+ getCLAVE(): String «property set»
+ getFECHA_REGUSUARIO(): Timestamp + setID_COMPUESTO(Integer): void
+ getESTADO_USUARIO(): Integer + setID_MENU_PRINCIPAL(Integer): void
«property set» + setID_SUBMENU(Integer): void
+ setID_USUARI(Integer): void
+ setID_PERFIL(Integer): void
+ setID_OCUPA(Integer): void
+ setUSUARIO(String): void
+ setCLAVE(String): void
+ setFECHA_REGUSUARIO(Timestamp): void
+ setESTADO_USUARIO(Integer): void

94
class DC-9 Compuesto
Diagrama de Clases::Compuesto
- ID_COMPUESTO: Integer
- ID_MENU_PRINCIPAL: Integer
- ID_SUBMENU: Integer
+ Compuesto(Integer, Integer, Integer)
«property get»
+ getID_COMPUESTO(): Integer
+ getID_MENU_PRINCIPAL(): Integer
+ getID_SUBMENU(): Integer
«property set»
+ setID_COMPUESTO(Integer): void
+ setID_MENU_PRINCIPAL(Integer): void
+ setID_SUBMENU(Integer): void
Diagrama de Clases::Menu_principal
- ID_MENU_PRINCIPAL: Integer
- MENU_PRINCIPAL: String
- RUTA_MENU_PRINCIPAL: String
- DESCRIPCION_MENU_PRINCIPAL: String
- ESTADO_MENU_PRINCIPAL: Integer
- ID_USUARIO: Integer
«property get»
+ getID_MENU_PRINCIPAL(): Integer
+ getMENU_PRINCIPAL(): String
+ getRUTA_MENU_PRINCIPAL(): String
+ getDESCRIPCION_MENU_PRINCIPAL(): String
+ getESTADO_MENU_PRINCIPAL(): Integer
+ getID_USUARIO(): Integer
«property set»
1
+ setID_MENU_PRINCIPAL(Integer): void
+ setMENU_PRINCIPAL(String): void
+ setRUTA_MENU_PRINCIPAL(String): void
*
+ setDESCRIPCION_MENU_PRINCIPAL(String): void
+ setESTADO_MENU_PRINCIPAL(Integer): void
+ setID_USUARIO(Integer): void
Diagrama de Clases::Sub_menu
- ID_SUBMENU: Integer
- DESCRIPCION: String
- ORDEN: Integer
*
- RUTA_SUB_MENU: String
- SUB_MENU: String
1
- ESTADO_SUBMENU: Integer
+ Sub_menu(Integer, String, String, String, Integer)
«property get»
+ getID_SUBMENU(): Integer
+ getSUB_MENU(): String
+ getRUTA_SUB_MENU(): String
+ getDESCRIPCION(): String
+ getORDEN(): Integer
+ getESTADO_SUBMENU(): Integer
«property set»
+ setID_SUBMENU(Integer): void
+ setSUB_MENU(String): void
+ setRUTA_SUB_MENU(String): void
+ setDESCRIPCION(String): void
+ setORDEN(Integer): void
+ setESTADO_SUBMENU(Integer): void
95
class DC-10

Diagrama de Clases::Ocupacion_persona
- ID_OCUPA: Integer
- ID_PERSONA: Integer
- ID_TIPO: Integer
- ID_USUARIO: Integer
- COD_PER_OCUPA: String
- FECHA_REGOCUP: Timestamp
- ESTADO_OCUP: Integer
+ Ocupacion_persona(Integer, Integer, Integer, Integer, String, Integer)
«property get»
+ getID_OCUPA(): Integer
+ getID_PERSONA(): Integer
+ getID_TIPO(): Integer
+ getCOD_PER_OCUPA(): String
Diagrama de Clases::Usuario
+ getFECHA_REGOCUP(): Timestamp
- ID_USUARIO: Integer + getID_USUARIO(): Integer
- ID_PERFIL: Integer + getESTADO_OCUP(): Integer
- ID_OCUPA: Integer «property set»
- USUARIO: String + setID_OCUPA(Integer): void
- CLAVE: String 1..* + setID_PERSONA(Integer): void
- FECHA_REGUSUARIO: Timestamp + setID_TIPO(Integer): void
1
- ESTADO_USUARIO: Integer + setCOD_PER_OCUPA(String): void
+ Usuario(Integer, Integer, Integer, String, String, Timestamp) + setFECHA_REGOCUP(Timestamp): void
+ setID_USUARIO(Integer): void
«property get»
+ setESTADO_OCUP(Integer): void
+ getID_USUARI(): Integer
+ getID_PERFIL(): Integer 1..*
+ getID_OCUPA(): Integer
+ getUSUARIO(): String
+ getCLAVE(): String
Diagrama de Clases::Persona
+ getFECHA_REGUSUARIO(): Timestamp
+ getESTADO_USUARIO(): Integer - ID_PERSONA: Integer
«property set» - ID_CIVIL: Integer
+ setID_USUARI(Integer): void - ID_USUARIO: Integer
+ setID_PERFIL(Integer): void - CI: Integer
+ setID_OCUPA(Integer): void - NOMBRES: String
+ setUSUARIO(String): void - PATERNO: String
+ setCLAVE(String): void - MATERNO: String
+ setFECHA_REGUSUARIO(Timestamp): void - DIRECCION: String
+ setESTADO_USUARIO(Integer): void - CELULAR_PER: String
- CORREO_PER: String
1
- FECHA_NACIMIENTO: Date
- SEXO: String
1 - ESTADO_PER: Integer
+ Persona(Integer, String, String, String, String, String, String, Date, Integer, String)
Diagrama de Clases::Tipo_persona
«property set»
- ID_TIPO: Integer + setID_PERSONA(Integer): void
- ID_USUARIO: Integer + setID_CIVIL(Integer): void
- TIPO: String + setID_USUARIO(Integer): void
- FECHA_REGTIPO: Timestamp + setCI(Integer): void
1
- ESTADO_TIPO: Integer + setNOMBRES(String): void
+ Tipo_persona(String, Integer, Timestamp, Integer) + setPATERNO(String): void
+ setMATERNO(String): void
«property get» + setDIRECCION(String): void
+ getESTADO_TIPO(): Integer + setCELULAR_PER(String): void
+ getFECHA_REGTIPO(): Timestamp + setCORREO_PER(String): void
+ getID_TIPO(): Integer + setFECHA_NACIMIENTO(Date): void
+ getID_USUARIO(): Integer + setSEXO(String): void
+ getTIPO(): String + setESTADO_PER(Integer): void
«property set» «property get»
+ setESTADO_TIPO(Integer): void + getID_PERSONA(): Integer
+ setFECHA_REGTIPO(Timestamp): void + getID_CIVIL(): Integer
+ setID_TIPO(Integer): void + getID_USUARIO(): Integer
+ setID_USUARIO(Integer): void + getCI(): Integer
+ setTIPO(String): void + getNOMBRES(): String
+ getPATERNO(): String
+ getMATERNO(): String
+ getDIRECCION(): String
+ getCELULAR_PER(): String
+ getCORREO_PER(): String
+ getFECHA_NACIMIENTO(): Date
+ getSEXO(): String
+ getESTADO_PER(): Integer

Anexo H: Manual de Usuario

96
Panel de control del sistema

MENUS DE MENUS DE
OPERACION OPERACION

Área de registro de una persona

DATOS DE FOTO DE
UNA LA
PERSONA PERSONA

BOTON DE LA FOTO

97
Segmento de registro de una huella

LISTADO DE
DEDOS

LISTADO DE HUELLAS REGISTRADAS DE

LA PERSONA

HUELLA

Asignación de materias a un estudiante

NUEVA BORRAR
MATERIA MATERIA

LISTADO DE
MATERIAS
ABILITADAS

98
 Registro de asignaturas y horarios a un docente o becario

FORMULARIO
ASIGNATURA
LISTADO DE MATERIAS Y
HORARIOS

AGREGAR LA MATERIA EN
HORARIOS
Control de asistencia

DATOS PERSONALES GENERALES AL

MARCAR ASISTENCIA

99
Anexo I: Auditoria de Seguridad al sistema biométrico dactilar cliente/servidor de
control de ambientes y asistencia de personal del acyt.

Ilustración 47: Auditoria de Seguridad al Sistema

Fuente elaboración propia

100
101