UNIVERSIDAD TÉCNICA DEL NORTE

FACULTAD DE INGENIERÍA EN CIENCIAS APLICADAS

CARRERA DE INGENIERÍA EN ELECTRÓNICA Y REDES DE COMUNICACIÓN

“CONTROL DE ASISTENCIA SEMIAUTOMATICO USANDO JAVA”

TRABAJO DE GRADO PREVIO A LA OBTENCIÓN DEL TÍTULO DE INGENIERO

EN ELECTRÓNICA Y REDES DE COMUNICACIÓN

AUTORES: JACOME JHONATAN, ROMERO ROBERTH, RUIZ GALO

DIRECTOR: MSC. LUIS SUAREZ

Ibarra-Ecuador

2019
 2

Índice
CAPÍTULO 1. ANTECEDENTES. .................................................................................... 3

1.1 TEMA. ...................................................................................................................... 4

1.2 PROBLEMA. ............................................................................................................ 4
1.3 OBJETIVO ................................................................................................................ 5
1.3.1 Objetivo general. ................................................................................................ 5
1.3.2 Objetivos específicos. ........................................................................................ 5
1.4 ALCANCE. ............................................................................................................... 6
1.5 JUSTIFICACIÓN. .................................................................................................... 7

CAPÍTULO 2. JUSTIFICACIÓN TEÓRICA .................................................................... 8

MARCO TEÓRICO ............................................................................................................ 8

2.1 Programación orientada a objetos: ............................................................................ 8
2.2 Objetos: ..................................................................................................................... 9
2.2.1 Abstracción: ....................................................................................................... 9
2.2.2 Herencia: ............................................................................................................ 9
2.2.3 Polimorfismo:................................................................................................... 10
2.2.4 Encapsulamiento: ............................................................................................. 10
2.3 Atributos: ................................................................................................................ 11
2.4 Métodos:.................................................................................................................. 12
2.5 Clases: ..................................................................................................................... 13
2.5.1Concepto: .......................................................................................................... 13
2.5.2 Tipos: ............................................................................................................... 14
2.5.3 Cardinalidad: .................................................................................................... 14
2.6 Diagrama de Clases: ................................................................................................ 15
2.7 Relaciones entre los diagramas de clases ............................................................ 16
2.7.1 Asociación: ....................................................................................................... 16
2.7.2 Asociaciones unidireccionales: ........................................................................ 17
2.7.3 Agregación: ...................................................................................................... 17
2.7.4 Composición: ................................................................................................... 18
2.7.5 Dependencia: .................................................................................................... 18
2.7.6 Herencia: .......................................................................................................... 19
2.7.7 Multiplicidad: ................................................................................................... 19

CAPÍTULO3.DISEÑO ..................................................................................................... 21
 3

3.1 Situación Actual ...................................................................................................... 21

3.2 Metodología ............................................................................................................ 22
3.3 Requerimientos ....................................................................................................... 24
3.4 Requerimientos de Stakeholders ............................................................................. 25
3.5 Listado de Clases: ................................................................................................... 27
3.6 Diagrama de Clases ................................................................................................. 28
3.7 Diseño del Sistema .................................................................................................. 29
3.8 Diagrama de Bloques .............................................................................................. 30

CAPÍTULO 4. PRUEBAS Y RESULTADOS ................................................................. 31

REFERENCIAS ................................................................................................................ 31

Tabla de ilustraciones

Ilustración 1 Atributo de una clase.................................................................................... 11

Ilustración 2 ejemplo de clase ........................................................................................... 15

Ilustración 3 asociación ..................................................................................................... 16

Ilustración 4 asociaciones unidireccionales ...................................................................... 17

Ilustración 5 ejemplo de agregación ................................................................................. 17

Ilustración 6 Composición ................................................................................................ 18

Ilustración 7 Dependencia ................................................................................................. 18

Ilustración 8 Herencia ....................................................................................................... 19

Ilustración 9Multiplicidad ................................................................................................. 20

Ilustración 10 Ejemplos de multiplicidad ......................................................................... 20

Ilustración 11 diagrama del proyecto ................................................................................ 28

Ilustración 12 Diagrama de bloques del sistema ............................................................... 30

 4

CAPÍTULO 1. ANTECEDENTES.

1.1 TEMA.

