Avance Proyecto.docx

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 4.- Asociación Unidireccional Ilustración 4 asociaciones 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”.

5.Ilustración 5 ejemplo deFigura 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

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.

Media Baja

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 Software.Barcelona,España: Ediciones Fibertel.

por

desarrolladores

de

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.