Aplicación para la gestión de aforos en las universidades: Resuniversita

APLICACIÓN PARA LA GESTIÓN DE AFOROS EN LAS UNIVERSIDADES: RESUNIVERSITAS APPLICATION FOR MANAGING CAPACITY IN UNIVERSITIES: RESUNIVERSITAS JOSÉ MIGUEL CABRERA LLAMAS VÍCTOR CHOZA MERINO ÁLVARO PENALVA ALBERCA PEDRO SÁNCHEZ ESCRIBANO GRADO EN INGENIERÍA DE SOFTWARE E INFORMÁTICA FACULTAD DE INFORMÁTICA UNIVERSIDAD COMPLUTENSE DE MADRID TRABAJO DE FIN DE GRADO CURSO 2021-2022 DIRECTOR ANTONIO SARASA CABEZUELO FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 2 de 196 Agradecimientos Este trabajo es el resultado de varios meses de esfuerzo y aprendizaje. En especial, agradecer a nuestras familias y amigos, que nos han brindado su apoyo durante este camino universitario. FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 3 de 196 Resumen En este proyecto se recoge el diseño, la especificación y la implementación tanto de una solución Android como de una solución web de valor añadido. En el presente trabajo se desarrolla un software que facilita la gestión de aforos en universidades ofreciendo funcionalidades como reservar un asiento en una determinada aula o comprobar la disponibilidad de los espacios de las facultades que conforman las universidades. También, a nivel de administrador, se permite modificar cualquier aspecto de las salas y las facultades, gestionar las plazas de las instalaciones de la universidad y crear eventos y noticias para los usuarios de estas. La extracción de una parte de los datos usados en la aplicación proviene de las páginas oficiales de las entidades universitarias. Entre estos datos se encuentra información como la dirección, correo, descripción e imágenes. Los datos restantes han sido generados de manera intuitiva. PALABRAS CLAVE Universidad, facultad, ocupación, reservar, Android, Angular, Firebase FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 4 de 196 Abstract This project includes the design, specification and implementation of both, an Android solution, and a web solution, both of which have added value. In the present work a software is developed that facilitates the management of capacity in universities offering functionalities such as reserve a seat in a certain classroom or check the availability of the spaces of the faculties. Also, at the administrator level, it is allowed to modify any aspect of the rooms and the faculties, manage the sites of the university facilities, and create events and news for the users of these. The extraction of a part of the data used in the application comes from the official websites of the university entities. Among this data is information such as address, mail, description, and images. The remaining data has been generated intuitively. KEYWORDS University, faculty, occupation, reserve, Android, Angular, Firebase FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 5 de 196 Índice Capítulo 1. Introducción ......................................................................................... 16 1.1. Motivación .................................................................................................................. 16 1.2. Objetivos .................................................................................................................... 17 1.3. Estructura de la memoria ......................................................................................... 17 1.4. Plan de trabajo .......................................................................................................... 18 Chapter 1. Introduction ........................................................................................... 21 1.1. Motivation .................................................................................................................. 21 1.2. Objectives .................................................................................................................. 22 1.3. Memory structure ...................................................................................................... 22 1.4. Work planning ........................................................................................................... 23 Capítulo 2. Estado del arte ..................................................................................... 26 2.1. Aplicaciones similares ............................................................................................. 26 2.1.1. Kalena ................................................................................................................................ 26 2.1.2. Affluences .......................................................................................................................... 27 2.1.3. Tenea-Talent ..................................................................................................................... 28 2.1.3. Hybo................................................................................................................................... 28 Capítulo 3. Tecnología utilizada ............................................................................ 30 3.1. Herramientas de desarrollo ..................................................................................... 30 3.1.1. Android Studio ................................................................................................................... 30 3.1.2. Visual Studio Code ............................................................................................................ 30 3.2. Lenguajes de programación .................................................................................... 30 3.2.1. Kotlin .................................................................................................................................. 30 3.2.2. TypeScript .......................................................................................................................... 31 3.2.3. HTML5 ............................................................................................................................... 31 3.2.4. CSS .................................................................................................................................... 31 3.3. Frameworks ............................................................................................................... 31 3.3.1. Angular............................................................................................................................... 31 3.4. Base de datos, repositorio y hosting ..................................................................... 32 3.4.1. Firebase ............................................................................................................................. 32 3.5. Control de versiones ................................................................................................ 32 3.5.1. Git ...................................................................................................................................... 32 3.5.2. GitHub ................................................................................................................................ 33 3.6. Varios.......................................................................................................................... 33 3.6.1. Código QR ......................................................................................................................... 33 3.6.2. GPS ................................................................................................................................... 33 FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 6 de 196 3.6.3. Google Forms .................................................................................................................... 33 Capítulo 4. Especificación de requisitos .............................................................. 34 4.1. Actores del sistema .................................................................................................. 34 4.1.1. Usuario no registrado ........................................................................................................ 34 4.1.2. Usuario registrado ............................................................................................................. 34 4.1.3. Administrador ..................................................................................................................... 34 4.2. Diagrama de casos de uso ...................................................................................... 35 4.2.1. Usuario no registrado ........................................................................................................ 35 4.2.2. Usuario registrado ............................................................................................................. 36 4.2.3. Administrador ..................................................................................................................... 37 4.3. Casos de uso ............................................................................................................. 37 4.3.1. Casos de uso de usuario no registrado ............................................................................. 38 4.3.2. Casos de uso de usuario registrado .................................................................................. 51 4.3.3. Casos de uso de usuario administrador ............................................................................ 68 Capítulo 5. Arquitectura .......................................................................................... 88 5.1. Arquitectura del sistema .......................................................................................... 88 5.2. Patrones de diseño y arquitectónicos Android .................................................... 89 5.2.1. MVVM (Mode-View-ViewModel)........................................................................................ 89 5.2.2. Singleton ............................................................................................................................ 89 5.2.3. Kotin DataClass ................................................................................................................. 89 5.2.4. Kotin StateFlow .................................................................................................................. 90 5.2.5. Kotlin SharedFlow.............................................................................................................. 90 5.2.6. Observer ............................................................................................................................ 90 5.2.7. Data Binding ...................................................................................................................... 91 5.2.8. Corrutinas de Kotlin ........................................................................................................... 91 5.2.9. SavedStateHandle ............................................................................................................. 91 5.3. Patrones de diseño y arquitectónicos web ........................................................... 92 5.3.1. Model-View-ViewModel (MVVM) ....................................................................................... 92 5.3.2. Observer ............................................................................................................................ 92 5.3.2. Facade ............................................................................................................................... 92 5.3.3. Proxy .................................................................................................................................. 92 5.3.4. Data Binding ...................................................................................................................... 93 5.4. Modelo de repositorio de documentos .................................................................. 93 5.5. Modelo de base de datos NoSQL ............................................................................ 94 5.5.1. Tabla sobre universidades ................................................................................................ 96 5.5.2. Tabla sobre facultades ...................................................................................................... 96 5.5.3. Tabla sobre salas .............................................................................................................. 96 5.5.4. Tabla sobre eventos y noticias .......................................................................................... 97 5.5.5. Tabla sobre usuarios ......................................................................................................... 97 5.5.6. Tabla sobre reservas ......................................................................................................... 98 5.5.7. Tabla sobre ocupación ...................................................................................................... 98 FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 7 de 196 Capítulo 6. Diseño e implementación ................................................................... 99 6.1. Diseño Android ......................................................................................................... 99 6.1.1. Colores............................................................................................................................... 99 6.1.2. Temas .............................................................................................................................. 100 6.1.3. Splash Screen ................................................................................................................. 101 6.2. Diseño Web .............................................................................................................. 102 6.2.1. Diseño .............................................................................................................................. 102 6.2.2. Bootstrap.......................................................................................................................... 104 6.2.3. Angular 13 ....................................................................................................................... 105 6.2.4. Fuente .............................................................................................................................. 108 6.3. Funcionalidad de la aplicación Android .............................................................. 109 6.3.1. Inicio de sesión y registro de usuario .............................................................................. 109 6.3.2. Listados de facultades, salas y reservas ......................................................................... 111 6.3.3. Reserva de sitios ............................................................................................................. 115 6.3.4. Creación y actualización de facultades, salas y eventos o noticias................................ 123 6.4. Funcionalidad de la aplicación web ..................................................................... 127 6.4.1. Pantalla de Bienvenida .................................................................................................... 127 6.4.2. Inicio de sesión ................................................................................................................ 129 6.4.3. Listado de facultades ....................................................................................................... 131 6.4.4. Crear facultad .................................................................................................................. 136 6.4.5. Modificar facultad............................................................................................................. 140 Capítulo 7. Evaluación de usabilidad.................................................................. 144 7.1. Metodología ............................................................................................................. 144 7.2. Resultados ............................................................................................................... 144 7.2.1. Registro en la aplicación ................................................................................................. 145 7.2.2. Escáner QR ..................................................................................................................... 146 7.2.3. Creación de mapas.......................................................................................................... 147 7.2.4. Uso de botones con texto y/o icono ................................................................................ 149 Capítulo 8. Conclusiones y trabajo futuro ......................................................... 151 8.1. Conclusiones ........................................................................................................... 151 8.2. Trabajo a futuro ....................................................................................................... 153 Chapter 8. Conclusions and future work ............................................................ 156 8.1. Conclusions ............................................................................................................. 156 8.2. Future work .............................................................................................................. 158 Capítulo 9. Aportaciones Individuales ................................................................ 160 9.1. José Miguel Cabrera Llamas ................................................................................. 160 9.2. Víctor Choza Merino ............................................................................................... 160 9.3. Álvaro Penalva Alberca .......................................................................................... 161 FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 8 de 196 9.4. Pedro Sánchez Escribano ...................................................................................... 161 Bibliografía ............................................................................................................. 162 ANEXO I. Guía de Usuario .................................................................................... 166 I.I. Aplicación Android ................................................................................................... 166 I.I.I. Vista de inicio de sesión o registro ..................................................................................... 166 I.I.II. Vista de facultades ............................................................................................................ 166 I.I.III. Vista de salas facultad ...................................................................................................... 167 I.I.IV. Vista del tablón de anuncios ............................................................................................ 168 I.I.V. Vista de información de facultad ....................................................................................... 169 I.I.VI. Vista de información de sala ............................................................................................ 169 I.I.VII. Vista de creación/edición de facultad ............................................................................. 171 I.I.VIII. Vistas de creación/edición de sala ................................................................................. 173 I.I.IX. Vista de creación/edición de evento o noticia .................................................................. 174 I.I.X. Proceso de bloqueo de sala .............................................................................................. 175 I.I.XI. Vistas de reserva de sitio ................................................................................................. 177 I.I.XII. Proceso de check-in y check-out .................................................................................... 177 I.I.XIII. Vista de Ajustes.............................................................................................................. 179 I.I.XIV. Vista de reservas ........................................................................................................... 180 I.I.XV. Proceso de descarga del documento PDF de facultad .................................................. 181 I.I.XVI. Proceso de descarga del documento PDF de sala ....................................................... 183 I.I.XVII. Proceso de descarga del documento PDF de evento o noticia ................................... 184 I.II Aplicación web .......................................................................................................... 186 I.II.I. Vista de inicio de sesión .................................................................................................... 186 I.II.II. Vista de facultades ........................................................................................................... 187 I.II.III. Vista de creación/edición de facultad .............................................................................. 188 I.II.IV. Vista de información del proyecto web ........................................................................... 189 ANEXO II. Preguntas de la evaluación ................................................................ 191 II.I. Preguntas sobre las funcionalidades disponibles para usuarios no registrado .......................................................................................................................................... 191 II.II. Preguntas sobre las funcionalidades disponibles para usuarios registrados193 II.III. Preguntas sobre las funcionalidades disponibles para administradores ...... 195 FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 9 de 196 Índice de figuras Figura 1 - Diagrama de Gantt: planificación genérica........................................................... 18 Figura 2 - Diagrama de Gantt: Aplicación Android 1 ............................................................ 19 Figura 3 - Diagrama de Gantt: Aplicación Android 2 ............................................................ 19 Figura 4 - Diagrama de Gantt: Aplicación web 1 .................................................................. 19 Figura 5 - Diagrama de Gantt: Aplicación web 2 .................................................................. 20 Figura 6 - Diagrama de Gantt: Documentación 1 ................................................................. 20 Figura 7 - Diagrama de Gantt: Documentación 2 ................................................................. 20 Figura 8 - Aplicación Kalena .................................................................................................. 27 Figura 9 - Aplicación Affluences ............................................................................................ 28 Figura 10 - Página web de Hybo ........................................................................................... 29 Figura 11 - Diagrama de CU de usuario no registrado ......................................................... 35 Figura 12 - Diagrama de CU de usuario registrado .............................................................. 36 Figura 13 - Diagrama de CU de usuario administrador ........................................................ 37 Figura 14 - Diagrama de arquitectura ................................................................................... 88 Figura 15 - Patrón Singleton .................................................................................................. 89 Figura 16 - Patrón Kotlin DataClass ...................................................................................... 90 Figura 17 - Patrón Kotlin StateFlow ...................................................................................... 90 Figura 18 - Patrón Kotlin SharedFlow ................................................................................... 90 Figura 19 - Patrón Observer .................................................................................................. 91 Figura 20 - Patrón SavedStateHandle 1 ............................................................................... 91 Figura 21 - Patrón SavedStateHandle 2 ............................................................................... 91 Figura 22 - Patrón Observer .................................................................................................. 92 Figura 23 - Patrón Proxy 1..................................................................................................... 93 Figura 24 - Patrón Proxy 2..................................................................................................... 93 Figura 25 - Patrón Proxy 3..................................................................................................... 93 Figura 26 - Firestore Database: Colección de usuarios........................................................ 95 Figura 27 - Diseño Android: Material Theme Builder ............................................................ 99 Figura 28 - Diseño Android: Dynamic Colors ...................................................................... 100 Figura 29 - Diseño Android: Temas con diferentes versiones ............................................ 101 Figura 30 - Diseño Android: Temas versión por defecto .................................................... 101 Figura 31 - Diseño Android: Splash Screen ........................................................................ 102 Figura 32 - Diseño web: Diseño, CSS ................................................................................. 103 Figura 33 - Diseño web: Diseño pantalla listado de facultades .......................................... 103 Figura 34 - Diseño web: Bootstrap, utilización .................................................................... 104 Figura 35 - Diseño web: Bootstrap, utilización en elementos HTML .................................. 105 Figura 36 - Diseño web: Bootstrap, menú de navegación .................................................. 105 Figura 37 - Diseño web: Angular 13, estructura de proyecto ............................................. 106 Figura 38 - Diseño web: Angular 13, directiva *ngFor ........................................................ 107 Figura 39 - Diseño web: Angular 13, variantes data binding .............................................. 108 Figura 40 - Diseño web: Fuente, CSS ................................................................................. 108 Figura 41 - Funcionalidades Android: Vista de inicio de sesión o registro ......................... 109 Figura 42 - Funcionalidades Android: Función onClickValidateLogin de StartViewModel 110 FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 16 de 196 Capítulo 1. Introducción En este capítulo se realizará un breve resumen de lo que es ResUniversitas, se comentará cuáles han sido las motivaciones que han llevado a su desarrollo, y se explicarán los objetivos a alcanzar en el desarrollo del trabajo. En definitiva, esté capítulo pretende poner en contexto al lector y situarlo dentro del tema que será tratado en esta memoria. 1.1. Motivación Las consecuencias de la pandemia COVID-19 han sido nefastas a nivel mundial. En los tres últimos años la población se ha visto obligada a cambiar la forma de relacionarse, y empresas, comercios y universidades entre otras instituciones han tenido que adaptarse a las nuevas normativas establecidas para reducir el contagio del virus. Debido a la crisis epidemiológica que ha provocado el virus COVID-19, y en consonancia con sus numerosas variantes, se ha producido una revolución en la forma de las reuniones presenciales, sobre todo, en lugares públicos como es el Campus Universitario. En concreto, la medida sanitaria del aforo de personas ha dado lugar a la creación de una necesidad concreta como es el control y la limitación de la capacidad del aforo. Por otro lado, dejando atrás la situación actual de pandemia, y en consonancia con la experiencia adquirida durante el periodo universitario, se observó que los servicios de gestión de espacios en la universidad no disponen de información al alcance de todos referente a la ocupación, así como no cuentan con un servicio de reserva en dichos espacios. Además, la información de los distintos eventos y conferencias que tienen lugar en las facultades no se muestran de manera sencilla, unificada e intuitiva. En consonancia con esta situación y para solventar estas limitaciones, en este trabajo se ha propuesto el desarrollo de una aplicación móvil y web en la que, de forma ordenada y planificada, y respetando las medidas que en cada momento sean instauradas, se pueda hacer uso de las instalaciones que la universidad pone a disposición de todos los usuarios. En esta aplicación se permite visualizar la información referente a la ocupación, así como, la reserva de un determinado asiento mediante vista de plano, dando una solución al problema anteriormente planteado. También resulta útil la reserva de un asiento para una determinada clase o evento, de modo que, si el estudiante sabe que va a llegar con retraso a su clase, pueda reservar un asiento de antemano, o consultar las estadísticas de ocupación para el periodo de tiempo que ocupa su asignatura. FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 17 de 196 1.2. Objetivos El objetivo principal de este trabajo es la implementación de una aplicación Android que permite a sus usuarios reservar un asiento en una determinada aula o comprobar la disponibilidad de los espacios cerrados (a partir de ahora se denominan salas para generalizar, ya que pueden incluir aulas, laboratorios, cafeterías, etc.), así como gestionar las plazas de las instalaciones de la universidad y mostrar eventos y noticias a los usuarios. Aparte de la aplicación Android, ResUniversitas también está formado por una aplicación web que recogerá únicamente la gestión de las instalaciones, la cual al igual que en la aplicación Android permite a un usuario acreditado como administrador crear y modificar facultades, salas y noticias o eventos... A continuación, se detallan los objetivos específicos: ● Desarrollo de un módulo que disponga de una visualización de la información correspondiente al aforo de las salas de las universidades. ● Implantación de un módulo específico para usuarios donde se les permite gestionar reservas de asientos y consultar el aforo de las salas. ● Puesta en marcha de un módulo dedicado a la gestión de las instalaciones de las universidades, al cual sólo tendrán acceso los usuarios administradores. ● Diseño e implementación de una página web de apoyo a la aplicación Android que permita realizar las gestiones necesarias a los usuarios administradores de los edificios o zonas. ● Tanto la aplicación de Android como la página web compartirán la misma base de datos y repositorio de almacenamiento. 1.3. Estructura de la memoria En este apartado, se describen brevemente los capítulos que forman parte de la estructura de la memoria: Capítulo 1: En este capítulo se describe la motivación del trabajo, los objetivos a conseguir, la estructura de la memoria y el plan de trabajo. Capítulo 2: En este capítulo se detallan soluciones similares a la que se ha realizado en el trabajo. Capítulo 3: En este capítulo se describe la tecnología utilizada en el desarrollo del proyecto. FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 18 de 196 Capítulo 4: En este capítulo se detallan los actores y se especifican los casos de uso (CU) junto a su descripción. Capítulo 5: En este capítulo se detalla la arquitectura y los patrones utilizados en la aplicación Android, así como en la aplicación web. Además, se describen los modelos utilizados en la base de datos y en el repositorio. Capítulo 6: En este capítulo se describen los aspectos principales de la funcionalidad y el diseño en la aplicación Android, así como en la aplicación web. Capítulo 7: En este capítulo se detalla la encuesta de usabilidad y se analizan los resultados obtenidos en dicha encuesta con usuarios reales. Capítulo 8: En este capítulo se realiza una conclusión y se describen brevemente los futuros casos de uso. Capítulo 9: En este capítulo se desarrollan las tareas que han llevado a cabo los miembros del equipo. Bibliografía Anexo I: Guía de Usuario Anexo II: Preguntas de la evaluación 1.4. Plan de trabajo En este apartado se va a realizar un resumen con ayuda de un diagrama de Gantt representado en las Figuras 1, 2, 3, 4, 5, 6 y 7, en él se expondrá el desarrollo del proyecto a lo largo del tiempo, dividiéndose la carga de trabajo en tres bloques principales: aplicación Android, aplicación web y documentación. Es importante señalar que, al estar formado el proyecto por cuatro miembros, se ha trabajado paralelamente en la aplicación Android, la aplicación web y en la documentación. Inicialmente, se realizó una reunión para determinar y aclarar el objeto de este proyecto como se muestra en la Figura 1. En esta misma figura también se refleja la siguiente reunión en la que se tomaron los requisitos de usuario dando lugar a los casos de uso para comenzar posteriormente el desarrollo de los objetivos. Figura 1 - Diagrama de Gantt: planificación genérica En las Figuras 2 y 3 se reflejan todas las tareas que se han acometido en el desarrollo de la aplicación Android. Se puede ver como este desarrollo es el que más tiempo ha ocupado, FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 19 de 196 yendo desde el mes de octubre de 2021 al mes de abril de 2022 prácticamente sin periodos vacíos. Figura 2 - Diagrama de Gantt: Aplicación Android 1 Figura 3 - Diagrama de Gantt: Aplicación Android 2 A continuación, en las Figuras 4 y 5 se muestran las tareas realizadas en el desarrollo de la aplicación web. En este caso los desarrollos más importantes se dieron a lo largo de noviembre, diciembre y enero, para luego culminar los trabajos en el mes de abril. Figura 4 - Diagrama de Gantt: Aplicación web 1 FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 20 de 196 Figura 5 - Diagrama de Gantt: Aplicación web 2 Finalmente, en las Figuras 6 y 7, se recogen las tareas que constituyen la fase de documentación del proyecto y hacen referencia a la elaboración del contenido de esta memoria. Como se puede ver, lo primero que se llevó a cabo fue la elaboración de una introducción y los casos de uso necesarios para el desarrollo de las aplicaciones. Después se retomaron el resto de las partes de la memoria una vez las aplicaciones estaban prácticamente completadas. Figura 6 - Diagrama de Gantt: Documentación 1 Figura 7 - Diagrama de Gantt: Documentación 2 FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 21 de 196 Chapter 1. Introduction In this chapter, a brief summary of what ResUniversitas is will be made, the motivations that have led to its development will be discussed, and the objectives to be achieved in the development of the work will be explained. In short, this section is intended to put the reader in context and place them within the topic that will be covered in this part of the project. 1.1. Motivation The consequences of the COVID-19 pandemic have been disastrous worldwide. In the last three years, the population has been forced to change the way they interact, and companies, businesses, and universities, among other institutions, have had to adapt to the new regulations established to reduce the spread of the virus. Due to the epidemiological crisis caused by the COVID-19 virus, and in line with its numerous variants, there has been a revolution in the form of face-to-face meetings, especially in public places such as the University Campus. Specifically, the sanitary measure of the capacity of people has given rise to the creation of a specific need such as the control and limitation of the capacity of the capacity. On the other hand, and leaving behind the current pandemic situation, and in line with the experience acquired during the university period, it was observed that space management services at the university do not have information available to everyone regarding occupancy, just as they do not have a reservation service in those spaces. In addition, the information of the different events and conferences that take place in the faculties is not shown in a simple, unified, and intuitive way. On the other hand, leaving behind the current pandemic situation, and in line with the experience acquired during the university period, it was seen that space management services at the university do not have information available to everyone regarding occupation, as well as they do not have a reservation service in these spaces. In addition, the information of the different events and conferences that take place in the faculties are not shown in a simple, unified, and intuitive way. Following this situation and to solve these limitations, in this project the development of a mobile and web application has been proposed in which, in an orderly and planned manner, and respecting the measures that are established at any time, users can use the facilities that the university makes available. FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 22 de 196 In this application it is possible to visualize the information referring to the occupation, as well as the reservation of a certain seat through plan view, giving a solution to the problem previously raised. It is also useful to reserve a seat for a certain class or event, so that if the student knows that they are going to be late for their class, they can reserve a seat in advance and check the occupancy statistics for the duration of the class. 1.2. Objectives The main objective of this project is the implementation of an Android app that allows its users to reserve a seat in a certain classroom or check the availability of enclosed spaces (from now on they will be called rooms, since there might be classrooms, labs, canteens, etc.), as well as manage the places of the facilities of the university and show events and news to users. It is also useful to reserve a seat for a certain class or event, so that if the student knows that they will be late for their class, they can reserve a seat in advance, or check the occupancy statistics for the time of the subject. The specific goals are detailed below: ● Development of a module that has a visualization of the information corresponding to the capacity of the rooms of the universities. ● Establishment of a specific module for users where they are allowed to manage seat reservations and consult the capacity of the rooms. ● The launch of a module dedicated to the management of university facilities, to which only administrative users will have access. ● Design and implementation of a web page to support the android application that allows the necessary procedures to be conducted by the administrator users of buildings or areas. ● The android app and the web app will share the same database and storage repository. 1.3. Memory structure The chapters that are part of the structure of the document are now briefly described: FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 23 de 196 Chapter 1: This chapter describes the motivation of the work, the objectives to be achieved, the structure of the document and work planning. Chapter 2: This chapter details solutions like the one that has been made in the project. Chapter 3: This chapter describes the technology used in the development of the project. Chapter 4: This chapter details the actors and specifies the use cases along with their description. Chapter 5: This chapter details the architecture and patterns used in the Android application as well as in the web application. In addition, describes the models used in the database and repository. Chapter 6: This chapter describes the main aspects of functionality and design in the Android application as well as in the web application. Chapter 7: This chapter details the usability survey and analyzes the results obtained in this survey with real users. Chapter 8: This chapter makes a conclusion and briefly describes future use cases. Chapter 9: This chapter develops the tasks that the team members have conducted. Bibliography Annex I: User guide Annex II: Evaluation questions 1.4. Work planning In this section a summary will be made with the help of a Gantt diagram represented in Figures 1, 2, 3, 4, 5, 6 and 7, in it the development of the project will be exposed over time, dividing the workload in three main blocks: Android application, web application and documentation. It is important to point out that, since the project is made up of four members, work has been done in parallel on the Android application, the web application, and the documentation. Initially, a meeting was held to determine and clarify the purpose of this project as shown in Figure 1. This same figure also reflects the following meeting in which the user requirements were taken, giving rise to the use cases to subsequently begin the development of the objectives. FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 24 de 196 Figura 1 - Diagrama de Gantt: planificación genérica Figures 2 and 3 show all the tasks that have been undertaken in the development of the Android application. Figura 2 - Diagrama de Gantt: Aplicación Android 1 Figura 3 - Diagrama de Gantt: Aplicación Android 2 Next, Figures 4 and 5 show the tasks performed in the development of the web application. Figura 4 - Diagrama de Gantt: Aplicación web 1 FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 25 de 196 Figura 5 - Diagrama de Gantt: Aplicación web 2 Finally, in Figures 6 and 7, the tasks that constitute the documentation phase of the project are collected and refer to the elaboration of the content of this memory. Figura 6 - Diagrama de Gantt: Documentación 1 Figura 7 - Diagrama de Gantt: Documentación 2 FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 32 de 196 Entre sus características se puede destacar que trabaja con el modelo SPA (Single Page Application) generando una aplicación web donde todas las vistas se muestran en la misma página, sin recargar el navegador y la página. Así pues, una división de código en componentes dispone de un renderizado instantáneo con Node.js, siendo un intérprete de comandos que facilita la creación de elementos mediante plantillas. 3.4. Base de datos, repositorio y hosting 3.4.1. Firebase Firebase ([19]): Es una plataforma almacenada en la nube que mantiene Google en la que se incluyen distintas herramientas para el desarrollo de aplicaciones móviles y web en una SDK o conjunto de herramientas. En este SDK se incluyen distintas librerías para facilitar la implementación en diferentes plataformas. Además, Firebase proporciona al usuario la documentación suficiente para comprender todas las funcionalidades que ofrece. En este proyecto, los servicios que se han utilizado son los siguientes: ● Firebase Auth ([20]): Es un servicio que provee una gestión de usuarios y un proceso de autenticación a través de un sistema con distintas formas de validación e implementación, como puede ser el uso de proveedores de inicio de sesión externos. ● Cloud Firestore ([21]): Es una base de datos NoSql a la que se facilita su conexión y actualización del contenido en tiempo real entre distintos sistemas. Dispone de un procedimiento en el que se utiliza la caché para realizar actualizaciones en caso de producirse un error de conexión. ● Cloud Storage ([22]): Es un servicio que proporciona almacenamiento de archivos mediante procesos de carga y descarga seguros incluyendo la seguridad de Google junto con la autenticación de la aplicación en su implementación. ● Firebase Hosting ([23]): Es un servicio que provee alojamiento de sitios web con conexiones seguras (SSL), sirviendo contenido dinámico y estático. Actualmente, también permite almacenar microservicios. En este SDK se incluyen distintas librerías y versiones del conjunto de herramientas para facilitar la implementación y configuración en distintas plataformas. Además, Firebase proporciona al usuario la documentación suficiente para comprender todas las funcionalidades que ofrece. 3.5. Control de versiones 3.5.1. Git Git ([24]): Git es un sistema de control de versiones distribuido. Esto significa que un clon local del proyecto es un repositorio de control de versiones completo. Estos repositorios FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 33 de 196 locales plenamente funcionales permiten trabajar sin conexión o de forma remota fácilmente. Los desarrolladores confirman su trabajo localmente y, a continuación, sincronizan su copia del repositorio con la copia en el servidor. 3.5.2. GitHub GitHub ([25]): Es un repositorio de desarrollo colaborativo de código mediante un control de versiones que es propiedad de Microsoft. La mayoría de los proyectos almacenados están de manera pública. 3.6. Varios 3.6.1. Código QR Código QR ([26]): Es una matriz de puntos o un código de barras bidimensional en la que se encuentra información. Su predecesor es el código de barras. Al igual que estos últimos, tiene que escanearse, en este caso desde un lector de códigos QR instalado en un dispositivo móvil o Smartphone. 3.6.2. GPS GPS ([27]): Con sus siglas procedentes de sistema de posicionamiento global, este consiste en el establecimiento de conexión de un receptor con como mínimo cuatro satélites de este sistema para recibir una señal de ellos y comprobará la hora de emisión de la señal con su hora del sistema para así conocer la distancia aproximada y poder estimar la ubicación en la que se encuentra mediante el método de trilateración inversa ([28]). El método nombrado anteriormente consiste en el uso de la distancia al satélite para saber que radio alrededor del satélite se debe tener en cuenta para conocer la posición del receptor, al combinarse la señal de varios satélites, el receptor debe encontrarse en la intersección de todos esos radios. 3.6.3. Google Forms Google Forms ([29]): Es una aplicación web desarrollada por Google que permite la creación y edición de encuestas. Además, se puede consultar el resultado de las encuestas y descargar un informe de estos. FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 34 de 196 Capítulo 4. Especificación de requisitos El sistema consta de una aplicación web utilizada para la gestión administrativa y una aplicación Android para el usuario. A continuación, se describen tanto las características de los usuarios futuros del sistema como los servicios definidos para el desarrollo de la aplicación Android, la aplicación web y los actores del sistema. 4.1. Actores del sistema Se distinguen tres tipos de actores que interactúan con el sistema para realizar los diferentes casos de uso: 4.1.1. Usuario no registrado Acceden a la aplicación Android sin identificarse y tienen acceso a las funciones básicas: ● Información sobre salas y facultades: Ocupación en tiempo real, estadísticas de ocupación, eventos y noticias, información de contacto de los espacios. No tienen acceso a las funciones de la aplicación relacionadas con la reserva de sitios ni la posibilidad de realizar check-in y check-out en los sitios de las salas. Los usuarios no registrados tienen la opción de registrarse o identificarse como usuario registrado en el caso de disponer de una cuenta (iniciar sesión). 4.1.2. Usuario registrado Acceden a la aplicación Android identificándose mediante un correo y contraseña. Tienen acceso tanto a las funciones básicas previamente descritas como funciones de la aplicación relacionadas con la reserva de sitios en sala y la posibilidad de hacer check-in/out en los sitios de sala. 4.1.3. Administrador Acceden a la aplicación web iniciando sesión mediante un correo y contraseña entregados por el vendedor de la aplicación. Además de poder acceder a las funciones comentadas para los usuarios anteriores, tienen acceso a funciones relacionadas con la gestión de salas y sitios, así como la creación de mapas: FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 35 de 196 ● Crear, editar y eliminar salas junto a sus mapas de sitios (con información de contacto y otros). ● Crear, editar y eliminar facultades (con información de contacto y otros). ● Crear, editar y eliminar noticias y eventos en sala. 4.2. Diagrama de casos de uso En este apartado se incluye un diagrama de casos de uso por cada perfil de usuario que accede a la aplicación. Los diagramas están reflejados en las Figuras 11, 12 y 13 para los usuarios no registrados, usuarios registrados y usuarios administradores respectivamente. 4.2.1. Usuario no registrado Figura 11 - Diagrama de CU de usuario no registrado FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 36 de 196 4.2.2. Usuario registrado Figura 12 - Diagrama de CU de usuario registrado FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 37 de 196 4.2.3. Administrador Figura 13 - Diagrama de CU de usuario administrador 4.3. Casos de uso En este apartado se especifican los casos de uso que se han llevado a cabo en el desarrollo de las aplicaciones, haciendo referencia a los usuarios no registrados desde la Tabla 1 hasta la Tabla 13, a los usuarios registrados desde la Tabla 14 hasta la Tabla 20 y, por último, a los usuarios administradores desde la Tabla 30 hasta la Tabla 49. FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 38 de 196 4.3.1. Casos de uso de usuario no registrado Detalles Descripción Identificador CU_UNR01 Nombre Registrar usuario Prioridad Alta Estabilidad Alta Descripción Añadir un nuevo usuario a la base de datos compuesto por un correo electrónico, un nombre y una contraseña Entrada Correo electrónico, nombre, contraseña, fecha del sistema Salida Se abre la aplicación con la sesión del usuario y su información Origen GUI Destino GUI Necesita Correo electrónico, nombre y contraseña Acción Se añade a la base de datos el nuevo usuario y se inicia sesión con las credenciales introducidas Precondición El correo electrónico introducido no existe en la base de datos y es válido, y la contraseña es de al menos 6 caracteres Postcondición En la aplicación se inicia la sesión del usuario y la base de datos contiene el nuevo usuario Efectos laterales Se muestra un mensaje de error en caso de que el correo electrónico ya exista en la base de datos o no sea válido, y en caso de que la contraseña tenga menos de 6 caracteres. Se muestra un mensaje de error en caso de producirse alguno Tabla 1 - CU usuario no registrado: Registrar usuario FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 39 de 196 Detalles Descripción Identificador CU_UNR02 Nombre Iniciar sesión Prioridad Alta Estabilidad Alta Descripción Se inicia sesión en la aplicación con las credenciales introducidas Entrada Correo electrónico y contraseña Salida Se inicia sesión en la aplicación Origen GUI Destino GUI Necesita Correo electrónico y contraseña Acción Se inicia sesión con las credenciales introducidas mostrando la pantalla de inicio Precondición El correo electrónico introducido existe en la base de datos y la contraseña coincide con la que está asociada al correo electrónico en la base de datos Postcondición Se inicia la sesión del usuario en la aplicación Efectos laterales Muestra un mensaje de error en caso de que el correo electrónico no exista en la base de datos y en caso de que la contraseña introducida no coincida con la contraseña almacenada asociada al correo electrónico. Se muestra un mensaje de error en caso de producirse alguno Tabla 2 - CU usuario no registrado: Iniciar sesión FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 40 de 196 Detalles Descripción Identificador CU_UNR03 Nombre Ver facultades Prioridad Baja Estabilidad Media Descripción Ver un listado de las facultades existentes. Al hacer clic en una facultad se muestra el listado de las salas de dicha facultad. Se muestra un botón para ver la información de la facultad Entrada N/A Salida Se muestra por pantalla el listado de las facultades Origen GUI Destino GUI Necesita N/A Acción Se extraen de la base de datos las facultades existentes y se muestran por pantalla Precondición Existe al menos una facultad en la base de datos Postcondición El listado de facultades se muestra en la pantalla Efectos laterales Se muestra un mensaje de error en caso de producirse alguno Tabla 3 - CU usuario no registrado: Ver facultades FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 41 de 196 Detalles Descripción Identificador CU_UNR04 Nombre Ver información de facultad Prioridad Baja Estabilidad Media Descripción Ver la información de una facultad, como su teléfono de contacto y correo electrónico en caso de existir (se muestran con un botón para llamar y/o enviar correo electrónico) Entrada idFacultad Salida Se muestra por pantalla la información de la facultad Origen GUI Destino GUI Necesita Facultad Acción Se extrae de la base de datos la información de la facultad consultada y se muestra en la pantalla Precondición La facultad existe en la base de datos Postcondición La información se muestra en la pantalla Efectos laterales Se muestra un mensaje de error en caso de producirse alguno Tabla 4 - CU usuario no registrado: Ver información de facultad FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 48 de 196 Detalles Descripción Identificador CU_UNR11 Nombre Sala: Consultar estadísticas de ocupación Prioridad Media Estabilidad Alta Descripción Se muestra un histórico de la ocupación en la sala en fechas pasadas y una predicción de ocupación junto a la cantidad de reservas confirmadas para fechas futuras. En la pantalla se mostrará la ocupación por horas del día elegido Entrada idSala y fecha seleccionada Salida Se muestra por pantalla la información de ocupación del día elegido Origen GUI Destino GUI Necesita Sala y fecha Acción Se extrae de la base de datos la ocupación de una fecha pasada o futura y en caso de ser futura se calcula con datos almacenados Precondición La sala existe en la base de datos y tiene información de ocupación de fechas pasadas Postcondición La información se muestra en pantalla Efectos laterales Se muestra un mensaje de error en caso de producirse alguno Tabla 11 - CU usuario no registrado: Sala, consultar estadísticas de ocupación FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 49 de 196 Detalles Descripción Identificador CU_UNR12 Nombre Consultar tablón de anuncios Prioridad Baja Estabilidad Alta Descripción Ver una lista de anuncios de una facultad publicados por un administrador, o notificaciones de cierre de sala, eventos próximos u otros Entrada idFacultad Salida Se muestra por pantalla la lista de anuncios y notificaciones de la facultad Origen GUI Destino GUI Necesita Facultad Acción Se extrae de la base de datos la lista de anuncios y notificaciones de la facultad Precondición La facultad existe en la base de datos Postcondición La información se muestra en la pantalla Efectos laterales Se muestra un mensaje de error en caso de producirse alguno Tabla 12 - CU usuario no registrado: Consultar tablón de anuncios FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 50 de 196 Detalles Descripción Identificador CU_UNR13 Nombre Vista de información mediante QR Prioridad Baja Estabilidad Alta Descripción El usuario puede leer un código QR de distintos tipos, ya sea para acceder a la información de una facultad de una sala para observar su ocupación, de un evento, el lector de códigos QR le llevará a su vista de información correspondiente Entrada String identificativo del QR entre: idSala, idEvento, idFacultad. Salida Vista de información del elemento. Origen Externo Destino GUI Necesita QR, Permiso para acceder a cámara. Acción Se muestra la información sobre lo que corresponda al QR ya sea evento, facultad o sala. Precondición La sesión está activa y el QR pertenece a la aplicación Postcondición N/A Efectos laterales Se muestra un mensaje de error en caso de producirse alguno Tabla 13 - CU usuario no registrado: Vista de información mediante QR FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 51 de 196 4.3.2. Casos de uso de usuario registrado Detalles Descripción Identificador CU_UR01 Nombre Cambiar contraseña Prioridad Alta Estabilidad Alta Descripción Una vez introducida la contraseña anterior del usuario para confirmar su identidad, se guarda la nueva contraseña introducida en la base de datos encriptada Entrada idUsuario, contraseña anterior y contraseña nueva Salida Se muestra un mensaje confirmando el cambio de contraseña Origen GUI Destino GUI Necesita Usuario, contraseña anterior y contraseña nueva Acción Se compara la contraseña anterior introducida por el usuario con la almacenada en la base de datos. Si esta es correcta, se valida la nueva contraseña y se almacena encriptada en la base de datos si cumple los criterios Precondición El usuario tiene la sesión iniciada y ha introducido la contraseña anterior correctamente. La nueva contraseña no debe ser igual a la anterior y cumplir los criterios de contraseña Postcondición Se guarda la nueva contraseña encriptada en la base de datos y se muestra un mensaje al usuario de que el cambio de contraseña se ha realizado correctamente FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 52 de 196 Efectos laterales Muestra un mensaje de error en caso de que el usuario no haya introducido la contraseña anterior correctamente o si la nueva contraseña es igual que la anterior. Se muestra un mensaje de error en caso de producirse alguno Tabla 14 - CU usuario registrado: Cambiar contraseña FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 53 de 196 Detalles Descripción Identificador CU_UR02 Nombre Reservar sitio Prioridad Alta Estabilidad Alta Descripción El usuario realiza una reserva en el sitio de la sala y en la fecha seleccionados durante la/s hora/s que haya elegido el sitio. La disponibilidad de la sala disminuye en dicha fecha y hora/s. Entrada idUsuario, idSala, idSitio, fecha y hora/s Salida Se muestra un mensaje de confirmación al usuario Origen GUI Destino GUI Necesita Usuario, sala, sitio, fecha y hora Acción Se añade a la base de datos la reserva del usuario en el sitio de la sala durante la fecha y hora/s elegidas. La disponibilidad disminuye en una unidad para estos mismos parámetros Precondición La sala existe, está activa y el sitio está libre para la fecha y hora/s seleccionadas Postcondición La reserva se almacena en la base de datos y se muestra un mensaje al usuario de que la reserva se ha realizado correctamente Efectos laterales Se muestra un mensaje de error en caso de producirse alguno Tabla 15 - CU usuario registrado: Revisar sitio FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 54 de 196 Detalles Descripción Identificador CU_UR03 Nombre Realizar reserva de sitio para eventos Prioridad Media Estabilidad Alta Descripción Se realiza la reserva de un sitio disponible en una sala Entrada idUsuario, idEvento, idSitio Salida Notificación con la confirmación de la reserva de la sala Origen GUI Destino GUI Necesita Usuario, evento, sitio Acción Se crea un nuevo registro de reserva en el sistema asignándole un ID único Precondición El sitio que se quiere reservar está libre Postcondición La reserva del sitio en el evento queda registrada Efectos laterales Se muestra un mensaje de error en caso de producirse alguno Tabla 16 - CU usuario registrado: Realizar reserva de sitio para eventos FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 55 de 196 Detalles Descripción Identificador CU_UR04 Nombre Editar una reserva Prioridad Alta Estabilidad Alta Descripción Se realiza la modificación de una reserva Entrada idUsuario, idReserva, idSitio, día, hora Salida Notificación con la confirmación de la modificación de la reserva Origen GUI Destino GUI Necesita Usuario, reserva, sitio, fecha Acción Se actualiza el registro de la reserva en el sistema Precondición La sala no tiene el aforo completo en el evento/horario nuevo Postcondición Los datos de la reserva quedan actualizados Efectos laterales Se muestra un mensaje de error en caso de producirse alguno Tabla 17 - CU usuario registrado: Editar una reserva FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 56 de 196 Detalles Descripción Identificador CU_UR05 Nombre Anular una reserva Prioridad Alta Estabilidad Alta Descripción Se realiza la anulación de una reserva Entrada idReserva Salida Notificación con la confirmación de la anulación de la reserva Origen GUI Destino GUI Necesita Reserva Acción Se da de baja el registro de la reserva en el sistema Precondición La reserva está activa Postcondición No existe la reserva en la sala y evento/horario por cuenta de correo. El aforo de la sala en el evento/horario seleccionado no está completo Efectos laterales Se muestra un mensaje de error en caso de producirse alguno Tabla 18 - CU usuario registrado: Anular una reserva FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 57 de 196 Detalles Descripción Identificador CU_UR06 Nombre Cerrar sesión en la aplicación Prioridad Alta Estabilidad Alta Descripción Se realiza un cierre de sesión en la aplicación Entrada idUsuario Salida Mensaje con la confirmación del cierre de sesión mostrado en la pantalla principal de la aplicación Origen GUI Destino GUI Necesita Usuario Acción Se cierra la sesión en la aplicación Precondición La sesión está activa Postcondición No una sesión activa del usuario Efectos laterales Se muestra un mensaje de error en caso de producirse alguno Tabla 19 - CU usuario registrado: Cerrar sesión en la aplicación FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 64 de 196 Detalles Descripción Identificador CU_UR13 Nombre Establecer facultad favorita Prioridad Media Estabilidad Alta Descripción El usuario puede establecer una facultad como favorita. De este modo al entrar en la app lo primero que le aparecerá es la lista de salas de esa facultad. Entrada idUsuario, idFacultad Salida Mensaje de confirmación Origen GUI Destino GUI Necesita Usuario, facultad Acción Se establece la facultad favorita del usuario Precondición La sesión está activa y la facultad existe Postcondición Queda registrado en la base de datos la facultad favorita del usuario Efectos laterales Se muestra un mensaje de error en caso de producirse alguno Tabla 26 - CU usuario registrado: Establecer facultad favorita FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 65 de 196 Detalles Descripción Identificador CU_UR14 Nombre Notificación de reserva Prioridad Media Estabilidad Alta Descripción El usuario recibe una notificación cuando falten 10 minutos para la hora a la que ha reservado. Entrada idReserva Salida Notificación de reserva cercana Origen Externo Destino GUI Necesita idReserva Acción Se genera una notificación hacia el usuario creada en el momento de realizar la reserva programada previamente. Precondición La reserva existe. Postcondición Se manda una notificación al sistema de notificaciones Efectos laterales Se muestra un mensaje de error en caso de producirse alguno Tabla 27 - CU usuario registrado: Notificación de reserva FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 66 de 196 Detalles Descripción Identificador CU_UR15 Nombre Notificación de check-in Prioridad Media Estabilidad Alta Descripción El usuario a la hora de realizar check-in en algún sitio recibirá una notificación por parte del sistema de que el check-in se ha realizado correctamente. Entrada N/A Salida Notificación de confirmación de check-in Origen Sistema Destino GUI Necesita IdReserva Acción Se envía una notificación al sistema de notificaciones. Precondición El check-in es correcto. Postcondición La notificación se muestra al usuario Efectos laterales Se muestra un mensaje de error en caso de producirse alguno Tabla 28 - CU usuario registrado: Notificación de check-in FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 67 de 196 Detalles Descripción Identificador CU_UR16 Nombre Ver información evento Prioridad Media Estabilidad Alta Descripción Ver la información completa de un evento, cuando ocurre en qué sala sucede, y el nombre del evento. Entrada idEvento Salida Se muestra por pantalla la información del evento Origen GUI Destino GUI Necesita idEvento Acción Se extrae de la BBDD toda la información del evento. Precondición El evento existe en la BBDD. Postcondición La información se muestra en pantalla Efectos laterales Se muestra un mensaje de error en caso de producirse alguno Tabla 29 - CU usuario registrado: Ver información evento FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 68 de 196 4.3.3. Casos de uso de usuario administrador Detalles Descripción Identificador CU_A01 Nombre Activar Sala Prioridad Alta Estabilidad Alta Descripción Se activa una sala que estaba bloqueada Entrada idSala Salida Mensaje de confirmación de activación Origen GUI Destino GUI Necesita Cuenta de administrador del lugar Acción Se actualiza la sala en la base de datos como activo Precondición La sala debe estar inactiva Postcondición La sala se encuentra activa Efectos laterales Se muestra un mensaje de error en caso de producirse alguno. Tabla 30 - CU usuario administrador: Activar Sala FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 69 de 196 Detalles Descripción Identificador CU_A02 Nombre Activar Sitio Prioridad Alta Estabilidad Alta Descripción Se activa un sitio no disponible en una sala Entrada idSitio, idSala Salida Mensaje de confirmación de activación Origen GUI Destino GUI Necesita Cuenta de administrador del lugar Acción Se actualiza el sitio en la base de datos como activo Precondición El sitio debe estar inactivo Postcondición El sitio se encuentra activo y puede ser reservado mientras la sala esté activa Efectos laterales Se muestra un mensaje de error en caso de producirse alguno. Tabla 31 - CU usuario administrador: Activar sitio FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 70 de 196 Detalles Descripción Identificador CU_A03 Nombre Bloquear Sala Prioridad Alta Estabilidad Alta Descripción Se bloquea toda interacción sobre una sala para reservas y check-in Entrada IdSala Salida Mensaje de confirmación de bloqueo Origen GUI Destino GUI Necesita Cuenta de administrador del lugar Acción Se actualiza la sala en la base de datos como bloqueada Precondición La sala debe estar desbloqueada Postcondición El sitio se encuentra activo y puede ser reservado mientras la sala esté activa. Efectos laterales Se muestra un mensaje de error en caso de producirse alguno Tabla 32 - CU usuario administrador: Bloquear sala FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 71 de 196 Detalles Descripción Identificador CU_A04 Nombre Bloquear Sitio Prioridad Alta Estabilidad Alta Descripción Se bloquea un sitio en una sala para que este no pueda ser reservado ni se permite el check-in en el mismo Entrada idSitio, idSala Salida Mensaje de confirmación de bloqueo Origen GUI Destino GUI Necesita Cuenta de administrador del lugar Acción Se actualiza el sitio en la base de datos como inactivo Precondición El sitio debe estar activo Postcondición El sitio se bloquea y no puede ser reservado Efectos laterales Se muestra un mensaje de error en caso de producirse alguno Tabla 33 - CU usuario administrador: Bloquear sitio FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 72 de 196 Detalles Descripción Identificador CU_A05 Nombre Editar información de sala Prioridad Alta Estabilidad Alta Descripción Se modifica la información de una sala Entrada Teléfono, correo electrónico, aforo Salida Se muestra la nueva información Origen GUI Destino GUI Necesita Cuenta de administrador del lugar Acción Se modifican los datos de una sala ya sea teléfono o sus características en la base de datos Precondición La sala debe estar activa Postcondición Los nuevos datos mostrados están actualizados Efectos laterales Se muestra un mensaje de error en caso de producirse alguno o no se introduzca el tipo de datos adecuado Tabla 34 - CU usuario administrador: Editar información de sala FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 73 de 196 Detalles Descripción Identificador CU_A06 Nombre Añadir sala Prioridad Alta Estabilidad Alta Descripción Se genera una nueva sala con su información como el teléfono, correo electrónico, nombre, ubicación y perímetro Entrada Nombre de sala, ubicación y perímetro Teléfono y correo electrónico (Opcional) Salida Mensaje de confirmación de creación de sala Origen GUI Destino GUI Necesita Cuenta de administrador Acción Se da de alta una sala con sus características en la base de datos Precondición La sala no debe existir previamente Postcondición Todos los datos de la sala quedan registrados Efectos laterales Se muestra un mensaje de error en caso de producirse alguno o no se introduzca el tipo de datos adecuado Tabla 35 - CU usuario administrador: Añadir sala FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 80 de 196 Detalles Descripción Identificador CU_A13 Nombre Publicar anuncio Prioridad Media Estabilidad Alta Descripción Se crea un anuncio que aparecerá en el tablón de anuncios de la facultad Entrada idFacultad, texto de anuncio, fecha de publicación, fecha fin de publicación Salida Mensaje de confirmación de creación de anuncio en tablón de anuncios Origen GUI Destino GUI Necesita Cuenta de administrador, facultad, texto de anuncio, fecha de publicación, fecha fin de publicación Acción Se crea un anuncio para el tablón de anuncios de una facultad Precondición La facultad debe existir Postcondición Queda registrado el anuncio asociado a la facultad Efectos laterales Se muestra un mensaje de error en caso de producirse alguno Tabla 42 - CU usuario administrador: Publicar anuncio FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 81 de 196 Detalles Descripción Identificador CU_A14 Nombre Editar anuncio Prioridad Media Estabilidad Alta Descripción Se modifica un anuncio existente en el tablón de anuncios de la facultad Entrada idFacultad, idAnuncio, texto de anuncio, fecha de publicación, fecha fin de publicación Salida Mensaje de confirmación de modificación de anuncio en tablón de anuncios Origen GUI Destino GUI Necesita Cuenta de administrador, facultad, anuncio, texto de anuncio, fecha de publicación, fecha fin de publicación Acción Se modifica un anuncio del tablón de anuncios de una facultad Precondición La facultad y el anuncio deben existir Postcondición Queda registrado el nuevo anuncio asociado a la facultad Efectos laterales Se muestra un mensaje de error en caso de producirse alguno Tabla 43 - CU usuario administrador: Editar anuncio FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 82 de 196 Detalles Descripción Identificador CU_A15 Nombre Eliminar anuncio Prioridad Media Estabilidad Alta Descripción Se elimina un anuncio existente Entrada idFacultad, idAnuncio Salida Mensaje de confirmación de eliminación de anuncio Origen GUI Destino GUI Necesita Cuenta de administrador, facultad, anuncio Acción Se elimina un anuncio de una facultad Precondición La facultad y el anuncio deben existir Postcondición Queda eliminado el anuncio asociado a la facultad Efectos laterales Se muestra un mensaje de error en caso de producirse alguno Tabla 44 - CU usuario administrador: Eliminar anuncio FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 83 de 196 Detalles Descripción Identificador CU_A16 Nombre Añadir Facultad Prioridad Alta Estabilidad Alta Descripción Se da de alta una facultad en el sistema, tanto desde aplicación Android como web Entrada Nombre, acrónimo, dirección, descripción, ciudad, email, vacaciones, horarios, imagen, región y teléfono Salida Mensaje de confirmación de alta de facultad Origen GUI (Android, Web) Destino GUI (Android, Web) Necesita Cuenta de administrador, facultad Acción Se da de alta en el sistema una facultad con los datos proporcionados por el administrador. Precondición La facultad no debe existir previamente Postcondición La facultad se da de alta en el sistema. Efectos laterales Se muestra un mensaje de error en caso de producirse alguno Tabla 45 - CU usuario administrador: Añadir Facultad FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 84 de 196 Detalles Descripción Identificador CU_A17 Nombre Modificar Facultad Prioridad Alta Estabilidad Alta Descripción Permite modificar los atributos de una facultad ya existente, ya sea desde Android o la aplicación web. Entrada idFacultad, nombre, acrónimo, dirección, descripción, ciudad, email, vacaciones, horarios, imagen, región y teléfono Salida Mensaje de confirmación de modificación de facultad Origen GUI (Android, Web) Destino GUI (Android, Web) Necesita Cuenta de administrador, facultad Acción Se actualizan los datos modificados por el administrador Precondición La facultad debe existir previamente Postcondición La facultad se actualiza con los datos modificados por el administrador Efectos laterales Se muestra un mensaje de error en caso de producirse alguno Tabla 46 - CU usuario administrador: Modificar facultad FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 85 de 196 Detalles Descripción Identificador CU_A18 Nombre Eliminar Facultad Prioridad Alta Estabilidad Alta Descripción Se elimina la facultad del sistema desde Android o desde el sitio web. Entrada idFacultad Salida Mensaje de confirmación de eliminación de una facultad Origen GUI (Android, Web) Destino GUI (Android, Web) Necesita Cuenta de administrador, idFacultad Acción Se elimina una facultad existente Precondición La facultad debe existir previamente Postcondición La facultad se elimina del sistema Efectos laterales Se muestra un mensaje de error en caso de producirse alguno Tabla 47 - CU usuario administrador: Eliminar facultad FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 86 de 196 Detalles Descripción Identificador CU_A19 Nombre Crear documento con códigos QR de sala Prioridad Alta Estabilidad Alta Descripción El usuario administrador tiene la opción de generar un PDF con los códigos QR correspondientes a la sala en sí y a los sitios que hay en la sala. Entrada idSala Salida Mensaje de confirmación de documento generado. Origen GUI Destino GUI Necesita Cuenta de administrador, idSala Acción Se almacena en la memoria interna un PDF con los códigos QR de la sala Precondición La sala debe existir. Postcondición Se genera un PDF en memoria interna. Efectos laterales Se muestra un mensaje de error en caso de producirse alguno Tabla 48 - CU usuario administrador: Crear documento con códigos QR de sala FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 87 de 196 Detalles Descripción Identificador CU_A20 Nombre Crear documento con códigos QR de evento Prioridad Alta Estabilidad Alta Descripción El usuario administrador tiene la opción de generar un PDF con los códigos QR correspondientes al evento en sí y a los sitios que hay en el evento. Entrada idEvento Salida Mensaje de confirmación de documento generado. Origen GUI Destino GUI Necesita Cuenta de administrador, idEvento Acción Se almacena en la memoria interna un PDF con los códigos QR del evento Precondición El evento debe existir. Postcondición Se genera un PDF en memoria interna. Efectos laterales Se muestra un mensaje de error en caso de producirse alguno Tabla 49 - CU usuario administrador: Crear documento con códigos QR de evento FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 88 de 196 Capítulo 5. Arquitectura En este capítulo se describe y explica la arquitectura del sistema desarrollado además de los patrones de diseño empleados tanto en el desarrollo de la aplicación web como de la aplicación Android. Además, se explican los modelos utilizados en el almacenamiento de datos en los servicios de Firebase, Firestore Database y Storage. 5.1. Arquitectura del sistema Al disponer de dos aplicaciones software completamente distintas, cada una de ellas está desarrollada en una arquitectura distinta. Figura 14 - Diagrama de arquitectura FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 89 de 196 En la Figura 14 se muestra tanto la arquitectura de la aplicación Android como, la arquitectura de la aplicación web siendo en este caso una arquitectura cliente(s)-servidor ([30]) compartiendo servicios externos de Firebase. En el caso de la aplicación Android, se hace uso de los servicios Authentication, Firestore Database y Storage de Firebase a través de una API ([31]) de Firebase para desacoplar a la aplicación de esas tareas y mantener los datos actualizados desde cualquier dispositivo móvil. Por otro lado, en la aplicación web, se hace uso además de los servicios Authentication, Firestore Database y Storage, del servicio de Hosting para dar almacenamiento web y poder conectarse a través de cualquier navegador a la URL ([32]) pública. Al igual que en la aplicación Android, los servicios de Firebase se han utilizado a través de una API. 5.2. Patrones de diseño y arquitectónicos Android 5.2.1. MVVM (Mode-View-ViewModel) Se ha utilizado el patrón MVVM ([33]) para separar la parte de vistas (Activity y Fragment), de la lógica de negocio. Las vistas se encargan de recoger los eventos generados por el usuario mediante la pantalla, para realizar alguna función en los ViewModel, la cual puede emplear acceso a las bases de datos mediante los repositorios. Finalmente, es el ViewModel el encargado de notificar a la vista cualquier cambio que esta deba realizar en la pantalla. 5.2.2. Singleton El patrón de diseño Singleton ([34]) se ha utilizado para obtener una instancia de los diferentes servicios que ofrece Firebase. En concreto, se ha utilizado para 3 servicios: Firebase Firestore, Firebase Authentication y Firebase Storage. Figura 15 - Patrón Singleton 5.2.3. Kotin DataClass Para poder usar los documentos de Firestore obtenidos de Firebase se han de convertir en objetos que se puedan interpretar en el código. Por esto, se usan las DataClasses ([35]) de Kotlin, en las que se pueden convertir los documentos obtenidos de Firestore fácilmente y así poder manejarlos. FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 96 de 196 En este apartado se describe la estructura de cada una de las tablas de la base de datos organizadas por el tipo de entidad de la que se guarda información. 5.5.1. Tabla sobre universidades Contiene información sobre una entidad universitaria: ● acronym: Representa el acrónimo de la universidad a la que pertenece la facultad y es de tipo string. ● name: Representa el nombre de la universidad y es de tipo string. 5.5.2. Tabla sobre facultades Contiene información sobre una facultad: ● idUniversity: Representa el identificador de la universidad a la que pertenece la facultad y es de tipo string. ● acronym: Representa el acrónimo de la facultad y es de tipo string. ● active: Representa si la facultad se encuentra activa o inactiva y es de tipo boolean. ● address: Representa la dirección de la facultad y es de tipo string. ● city: Representa la ciudad de la facultad y es de tipo string. ● coordinates: Representa las coordenadas de la facultad y es de tipo array de números. ● description: Representa la descripción de la facultad y es de tipo string. ● email: Representa el email de la facultad y es de tipo string. ● holidays: Representa la fecha de los días festivos o de cierre de la facultad y es de tipo array de timestamps. ● hoursEnd: Representa la hora de cierre de la facultad para cada día de la semana y es de tipo array de strings. ● hoursStart: Representa la hora de apertura de la facultad para cada día de la semana y es de tipo array de strings. ● imageUrl: Representa el URL de la imagen de la facultad y es de tipo string. ● name: Representa el nombre de la facultad y es de tipo string. ● region: Representa la provincia de la facultad y es de tipo string. ● tlfNumber: Representa el número de teléfono de la facultad y es de tipo string. 5.5.3. Tabla sobre salas Contiene información sobre una sala: ● idFaculty: Representa el identificador de la facultad a la que pertenece la sala y es de tipo string. ● active: Representa si la sala se encuentra activa o inactiva y es de tipo boolean. FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 97 de 196 ● coordinates: Representa las coordenadas de la sala, junto al radio correspondiente al área circular y es de tipo array. ● email: Representa el email de la sala y es de tipo string. ● hoursEnd: Representa la hora de cierre de la sala para cada día de la semana y es de tipo array de strings. ● hoursStart: Representa la hora de apertura de la sala para cada día de la semana y es de tipo array de strings. ● imageUrl: Representa el URL de la imagen de la sala y es de tipo string. ● messageLocked: Representa el mensaje de sala bloqueada y es de tipo string. ● name: Representa el nombre de la sala y es de tipo string. ● seats: Representa el mapa de sitios de una sala mediante una cadena y es de tipo string. ● timestampEndLockdown Representa la fecha y hora de finalización del bloqueo de sala y es de tipo timestamp. ● tlfNumber: Representa el número de teléfono de la sala y es de tipo string. 5.5.4. Tabla sobre eventos y noticias Contiene información sobre un evento o noticia: ● idFaculty: Representa el identificador de la facultad a la que pertenece el evento o noticia y es de tipo string. ● idRoom: Representa el identificador de la sala en caso de que se trate de un evento en sala y es de tipo string. ● description: Representa la descripción del evento o noticia y es de tipo string. ● link: Representa la URL del evento o noticia y es de tipo string. ● showTimestampEnd: Representa si se muestra la fecha de finalización del evento o noticia y es de tipo boolean. ● showTimestampStart: Representa si se muestra la fecha de comienzo del evento o noticia y es de tipo boolean. ● timestampEnd: Representa la fecha y hora de finalización del evento o noticia y es de tipo timestamp. ● timestampStart: Representa la fecha y hora de comienzo del evento o noticia y es de tipo timestamp. ● title: Representa el título del evento o noticia y es de tipo string. 5.5.5. Tabla sobre usuarios Contiene información sobre un usuario: ● checkInRoomId: Representa el identificador de sala donde el usuario ha realizado el check-in y es de tipo string. ● checkInSeatId: Representa el identificador del sitio donde el usuario ha realizado el check-in y es de tipo entero. FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 98 de 196 ● checkInTimestamp: Representa la fecha y hora del check-in y es de tipo timestamp. ● checkOutTimestamp: Representa la fecha y hora del check-out y es de tipo timestamp. ● idFavoriteFaculty: Representa el identificador de la facultad favorita del usuario y es de tipo string. ● idOcuppancy: Representa el identificador de ocupación y es de tipo string. ● lastName: Representa los apellidos del usuario y es de tipo string. ● name: Representa el nombre del usuario y es de tipo string. ● userType: Representa el tipo de usuario y es de tipo string. 5.5.6. Tabla sobre reservas Contiene información sobre una reserva: ● idFaculty: Representa el identificador de la facultad a la que pertenece la reserva y es de tipo string. ● idRoom: Representa el identificador de la sala a la que pertenece la reserva y es de tipo string. ● idSeat: Representa el identificador del sitio y es de tipo string. ● idUser: Representa el identificador del usuario y es de tipo string. ● timestampEnd: Representa la fecha y hora de fin de la reserva y es de tipo timestamp. ● timestampStart: Representa muestra la fecha y hora de comienzo de la reserva y es de tipo timestamp. 5.5.7. Tabla sobre ocupación Contiene información sobre la ocupación en salas: ● idRoom: Representa el identificador de la sala en la que se ha hecho check-in y es de tipo string. ● timestampEnd: Representa la fecha y hora del check-out y es de tipo timestamp. ● timestampStart: Representa muestra la fecha y hora del check-in y es de tipo timestamp. FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 99 de 196 Capítulo 6. Diseño e implementación En este capítulo se van a desarrollar los aspectos referentes al diseño y a la implementación de la aplicación Android y la web. 6.1. Diseño Android En términos generales, se han seguido las guías de diseño marcadas por Google en su sistema de diseño más reciente llamado Material Design 3 ([45]). 6.1.1. Colores Para la elección de colores se ha usado Material Theme Builder ([46]), con el cual, introduciendo los colores primario, secundario y terciario, se han generado el resto de los colores que se han usado en la aplicación. Se ha decidido usar colores fríos, con tonos azules para el color primario y secundario, y un tono morado para el color terciario. También se ha generado como añadido el color marrón, el cual se usa para representar las mesas en el mapa de sitios de las salas. A continuación, tal como se visualiza en la Figura 27 se puede observar el tema generado con Material Theme Builder donde se puede ver la gama de colores que le componen junto a su prioridad. Figura 27 - Diseño Android: Material Theme Builder En los colores exportados del Material Theme Builder también se encuentran colores adaptados al modo oscuro de Android, por lo que la app se adaptará al tema oscuro cuando el usuario lo active, mejorando así la visualización de esta. FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 100 de 196 Se ha decidido utilizar también los colores dinámicos (Dynamic Colors) ([47]), con los cuales los colores de la aplicación, si esta se está ejecutando en un dispositivo con Android 12 o superior, se adaptarán al tema elegido por el usuario en su dispositivo. Se puede ver cómo se adaptan los colores de la aplicación a los diferentes temas en la Figura 28. Figura 28 - Diseño Android: Dynamic Colors 6.1.2. Temas Para conseguir que la aplicación se visualice correctamente en las distintas versiones de Android partiendo de la versión Android 5.0 (La mínima soportada por la aplicación), se han creado varios recursos de temas. De este modo se consigue que las últimas versiones aprovechen las características de diseño más recientes, mientras que las versiones más antiguas no se ven afectadas por estas nuevas características no soportadas. Seguidamente, tal como se visualiza en las Figuras 29 y 30, se puede observar los diferentes recursos de temas anteriormente mencionados presentes en la aplicación y un ejemplo a nivel de código de uno de estos recursos. FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 101 de 196 Figura 29 - Diseño Android: Temas con diferentes versiones Figura 30 - Diseño Android: Temas versión por defecto 6.1.3. Splash Screen Otro añadido en cuestión de diseño ha sido la implementación de una Splash Screen ([48]), la cual, es una pantalla que se muestra al iniciar la aplicación cuando esta no estaba cargada en segundo plano. En esta pantalla se ha decidido utilizar el texto “ResU” como icono, que sería el diminutivo de “ResUniversitas”. Además, empezando en Android 12, este icono se ha animado ligeramente para aportar atractivo visual. En las capturas de la derecha de la Figura 31 se puede observar el aspecto visual de la Splash Screen. FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 102 de 196 Cabe destacar que se ha programado la Splash Screen para que no muestre la interfaz de la propia aplicación hasta que no estén cargados todos los elementos visuales. De este modo, cuando se muestre la interfaz al usuario, este podrá ver todo sin necesidad de esperar a que ningún elemento termine de cargar. Figura 31 - Diseño Android: Splash Screen 6.2. Diseño Web A continuación, se describen los aspectos fundamentales del diseño de la aplicación web donde se ha implementado un diseño responsive mediante los frameworks Bootstrap ([49]) y Angular. 6.2.1. Diseño El diseño se ha implementado usando Bootstrap, un framework de Javascript para el desarrollo de aplicaciones de front-end que tiene compatibilidad con la mayoría de los navegadores y Angular, un framework de Javascript escrito en Typescript. Por otra parte, se han implementado archivos CSS3 para dar diseño a los documentos HTML y complementar las clases Bootstrap anteriormente mencionadas. Seguidamente, como se visualiza en las Figura 32 y 33 se muestra un ejemplo de un fragmento del archivo faculty-list.component.css y su repercusión en la vista facultylist.component.html. FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 103 de 196 Figura 32 - Diseño web: Diseño, CSS Figura 33 - Diseño web: Diseño pantalla listado de facultades FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 104 de 196 6.2.2. Bootstrap Es un framework de Javascript enfocado al desarrollo de aplicaciones de front-end que proporciona una librería de estilos CSS, aplicando un diseño responsive ([50]) adaptable a cualquier dispositivo. Actualmente la compatibilidad de Bootstrap se extiende a los siguientes navegadores: - Navegadores en dispositivos móviles Chrome Firefox Safari Android Browser & WebView Microsoft Edge Android Supported Supported Supported Android v5.0+ supported Supported IOS Supported Supported Supported Supported Supported Tabla 50 - Diseño web: Bootstrap, navegadores en dispositivos móviles - Navegadores en ordenadores Chrome Firefox Internet Explorer Microsoft Edge Opera Safari Mac Supported Supported N/A N/A Supported Supported Windows Supported Supported Supported , IE10+ Supported Supported Supported Tabla 51 - Diseño web: Bootstrap, navegadores en ordenadores Tal como se visualiza en la Figura 34 se muestra la inclusión del framework en la aplicación web mediante el uso de los CDN ([51]) proporcionados en la página oficial de Bootstrap. De esta manera, se evita cargar el framework en el servidor de la aplicación Figura 34 - Diseño web: Bootstrap, utilización A continuación, como se visualiza en la Figura 35 se muestra un ejemplo a nivel de código del archivo HTML navbar.component.html donde se usan clases de Bootstrap para el diseño de la barra de navegación de la aplicación. FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 105 de 196 Figura 35 - Diseño web: Bootstrap, utilización en elementos HTML En la Figura 36 que se muestra a continuación se puede ver a nivel de vista la barra de navegación, cuyos estilos únicamente se han definido mediante Bootstrap. Figura 36 - Diseño web: Bootstrap, menú de navegación 6.2.3. Angular 13 Otro añadido en cuestión de diseño ha sido el uso de Angular 13, el cual, es un framework de Javascript escrito en Typescript ([52]), basado en componentes. En cada componente se define una clase que contiene datos y lógica la cual está vinculada a una página HTML y un archivo CSS3. Cabe destacar que gracias a estos componentes el diseño de la aplicación web se ha implementado de manera escalable donde los distintos componentes son reutilizables, ver Figura 37. FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 112 de 196 Lo que tienen en común estos listados es que están generados con un RecyclerView, un componente gráfico de Android que consiste en una lista optimizada en el que los elementos se reciclan para ahorrar recursos. Estos RecyclerViews dependen de un adaptador, el cual se encarga de insertar cada elemento de la lista en la interfaz gráfica. Se puede ver un ejemplo de un adaptador para el listado de facultades en las Figuras 46 y 47. Figura 46 - Funcionalidades Android: Clase FacultiesRecyclerViewAdapter (Adaptador de lista de facultades) 1 Figura 47 - Funcionalidades Android: Clase FacultiesRecyclerViewAdapter (Adaptador de lista de facultades) 2 A este adaptador le llegan los datos correspondientes a través de un BindingAdapter (ver Figura 48), que se encarga de obtener los datos del elemento RecyclerView de la vista XML (ver Figura 49) y construir el adaptador. FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 113 de 196 Figura 48 - Funcionalidades Android: Función BindingAdapter.adapterFaculties de BindingAdapters Figura 49 - Funcionalidades Android: Elemento RecyclerView de facultades faculties_fragment.xml Finalmente, en la vista XML de cada ítem de la lista, gracias al Data Binding, se recogen los datos obtenidos del adaptador y se insertan en los respectivos textos, botones, y demás elementos visuales. En las Figuras 50, 51 y 52 se puede visualizar un ejemplo de ítem de la lista de facultades con sus distintos elementos. FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 114 de 196 Figura 50 - Funcionalidades Android: Layout de facultad faculty_item.xml 1 Figura 51 - Funcionalidades Android: Layout de facultad faculty_item.xml 2 Figura 52 - Funcionalidades Android: Layout de facultad faculty_item.xml 3 FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 115 de 196 Para obtener estas listas, guardadas en un StateFlow en el ViewModel compartido (ver Figura 53), se realiza una llamada asíncrona a la BBDD desde una clase repositorio con la que se obtienen los documentos solicitados (ver Figura 54). Tal como se muestra en la Figura 54, desde el SharedViewModel se llama a la función del repositorio mencionada anteriormente y el resultado, en este caso la lista de facultades se introduce en el StateFlow correspondiente. Figura 53 - Funcionalidades Android: Variable StateFlow faculties de SharedViewModel Figura 54 - Funcionalidades Android: Función fetchFaculties de UniversityRespository Figura 55 - Funcionalidades Android: Función fetchFaculties de SharedViewModel 6.3.3. Reserva de sitios Para comenzar con esta función el usuario debe pulsar el botón “Reservar” de una sala, el cuál mostrará una ventana emergente para elegir fecha y horas de la reserva, como se puede ver en la Figura 56. FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 116 de 196 Figura 56 - Funcionalidades Android: Pantallas de reservar en sala Tal como aparece en la función de las Figuras 57 y 58, una vez comprobado que el usuario no sea de tipo invitado, se configura la funcionalidad de los selectores de fecha y hora para los cuadros de texto de la ventana emergente. FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 117 de 196 Figura 57 - Funcionalidades Android: Función FragmentActivity.handleReserveSeatRoom de RoomUtils 1 Figura 58 - Funcionalidades Android: Función FragmentActivity.handleReserveSeatRoom de RoomUtils 2 Una vez el usuario haya terminado de completar los campos pulsará el botón confirmación que llamará a la función de RoomViewModel encargada de validar los datos y navegar a la siguiente pantalla. Esta función se puede visualizar en la Figura 59. FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 118 de 196 Figura 59 - Funcionalidades Android: Función validateAndNavigateToReserveSeatRoom de RoomViewModel La validación de datos se lleva a cabo en otra clase, con la función que se puede ver en las Figuras 60 y 61. En esta función también se define el error que se debe mostrar en caso de que haya alguno y cómo mostrarlo, si en un mensaje flotante o en alguno de los cuadros de texto. FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 119 de 196 Figura 60 - Funcionalidades Android: Función validateToReserveSeat de ValidationRoomUtil 1 Figura 61 - Funcionalidades Android: Función validateToReserveSeat de ValidationRoomUtil 2 Si se ha completado la validación de datos sin ningún error se pasa a la función representada en la Figura 62, ubicada en el ViewModel compartido, la cual obtiene las reservas de la BBDD para esa sala y las filtra por el horario escogido para luego introducirlas en el StateFlow de sala actual. Esta variable es la que se va a usar para dibujar el mapa de sitios con las reservas existentes en la siguiente pantalla. FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 120 de 196 Figura 62 - Funcionalidades Android: Función navigateToBookingWithAlertDialog de SharedViewModel En la Figura 63 se puede observar cómo queda el mapa de sitios para la reserva en la sala elegida. Este mapa está formado por un ScrollView horizontal y otro vertical anidado, los cuáles se rellenan con vistas que representan cada sitio, mesa o espacio vacío. La función de seleccionar que se puede ver en la Figura 64 es la encargada de representar el sitio seleccionado y repintar el sitio anterior al pulsar en uno nuevo. FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 121 de 196 Figura 63 - Funcionalidades Android: Pantalla de realizar reserva en mapa FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 128 de 196 Como se muestra en la Figura 75, el fichero index-view.component.html realiza una inclusión del componente del fichero index.component.html denominado en la Figura 76 con el nombre app-index como ocurre en la especificación del resto de componentes. Figura 75 - Funcionalidades web: Componentes reutilizables Figura 76 - Funcionalidades web: Fichero Typescript que especifica el componente app-index FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 129 de 196 6.4.2. Inicio de sesión Para acceder a las funcionalidades de la aplicación es necesario que se inicie sesión con un usuario con perfil administrador en la pantalla de inicio de sesión que se muestra en la Figura 77. Figura 77 - Funcionalidades web: Pantalla de inicio de sesión La comprobación del usuario se realiza como se muestra en la Figura 78 haciendo uso de un servicio en el que implementan las funciones de Firestore Authentication como se muestra en las Figuras 79 y 80. Figura 78Funcionalidades web: Controlador de pantalla inicio de sesión FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 130 de 196 Figura 79 - Funcionalidades web: Servicio de implementación de funciones de Authentication 1 Figura 80 - Funcionalidades web: Servicio de implementación de funciones de Authentication 2 FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 131 de 196 6.4.3. Listado de facultades La pantalla de facultades se visualiza como se observa en la Figura 81 a través de un listado utilizando la directiva de Angular *ngFor como se muestra en la Figura 82. Figura 81 - Funcionalidades web: Pantalla de facultades FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 132 de 196 Figura 82 - Funcionalidades web: Fichero HTML de listar facultades En la Figura 83 se especifica cómo se cargan todas las facultades a través de un servicio que inicializa una lista de observables para cada tipo de tabla consultada de Firestore Database como se muestra en la Figura 84. En la Figura 83 también se muestra el método utilizado para eliminar facultades solicitando una confirmación del usuario a través de un mensaje del navegador como se muestra en la Figura 85. FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 133 de 196 Figura 83 - Funcionalidades web: Typescript que controla la pantalla de listar facultades FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 134 de 196 Figura 84 - Funcionalidades web: Operaciones de obtención, actualización y creación de datos Figura 85 - Funcionalidades web: Mensaje de confirmación de eliminación de facultad En las Figuras 86 y 87 se muestra la función que elimina las facultades de Firestore Database realizando una eliminación de todos los datos dados de alta y que hagan referencia a la facultad. FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 135 de 196 Figura 86 - Funcionalidades web: Operación de eliminación de facultades 1 Figura 87 - Funcionalidades web: Operación de eliminación de facultades 2 FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 136 de 196 6.4.4. Crear facultad La pantalla de alta de facultades se muestra en las Figuras 88 y 89 con las validaciones de los campos activas de manera que se puede observar a simple vista los campos obligatorios. Las validaciones utilizadas se especifican en cada elemento a través de la funcionalidad que ofrece Angular como se muestra en la Figura 90. Figura 88 - Funcionalidades web: Pantalla de alta de facultades 1 Figura 89 - Funcionalidades web: Pantalla de alta de facultades 2 FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 137 de 196 Figura 90 - Funcionalidades web: Fichero HTML de formulario de facultades Esta pantalla se carga desde el componente faculty-new-view.component.html (ver Figura 91) que carga a su vez el componente app-faculty-form (formulario de facultades utilizado en las pantallas de alta y modificación) con el título de “Nueva facultad” y un método de regreso al listado al finalizar la acción de volver o guardar. Figura 91 - Funcionalidades web: Fichero de vista que carga el componente de formulario FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 144 de 196 Capítulo 7. Evaluación de usabilidad En este capítulo se han realizado unas encuestas para captar la valoración de algunos usuarios sobre la usabilidad que presenta esta aplicación. 7.1. Metodología Para llevar a cabo esta valoración se ha realizado una encuesta mediante la herramienta de Google Forms. Se han elaborado unas preguntas utilizando la escala de Likert. En estas preguntas, se plantea a los usuarios una afirmación para que ellos puedan mediante una valoración numérica del uno al cinco, establecer el grado de conformidad que tienen con la afirmación presentada. Con este método se ha desarrollado un total de veintisiete preguntas centradas en valorar si la aplicación es intuitiva en cuanto al acceso a las distintas utilidades que esta presenta. Tales son como ejemplo si ha sido sencillo acceder a vistas de información de una facultad, utilizar los QR 's para distintos casos, etc. 7.2. Resultados Comprobando los resultados que hemos obtenido como conclusión se obtiene que la aplicación por lo general es bastante intuitiva para los usuarios. Los usuarios encuestados han sido en su mayoría alumnos de la facultad de informática de la Complutense, y en menor medida algunas personas de mayor edad. Como resultados generales se puede observar en la Figura 102 que la valoración es más que positiva, puesto que supone en su mayoría una media de valoración por encima de los 4 puntos. Después de este análisis general se pasa a analizar algunos rasgos más específicos de la aplicación. FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 145 de 196 Figura 102 - Media de respuestas del formulario 7.2.1. Registro en la aplicación Sobre este punto, como se puede ver en la Figura 103 los usuarios han valorado como perfectamente intuitiva la funcionalidad de registro en la aplicación. Un 94.4% de los usuarios ha opinado que el registro en sí es perfecto. Figura 103 - Registro en la aplicación FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 146 de 196 7.2.2. Escáner QR Las valoraciones obtenidas sobre las funcionalidades relacionadas con los códigos QR son las que han obtenido una valoración más baja, siendo aun así elevada. Este resultado puede deberse a la presencia de usuarios de mayor edad que probaron la aplicación. Se puede comprobar en las Figura 104, 105 y 106.En los tres casos las valoraciones situadas en un 3 se encuentran por debajo del 50% siendo su rango máximo un 44.4 % de los usuarios en la cuestión de acceder a la información de una facultad y el 33.3% en el caso de hacer checkin, por supuesto en las tres figuras no se aprecia, pero los usuarios que valoran de un 4 a un 5 se encuentran en todas por encima del 50%. Figura 104 - Escáner QR 1 FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 147 de 196 Figura 105 - Escáner QR 2 Figura 106 - Escáner QR 3 7.2.3. Creación de mapas Otra de las funcionalidades que ha resultado algo más compleja de utilizar para algunos usuarios ha sido la generación de mapas de salas. Como se puede observar en las Figuras 107 y 108, a los usuarios les ha resultado más difícil el primer contacto con la funcionalidad de mapas de sala, ya que luego los resultados mejoran para la opción de modificar el mapa de sitios. En el caso de la creación de mapas los valores se situaron en 3 para un 44.4% de FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 148 de 196 los usuarios, mientras que en la modificación ese valor se reduce a cero y se reparte entre un 4 y un 5, siendo el 4 la respuesta del 55,6% de los usuarios. Figura 107 - Creación de mapas 1 Figura 108 - Creación de mapas 2 FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 149 de 196 7.2.4. Uso de botones con texto y/o icono Sobre las funcionalidades que incluyen el uso de botones para dar acceso a la utilidad correspondiente se han obtenido valoraciones también altas en cuanto a si han sido intuitivas o no. Esto se interpreta como un buen uso de los iconos y textos para transmitir al usuario qué es lo que puede realizar con cada botón. Las Figuras 109, 110 y 111 representan los resultados comentados. En estas figuras se puede apreciar que únicamente en uno de los casos se ha valorado con un 3 el uso de estos botones de manera intuitiva, que ha sido en el caso del tablón de anuncios. Esta valoración corresponde al 5.6% del total sobre esa pregunta. Con respecto a los datos correspondientes a un 4 de valoración se sitúan entre un 77% y un 50%, siendo esta la valoración que mejor han considerado los usuarios para la intuitividad de los botones. Figura 109 - Uso de botones con texto y/o icono 1 FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 150 de 196 Figura 110 - Uso de botones con texto y/o icono 2 Figura 111 - Uso de botones con texto y/o icono 3 FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 151 de 196 Capítulo 8. Conclusiones y trabajo futuro En este capítulo se reflejan las conclusiones del proyecto extraídas a lo largo de la realización de este, así como los desarrollos y ampliación de las funcionalidades que se podrían realizar en un futuro. 8.1. Conclusiones Al no tratarse de un trabajo de investigación propiamente dicho, sino más bien un proyecto que pretende desarrollar una aplicación para Smartphone con el sistema operativo Android, las conclusiones que se plantean serán un breve resumen de los resultados finalmente obtenidos y de las reflexiones a las que se ha llegado con su elaboración. Al analizar su funcionalidad, se puede observar que el presente proyecto ha cumplido con los objetivos inicialmente propuestos. Se ha creado un servicio que permite a los usuarios disponer de información de las facultades, visualizar eventos y noticias, comprobar el estado de ocupación de las salas, y reservar con antelación asientos en las diferentes salas. Es importante señalar que la aplicación no sólo está dirigida a los usuarios más comunes de la universidad, los estudiantes, puesto que abarca a cualquier usuario de la universidad que estando registrado necesite hacer uso de las instalaciones y, en el caso de no estar registrado, igualmente podrá acceder a toda la información de las distintas facultades. Con este servicio el usuario también podrá realizar un registro de entrada a través de la lectura de un código QR, y dispondrá de un aviso automático a la salida de la sala para que realice el registro de salida manualmente. De esta manera se asegura la precisión del espacio reservado en salas. Además, la aplicación también cuenta con un sistema de notificaciones que permite avisar al usuario de la existencia de una reserva con una antelación de 10 minutos. Pulsando esta notificación el usuario accede a una vista en la que se mostrará el mapa de sitios de la sala con su asiento seleccionado, en la cual podrá modificar su reserva o realizar el registro de entrada. Por otro lado, se permite el acceso de usuarios administradores, solicitados bajo petición, que tendrán la posibilidad añadir, modificar y eliminar facultades y salas, incluyendo sus respectivos mapas de sitios, y podrán gestionar las noticias y eventos del tablón de anuncios de cada facultad. FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 152 de 196 Como un plus al proyecto se ha desarrollado otro servicio de apoyo a la gestión para los usuarios administradores, que permite la gestión de las facultades sin la necesidad de disponer de un dispositivo con sistema operativo Android. Se trata de un servicio web que consta de un acceso público con una autentificación de usuario, de manera que sólo podrán acceder al servicio los usuarios con perfil administrador. Desde este servicio podrán consultar, dar de alta y modificar facultades con la información que se muestra en la aplicación Android y, asimismo, tendrán la capacidad de eliminarlas junto con todas sus relaciones de las distintas funcionalidades. En conclusión, se ha desarrollado una aplicación que ayuda a tener una organización en las aulas, con la certeza de que, si un usuario reserva un asiento, va a poder utilizarlo. Al mismo tiempo, las universidades podrán comprobar la ocupación y utilización de las distintas salas con el objeto de prestar un mejor servicio a los usuarios de estas instalaciones. En este mismo enfoque, en los tiempos de pandemia en los que aún se encuentra la población, la planificación y gestión de los espacios es esencial, y ResUniversitas es capaz de satisfacer estas necesidades. Además, es importante señalar que para el desarrollo de este proyecto se han utilizado dos repositorios en GitHub, con una visibilidad privada para separar los desarrollos de la aplicación Android de la página web y mantener una seguridad en el acceso a los mismos. En estos repositorios se ha modificado la visibilidad para hacer pública la versión final de los desarrollos realizados. A continuación, se indican los enlaces tanto de la aplicación Android como de la aplicación web, de esta manera se puede acceder al código desarrollado: ● Aplicación Android: https://github.com/JoseMiguelC/TFG ● Aplicación web: https://github.com/JoseMiguelC/TFGweb Por otra parte, se ha generado un fichero APK [(54)] para permitir la instalación del software en un Smartphone. En referencia a la aplicación web, se ha publicado en el siguiente enlace: https://resuniversitas-c10b4.web.app/. Por último, para la publicación de los documentos que forman este proyecto se han subido los mismos a un repositorio en Google Drive (https://drive.google.com/drive/folders/1EbkW03SGrS8HrbV4H9C9mKywGlu0HCVH) proporcionado por Formularios de la Facultad de Informática. Dichos documentos son los siguientes: ● TFG-master.zip: Fichero que contiene el código actualizado del repositorio de la aplicación Android. FACULTAD DE INFORMÁTICA ResUniversitas Memoria ResUniversitas Página 153 de 196 ● TFGweb-master.zip: Fichero que contiene el código actualizado del repositorio de la aplicación web. ● ResUniversitas.apk: APK Instalable generado con la última versión del código del repositorio. ● Memoria ResUniversitas.pdf: El presente documento de la memoria del proyecto. ● Diagrama Gantt.xlsx: Diagrama de Gantt utilizado en la planificación del proyecto. Para poder acceder a la aplicación Android y a la aplicación web con el perfil de usuario administrador, se ha creado un usuario de prueba con el correo electrónico [email protected] y la contraseña “ResU1234”. 8.2. Trabajo a futuro Algunas mejoras de funcionalidad que se podrían desarrollar en los servicios son la siguientes: • Control de pertenencia a una universidad o facultad: Actualmente solo existe un perfil administrador que puede gestionar todas las facultades de la aplicación indistintamente de la universidad a la que pertenezcan. Para poder realizar una utilización de varias universidades independientemente se tendría que ampliar el control de acceso al nivel de la universidad para los usuarios administradores. Por tanto, solo tendrán acceso a las facultades que pertenezcan a la universidad del usuario. • Desarrollo en iOS: Para poder alcanzar al mayor número de usuarios posibles y que todos los mismos pudieran realizar usos de los servicios que proporciona la aplicación Android, sería necesario realizar el desarrollo de una nueva aplicación para el sistema operativo iOS. ● Ampliación de la gestión web: Hasta el momento, solo se permite una gestión web simple. Para poder englobar todas las funcionalidades que dispone la aplicación Android mediante los usuarios administradores, sería necesario realizar una ampliación de estas en la página web. Así se dispondría de una mayor accesibilidad para los usuarios administradores. ● Formulario de errores y mejoras: De cara a una mejora constante de los servicios prestados, se desarrollaría un formulario que permita informar errores producidos en la aplicación Android y en la página web, además de, recoger las necesidades de funcionalidades que no contienen los servicios. ● Ampliar patrones y arquitecturas: En cuanto a la aplicación Android, con el objetivo de facilitar el posterior desarrollo y mantenibilidad de la aplicación, sería adecuado cambiar ciertos aspectos de la arquitectura. Se podrían aplicar los principios de Clean Architecture ([55]), organizando el código en casos de uso entre