“CONTROL DE ASISTENCIA DE LOS ESTUDIANTES DE LA FACULTAD DE

INGENIERÍA EN CIENCIAS APLICADAS

1.2 PROBLEMA.

En la Facultad de Ingenierías en Ciencias Aplicadas, el llevar el registro de asistencia puede

ser un problema un poco tedioso para los maestros ya que esto conlleva un gasto de tiempo; no es

un tiempo sustancialmente grande, pero al fin y al cabo esta pequeña pérdida puede generar

conflictos con el tiempo que los estudiantes tienen para realizar alguna actividad propuesta por el

docente.

La falta de un control de asistencia Semiautomático genera ciertos problemas entre

estudiantes y docentes; generalmente al final de los periodos académicos, o a su vez en el registro

diario del docente ya que este puede cometer errores. No obstante, existen otros problemas

relacionados con el registro de asistencia como puede ser la pérdida de alguna asignatura por no

asistir a la misma.
 5

1.3 OBJETIVO

1.3.1 Objetivo general.

● Desarrollar un programa para el control de asistencia de los estudiantes de la Facultad de

Ingenierías en Ciencias Aplicadas

1.3.2 Objetivos específicos.

● Analizar la situación actual referente al control de asistencia en los estudiantes.

● Diseñar el diagrama de clases, y las interfaces de usuario para el sistema.

● Desarrollar la programación de las funciones requeridas para el control de asistencia.

● Realizar pruebas de funcionamiento.

● Documentar la propuesta.
 6

1.4 ALCANCE.

Este proyecto es un primer paso hacia el sistema de registro semiautomático el cual se

centra en buscar un sistema simple, pero a su vez con una calidad de rendimiento lo

suficientemente alta como para ser implementado en un futuro.

Se diseñará un diagrama de clases en el cual se muestre la estructura básica del proyecto y

las distintas relaciones entre las clases, al igual que la multiplicidad entre ellas. Para ello se va a

distribuir las diferentes fases del proyecto en varios módulos que nos ayudarán a organizar el

trabajo y se aplicará interfaces.

Una vez culminado el diagrama de clases se va a implementar el código necesario para la

ejecución del programa en el Software de NetBeans, específicamente utilizando la Programación

Orientada a Objetos de Java mediante una aplicación de Escritorio.

 7

1.5 JUSTIFICACIÓN.

Un problema serio que se presenta en la Facultad de Ingenierías en Ciencias Aplicadas a

nivel general es la falta de un modelo adecuado de registro de asistencia para los estudiantes. Con

esta investigación se pretende realizar una mirada estratégica al momento que los estudiantes

asisten a clase.

Utilizando el registro semiautomático los docentes y estudiantes tendrán más tiempo

disponible para centrarse en actividades académicas que anteriormente no era posible realizar.

Este control permitirá a los docentes y a los estudiantes facilitar el proceso de registro de

asistencia y evitar inconvenientes día a día ya que al final de los periodos académicos genera

problemáticas.
 8

CAPÍTULO 2. JUSTIFICACIÓN TEÓRICA

MARCO TEÓRICO

2.1 Programación orientada a objetos:

Concepto: La orientación a objetos ha tomado por asalto y en forma legítima al mundo

del software. Como medio para la generación de programas, tiene varias ventajas. Fomenta

una metodología basada en componentes para el desarrollo de software, de manera que

primero se genera un sistema mediante un conjunto de objetos, luego podrá ampliar el

sistema agregándole funcionalidad a los componentes que ya había generado o agregándole

nuevos componentes y finalmente podrá volver a utilizar los objetos que genero para el

sistema cuando cree uno nuevo, con lo cual reducirá sustancialmente el tiempo de

desarrollo de un sistema.

Características: un objeto es la instancia de una clase. Usted y yo, por ejemplo, somos

instancias de la clase persona. Un objeto cuenta con una estructura, es decir atributos y

acciones. Las acciones son todas las actividades que el objeto es capaz de realizar. Los

atributos y acciones, en conjunto, se conocen como características o rasgos.

 9

2.2 Objetos:

La orientación a objetos se refiere a algo más que tan solo atributos y acciones también

considera otros aspectos. Dichos aspectos se conocen como abstracción, herencia,

polimorfismo y encapsulamiento. Otros aspectos importantes de la orientación a objetos

son: él envió de mensajes, las asociaciones y la agregación. Examinemos cada uno de estos

conceptos.

2.2.1 Abstracción:

La abstracción se refiere a quitar las propiedades y acciones de un objeto para dejar

solo aquellas que sean necesarias. Es decir, diferentes tipos de problemas requieren distintas

cantidades de información, aun si estos problemas pertenecen a un área en común. En la

segunda fase de la creación de la clase lavadora, se podrían agregar más atributos y acciones

que en la primera fase.

2.2.2 Herencia:

Un objeto es una instancia de una clase. Esta idea tiene una consecuencia

importante: como instancia de una clase, un objeto tiene todas las características de la

clase de la que proviene. A esto se le conoce como herencia. A demás un objeto no solo

hereda de una clase, si no que una clase también puede heredar de otra. Las lavadoras,

refrigeradoras, hornos, radios y planchas son clases y forman parte de una clase más

genérica llamada: electrodomésticos.

 10

2.2.3 Polimorfismo:

En ocasiones tiene el mismo nombre en diferentes clases. por ejemplo, podrá abrir

una puerta, una ventana, un periódico, un regalo o una cuenta de banco en cada, uno de

estos casos, realizará una operación diferente. En la orientación a objetos, cada clase sabe

cómo realizar tal operación. El polimorfismo permite al modelador mantener tal

terminología sin tener que crear palabras artificiales para sustentar una unicidad innecesaria

de los términos.

2.2.4 Encapsulamiento:

La esencia del encapsulamiento es que cuando un objeto trae consigo su funcionalidad, esta

última se oculta. En el mundo del software, el encapsulamiento permite reducir el potencial

de errores que pudieran ocurrir. En un sistema que consta de objetos, estos dependen unos

de otros en diversas formas. Si uno de ellos falla y los especialistas de software tienen que

modificar de alguna forma, el ocultar sus operaciones de otros objetos significa que tal vez

no será necesario modificar los demás objetos. En el mundo real, también verá la

importancia del encapsulamiento en los objetos con los que trabaje. Por ejemplo, el monitor

de su computadora en cierto sentido oculta sus operaciones de la CPU, es decir, si algo falla

en su monitor, lo reparara o lo reemplazará; pero es muy probable que no tenga que reparar

o reemplazar la CPU al mismo tiempo que el monitor.

 11

2.3 Atributos:

Los atributos UML son las cualidades de una clase que tiene una correspondencia directa y

son traducidos a esquemas de estados en la clase que pertenezca los atributos de la clase UML.

En la lista de visibilidad se encuentran los atributos que son públicos. En el esquema inicial

podemos encontrar los atributos que contengan un valor inicial (Becker y Pons, 2003).

Ilustración 1 Atributo de una clase.

Los atributos pueden tener datos que son simples, complejos, objetuales, etc. En UML los

atributos poseen un conjunto predefinido de tipos de datos, y tiene la posibilidad de crear

otros tipos de datos, depende de la herramienta que se realiza un modelo y su conjunto

predefinido de tipos de datos se compara hasta obtener la equivalencia uno a uno por cada

tipo de dato. Un atributo posee una propiedad que nos indica si el valor puede cambiar en

un tiempo, esta propiedad se le conoce como changeability. En cambio, si el atributo es

derivado no contiene la propiedad changeability, por lo tanto, tiene una propiedad booleana

(isDerived). El valor inicial de un atributo depende al valor que tomará el atributo cuando

se crea un objeto de una clase. Los atributos en UML tiene un número mínimo y máximo

de valores que un atributo puede tener en un instante del tiempo. Se lo conoce como

multiplicidad del atributo, cuando su mínimo es 0 significa que el atributo acepta nulos

(Marín,Giachetti y Pastor,2007).
 12

En la visibilidad de un atributo puede ser: privada, pública y protegida. Si es privada

es sólo la clase puede ver. En cambio, cuando un atributo es público cualquier clase puede

ver el atributo. Finalmente, cuando el atributo es protegido solo la clase y sus descendientes

pueden ver el atributo. También un atributo tiene un ámbito que puede ser de: instancia y

clase. Un atributo de instancia tiene una propiedad aplicable a los objetos de la clase y esos

objetos tienen un valor diferente del atributo. En cambio, un atributo de clase los objetos

de la clase comparten el valor del atributo y tiene la propiedad aplicable a la clase de objetos

(Gómez, Mayol, Olivé y Teniente, 2003).

2.4 Métodos:

En UML todo objeto tiene un grupo de atributos y un grupo de métodos. Los métodos es un

conjunto de instrucciones que contiene valores de entrada y se modifica los valores de los

atributos o forman un resultado. Un conjunto de objetos que son similares, en otras palabras,

que tienen los atributos y métodos semejantes, forma una clase de objetos. Por lo tanto la

estrucutra y el comportamiento se puede definir en común en el ámbito de la clase (Laurent y

Fien, 2016).

Hay diferentes clases de métodos entre los más comunes son: privado, protegido y público. El

privado es el que indica que no va a ser visible para los que quieren solicitar fuera de la clase.

El protegido es que se puede ver cuando son solo clases hijas. Finalmente el público son

visibles para todo. En la notación de los métodos podemos encontrar convenciones textuales,

lo cual podemos encontrar en la siguiente tabla que tenemos a continuación (Sparks, 2007).
 13

Símbolo Significado

+ Público

- Privado

# Protegido

$ Estático

/ Derivado (atributo-no estándar)

* Abstracto (atributo-no estándar)

Tabla 1 Convenciones textuales de un método

2.5 Clases:

2.5.1Concepto:

Una clase es un elemento estándar del UML, además describe un conjunto de objetos que

comparten atributos, asociaciones, operaciones y métodos. Una clase es una especificación; un

objeto es una instancia de una clase. Las clases se pueden heredar de otras clases (en otras

palabras, significa que van a obtener el comportamiento y el estado de sus padres y agregan

nueva funcionalidad propia), es posible que otras clases puedan tener atributos, pueden dar

responsabilidades a otras clases e implementar interfaces abstractas. Una clase puede

encapsular el estado además ofrece los servicios para manipularlo (el comportamiento). Un

diseño orientado a objetos da límites al acceso directo a los atributos de la clase y ofrece los

servicios que manipulan a solicitud del solicitante. El ocultamiento de los datos y exposición

de los servicios asegura que las modificaciones de los datos se realizan sólo en un lugar y de
 14

acuerdo con reglas específicas; para grandes sistemas la cantidad de código que tiene acceso

directo a los elementos de datos en muchos sitios es extremadamente alto. Para identificar una

clase debe tener el nombre que se le asigno en el diagrama UML y se le antepone el nombre

del paquete en dónde se encuentra el diagrama y un punto (Becker y Pons, 2003).

2.5.2 Tipos:

La materialización es un tipo de relación genérico que relaciona una clase que representa

una categoría se llama clase abstracta con una o muchas clases que representan objetos

concretos de esa categoría llamadas clases concretas. Las clases abstractas son aquellas de

las cuales no se pueden crear instancias directamente. En cambio, las clases concretas

heredan una serie de propiedades de la clase abstracta. Las subclases es una descripción de

una clase basada en la estructura de otra clase. Una subclase hereda ciertas características

de la/s clase/s padre/s, es como una extensión de esta, e, incluso, pueden redefinirse o

agregarse nuevas características de la clase padre. Finalmente, las superclases es el que

posee una gran cantidad de número de subclases (Cabot, 2003).

2.5.3 Cardinalidad:

La cardinalidad en uml se sitúa en un extremo de una asociación nos informa las instancias

de la clase situada en el mismo extremo lo cual va a estar vinculada a una instancia de la

clase situada en el extremo opuesto. En uno de los extremos es posible encontrar la

cardinalidad mínima y máxima con la finalidad de indicar el intervalo de valores que

 15

pertenece a la cardinalidad. Cuando tenemos en un extremo que contenga una cardinalidad

superior a 1, tenemos que las ocurrencias deben estar ordenadas. La notación de la

cardinalidad mínima y máxima se puede observar en la misma tabla (Debrauwer,2016).

2.6 Diagrama de Clases:

El Lenguaje Unificado de Modelado (UML) es una notación grafica para dibujar diagramas

de conceptos de software. Se pueden utilizar para dibujar diagramas de un dominio del

problema, un diseño del software propuesto o una implementación de un software ya

completo (Martin, 2004).

Una concepción sencilla de las clases es tomarlas como categorías, estas categorías o grupo

de cosas que tienen atributos y acciones similares son las que conocemos como clases.

Un rectángulo es el símbolo que representa a la clase y se divide en tres áreas. El

área superior contiene el nombre, el área central contiene los atributos, y el área inferior las

acciones (Schmuller, 1999).

Ilustración 2 ejemplo de clase

 16

Los diagramas de clases facilitan las representaciones a partir de las cuales los

desarrolladores podrán trabajar. Estos diagramas permiten la comunicación entre el

Figura 2: Símbolo UML de una clase
programador y el usuario utilizando un lenguaje sencillo de entender, a través del cual el

usuario puede detallar los requerimientos que desee o observar los problemas en caso de

existir (Martin, 2004). Afirma. “Puede ser mucho más fácil evaluar la estructura de

dependencia de un sistema desde un diagrama que desde el código fuente. Los diagramas

hacen posible ciertas estructuras de dependencia.”

2.7 Relaciones entre los diagramas de clases

Los diagramas de clases pueden tener varias relaciones entre si las cuales representan los

distintos tipos de interacción entre las clases de un diagrama, a continuación, veremos sus

relaciones:

2.7.1 Asociación:

Las asociaciones entre clases representan muy a menudo variables instancias que

mantienen referencias a otros objetos.

Ilustración 3 asociación
 17

Por ejemplo, en la ilustración 3 vemos una asociación entre Cliente y Dirección del tipo

“vive en” en la cual vemos como el cliente tiene referencia a una dirección establecida.

2.7.2 Asociaciones unidireccionales:

Además de las asociaciones ya conocidas que son tipo bidireccional existen otras

las cuales son unidireccionales y se las representa mediante una flecha en el extremo de la

asociación para indicar su sentido.

Figura
Ilustración 4.- Asociación
4 asociaciones Unidireccional
unidireccionales

2.7.3 Agregación:

La agregación es una forma especial de asociación que supone una relación entre el todo y

sus partes. La destrucción del compuesto no conlleva la destrucción de los componentes.

Habitualmente se da con mayor frecuencia que la composición. La agregación se representa

en UML mediante un diamante de color blanco colocado en el extremo en el que está la

clase que representa el “todo”.

Ilustración 5 ejemplo deFigura 5.-

agregación Agregación
 18

2.7.4 Composición:

La composición es una forma especial de agregación según (Martin, 2004) “El propietario

es responsable del tiempo de vida de la parte. Si el propietario es destruido, el Ward deber

ser destruido con él. Si el propietario es copiado, la parte deber ser copiada con él.”

Ilustración 6 Composición

2.7.5 Dependencia:

Es una relación de uso entre dos clases (una usa a la otra). Esta relación es la más básica entre

clases y comparada con los demás tipos de relación, la más débil (Pérez, 2012).

Se representa con una flecha discontinua que parte desde una clase y apunta a otra. El sentido

de la flecha nos indica quien usa a quien. Esta es principalmente una relación de uso.

Figura 7: Dependencia
Ilustración 7 Dependencia
 19

2.7.6 Herencia:

La herencia indica que una clase (Hija) hereda los métodos y atributos especificados por una

clase (Padre), por lo cual una clase hija además de tener sus propios métodos y atributos, podrá

acceder a las características y atributos visibles de su clase Padre (public y protected).

Ilustración 8 Herencia
Figura 8: Herencia

2.7.7 Multiplicidad:

La multiplicidad de una asociación determina cuantos objetos de cada tipo intervienen en la

relación, es decir, el número de instancias de una clase que se relacionan con UNA instancia

de otra clase ( Booch, 1999).

Para especificar la multiplicidad de una asociación hay que indicar la multiplicidad mínima y

la multiplicidad máxima.
 20

Ilustración 9Multiplicidad
Figura 9: Tipos de multiplicidad.

Cuando la multiplicidad mínima es 0, la relación es opcional. En cambio, una multiplicidad

mínima mayor o igual que 1 establece una relación obligatoria.

Ejemplos de multiplicidad:

Ilustración 10 Ejemplos de multiplicidad

Figura 10: Ejemplos de tipos de multiplicidad

 21

CAPÍTULO3.DISEÑO

En este capítulo se da a conocer la situación actual donde se encuentra información sobre

los requerimientos y opciones con las que cuenta nuestro programa. Descripción de cada una de

sus características y funcionalidades, además el diseño de la interfaz.

Presentando una solución innovadora y eficaz en el control de asistencia, lo que permitirá

De igual manera se realiza un análisis de varias metodologías (en cascada, espiral, modelo

en V), de las cuales se escogió la adecuada para el desarrollo del sistema de alarma para la

detección de somnolencia.

En el desarrollo del proyecto se cuenta con varias etapas como el propósito del sistema, el

ámbito del sistema, las partes que se benefician con el progreso de este proyecto, las características

de un registro académico y además los requerimientos que presenta este sistema.

Con los requerimientos ya establecidos se procede a la selección del hardware y del

software donde se escoge los elementos necesarios que ayuden a cumplir con las necesidades que

presenta el sistema de registro académico.

3.1 Situación Actual

Mediante investigaciones y obteniendo información sobre el sistema de asistencia que

ejerce los docentes a estudiantes de la facultad de ciencias aplicadas, se llegó a realizar un análisis
 22

por lo que se llegó a concluir que el sistema de registro de asistencia contiene algunos errores

causados por el usuario o por la estructura del sistema.

Igualmente podemos evidenciar que el sistema que hemos desarrollado en nuestro proyecto

funciona de manera eficaz y sencilla para el usuario que está usando el sistema. Esta investigación

nos va a ayudar a mejorar el diseño actual del sistema y contesta las inquietudes que existan frente

al desarrollo del proyecto, el fin de esto es respaldar el proceso que se realizará durante el proyecto.

De tal forma hemos llegado a crear un prototipo del registro académico de asistencia desarrollado

por el interfaz de NetBeans con lenguaje de programación Java.

Actualmente el sistema de asistencia que está funcionando en la facultad de ciencias

aplicadas se basa en un registro digital en donde el docente realiza en su portafolio institucional.

Para el uso del sistema debe cumplir algunos requisitos como; el docente debe tener conexión a

internet, debe tener un correo institucional debido que el sistema de registro debe enviar un código

para ingresar y finalmente el docente debe estar registrado en el horario respectivo.

Es por eso y varias razones es que vamos a realizar un prototipo que realice funciones

similares al registro actual que se tiene en la universidad lo cual va ayudar a reducir problemas con

el estudiante y el docente debido que el sistema puede presentarse algunos errores al momento de

tomar asistencia.

3.2 Metodología

La metodología para desarrollar el software se considera de una forma ordenada para el

funcionamiento y desarrollo del proyecto con la finalidad de poder realizar y tener en un tiempo
 23

cercano un éxito rotundo de nuestro proyecto. En el desarrollo de nuestro proyecto se dividirá en

fases llamadas etapas como las acciones que pertenece a cada una de ellas que van a ayudar a

normalizar la forma de cómo será desarrollando nuestro proyecto.

- Modelo Incremental o Iterativo y Creciente

el Modelo Incremental repite el modelo de cascada (permite interactuar inversamente a un

proceso secuencial. Esto quiere decir que en cada etapa se hace una o diferentes

observaciones para estar seguro de seguir con la siguiente etapa) una y otra vez, pero con

pequeñas modificaciones o actualizaciones que se le puedan ir agregando al sistema. De

este modo el usuario final se ve sumamente sumergido en el desarrollo y puedes

proporcionarle un resultado óptimo.

- Modelo en V

Es un modelo diseñado por Alan Davis, el cual consiste en las mismas etapas del anterior

modelo (cascada), pero a diferencia que en esta metodología se agregaron sub-etapas las

cuales cumplen el trabajo de retroalimentación entre etapas de análisis y mantenimiento.

- Metodología XP

Si hablamos de metodologías de la programación sin mencionar a la Metodología XP, es

como no hablar de nada en absoluto. Esta metodología es posiblemente la más destacada

de las metodologías ágiles y esto se debe a su gran capacidad de adaptación ante cualquier

tipo de imprevisto que surja. Pues la idea no es mantener ciertos requisitos desde que se

está elaborando el proyecto, sino que, durante el proceso, estos vayan cambiando o vayan

evolucionando gradualmente sin complicaciones. Básicamente los creadores de esta

metodología XP, consideran que es mejor adaptarse en el proceso a los requisitos que vayan

apareciendo, que iniciar con requisitos y desarrollar un proyecto en base a eso.

 24

3.3 Requerimientos

Como referencia para analizar los requerimientos del proyecto se consideró el estándar

ISO/IEC/IEEE 29148:2011, este estándar contiene disposiciones para los procesos concernientes

con la ingeniería tanto para sistemas, productos y servicios de software a lo largo del ciclo de vida.

Esta norma define cómo realizar un buen requisito, proporcionando atributos y características de

los requerimientos tomando en cuenta el uso de una aplicación reiterativa a lo largo del ciclo de

vida. Igualmente, el ISO/IEC/IEEE 29148:2011 facilita la orientación adicional para la aplicación

de los requisitos de ingeniería y procesos de gestión para diferentes actividades. (Ortiz &

Fernández, 2017)

La determinación de requerimientos tiene la función de relacionar a dos partes muy

importantes como son las necesidades del usuario con la solución que se obtiene mediante el

proceso del proyecto, con el propósito de conservar y establecer medidas que el dispositivo debe

cumplir. En el proceso de desarrollo del sistema se toma en consideración a los implicados o

también llamados Stakeholders, como se puede evidenciar en la Tabla 4.

Tabla 2 Lista de stakeholders

LISTA DE IMPLICADOS O STAKEHOLDERS

1. Estudiantes Programación Avanzada.

2. Universidad Técnica Del Norte

 25

3. Ing. Luis Suárez Docente de la Asignatura

Fuente: Autoría.

Se definen requerimientos tanto de stakeholders, sistema y arquitectura, los cuales aportan

a las necesidades del usuario y también establecen la funcionalidad de un sistema. Todo esto es

tomado en cuenta para poder realizar el proyecto y además resolver las necesidades que se ven

presentadas en el estudio elaborado.

3.4 Requerimientos de Stakeholders

La intención es determinar requerimientos de los interesados para un sistema que puede

facilitar servicios con los que un usuario no cuenta en un medio específico. A estos requisitos se

los estudia y se los convierten en un grupo común en el cual se presenta la interacción entre el

sistema con el medio operativo, definiendo como una observación donde se valida cada servicio

operativo resultante. A continuación, en la Tabla 5 se muestran los requisitos de los implicados o

stakeholders.

.
Tabla 3Requerimientos de los Stakeholders

StSR

REQUERIMEINTOS DE STAKEHOLDERS
 26

# REQUERIMEINTOS PRIORIDAD

Alta Media Baja

REQUERIEMINTOS OPERACIONALES

StSR 1 El programa debe ser sencillo y amigable con el usuario.

StSR 2 Deber tener un interfaz agradable para los usuarios

StSR 3 El sistema debe contar con una opción para seleccionar las

materias a las cuales asiste.

StSR 1 El programa deber permanecer activo hasta el cierre manual.

REQUERIEMINTOS DE USUARIOS

StSR 2 No convendría que el usuario pueda modificar algún apartado

del programa.

StSR 1 El programa debe mostrar los datos necesarios.

StSR 1 El programa cumplirá su cometido siempre y cuando los

alumnos lo usen de manera responsable.

StSR 2 Debe contar con un indicador de fecha.

Fuente: Autoría.
 27

3.5 Listado de Clases:

A continuación, se detalla el listado de las clases del diagrama de clases:

Clase1: Universidad. Clase 13: Aulas.

Clase 2: Carrera. Clase 14: Talleres

Clase 3: Periodo Académico. Clase 15: Laboratorios

Clase 4. Matricula

Clase 5. Estudiante.

Clase 6: Asignaturas.

Clase 7: Horario

Clase 8: Docente.

Clase 9: Registro.

Clase 10: Asiste

Clase 11: No Asiste.

Clase 12: Distributivo de Aulas.

 28

3.6 Diagrama de Clases

El diagrama de clases fue diseñado pensado en las diferentes opciones que tendrá nuestro

proyecto:

Ilustración 11 diagrama del proyecto

Ya determinados los requerimientos del proyecto, se puede elegir el tipo interfaz s=que

demanda el sistema. Es por esto que se pensó en una serie de 2 ventanas emergentes a través de

las cuales interactúa el usuario.

 29

3.7 Diseño del Sistema

Con la información encontrada y clara en los anteriores capítulos se realizó la investigación

que permitió determinar la orientación correcta para acceder a la realización del diseño de nuestro

sistema. Posteriormente vamos a dar detalles sobre las pautas que hemos utilizado para el

desarrollo de nuestro sistema que es el registro de asistencia.

● El sistema funciona para el registro de estudiantes y docentes de la facultad de ciencias

aplicadas, se llegó la idea de elaborar un sistema debido que hay problemas en el

funcionamiento del registro de asistencia que se usa en la universidad lo que conlleva a

crear malas relaciones entre estudiantes y docentes debido a ese problema.

● El gran objetivo de nuestro proyecto es de dar seguridad en el proceso del registro de

asistencia para los estudiantes y docentes para la facultad de ciencias aplicadas.

● En nuestro diseño hay que detallar las limitaciones que probablemente se presente de los

usuarios que van a utilizar nuestro sistema, por esta razón vamos a elaborar un análisis de

la ubicación conveniente del sistema para que este pueda acondicionarse a las diferentes

necesidades del usuario.

Lo fundamental en nuestro diseño es una muestra del diagrama de bloques y a su vez el

diagrama de flujo, con el propósito de guiar el funcionamiento y los procesos para lograr

correctamente el funcionamiento de nuestro sistema.

 30

3.8 Diagrama de Bloques

En este apartado se muestra el diagrama que contiene las etapas realizadas en el diseño,

está conformado por cinco bloques en donde estos se forman por diferentes subprocesos, se ha

determinado cada bloque en base a su cometido que cada uno de ellos debe realizar.

Detección y procesamiento del carnet estudiantil

Ilustración 12 Diagrama de bloques del sistema

Fuente: Autoría.

Como inicio en el bloque 1 se realiza la iniciación del sistema permitiendo al usuario

introducir su credencial para el debido control, Ya en el bloque 2 el programa imprimirá en pantalla

la gestión del usuario ingresado con su debida hora y fecha actualizada.

Con el análisis realizado en el bloque 1 y 2 se obtiene datos que permiten al bloque 3 hacer

un proceso donde se estudia los aspectos del estudiante y horario de clases, con la finalidad de

poder determinar si el individuo ingresa a clases y si asiste a todas sus horas respectivas. Como

punto final en el Bloque 4 finalmente el análisis de los datos obtenidos se los podrá realizar

mediante un registro de eventos los cuales se almacenaran en una base de datos.

 31

CAPÍTULO 4. PRUEBAS Y RESULTADOS

REFERENCIAS

Becker, V. y Pons, C. (2003). DEFINICION FORMAL DE LA SEMANTICA DE UML-OCL A

TRAVES DE SU TRADUCCION A OBJECT-Z. RedUNCI ,13(2),984.
Booch, G, Rumbaugh, J. y Jacobson, I. (2015). El lenguaje unificado de modelado.
Barcelona, España: Ediciones Berzal
Boach, G. (1999). Especificación de sistemas software en UML. Buenos Aires,Argentina:
Ediciones Prentice.
Cabot, J. (2003). La relación de materialización en UML. Universidad Politécnica de Catalunya,
Barcelona, España.
Gómez, C., Mayol, E., Olivé, A. y Teniente, E. (2003). Diseño de Sistemas software en UML.
Barcelona,España:Edicions UPC.
Debrauwer, L y Van der Heyde, F. (2016). UML 2.5: iniciación, ejemplos y ejercicios corregidos.
Cornellaá de Llobregat,Barcelona: Ediciones Software.
Marín, B, Giachetti, G y Pastor, O. (2007). Intercambio de modelos UML y OO-Method.
Universidad Politécnica de Valencia, Valencia, España
Sparks, G. (2007). Una Introducción al UML . Sparx Systems.10(1), 4-5.
Laurent, D y Fien, V. (2016). UML 2.5: iniciación, ejemplos y ejercicios corregidos.
Barcelona,España: Ediciones Software.
Martín, H. (2004). El lenguaje unificado en modelos desarrollados en software. Universidad
Nacional San Marcos, San Marcos, Argentina
Ortiz, J y Fernández, M. (2017). Fuentes Utilizadas por desarrolladores de
Software.Barcelona,España: Ediciones Fibertel.
 32

Pérez, F. (2012). Desarrollo de software orientado a objetos. Universidad Politécnica de Valencia,

Valencia, España
Schmuller, D. (1999). Patrones UML. Buenos Aires,Argentina: Ediciones Prentice.