UVassistantSG

Universidad de Valladolid ESCUELA DE INGENIERÍA INFORMÁTICA (SG) Grado en Ingeniería Informática de Servicios y Aplicaciones UVassistantSG Alumno: Sergio Muñoz Gómez Tutor: José Vicente Álvarez Bravo Resumen El objetivo de este proyecto consiste en dar al lector una visión global sobre las diferentes necesidades que presentan los alumnos del campus de Segovia de la Universidad de Valladolid, sobre todo a los alumnos de primer ingreso. Este estudio se ejemplifica con el desarrollo del sistema móvil UVassistantSG. UVassistantSG es una aplicación móvil destinada a estos alumnos para proporcionarles una herramienta útil que les ayude con los principales problemas que suelen sufrir dentro del ámbito universitario. Para ello se ha recreado una pequeña red social donde puedan consultar problemas en foros comunitarios y enterarse de los nuevos eventos que organice la universidad, además de un sistema de localización basado en AR para hacer más sencillo la memorización de la estructura del edificio. Índice general Resumen ....................................................................................................................... 3 Índice de figuras ........................................................................................................... 8 Índice de tablas ........................................................................................................... 10 Capítulo 1 - INTRODUCCIÓN .................................................................................. 3 1.1. Motivación...................................................................................................... 3 1.2. Objetivos y Alcance ........................................................................................ 3 1.3. Árbol de características y características principales del sistema ..................... 4 1.4. Estructura del documento ................................................................................ 5 Capítulo 2 – Estado del arte ....................................................................................... 7 2.1. Introducción .................................................................................................... 7 2.2. Comparativa de plataformas software para la gestión de universidades ........... 7 2.3. Conclusiones................................................................................................. 12 Capítulo 3 – Planificación y estimación.................................................................... 13 3.1. Modelo de desarrollo .................................................................................... 13 3.2. Estimación .................................................................................................... 14 3.2.1. Estimación por puntos de función aplicando el método de Albrecht ....... 14 3.2.2. Número de entradas: .............................................................................. 14 3.2.3. Número de salidas: ................................................................................ 14 3.2.4. Número de consultas: ............................................................................. 15 3.2.5. Número de ficheros lógicos internos ...................................................... 15 3.2.6. Número de ficheros lógicos externos...................................................... 15 3.3. Presupuestos ................................................................................................. 17 3.3.1. Presupuesto de Hardware ....................................................................... 17 3.3.2. Presupuesto de Software ........................................................................ 17 3.3.3. Presupuesto de desarrollo ....................................................................... 17 3.3.4. Presupuesto total estimado ..................................................................... 17 3.4. Fases del trabajo y planificación temporal ..................................................... 18 3.5. Conclusiones................................................................................................. 19 Capítulo 4 – Análisis ................................................................................................. 23 4.1. Objetivos de negocio..................................................................................... 23 4.2. Actores ......................................................................................................... 23  ACT-01: Usuario no registrado ..................................................................... 23  ACT-02: Usuario registrado .......................................................................... 23  ACT-03: Alumno .......................................................................................... 23  ACT-04: Profesor ......................................................................................... 23  ACT-05: Organizador de eventos .................................................................. 24  ACT-06: Correo ............................................................................................ 24 4.3. Requisitos de usuario .................................................................................... 24 ACT-01: Usuario no registrado ............................................................................ 24 ACT-02: Usuario registrado ................................................................................. 25 ACT-03: Alumno ................................................................................................. 26 ACT-04: Profesor ................................................................................................ 27 ACT-05: Organizador de eventos ......................................................................... 28 4.3.1. Especificación de los Casos de Uso ........................................................ 29 4.4. Requisitos funcionales .................................................................................. 61 4.4.1. Característica 1: Gestión de la información ............................................ 61 4.4.2. Característica 2: Gestión de usuarios ...................................................... 62 4.4.3. Característica 3: Gestión de la comunicación ......................................... 63 4.4.4. Característica 4: Gestión de la localización ............................................ 65 4.5. Requisitos no funcionales ............................................................................. 66 4.5.1. Atributos de calidad ............................................................................... 66 4.5.2. Requisitos de interfaz externa ................................................................ 67 4.5.3. Requisitos de negocio ............................................................................ 67 4.6. Requisitos de información ............................................................................. 68 4.6.1. Modelo Entidad-Relación ...................................................................... 68 4.6.2. Diccionario de datos .............................................................................. 68 Capítulo 5 – Diseño ................................................................................................... 75 5.1. Arquitectura lógica ....................................................................................... 75 5.1.1. Arquitectura lógica a alto nivel .............................................................. 75 5.1.2. Arquitectura lógica detallada.................................................................. 76 5.2. Arquitectura física......................................................................................... 79 5.3. Diagrama de clases ....................................................................................... 80 5.3.1. Paquete modelo ..................................................................................... 81 5.3.2. Paquete Android .................................................................................... 82 5.3.3. Paquete Listener .................................................................................... 88 5.4. Diseño de la interfaz ..................................................................................... 88 5.5. Diagramas de secuencia .............................................................................. 108 5.6. Modelo lógico ............................................................................................. 114 Capítulo 6 – Implementación.................................................................................. 117 6.1. Servidor ...................................................................................................... 117 6.1.1. Módulo de Realtime Database ............................................................. 117 6.1.2. Módulo de Authentication.................................................................... 118 6.1.3. Módulo de Cloud Functions ................................................................. 119 6.1.4. Módulo de Cloud Storage .................................................................... 120 6.1.5. Módulo de Google Analytics ............................................................... 121 6.2. Tecnologías utilizadas ................................................................................. 121 6.3. Herramientas utilizadas ............................................................................... 123 6.4. Detalles de implementación ........................................................................ 124 6.5. Detalles de despliegue ................................................................................. 129 6.5.1. Firebase ............................................................................................... 130 6.5.2. Arcore – Sceneform ............................................................................. 132 6.5.3. Cron-job .............................................................................................. 134 Capítulo 7 – Pruebas ............................................................................................... 137 7.1. Pruebas de caja negra .................................................................................. 137 Capítulo 8 – Manuales ............................................................................................ 145 8.1. Manual de instalación ................................................................................. 145 8.2. Manual de usuario ....................................................................................... 145 Capítulo 9 – Conclusiones y líneas futuras............................................................. 161 9.1. Conclusiones............................................................................................... 161 9.2. Líneas futuras ............................................................................................. 162 Capítulo 10 – Webgrafía ......................................................................................... 163 Apéndice 1 – Contenido del CD-ROM ................................................................... 165 Índice de figuras Figura 1 Árbol de características .............................................................................. 4 Figura 2 Plataforma web Uva.................................................................................... 8 Figura 3 Campus virtual Uva ..................................................................................... 8 Figura 4 Sigma Uva ................................................................................................... 9 Figura 5 UVa app ....................................................................................................... 9 Figura 6 Academic Mobile UVa .............................................................................. 10 Figura 7 Web Escuela Informática Segovia .......................................................... 10 Figura 8 Plataforma web UPM ................................................................................ 11 Figura 9 Plataforma web UMa ................................................................................ 11 Figura 10 Modelo Incremental ................................................................................ 13 Figura 11 Diagrama de Gantt.................................................................................. 19 Figura 12 Diagrama de Actores .............................................................................. 24 Figura 13 Diagrama casos de uso Usuario no registrado .................................... 25 Figura 14 Diagrama casos de uso Usuario registrado ......................................... 26 Figura 15 Diagrama casos de uso Alumno ........................................................... 27 Figura 16 Diagrama casos de uso Profesor .......................................................... 28 Figura 17 Diagrama casos de uso Organizador de eventos ............................... 28 Figura 18 Diagrama Entidad – Relación ................................................................ 68 Figura 19 Arquitectura lógica .................................................................................. 76 Figura 20 Diagrama de despliegue ........................................................................ 79 Figura 21 Diagrama de clases, representación de paquetes .............................. 80 Figura 22 Diagrama de clases, representación del paquete modelo.................. 81 Figura 23 Diagrama de clases, representación del paquete Android ................. 82 Figura 24 Diagrama de clases, representación del paquete Android, sección principal ..................................................................................................................... 83 Figura 25Diagrama de clases, representación del paquete Android, sección Usuario ...................................................................................................................... 83 Figura 26Diagrama de clases, representación del paquete Android, sección PDF ............................................................................................................................ 84 Figura 27 Diagrama de clases, representación del paquete Android, sección AR ................................................................................................................................... 84 Figura 28 Diagrama de clases, representación del paquete Android, sección QR.............................................................................................................................. 85 Figura 29Diagrama de clases, representación del paquete Android, sección Foros ......................................................................................................................... 86 Figura 30 Diagrama de clases, representación del paquete Android, sección evento ........................................................................................................................ 87 Figura 31 Diagrama de clases, representación del paquete Listener ................ 88 Figura 32 Diagrama de secuencia de crear foro de asistencia ......................... 109 Figura 33 Diagrama de secuencia de Editar evento........................................... 109 Figura 34 Diagrama de secuencia de visualizar imagen AR ............................. 110 Figura 35 Diagrama de secuencia de Listar mis foros académicos ................. 110 Figura 36 Diagrama de secuencia de hacer login .............................................. 111 Figura 37 Diagrama de secuencia de visualizar modelos 3D............................ 112 Figura 38 Diagrama de secuencia de registrarse ............................................... 113 Figura 39 Diagrama de secuencia de visualizar planos ..................................... 113 Figura 40 Diagrama de secuencia de cerrar sesión ........................................... 114 Figura 41 Modelo lógico de datos ........................................................................ 114 Figura 42 Extracto de layout parte 1 .................................................................... 124 Figura 43 Extracto de layout parte 2 .................................................................... 125 Figura 44 Extracto de layout parte 3 .................................................................... 125 Figura 45 Extracto de layout parte 4 .................................................................... 126 Figura 46 Extracto de la funcionalidad de Visualizar modelos 3D parte 1 ....... 126 Figura 47 Extracto de la funcionalidad de Visualizar modelos 3D parte 2 ....... 127 Figura 48 Extracto de la Cloud Function parte 1 ................................................ 128 Figura 49 Extracto de la Cloud Function parte 2 ................................................ 128 Figura 50 Extracto de la Cloud Function parte 3 ................................................ 129 Figura 51 Consola de Firebase para Google Analytics ...................................... 130 Figura 52 Consola de Firebase para Authentication .......................................... 131 Figura 53 Consola de Firebase para Database .................................................. 131 Figura 54 Consola de Firebase para Storage ..................................................... 132 Figura 55 Consola de Firebase para Functions .................................................. 132 Figura 56 Comprobaciones de compatibilidad e instalación de ARcore .......... 133 Figura 57 Creación de una tarea automática en Cron-job ................................. 135 Figura 58 Lista de tareas en Cron-job .................................................................. 135 Figura 59 Prueba caja negra................................................................................. 137 Figura 60 Pantalla principal ................................................................................... 146 Figura 61 Menús principales ................................................................................. 147 Figura 62 Login ....................................................................................................... 148 Figura 63 Registro .................................................................................................. 148 Figura 64 Ver perfil ................................................................................................. 149 Figura 65 Confirmación borrado de perfil ............................................................ 149 Figura 66 Editar perfil............................................................................................. 150 Figura 67 Ver y editar eventos .............................................................................. 151 Figura 68 Ver detalles foro .................................................................................... 152 Figura 69 Buscar usuario ...................................................................................... 153 Figura 70 Ver planos .............................................................................................. 154 Figura 71 Ver modelos 3D .................................................................................... 155 Figura 72 Escanear imagen AR ............................................................................ 156 Figura 73 Conceder permisos cámara ................................................................. 157 Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 4 Con el fin de conseguir una buena experiencia de usuario, la aplicación móvil contará con componentes visuales como AR, desarrollada con el motor de Google ARcore, que permitirá al alumno usar su móvil para escanear diferentes imágenes disponibles por el campus y así aumentar la información publicada. También se contempla la posibilidad, si fuera posible, la construcción de modelos muy básicos en 3D de la arquitectura de las diferentes plantas del campus para así indicar con mayor precisión la localización de las diferentes zonas que cuenta la universidad, también implementadas en AR, si las imágenes de los planos no fueran suficientes para el alumno. 1.3. Árbol de características y características principales del sistema El árbol de características es una representación gráfica a alto nivel de todas las características que ofrece el producto agrupadas de una forma lógica facilitando una visión completa de forma sencilla. Consta de características principales representadas por ramas que nacen del tronco, que a su vez se pueden dividir en sub-características y así sucesivamente hasta llegar a un nivel de concreción máximo. Las características son agrupaciones de elementos del sistema que tienen una función común permitiendo la gestión de estas de una manera más sencilla e intuitiva. Figura 1 Árbol de características Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 5  C-1: Gestión de la información. Se ofrecerá toda aquella información que necesite el alumno tanto académica como de entretenimiento. o C-1.1: Buscar. Se ofrecerá la posibilidad de filtrar la información por categorías para mayor rapidez. o C-1.2: Notificaciones. Se ofrecerá la posibilidad de ser notificado de aquellas publicaciones que admitan seguimiento. o C-1.3: Visualizar. Se permite visualizar la información publicada.  C-2: Gestión de los usuarios. Se ofrecerá a los usuarios herramientas para gestionar su perfil.  C-3: Gestión de la comunicación. Se ofrecerá al usuario diferentes formas de comunicarse con otros usuarios dependiendo de las necesidades de este. o C-3.1: Foro. Se ofrecerá a los alumnos y profesores la posibilidad de crear foros sobre temas de su interés. o C-3.2: Evento. Se ofrecerá a los servicios universitarios la posibilidad de crear eventos para alguna actividad concreta. o C-3.3: Enviar mensaje. Se ofrecerá a los usuarios la opción de ponerse en contacto con otro usuario de manera privada y personal.  C-4: Gestión de la localización. Se dispondrá al usuario la opción de usar diferentes herramientas para la localización de diferentes ubicaciones importantes dentro del campus. 1.4. Estructura del documento En este apartado realizaremos un análisis del contenido del documento en el que describiremos los capítulos que lo forman, y así facilitar su lectura. La memoria de este documento está formada por 4 bloques que comprenden diferentes capítulos, cada uno formado por diferentes apartados que ayudan a mantener la correcta estructura del documento.  Bloque 1. Descripción del proyecto. o Capítulo 1, Introducción: este capítulo expondrá al lector el contexto del trabajo que se va a desarrollar. Está formado por 4 apartados. En ellos veremos la motivación existente para decidir desarrollar este proyecto, objetivos y alcance que cumplirá el sistema, las características que compondrá y el apartado en el que nos encontramos. o Capítulo 2, Estado del arte: en este capítulo se realizará un análisis y comparativa de los sistemas que existen actualmente en el mercado con funcionalidades similares a nuestra aplicación. o Capítulo 3, Planificación: en este capítulo se explica el plan de trabajo a la hora de elaborar este proyecto. Se realizan las estimaciones temporales, detallando la metodología que se va a utilizar. También se realiza el presupuesto de desarrollo de la herramienta. Con todo ello se explicarán unas conclusiones.  Bloque 2. Documentación técnica. o Capítulo 4, Análisis: este capítulo, junto con el capítulo de diseño, son los más importantes de este documento ya que proporcionan la información más vital para el desarrollo del sistema. En este capítulo se Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 6 analiza el funcionamiento del sistema. El análisis se realiza desde tres puntos de vista, desde el del usuario (requisitos de usuario), desde el sistema (requisitos funcionales y no funcionales) y desde el de los datos (requisitos de información). o Capítulo 5, Diseño: en este capítulo encontraremos cómo se desarrollará el sistema y cuál será su comportamiento. Para ello se explica la arquitectura lógica y física que tendrá el sistema, y los diferentes diagramas a través de los cuales se implementará posteriormente el sistema. o Capítulo 6, Implementación: en este capítulo se explican las tecnologías y herramientas que se utilizarán para el desarrollo del sistema. o Capítulo 7, Pruebas: en este capítulo se detallan las pruebas realizadas durante y después del desarrollo de la aplicación.  Bloque 3, Manuales. o Capítulo 8, Manuales: en este capítulo está formado por dos apartados. En el primero veremos el manual de instalación y en el segundo veremos el manual de uso de la aplicación.  Bloque 4, Conclusiones y bibliografía. o Capítulo 9, Conclusiones y líneas futuras: en este capítulo se exponen las conclusiones obtenidas en el desarrollo de este proyecto y las líneas futuras donde se detallan las mejoras, a corto y largo plazo, que se pueden añadir al sistema. o Capítulo 10, Bibliografía: en este capítulo se mostrarán los recursos utilizados durante el proyecto. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 7 Capítulo 2 – Estado del arte 2.1. Introducción Antes de desarrollar este TFG se hizo un estudio de diferentes aplicaciones que dispongan otras universidades que cumplan con la misma o parecida funcionalidad que se quiere que proporcione este proyecto. Este estudio se ha realizado tanto en universidades públicas como en universidades privadas para tener un mayor espectro de comparaciones. Y a su vez, la investigación engloba tanto a plataformas móviles (Android e IOS) como plataformas web. 2.2. Comparativa de plataformas software para la gestión de universidades En este apartado vamos a analizar algunas plataformas web y móvil de diferentes universidades para ver la funcionalidad que tienen y compararla con UVassistantSG.  UVa La primera universidad que se va a comparar es la propia Uva, ya que ver las plataformas que tiene nos ayudará a ver qué más puede aportar o mejorar nuestra aplicación. De manera más general tenemos la plataforma web de la Uva (www.uva.es) que nos proporciona información general sobre títulos académicos, centros educativos, eventos, noticias y acceso a otras plataformas de la propia universidad para otras gestiones como el campus virtual. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 8 Figura 2 Plataforma web Uva Para la gestión de la información académica para un alumno o profesor concreto, tenemos el campus virtual. El cuál permite crear grupos por asignaturas donde comunicarse y compartir información publicada. Figura 3 Campus virtual Uva Esta universidad también dispone de una plataforma donde realizar toda la gestión académica del alumno, como la matriculación de grado, máster o doctorado, revisión de expediente, información personal del alumno, información para trámite de becas, Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 9 información para trámite de intercambios o información para trámite de prácticas en empresa. Figura 4 Sigma Uva Por otro lado, tenemos diversas aplicaciones móviles como son Uva App, que nos permite tener en un mismo sitio información académica de la Uva, noticias, eventos y nos permite crear chats y grupos para comunicarnos con otros usuarios que usen esta app. Figura 5 UVa app Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 10 Otra aplicación es la de Academic Mobile Uva, la cual permite revisar las notas publicadas en las diferentes convocatorias de las diferentes asignaturas de las diferentes carreras que se cursen en esta universidad. Figura 6 Academic Mobile UVa Por último, también cabe mencionar que las diferentes escuelas que trabajan en la Uva disponen de su propia plataforma web donde disponen de contenido más específico de las carreras que imparten. Figura 7 Web Escuela Informática Segovia Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 11  Universidad Politécnica de Madrid UPM La universidad politécnica de Madrid dispone de una plataforma web (http://www.upm.es/) muy similar a la que dispone la Uva, ya que también comparte información general de la universidad, tanto académica como actividades. También dispone de un blog y un campus virtual. Figura 8 Plataforma web UPM A su vez, esta universidad dispone de diferentes aplicaciones móviles. La más relevante a este estudio es “Estudiantes UPM” la cual tiene información general de la universidad, noticias, eventos, tasas de matrícula. Tiene información personal como notas y expedientes. Es una aplicación muy completa, ya que junta en una misma plataforma muchas funcionalidades, pero no tiene un aspecto social para la comunicación entre integrantes de la universidad.  Universidad de Málaga UMa Esta universidad cuenta con una aplicación web genérica que trata información académica, noticias y eventos. A diferencia de la aplicación web de la Uva, ésta cuenta con un diseño mucho más agradable e intuitivo que permite diferenciar y encontrar información de forma mucho más rápida. Figura 9 Plataforma web UMa Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 12 También cuenta con una aplicación móvil muy completa llamada UMA, al igual que ocurría con la de la UPM. En este caso tampoco tenemos una funcionalidad de comunicación a parte de los medios de contacto externos, como correos, que pone a disposición.  Universidad Alfonso X el Sabio Más que su plataforma web, lo que más destaca esta universidad es en su aplicación móvil. Dispone de una de las más completas que hay en las universidades de España, ya que aparte de reunir toda la información típica que reúnen las aplicaciones de otras universidades (información académica, noticias, eventos, etc.), dispone de otra información muy útil para el alumno como mapas de los edificios para ayudar a la localización, una versión móvil del campus virtual, reserva de las pistas deportivas, información de la biblioteca, menú de cafetería y demás. Es cierto que a cuanto a funcionalidad es muy completa, pero esto también trae inconvenientes. El mayor problema que tiene esta aplicación es la lentitud con la que maneja, ya que los tiempos de carga son muy grandes y es bastante tedioso encontrar la información que necesitamos.  Universidad Francisco de Vitoria Respecto a su plataforma web no tiene mayor funcionalidad de la que encontramos en la de la Uva. Aunque cabe destacar que es más vistosa y usable de todas las mencionadas, utilizando animaciones y una estructura muy intuitiva. En este caso, no he encontrado una aplicación móvil para esta universidad. 2.3. Conclusiones Tras estudiar diferentes plataformas que ofrecen diferentes universidades, ninguna cumple con todos los objetivos que se quieren cumplir. Algunas universidades tienen las funcionalidades en plataformas diferentes, otras tienen escasas funcionalidades y otras no aportan el concepto de comunidad que buscamos con este TFG. Es considerable remarcar que UVassistantSG unificará en una sola plataforma móvil toda la información que proporcionan las diferentes escuelas que trabajan en el campus de Segovia de la Uva. De esta manera, todos los alumnos tendrán la misma aplicación que ofertará una gran variedad de funcionalidades útiles para los alumnos. Para el éxito de esta aplicación es muy importante su usabilidad, ya que se tiene que conseguir que el usuario se sienta cómodo usando esta aplicación para cualquier consulta que necesite de manera rápida e intuitiva. Este aspecto es esencial a la hora de crear una comunidad de usuarios que se comuniquen entre ellos para ofrecer cualquier información o alertar de cualquier problema que surja. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 13 Capítulo 3 – Planificación y estimación 3.1. Modelo de desarrollo Debido al tamaño del proyecto, el tipo que es (TFG) y el equipo que lo desarrolla (yo mismo), considero que el modelo más apropiado para el desarrollo de este TFG es el modelo incremental. El modelo de desarrollo iterativo se basa en el modelo tradicional en cascada al que se le aplican varios ciclos de forma iterativa. Cada iteración se centra en la construcción de incrementos de funcionalidades de la plataforma. La manera de usar este modelo consiste en crear un primer incremento, utilizando un modelo en cascada, en el que se contemplen los requisitos básicos. Estos requisitos se priorizan para saber cuáles son los más importantes, por tanto, cuáles son los primeros que hay que satisfacer. Durante el resto de las iteraciones se va consiguiendo mayor conciencia de la estructura del proyecto y se va teniendo la capacidad para incluir nuevos requisitos que no se hayan incluido hasta el momento por diferentes motivos, como que no sea tan prioritarios o porque sean nuevos requisitos que hayan surgido. Figura 10 Modelo Incremental Debido al desarrollo del TFG, el trabajo que se presenta en esta documentación será referencia únicamente a la primera iteración. Es cierto que se harán revisiones, pero no las contaremos como iteraciones ya que no supone un aumento de requisitos o funcionalidad, será únicamente para correcciones en la documentación. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 20 Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 21 Bloque 2. Documentación técnica Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 22 Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 23 Capítulo 4 – Análisis 4.1. Objetivos de negocio  OBJ-01: Conseguir aumentar el número de nuevos alumnos al campus de Segovia de la Uva  OBJ-02: Conseguir aumentar la difusión y participación de los alumnos en las actividades organizadas por la universidad.  OBJ-03: Orientar a los alumnos sobre la localización de las diferentes zonas que dispone el campus.  OBJ-04: Mejorar la cantidad y la calidad de la información académica de interés para el alumno.  OBJ-05: Facilitar y agilizar las gestiones burocráticas entre el alumno y la universidad.  OBJ-06: Crear un lugar virtual donde los alumnos puedan ayudarse entre ellos junto a los profesores para solucionar problemas académicos. 4.2. Actores  ACT-01: Usuario no registrado El actor usuario no registrado representa a cualquier usuario que accede al sistema sin estar registrado. Sus funciones son la capacidad de registrarse en el sistema y acceder a información pública de interés para cualquier alumno, como por ejemplo actividades programadas dentro del ámbito universitario.  ACT-02: Usuario registrado El actor usuario registrado representa a cualquier usuario registrado en el sistema y que ha seguido el proceso de identificación. Sus funciones son las de buscar información pública, como un usuario no registrado, y además tendrá un perfil que podrá gestionar.  ACT-03: Alumno El actor alumno representa a todo alumno matriculado en el campus de Segovia en la Uva. Sus funciones son gestiones burocráticas como temas de matrícula, convalidaciones, incidencias. Búsqueda de información como horarios, localización de zonas relevantes, actividades organizadas como un usuario no registrado, pero a su vez orientado al grado que esté desarrollando. Comunicación con otros actores como profesorado, otros alumnos u otros departamentos.  ACT-04: Profesor El actor profesor representa a todos los profesores que trabajen en el campus de Segovia de la Uva. Aunque las funciones de los profesores sean comunes para todos, un profesor solo podrá gestionar aquella información que pertenezca a los grados que imparta. Estas funciones son la de publicación de contenido relevante a los grados que imparta, mensajes generales, medio de contacto con los alumnos y otros departamentos. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 24  ACT-05: Organizador de eventos El actor organizador de eventos representa a toda persona encargada de la gestión de información pública, independientemente del departamento al que pertenezca dentro del campus. Sus funciones son la de publicar actividades durante el curso, ya sean actividades continuadas como un curso de idiomas o actividades puntuales como una carrera. También podrá gestionar la participación de alumnos en dichas actividades y comunicarse con dichas personas para un trato más individual.  ACT-06: Correo El actor Correo no representa a ningún Stakeholder, pero interactúa con el actor Usuario no registrado para enviar un e-mail de confirmación y así asegurar la identidad del usuario en el proceso de registro. Al ser un servicio externo al sistema, es necesario representarlo como un actor. Figura 12 Diagrama de Actores 4.3. Requisitos de usuario ACT-01: Usuario no registrado  UC-101: Registro en la plataforma. El actor Usuario no registrado podrá solicitar al sistema la creación de una cuenta para acceder a la plataforma. El actor secundario Correo enviará un e-mail de validación al Usuario no registrado.  UC-102: Identificarse. El Usuario no registrado podrá solicitar al sistema hacer log-in para ser reconocido como usuario registrado.  UC-103: Visualizar información académica. El Usuario no registrado podrá obtener información detallada de cualquier plataforma web asociada con la Uva.  UC-104: Visualizar información de eventos. El Usuario no registrado podrá obtener información detallada de un evento publicado.  UC-105: Visualizar información de foros. El Usuario no registrado podrá obtener información detallada de los comentarios publicados en un foro concreto. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 25  UC-106: Buscar información. El Usuario no registrado podrá buscar información publicada filtrada por categorías o palabras. Figura 13 Diagrama casos de uso Usuario no registrado ACT-02: Usuario registrado  UC-201: Ver perfil de usuario. El actor Usuario registrado podrá obtener información detallada sobre su perfil de usuario.  UC-202: Modificar perfil de usuario. El actor Usuario registrado podrá modificar realizar cambios sobre datos de su perfil de usuario.  UC-203: Des identificarse. El actor Usuario registrado podrá dejar de estar identificado en el sistema.  UC-204: Baja perfil. El actor Usuario registrado podrá dejar de estar registrado en el sistema.  UC-205: Escribir comentario. El actor Usuario registrado podrá escribir un comentario en un foro o en un evento.  UC-206: Borrar comentario. El actor Usuario registrado podrá borrar un comentario que haya escrito.  UC-207: Asistir a evento. El actor Usuario registrado podrá indicar la participación a un evento.  UC-208: Escribir mensaje. El actor Usuario registrado podrá enviar un mensaje privado a otro usuario para ponerse en contacto de manera directa.  UC-209: Listar conversaciones. El actor Usuario registrado podrá listar las conversaciones privadas que tenga con otro usuario. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 26  UC-210: Borrar mensaje. El actor Usuario registrado podrá borrar un mensaje o la conversación entera con otro usuario.  UC-211: Visualizar conversación. El actor Usuario registrado podrá visualizar los mensajes que contenga una conversación.  UC-212: Crear notificación. El actor Usuario registrado podrá crear una notificación sobre algún evento o foro que desee mantenerse notificado.  UC-213: Borrar notificación. El actor Usuario registrado podrá dejar de ser notificado sobre nuevos mensajes en un foro o evento.  UC-214: Listar favoritos. El actor Usuario registrado podrá listar aquellos temas que haya creado notificación.  UC-215: Buscar usuario. El actor Usuario registrado podrá buscar el perfil público de cualquier usuario registrado. Figura 14 Diagrama casos de uso Usuario registrado ACT-03: Alumno  UC-301: Crear foro asistencia. El actor Alumno podrá crear un foro colaborativo en donde se podrán discutir temas de interés para otros alumnos.  UC-302: Borrar foro de asistencia. El actor Alumno podrá borrar aquellos foros de asistencia que haya creado si considera que han dejado de aportar ayuda. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 27  UC-303: Listar mis foros de asistencia. El actor Alumno podrá listar aquellos foros de asistencia que haya creado.  UC-304: Acceso a Sigma. El actor Alumno podrá acceder con un enlace a la plataforma Sigma de la Uva para procesos burocráticos.  UC-305: Acceso a la página de la escuela. El actor Alumno dispondrá de un acceso a la plataforma web de la carrera que esté cursando para consultar información relevante.  UC-306: Acceso al campus virtual. El actor Alumno dispondrá de un acceso al campus virtual de la universidad.  UC-307: Visualizar planos campus. El actor Alumno dispondrá de unos planos informativos para ayudarlo a localizar las zonas más relevantes del campus.  UC-308: Visualizar modelo 3D del campus. El actor Alumno podrá utilizar AR para visualizar un modelo 3D del campus con etiquetas de las zonas más relevantes del campus.  UC-309: Escaneo de imágenes AR. El actor Alumno podrá utilizar AR para escanear determinadas imágenes distribuidas por el campus para poder obtener más información.  UC-310: Escaneo de QR. El actor Alumno podrá escanear imágenes QR para tener acceso a más información solicitada. Figura 15 Diagrama casos de uso Alumno ACT-04: Profesor  UC-401: Crear foro académico. El actor Profesor podrá crear un foro académico donde tratar asuntos sobre las asignaturas que imparta.  UC-402: Borrar foro académico. El actor Profesor podrá borrar aquellos foros académicos que haya creado.  UC-403: Listar foro académico. El actor Profesor podrá listar aquellos foros académicos que haya creado. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 28 Figura 16 Diagrama casos de uso Profesor ACT-05: Organizador de eventos  UC-501: Crear evento. El actor Organizador de eventos podrá crear un evento que represente algún acontecimiento que se vaya a realizar en el ámbito universitario.  UC-502: Borrar evento. El actor Organizador de eventos podrá borrar un evento que haya creado.  UC-503: Modificar evento. El actor Organizador de eventos podrá modificar los detalles de un evento que haya creado.  UC-504: Listar eventos. El actor Organizador de eventos podrá listar aquellos eventos que haya creado. Figura 17 Diagrama casos de uso Organizador de eventos Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 29 4.3.1. Especificación de los Casos de Uso UC-101 Registro en la plataforma Autor Sergio Muñoz Gómez Objetivos asociados OBJ-01: Conseguir aumentar el número de nuevos alumnos al campus de Segovia de la Uva Requisitos asociados Req. de usuario UC-101 Registro en la plataforma Descripción El actor Usuario no registrado podrá solicitar al sistema la creación de una cuenta para acceder a la plataforma. El actor secundario Correo enviará un e-mail de validación al Usuario no registrado. Precondición Ninguna detectada Secuencia normal Paso Acción p1 El actor usuario no registrado solicitará al sistema registrarse. p2 El sistema solicitará al actor que introduzca los campos de usuario, contraseña, correo de la universidad, rol en la aplicación P3 El actor indicará los campos solicitados en el paso 2. p4 El sistema recibirá los datos y comprobará que son correctos P5 El sistema enviará un e-mail al correo universitario proporcionado por el actor Usuario. P6 El actor accederá al correo universitario de forma externa para confirmar su identidad en el registro. P7 El sistema recibirá la confirmación de email y activará la cuenta. El caso de uso ha concluido. Postcondición El actor Usuario se ha registrado en la plataforma y podrá realizar el caso de uso UC-102 identificarse. Excepciones Paso Acción P4 Si alguno de los campos no es correcto el sistema informará de la situación al actor Usuario a continuación se volverá a realizar el paso 2 de este caso de uso. P7 Si el actor Usuario no confirma el correo en menos de 5 minutos, el sistema lo reconocerá como un registro fallido y borrará toda la información relacionada con la solicitud, a continuación, el caso de uso queda sin efecto. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 36 P2 El sistema presentará al Usuario registrado los datos de su perfil. P3 El Usuario registrado modificará los datos. P4 El sistema almacenará los nuevos datos y se lo notificará al usuario. El caso de uso ha concluido. Postcondición El actor usuario registrado ha modificado su perfil de usuario. Excepciones Paso Acción P4 Si el usuario no ha introducido algún dato, el sistema se lo notificará y volverá a ejecutar el paso 2. Importancia Normal Tabla 13 UC-202 Modificar perfil usuario UC-203 Des identificarse Autor Sergio Muñoz Gómez Objetivos asociados OBJ-01: Conseguir aumentar el número de nuevos alumnos al campus de Segovia de la Uva Requisitos asociados Req. de usuario UC-203: Des identificarse. Descripción El actor Usuario registrado podrá dejar de estar identificado en el sistema. Precondición -El actor que ejecuta este caso de uso ha de ser un Usuario registrado o un descendiente de este. - El actor ha de estar identificado previamente. Secuencia normal Paso Acción p1 El actor Usuario registrado solicitará la salida del sistema. P2 El sistema des identificará al Usuario registrado y le mostrará un mensaje informándole de ello. El caso de uso ha concluido. Postcondición El actor usuario registrado ha modificado su perfil de usuario. Excepciones Paso Acción Importancia Normal Tabla 14 UC-203 Des identificarse Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 37 UC-204 Baja perfil Autor Sergio Muñoz Gómez Objetivos asociados OBJ-01: Conseguir aumentar el número de nuevos alumnos al campus de Segovia de la Uva Requisitos asociados Req. de usuario UC-204: Baja perfil. Descripción El actor Usuario registrado podrá dejar de estar registrado en el sistema Precondición -El actor que ejecuta este caso de uso ha de ser un Usuario registrado o un descendiente de este. - El actor ha de estar identificado previamente. Secuencia normal Paso Acción p1 El actor Usuario registrado solicitará la baja del sistema. P2 El sistema avisará al usuario de la pérdida de todos sus datos y le pedirá una confirmación. P3 El actor Usuario registrado aceptará la confirmación. P4 El sistema borrará toda la información guardada del perfil del usuario. El caso de uso ha concluido. Postcondición El actor usuario registrado ha eliminado su perfil. Excepciones Paso Acción P2 Si el actor usuario registrado rechaza la confirmación de baja el caso de uso queda sin efecto. Importancia Normal Tabla 15 UC-204 Baja perfil UC-205 Escribir comentario Autor Sergio Muñoz Gómez Objetivos asociados OBJ-01: Conseguir aumentar el número de nuevos alumnos al campus de Segovia de la Uva. OBJ-02: Conseguir aumentar la difusión y participación de los alumnos en las actividades organizadas por la universidad. OBJ-06: Crear un lugar virtual donde los alumnos puedan ayudarse entre ellos junto a los profesores para solucionar problemas académicos. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 38 Requisitos asociados Req. de usuario UC-205: Escribir comentario. Descripción El actor Usuario registrado podrá escribir un comentario en un foro o en un evento. Precondición -El actor que ejecuta este caso de uso ha de ser un Usuario registrado o un descendiente de este. Secuencia normal Paso Acción p1 El actor Usuario registrado solicitará escribir un comentario. P2 El sistema le mostrará unos campos y herramientas para añadir dicha información P3 El actor Usuario registrado escribirá el comentario. P4 El sistema almacenará el comentario e informará al usuario de que se ha añadido correctamente. El caso de uso ha concluido. Postcondición El Usuario registrado ha añadido un comentario Excepciones Paso Acción P4 Si el actor no introduce ningún comentario, el sistema le informará sobre ello. A continuación, el caso de uso finaliza. Importancia Muy baja Tabla 16 UC-205 Escribir comentario UC-206 Borrar comentario Autor Sergio Muñoz Gómez Objetivos asociados OBJ-01: Conseguir aumentar el número de nuevos alumnos al campus de Segovia de la Uva. OBJ-02: Conseguir aumentar la difusión y participación de los alumnos en las actividades organizadas por la universidad. OBJ-06: Crear un lugar virtual donde los alumnos puedan ayudarse entre ellos junto a los profesores para solucionar problemas académicos. Requisitos asociados Req. de usuario UC-206: Borrar comentario. Descripción El actor Usuario registrado podrá borrar un comentario que haya escrito Precondición -El actor que ejecuta este caso de uso ha de ser un Usuario registrado o un descendiente de este. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 39 Secuencia normal Paso Acción p1 El actor Usuario registrado solicitará borrar un comentario. P2 El sistema le pedirá confirmación para borrar el comentario de manera definitiva. P3 El actor Usuario registrado aceptará la confirmación para borrar el comentario. P4 El sistema borrará el comentario y notificará que el borrado ha sido llevado a cabo satisfactoriamente. El caso de uso ha concluido. Postcondición El Usuario registrado ha borrado un comentario Excepciones Paso Acción P4 Si el actor no confirma el borrado, el sistema no borrará el comentario. A continuación, el caso de uso finaliza. Importancia Muy baja Tabla 17 UC-206 Borrar comentario UC-207 Asistir evento Autor Sergio Muñoz Gómez Objetivos asociados OBJ-01: Conseguir aumentar el número de nuevos alumnos al campus de Segovia de la Uva. OBJ-02: Conseguir aumentar la difusión y participación de los alumnos en las actividades organizadas por la universidad. Requisitos asociados Req. de usuario UC-207: Asistir evento. Descripción El actor Usuario registrado podrá indicar la participación a un evento Precondición -El actor que ejecuta este caso de uso ha de ser un Usuario registrado o un descendiente de este. Secuencia normal Paso Acción p1 El actor Usuario registrado solicitará la asistencia al evento. P2 El sistema notificará que la asistencia se ha sido realizada con éxito y actualizará el número de asistencia. El caso de uso ha concluido. Postcondición El usuario registrado estará guardado como asistente al evento. Excepciones Paso Acción Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 40 P2 Si el actor ya había indicado la asistencia al evento esta acción se interpretará como que ya no va a asistir al evento, se actualizará el número de asistencia y el caso de uso finalizará. Importancia Muy baja Tabla 18 UC-207 Asistir evento UC-208 Escribir mensaje Autor Sergio Muñoz Gómez Objetivos asociados OBJ-01: Conseguir aumentar el número de nuevos alumnos al campus de Segovia de la Uva. OBJ-06: Crear un lugar virtual donde los alumnos puedan ayudarse entre ellos junto a los profesores para solucionar problemas académicos. Requisitos asociados Req. de usuario UC-208: Escribir mensaje. Descripción El actor Usuario registrado podrá enviar un mensaje privado a otro usuario para ponerse en contacto de manera directa. Precondición -El actor que ejecuta este caso de uso ha de ser un Usuario registrado o un descendiente de este. Secuencia normal Paso Acción p1 El actor Usuario registrado solicitará enviar un mensaje a un usuario concreto. P2 El sistema solicitará al usuario que escriba el mensaje. P3 El usuario escribirá el nuevo mensaje. P4 El sistema añadirá el mensaje escrito a la conversación que tenga con el destinatario para notificar que se ha enviado correctamente. El caso de uso ha concluido. Postcondición El Usuario registrado habrá mandado un mensaje a su destinatario Excepciones Paso Acción P2 Si el actor no escribe un mensaje el caso de uso queda sin efecto. Importancia Normal Tabla 19 UC-208 Escribir mensaje Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 41 UC-209 Listar conversaciones Autor Sergio Muñoz Gómez Objetivos asociados OBJ-01: Conseguir aumentar el número de nuevos alumnos al campus de Segovia de la Uva. OBJ-06: Crear un lugar virtual donde los alumnos puedan ayudarse entre ellos junto a los profesores para solucionar problemas académicos. Requisitos asociados Req. de usuario UC-209: Listar conversaciones. Descripción El actor Usuario registrado podrá listar las conversaciones privadas que tenga con otro usuario Precondición -El actor que ejecuta este caso de uso ha de ser un Usuario registrado o un descendiente de este. Secuencia normal Paso Acción p1 El actor Usuario registrado solicitará listar todas las conversaciones creadas que tenga con otros usuarios. P2 El sistema mostrará todas las conversaciones que tenga ese usuario. El caso de uso ha concluido. Postcondición El Usuario registrado ha podido ver todas las conversaciones que tiene. Excepciones Paso Acción P2 Si el actor no dispone de ninguna conversación se le notificará y el caso de uso quedará sin efecto. Importancia Normal Tabla 20 UC-209 Listar conversaciones UC-210 Borrar mensaje Autor Sergio Muñoz Gómez Objetivos asociados OBJ-01: Conseguir aumentar el número de nuevos alumnos al campus de Segovia de la Uva. OBJ-06: Crear un lugar virtual donde los alumnos puedan ayudarse entre ellos junto a los profesores para solucionar problemas académicos. Requisitos asociados Req. de usuario UC-210: Borrar mensaje. Descripción El actor Usuario registrado podrá borrar un mensaje o la conversación entera con otro usuario Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 42 Precondición -El actor que ejecuta este caso de uso ha de ser un Usuario registrado o un descendiente de este. Secuencia normal Paso Acción p1 El actor Usuario registrado solicitará borrar un comentario. P2 El sistema notificará del borrado del mensaje y se actualizará la conversación. P2.1 Si el usuario registrado borra todos los mensajes de la conversación se entenderá como un borrado de la conversación. El caso de uso ha concluido. Postcondición El Usuario registrado ha borrado un mensaje. Excepciones Paso Acción P2 Si el actor no dispone de ninguna conversación se le notificará y el caso de uso quedará sin efecto. Importancia Normal Tabla 21 UC-210 Borrar mensaje UC-211 Visualizar conversación Autor Sergio Muñoz Gómez Objetivos asociados OBJ-01: Conseguir aumentar el número de nuevos alumnos al campus de Segovia de la Uva. OBJ-06: Crear un lugar virtual donde los alumnos puedan ayudarse entre ellos junto a los profesores para solucionar problemas académicos. Requisitos asociados Req. de usuario UC-211: Visualizar conversación. Descripción El actor Usuario registrado podrá visualizar los mensajes que contenga una conversación. Precondición -El actor que ejecuta este caso de uso ha de ser un Usuario registrado o un descendiente de este. Secuencia normal Paso Acción p1 El actor Usuario registrado solicitará ver una conversación concreta de las que tenga creadas. P2 El sistema mostrará todos los mensajes que forman la conversación con el usuario seleccionado. El caso de uso ha concluido. Postcondición El Usuario registrado ha podido ver toda la conversación con el usuario destinatario. Excepciones Paso Acción Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 43 P2 Si el actor no dispone de ninguna conversación se le notificará y el caso de uso quedará sin efecto. Importancia Normal Tabla 22 UC-211 Visualizar conversación UC-212 Crear notificación Autor Sergio Muñoz Gómez Objetivos asociados OBJ-01: Conseguir aumentar el número de nuevos alumnos al campus de Segovia de la Uva. OBJ-02: Conseguir aumentar la difusión y participación de los alumnos en las actividades organizadas por la universidad. OBJ-06: Crear un lugar virtual donde los alumnos puedan ayudarse entre ellos junto a los profesores para solucionar problemas académicos. Requisitos asociados Req. de usuario UC-212: Crear notificación. Descripción El actor Usuario registrado podrá crear una notificación sobre algún evento o foro que desee mantenerse notificado Precondición -El actor que ejecuta este caso de uso ha de ser un Usuario registrado o un descendiente de este. Secuencia normal Paso Acción p1 El actor Usuario registrado solicitará crear una notificación. P2 El sistema notificará que la notificación se ha creado con éxito. El caso de uso ha concluido. Postcondición El Usuario registrado ha creado una notificación. Excepciones Paso Acción P2 Si el actor ya ha creado una notificación para dicho evento o foro será notificado y el caso de uso quedará sin efecto. Importancia Normal Tabla 23 UC-212 Crear notificación Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 44 UC-213 Borrar notificación Autor Sergio Muñoz Gómez Objetivos asociados OBJ-01: Conseguir aumentar el número de nuevos alumnos al campus de Segovia de la Uva. OBJ-02: Conseguir aumentar la difusión y participación de los alumnos en las actividades organizadas por la universidad. OBJ-06: Crear un lugar virtual donde los alumnos puedan ayudarse entre ellos junto a los profesores para solucionar problemas académicos. Requisitos asociados Req. de usuario UC-213: Borrar notificación. Descripción El actor Usuario registrado podrá dejar de ser notificado sobre nuevos mensajes en un foro o evento Precondición -El actor que ejecuta este caso de uso ha de ser un Usuario registrado o un descendiente de este. Secuencia normal Paso Acción p1 El actor Usuario registrado solicitará borrar una notificación. P2 El sistema notificará que la notificación se ha borrado con éxito. El caso de uso ha concluido. Postcondición El Usuario registrado ha borrado una notificación. Excepciones Paso Acción P2 Si el actor no había creado una notificación para dicho evento o foro será notificado y el caso de uso quedará sin efecto. Importancia Normal Tabla 24 UC-213 Borrar notificación UC-214 Listar favoritos Autor Sergio Muñoz Gómez Objetivos asociados OBJ-01: Conseguir aumentar el número de nuevos alumnos al campus de Segovia de la Uva. OBJ-02: Conseguir aumentar la difusión y participación de los alumnos en las actividades organizadas por la universidad. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 45 OBJ-06: Crear un lugar virtual donde los alumnos puedan ayudarse entre ellos junto a los profesores para solucionar problemas académicos. Requisitos asociados Req. de usuario UC-214: Listar favoritos. Descripción El actor Usuario registrado podrá listar aquellos temas que haya creado notificación. Precondición -El actor que ejecuta este caso de uso ha de ser un Usuario registrado o un descendiente de este. Secuencia normal Paso Acción p1 El actor Usuario registrado solicitará ver todos los temas que le envíen notificación de novedades. P2 El sistema mostrará una lista de sus temas favoritos. El caso de uso ha concluido. Postcondición El Usuario registrado ha podido visualizar los eventos y foros que tenga con notificaciones activadas. Excepciones Paso Acción P2 Si el actor no había creado ninguna notificación será notificado y el caso de uso quedará sin efecto. Importancia Normal Tabla 25 UC-214 Listar favoritos Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 52 Excepciones Paso Acción P4 Si el actor alumno no elige un plano se volverá al paso p2. Importancia Normal Tabla 33 UC-307 Visualizar planos campus UC-308 Visualizar modelo 3D Autor Sergio Muñoz Gómez Objetivos asociados OBJ-01: Conseguir aumentar el número de nuevos alumnos al campus de Segovia de la Uva. OBJ-03: Orientar a los alumnos sobre la localización de las diferentes zonas que dispone el campus. Requisitos asociados Req. de usuario UC-308: Visualizar modelo 3D. Descripción El actor Alumno podrá utilizar AR para visualizar un modelo 3D del campus con etiquetas de las zonas más relevantes del campus. Precondición -El actor que ejecuta este caso de uso ha de ser un Usuario registrado o un descendiente de este. Secuencia normal Paso Acción p1 El actor alumno solicitará ver modelo 3D del campus María Zambrano. P2 El sistema preguntará al usuario qué planta desea visualizar. P3 El actor alumno elegirá la planta que desea ver. P4 El sistema pedirá al actor Alumno que utilice la cámara. P5 El actor Alumno moverá en círculos el dispositivo. P6 El sistema escaneará una superficie plana y pedirá al usuario que toque dónde quiere colocar el modelo dentro de la zona escaneada. P7 El actor Alumno tocará el lugar donde desea visualizar el modelo 3D. P8 El sistema mostrará en la zona seleccionada un modelo 3D del piso deseado, el cual el usuario podrá rotar y ampliar para mejorar la experiencia. El caso de uso ha concluido. Postcondición El actor Alumno ha visto el modelo en 3D de una planta del campus María Zambrano. Excepciones Paso Acción P4 Si el actor alumno no da permisos al sistema para acceder a la cámara del dispositivo el caso de uso queda sin efecto. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 53 Importancia Normal Tabla 34 UC-308 Visualizar modelo 3D UC-309 Escaneo de imágenes AR Autor Sergio Muñoz Gómez Objetivos asociados OBJ-01: Conseguir aumentar el número de nuevos alumnos al campus de Segovia de la Uva. OBJ-03: Orientar a los alumnos sobre la localización de las diferentes zonas que dispone el campus. OBJ-04: Mejorar la cantidad y la calidad de la información académica de interés para el alumno. Requisitos asociados Req. de usuario UC-309: Escaneo de imágenes AR. Descripción El actor Alumno podrá utilizar AR para escanear determinadas imágenes distribuidas por el campus para poder obtener más información. Precondición -El actor que ejecuta este caso de uso ha de ser un Usuario registrado o un descendiente de este. Secuencia normal Paso Acción p1 El actor alumno solicitará ver información en realidad aumentada P2 El sistema pedirá al actor Alumno que utilice la cámara mostrando un marco de ajuste. P3 El actor Alumno enfocará la imagen a escanear dentro del marco mostrado. P4 El sistema escaneará la imagen deseada y representará contenido en realidad aumentada. El caso de uso ha concluido. Postcondición El actor Alumno ha visto la información representada en AR respecto a la imagen escaneada. Excepciones Paso Acción P2 Si el actor alumno no da permisos al sistema para acceder a la cámara del dispositivo el caso de uso queda sin efecto. P4 Si el sistema no consigue reconocer la imagen o la representación del contenido no es precisa, volver al paso p2. Importancia Normal Tabla 35 UC-309 Escaneo de imágenes AR Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 54 UC-310 Escaneo de QR Autor Sergio Muñoz Gómez Objetivos asociados OBJ-01: Conseguir aumentar el número de nuevos alumnos al campus de Segovia de la Uva. OBJ-03: Orientar a los alumnos sobre la localización de las diferentes zonas que dispone el campus. OBJ-04: Mejorar la cantidad y la calidad de la información académica de interés para el alumno. Requisitos asociados Req. de usuario UC-310: Escaneo de QR. Descripción El actor Alumno podrá escanear imágenes QR para tener acceso a más información solicitada. Precondición -El actor que ejecuta este caso de uso ha de ser un Usuario registrado o un descendiente de este. Secuencia normal Paso Acción p1 El actor alumno solicitará escanear imagen QR P2 El sistema pedirá al actor Alumno que utilice la cámara mostrando un marco de ajuste. P3 El actor Alumno enfocará la imagen a escanear dentro del marco mostrado. P4 El sistema escaneará la imagen deseada y accederá a la información relacionada. El caso de uso ha concluido. Postcondición El actor Alumno ha accedido a la información relacionada con el escaneo del QR. Excepciones Paso Acción P2 Si el actor alumno no da permisos al sistema para acceder a la cámara del dispositivo el caso de uso queda sin efecto. Importancia Normal Tabla 36 UC-310 UC-401 Crear foro académico Autor Sergio Muñoz Gómez Objetivos asociados OBJ-01: Conseguir aumentar el número de nuevos alumnos al campus de Segovia de la Uva. OBJ-04: Mejorar la cantidad y la calidad de la información académica de interés para el alumno. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 55 OBJ-06: Crear un lugar virtual donde los alumnos puedan ayudarse entre ellos junto a los profesores para solucionar problemas académicos Requisitos asociados Req. de usuario UC-401: Crear foro académico. Descripción El actor Profesor podrá crear un foro académico donde tratar asuntos sobre las asignaturas que imparta. Precondición -El actor que ejecuta este caso de uso ha de ser un Usuario registrado o un descendiente de este. Secuencia normal Paso Acción p1 El actor Profesor solicitará crear foro académico P2 El sistema pedirá al actor Profesor los datos que conformarán el foro, así como los usuarios que formarán parte de él. P3 El actor Profesor introducirá la información requerida P4 El sistema guardará la información del foro y enviará una notificación a los usuarios invitados. El caso de uso ha concluido. Postcondición El usuario Profesor ha creado un foro académico. Excepciones Paso Acción P4 Si el actor Profesor no completa los datos mínimos se volverá al paso p2. Importancia Normal Tabla 37 UC-401 Crear foro académico UC-402 Borrar foro académico Autor Sergio Muñoz Gómez Objetivos asociados OBJ-01: Conseguir aumentar el número de nuevos alumnos al campus de Segovia de la Uva. OBJ-04: Mejorar la cantidad y la calidad de la información académica de interés para el alumno. OBJ-06: Crear un lugar virtual donde los alumnos puedan ayudarse entre ellos junto a los profesores para solucionar problemas académicos Requisitos asociados Req. de usuario UC-402: Borrar foro académico. Descripción El actor Profesor podrá borrar aquellos foros académicos que haya creado Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 56 Precondición -El actor que ejecuta este caso de uso ha de ser un Usuario registrado o un descendiente de este. Secuencia normal Paso Acción p1 El actor Profesor solicitará borrar foro académico P2 El sistema pedirá al actor Profesor una confirmación para borrarlo. P3 El actor Profesor aceptará la confirmación. P4 El sistema borrará la información del foro académico. El caso de uso ha concluido. Postcondición El usuario Profesor ha borrado un foro académico. Excepciones Paso Acción P4 Si el actor Profesor no acepta la confirmación, el caso de uso queda sin efecto. Importancia Normal Tabla 38 UC-402 Borrar foro académico UC-403 Listar foro académico Autor Sergio Muñoz Gómez Objetivos asociados OBJ-01: Conseguir aumentar el número de nuevos alumnos al campus de Segovia de la Uva. OBJ-04: Mejorar la cantidad y la calidad de la información académica de interés para el alumno. OBJ-06: Crear un lugar virtual donde los alumnos puedan ayudarse entre ellos junto a los profesores para solucionar problemas académicos Requisitos asociados Req. de usuario UC-403: Listar foro académico. Descripción El actor Profesor podrá listar aquellos foros académicos que haya creado. Precondición -El actor que ejecuta este caso de uso ha de ser un Usuario registrado o un descendiente de este. Secuencia normal Paso Acción p1 El actor Profesor solicitará ver todos sus foros académicos creados. P2 El sistema buscará y mostrará un listado con todos los foros creados por el usuario. El caso de uso ha concluido. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 57 Postcondición El usuario Profesor ha listado sus foros académicos. Excepciones Paso Acción P2 Si el actor Profesor no ha creado ningún foro académico se le notificará de ello y el caso de uso quedará sin efecto. Importancia Normal Tabla 39 UC-403 Listar foro académico UC-501 Crear evento Autor Sergio Muñoz Gómez Objetivos asociados OBJ-01: Conseguir aumentar el número de nuevos alumnos al campus de Segovia de la Uva. OBJ-02: Conseguir aumentar la difusión y participación de los alumnos en las actividades organizadas por la universidad. Requisitos asociados Req. de usuario UC-501: Crear evento. Descripción El actor Organizador de eventos podrá crear un evento que represente algún acontecimiento que se vaya a realizar en el ámbito universitario. Precondición -El actor que ejecuta este caso de uso ha de ser un Usuario registrado o un descendiente de este. Secuencia normal Paso Acción p1 El actor Organizador de eventos solicitará crear un evento. P2 El sistema solicitará los datos necesarios para la creación de un evento. P3 El actor Organizador de eventos introducirá los datos requeridos. P4 El sistema guardará los datos y creará el evento. El caso de uso ha concluido. Postcondición El actor Organizador de eventos ha creado un evento. Excepciones Paso Acción P4 Si el actor Organizador de eventos no introduce los datos necesarios se le notificará de ello y volverá al paso p2. Importancia Normal Tabla 40 UC-501 Crear evento Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 58 UC-502 Borrar evento Autor Sergio Muñoz Gómez Objetivos asociados OBJ-01: Conseguir aumentar el número de nuevos alumnos al campus de Segovia de la Uva. OBJ-02: Conseguir aumentar la difusión y participación de los alumnos en las actividades organizadas por la universidad. Requisitos asociados Req. de usuario UC-502: Borrar evento. Descripción El actor Organizador de eventos podrá borrar un evento que haya creado Precondición -El actor que ejecuta este caso de uso ha de ser un Usuario registrado o un descendiente de este. Secuencia normal Paso Acción p1 El actor Organizador de eventos solicitará borrar un evento. P2 El sistema solicitará una confirmación para borrarlo. P3 El actor Organizador de eventos aceptará la confirmación. P4 El sistema borrará los datos del evento. El caso de uso ha concluido. Postcondición El actor Organizador de eventos ha borrado uno de sus eventos. Excepciones Paso Acción P4 Si el actor Organizador de eventos no acepta la confirmación para borrar el evento, el caso de uso queda sin efecto. Importancia Normal Tabla 41 UC-502 Borrar evento UC-503 Modificar evento Autor Sergio Muñoz Gómez Objetivos asociados OBJ-01: Conseguir aumentar el número de nuevos alumnos al campus de Segovia de la Uva. OBJ-02: Conseguir aumentar la difusión y participación de los alumnos en las actividades organizadas por la universidad. Requisitos asociados Req. de usuario UC-503: Modificar evento. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 59 Descripción El actor Organizador de eventos podrá modificar los detalles de un evento que haya creado Precondición -El actor que ejecuta este caso de uso ha de ser un Usuario registrado o un descendiente de este. Secuencia normal Paso Acción p1 El actor Organizador de eventos solicitará modificar un evento. P2 El sistema mostrará todos los datos disponibles del evento a modificar. P3 El actor Organizador de eventos modificará la información deseada. P4 El sistema guardará los nuevos datos del evento. El caso de uso ha concluido. Postcondición El usuario Profesor ha modificado uno de sus foros académicos. Excepciones Paso Acción P4 Si el actor Organizador de eventos elimina alguno de los datos necesarios para el evento, se le notificará de ello y volverá al paso p2. Importancia Normal Tabla 42 UC-503 Modificar evento UC-504 Listar eventos Autor Sergio Muñoz Gómez Objetivos asociados OBJ-01: Conseguir aumentar el número de nuevos alumnos al campus de Segovia de la Uva. OBJ-02: Conseguir aumentar la difusión y participación de los alumnos en las actividades organizadas por la universidad. Requisitos asociados Req. de usuario UC-504: Listar eventos. Descripción El actor Organizador de eventos podrá listar aquellos eventos que haya creado Precondición -El actor que ejecuta este caso de uso ha de ser un Usuario registrado o un descendiente de este. Secuencia normal Paso Acción p1 El actor Organizador de eventos solicitará ver todos los eventos que ha creado. P2 El sistema mostrará todos los eventos creados por el actor. El caso de uso ha concluido. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 60 Postcondición El usuario Profesor ha modificado uno de sus foros académicos. Excepciones Paso Acción P2 Si el actor Organizador de eventos no ha creado ningún evento, se le notificará de ello y volverá al paso p2. Importancia Normal Tabla 43 UC-504 Listar eventos Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 61 4.4. Requisitos funcionales En este apartado se describen los requisitos funcionales del proyecto organizados desde las características del sistema hasta los propios requisitos funcionales pasando por los actores y casos de uso de cada actor de tal forma, se obtiene un listado ordenado en el que se pueden encontrar los mismos de forma rápida y sencilla. 4.4.1. Característica 1: Gestión de la información  Actor 1: Usuario no registrado o RF relacionados con el caso de uso UC_103: Visualizar información académica  RF-111. El sistema accederá a la página que haya requerido el usuario no registrado. o RF relacionados con el caso de uso UC_104: Visualizar información de eventos  RF-112. El sistema mostrará la información disponible sobre el evento seleccionado.  Rf-113. El sistema notificará al usuario que no información sobre el evento. o RF relacionados con el caso de uso UC_105: Visualizar información de foros  RF-114. El sistema mostrará la información disponible sobre el foro seleccionado.  RF-115. El sistema notificará al usuario que no hay información sobre el evento. o RF relacionados con el caso de uso UC_106: Buscar información  RF116. El sistema mostrará la información disponible a la búsqueda realizada.  RF-117. El sistema mostrará una lista de la información filtrada por categoría.  RF-118. El sistema mostrará una lista de la información filtrada por nombre  RF-119. El sistema notificará al usuario que no encuentra información que se corresponda a la búsqueda realizada.  Actor 2: Usuario registrado o RF relacionados con el caso de uso UC_212: Crear notificación  RF-226. El sistema creará la notificación e informará de ello.  RF-227. El sistema notificará error de que la notificación ya había sido creada. o RF relacionados con el caso de uso UC_213: Borrar notificación  RF-228. El sistema borrará la notificación en informará de ello.  RF-229. El sistema notificará error por no tener notificaciones que borrar. o RF relacionados con el caso de uso UC_214: Listar favoritos  RF-230. El sistema mostrará una lista de los elementos favoritos del usuario.  RF-231. El sistema notificará error de falta de elementos favoritos. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 68 4.6. Requisitos de información Los requisitos de información describen los datos y atributos con los que operará el sistema. Así pues, este apartado engloba el modelo entidad-relación del sistema y los requisitos de información descritos en forma de diccionarios de datos. 4.6.1. Modelo Entidad-Relación El modelo Entidad-Relación ilustra las entidades y los tipos de relaciones que pueden darse entre las entidades. Este modelo se utiliza para especificar los requisitos de información o como descripción conceptual de la base de datos. Figura 18 Diagrama Entidad – Relación 4.6.2. Diccionario de datos ID: Nombre Descripción IRQ-01: Usuario Registrado El sistema gestionará entidades de datos que describirán a la entidad de usuario registrado mediante los atributos que en esta tabla se describen. Atributos Descripción Tipo de dato Restricciones Unicidad Correo universitario Indica el correo de usuario String Debe tener el formato de una dirección estándar ([email protected]) de los correos pertenecientes a la universidad de Valladolid PRIMARY KEY Contraseña Indica la contraseña con la que se va a identificar el usuario String · No admite caracteres especiales. · >=6 caracteres. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 69 Nombre Indica el nombre que tendrá el perfil del usuario String Solo se admitirán letras. Rol Indica el rol que tendrá el usuario Enum Solo se podrá elegir entre Alumno, Profesor u Organizador de eventos Tabla 44 IRQ-01 Usuario registrado ID: Nombre Descripción IRQ-02: Profesor El sistema gestionará entidades de datos que describirán a la entidad de profesor mediante los atributos que en esta tabla se describen. Tabla 45 IRQ-02: Profesor ID: Nombre Descripción IRQ-03: Alumno El sistema gestionará entidades de datos que describirán a la entidad de alumno mediante los atributos que en esta tabla se describen. Atributos Descripción Tipo de dato Restricciones Unicidad Carrera Indica la carrera del alumno String Debe ser una de las ofertadas en el campus María Zambrano Tabla 46 IRQ-03 Alumno ID: Nombre Descripción IRQ-04: Organizador de eventos El sistema gestionará entidades de datos que describirán a la entidad de organizador de eventos mediante los atributos que en esta tabla se describen. Tabla 47 IRQ-04 Organizador de eventos ID: Nombre Descripción IRQ-05: Evento El sistema gestionará entidades de datos que describirán a la entidad de evento mediante los atributos que en esta tabla se describen. Atributos Descripción Tipo de dato Restricciones Unicidad ID Indica la identificación del evento Entero Debe ser mayor que 0 e incremental PRIMARY KEY Nombre Indica el nombre del evento String Solo se admitirán letras o números Descripción Indica un breve texto para describir el evento String Tendrá como máximo 500 caracteres. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 70 Asistencia Indica la asistencia que tendrá el evento Entero Solo se admitirán números enteros positivos Tabla 48 IRQ-05 Evento ID: Nombre Descripción IRQ-06: Mensaje El sistema gestionará entidades de datos que describirán a la entidad de mensaje mediante los atributos que en esta tabla se describen. Atributos Descripción Tipo de dato Restricciones Unicidad ID Indica la identificación del mensaje Entero Debe ser mayor que 0 e incremental PRIMARY KEY Contenido Indica el texto que compondrá el mensaje String Tendrá máximo 500 caracteres Tabla 49 IRQ-06: Mensaje ID: Nombre Descripción IRQ-07: Foro El sistema gestionará entidades de datos que describirán a la entidad de foro mediante los atributos que en esta tabla se describen. Atributos Descripción Tipo de dato Restricciones Unicidad ID Indica la carrera del alumno Entero Debe ser mayor que 0 e incremental PRIMARY KEY Nombre Indica el nombre del foro String Solo tendrá letras y números Descripción Indica un breve texto que describe el foro String Tendrá un máximo de 500 caracteres Tabla 50 IRQ-07 Foro Nombre Descripción Cardinalidades IRQ-08: escribe El sistema gestionará entidades de datos que describan las relaciones de escribe mediante los atributos que se especifican en esta tabla. Las cardinalidades corresponden a que un usuario registrado puede enviar entre 0 y muchos mensajes; y un mensaje puede ser enviado por 1 usuario registrado. Tabla 51 IRQ-08 escribe Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 71 Nombre Descripción Cardinalidades IRQ-09: recibe El sistema gestionará entidades de datos que describan las relaciones de escribe mediante los atributos que se especifican en esta tabla. Las cardinalidades corresponden a que un usuario registrado puede recibir entre 0 y muchos mensajes; y un mensaje puede ser recibido por 1 usuario registrado. Tabla 52 IRQ-09 recibe Nombre Descripción Cardinalidades IRQ-10: organiza El sistema gestionará entidades de datos que describan las relaciones de escribe mediante los atributos que se especifican en esta tabla. Las cardinalidades corresponden a que un organizador de eventos puede organizar entre 0 y muchos eventos; y un evento puede ser organizado por 1 organizador de eventos. Tabla 53 IRQ-10 organiza Nombre Descripción Cardinalidades IRQ-11: evento_favorito El sistema gestionará entidades de datos que describan las relaciones de escribe mediante los atributos que se especifican en esta tabla. Las cardinalidades corresponden a que un usuario registrado puede marcar favorito entre 0 y muchos eventos; y un evento puede ser marcado como favorito por 1 usuario registrado. Tabla 54 IRQ-11 evento_favorito Nombre Descripción Cardinalidades IRQ-12: comentar evento El sistema gestionará entidades de datos que describan las relaciones de escribe mediante los atributos que se especifican en esta tabla. Las cardinalidades corresponden a que un usuario registrado puede comentar entre 0 y muchos eventos; y un evento puede ser comentado por 0 o muchos usuarios registrados. Atributos Descripción Tipo de dato Restricciones Unicidad ID Identificador del comentario Entero >0 PRIMARY KEY Fecha Indica la fecha creación del comentario Fecha >= Fecha actual Contenido Indica el contenido del mensaje String Solo puede tener máximo 500 caracteres Tabla 55 IRQ-12 comentar_evento Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 72 Nombre Descripción Cardinalidades IRQ-13: forma El sistema gestionará entidades de datos que describan las relaciones de escribe mediante los atributos que se especifican en esta tabla. Las cardinalidades corresponden a que un profesor puede formar entre 0 y muchos foros; y un foro puede ser formado por 1 profesor. Tabla 56 IRQ-13 forma Nombre Descripción Cardinalidades IRQ-14: foro_favorito El sistema gestionará entidades de datos que describan las relaciones de escribe mediante los atributos que se especifican en esta tabla. Las cardinalidades corresponden a que un usuario registrado puede marcar como favorito entre 0 y muchos foros; y un foro puede ser marcado como favorito por 0 o muchos usuarios registrados. Tabla 57 IRQ-14 foro_favorito Nombre Descripción Cardinalidades IRQ-15: comentar_foro El sistema gestionará entidades de datos que describan las relaciones de escribe mediante los atributos que se especifican en esta tabla. Las cardinalidades corresponden a que un usuario registrado puede comentar entre 0 y muchos foros; y un foros puede ser comentado por 0 o muchos usuarios registrados. Atributos Descripción Tipo de dato Restricciones Unicidad ID Identificador del comentario Entero >0 PRIMARY KEY Fecha Indica la fecha de la creación del comentario Fecha >= Fecha actual Contenido Indica el contenido que tiene el comentario String Solo se admitirán 500 caracteres como máximo Tabla 58 IRQ-15: comentar_foro Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 73 Nombre Descripción Cardinalidades IRQ-16: crea El sistema gestionará entidades de datos que describan las relaciones de escribe mediante los atributos que se especifican en esta tabla. Las cardinalidades corresponden a que un alumno puede crear entre 0 y muchos foros; y un foro puede ser creado por 1 usuario registrado. Tabla 59 IRQ-16 crea Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 74 Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 75 Capítulo 5 – Diseño En este apartado se detallarán todos los componentes y arquitecturas lógicas y físicas que constituyen el diseño de la aplicación móvil. 5.1. Arquitectura lógica La arquitectura lógica define los elementos lógicos que forman la aplicación y cómo se relacionan entre ellos. La explicación de este apartado está desarrollada desde una visión más global, para entender las diferentes características del sistema de una manera conjunta y argumentar el porqué de cada una, hasta una visión más detallada donde se contemplan los componentes que forman cada parte. 5.1.1. Arquitectura lógica a alto nivel Desde un punto de vista a alto nivel, nuestro sistema se puede dividir en 3 capas:  La capa de presentación. Esta capa está formada por los componentes que describen la interfaz de usuario. Son diferentes elementos que nos proporcionan una vista intuitiva, atractiva y funcional para llevar a cabo las acciones que detalla la capa de negocio.  La capa de negocio. Esta capa contiene toda la lógica de la aplicación. Realiza, a través de métodos, todas aquellas funciones que nos permiten comunicar esta capa con la capa de presentación, entre compontes de esta misma capa y con el sistema de datos.  La capa de datos. Esta capa es la encargada de almacenar y gestionar la información (creación, acceso, actualización y borrado). El motivo de dividir el sistema en estas 3 capas es porque nos permite agrupar elementos similares y separarlos de aquellos que no cumplen funciones parecidas. Esto permite mejorar la comunicación entre elementos y, a la vez, nos da mayor facilidad a la hora de aplicar cambios en alguna de estas capas, ya que son independientes. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 76 Figura 19 Arquitectura lógica 5.1.2. Arquitectura lógica detallada Como hemos comentado en la introducción, en este apartado vamos a desarrollar el contenido de las capas anteriormente explicadas. La capa de presentación se compone de todos los layouts y elementos visibles que componen la aplicación. En nuestro caso, son los archivos xml y assets los que se encargan de contener y gestionar dicha información. La capa de negocio se compone de todas las clases que contienen las funcionalidades de la aplicación. Éstas permiten comunicarse con la capa de presentación para recoger y mostrar aquellos datos útiles para el usuario, y con la capa de datos para almacenarlas. En nuestro caso, son las clases java las que se encargan de esto. La capa de datos se compone de aquellos elementos que no permiten la persistencia de la información. En nuestro caso, gran parte de la información que generamos y a la que accedemos se gestiona de manera remota, ya sea a través de los servidores que nos proporciona Google con su herramienta Firebase o acceso a web externas. El resto de datos se acceden de manera local, como la información del usuario a través de las preferencias compartidas. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 77 Tanto ficheros (.obj, .mtl, .sfb, .sfa) que componen los modelos 3D como el fichero (.imgdb) que compone la base de datos donde se especifican las imágenes de escaneo conforman los datos propios a la gestión de la funcionalidad AR. Estos ficheros tienen una relación con cada capa del sistema, ya que se muestran en la capa de presentación, se gestionan en la capa de negocio y se accede a ellos desde la capa de presentación. La estructura de la aplicación se pude desglosar de la siguiente manera:  Capa de Negocio: Componentes que definen el comportamiento de la aplicación. o Snackbar Helper: clase que nos proporciona la configuración del snackbar para AR. o AugmentedImageActivity: clase que gestiona lo que tiene que representar en AR al escanear una imagen guardada. o AugmentedImageFragment: clase que carga la base de datos de imágenes a escanear y comprueba si nuestro dispositivo es compatible con ARcore y pide permisos de cámara. o Object3DModel: clase que crea los objetos tipo modelo para AR. o Object3DModelTransformable: clase que crea los objetos tipo modelo transformable para AR. o ObjectImage: clase que crea los objetos tipo imagen para AR. o Comentario: clase que representa la entidad del comentario. o Comentario adapter: clase que conecta la clase Comentario con aquellas que utilizan su información. o DatePickerFragment: clase que nos permite recoger la fecha. o Evento: clase que representa la entidad del evento. o EventoDetailFragment: clase que muestra la información detallada de un evento. o EventoEditFragment: clase que nos permite editar la información de un evento. o EventoMainFragment: clase que nos permite diferenciar qué listas son visibles respecto al rol del usuario. o EventosAdapter: clase que conectar la clase Evento con aquellas que utilizan su información. o EventoListFragment: clase que muestra la lista de todos los eventos vigentes. o EventosSearchFragment: clase que nos permite buscar eventos por su nombre. o MyEventosListFragment: clase que muestra la lista de todos los eventos que haya creado el usuario. o MyFavEventosListFragment: clase que muestra la lista de los eventos que tenga el usuario marcados como favoritos. o NewEventoFragment: clase que nos permite crear un nuevo evento. o Foro: clase que representa la entidad de foro. o ForoDetailFragment: clase que muestra la información detallada de un foro. o ForoEditFragment: clase que permite editar la información de un foro. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 84 5.3.2.3. Sección PDF Figura 26Diagrama de clases, representación del paquete Android, sección PDF 5.3.2.4. Sección AR Figura 27 Diagrama de clases, representación del paquete Android, sección AR Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 85 5.3.2.5. Sección QR Figura 28 Diagrama de clases, representación del paquete Android, sección QR Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 86 5.3.2.6. Sección Foros Figura 29Diagrama de clases, representación del paquete Android, sección Foros Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 87 5.3.2.7. Sección Evento Figura 30 Diagrama de clases, representación del paquete Android, sección evento Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 88 5.3.3. Paquete Listener Este paquete posee 2 clases que se encargan de implementar métodos a otras clases. Figura 31 Diagrama de clases, representación del paquete Listener 5.4. Diseño de la interfaz Este apartado proporciona una visión aproximada sobre cómo serán las interfaces de usuario del sistema. Por lo tanto, la aplicación final puede sufrir diferentes cambios estéticos. Para la creación de bocetos se ha utilizado una aplicación web denominada “Ninjamok”. La cual nos permite construir de manera rápida y sencilla interfaces orientadas a móviles muy básicas, pero con numerosos elementos. Se ha utilizado la versión gratuita, por lo que la creación es limitada y forzada a llevar su marca de agua. A pesar de esto, nos proporciona un resultado bastante visible. Nombre Lista de Enlaces Uva (main) Descripción Pantalla que aparecerá cuando se abra la aplicación. Los elementos variarán dependiendo del tipo de usuario que acceda. Entrada El usuario entra en la aplicación Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 89 Boceto Eventos relacionados  Hacer login  Hacer registro  Cerrar sesión (si hay una sesión iniciada)  Abrir menú lateral  Acceder a la página seleccionada Tabla 60 Boceto Lista de enlaces Uva Nombre Menú lateral Descripción Pantalla que aparecerá cuando se abra el menú lateral. Éste mostrará una lista de opciones dependiendo del tipo de usuario que sea. Entrada El usuario abre el menú lateral. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 90 Boceto Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 91 Eventos relacionados  Ver perfil (si es un usuario registrado)  Eventos  Foros  Buscar Usuario (si es un usuario registrado)  Planos (si el usuario tiene rol de Alumno)  Modelo 3D (si el usuario tiene rol de Alumno)  Imagen AR (si el usuario tiene rol de Alumno)  Escaneo QR (si el usuario tiene rol de Alumno) Tabla 61 Boceto menú lateral Nombre Mi perfil Descripción Pantalla que aparecerá cuando el usuario registrado seleccione la opción “Mi perfil” en el menú lateral. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 92 Entrada  El usuario registrado selecciona la opción “Mi perfil”.  El usuario registrado seleccione un nombre en el buscador de usuarios. Boceto Eventos relacionados  Editar perfil  Borrar perfil Tabla 62 Boceto mi perfil Nombre Foros Descripción Pantalla que aparecerá cuando el usuario acceda a foros. Esta pantalla es similar a la que aparece cuando se ven todos los foros creados, los foros que haya creado el usuario o los foros que tenga guardados como favoritos. Entrada El usuario selecciona la opción “Foros” en el menú lateral. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 93 Boceto Eventos relacionados  Buscar foro  Crear foro (si es un usuario con el rol de Alumno o Profesor)  Seleccionar foro Tabla 63 Boceto foros Nombre Eventos Descripción Pantalla que aparecerá cuando el usuario acceda a eventos. Esta pantalla es similar a la que aparece cuando se ven todos los eventos creados, los eventos que haya creado el usuario o los eventos que tenga guardados como favoritos. Entrada El usuario selecciona la opción “Eventos” en el menú lateral. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 100 Boceto Eventos relacionados  Confirmar la creación del foro Tabla 70 Boceto nuevo foro Nombre Nuevo Evento Descripción Pantalla que aparecerá cuando el usuario quiera crear un nuevo evento mostrándole un formulario con los diferentes campos que tiene que rellenar para su creación. Entrada El usuario seleccionará el icono del “+” para crear un nuevo evento. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 101 Boceto Eventos relacionados  Confirmar la creación del evento Tabla 71 Boceto nuevo evento Nombre Mis Eventos Descripción Pantalla que aparecerá cuando el usuario acceda a la lista de sus eventos creados. Entrada El usuario selecciona la pestaña de mis eventos dentro de la categoría de eventos. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 102 Boceto Eventos relacionados  Buscar evento  Crear evento (si es un usuario con el rol Organizador de eventos)  Seleccionar Evento Tabla 72 Boceto mis eventos Nombre Planos Descripción Pantalla que muestra una lista de opciones para que el usuario seleccione qué plano desea visualizar. Entrada El usuario selecciona la opción “Planos” dentro del menú lateral. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 103 Boceto Eventos relacionados  Seleccionar plano Tabla 73 Boceto planos Nombre Visualizar planos Descripción Pantalla que muestra en un navegador propio de la aplicación el plano que ha seleccionado el usuario. Para ellos se hace una petición a Firebase storage, que es donde están guardados los planos, a través de Google Drive. Entrada El usuario selecciona un plano de la lista de planos disponibles. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 104 Boceto Eventos relacionados  Manipular la visualización del plano Tabla 74 Boceto visualizar planos Nombre Modelos 3D Descripción Pantalla que muestra el visor de la cámara para crear un escena AR donde colocar los modelos 3D de las diferentes plantas del campus. Entrada El usuario selecciona la opción “Modelos 3D” en el menú lateral. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 105 Boceto Eventos relacionados  Seleccionar modelo 3D de la planta que queramos visualizar. Tabla 75 Boceto modelos 3D Nombre Registro Descripción Pantalla que muestra el formulario que el usuario usará para registrarse en la aplicación. Entrada El usuario selecciona la opción “Registrarse” en el menú de la pantalla principal. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 106 Boceto Eventos relacionados  Confirmar el registro. Tabla 76 Boceto registro Nombre Inicio de sesión Descripción Pantalla que muestra el formulario que el usuario usará para iniciar sesión en la aplicación. Entrada El usuario selecciona la opción “Login” en el menú de la pantalla principal. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 107 Boceto Eventos relacionados  Confirmar el registro. Tabla 77 Boceto inicio de sesión Nombre Buscar información Descripción Pantalla que muestra el formulario que el usuario usará para buscar usuarios, eventos o foros en la aplicación. Entrada El usuario selecciona la opción de buscar representada con el icono de una lupa. El punto de partida dependerá si se está en la búsqueda de usuarios, eventos o foros. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 108 Boceto Eventos relacionados  Buscar la información según el nombre introducido.  Seleccionar un elemento de la lista de resultados para ver más detalles. Tabla 78 Boceto buscar información 5.5. Diagramas de secuencia En este apartado se describen las interacciones que hay entre los componentes del sistema a lo largo del tiempo, a través de diagramas de secuencia. Debido a que habría un diagrama de secuencia por cada caso de uso descrito en el apartado de Análisis y la representación de todos haría demasiado extenso este punto, se ha decido seleccionar aquellos casos de uso más relevantes para ser representados. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 109 Figura 32 Diagrama de secuencia de crear foro de asistencia Figura 33 Diagrama de secuencia de Editar evento Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 116  Nivel 4 en adelante: En este nivel se guardan los propios atributos que pertenecen a su entidad. En el caso de venir de un nodo donde se representa una relación, los atributos que se guardan se almacenan en el siguiente nivel. A parte de la estructura de datos, también se han definido unas reglas básicas de seguridad para la base de datos. Estas reglas definen que cualquier usuario puede leer la base de datos, facilitando el acceso a usuarios no registrados, pero solo pueden escribir aquellos usuarios que estén registrados. La declaración de estas reglas sería el siguiente: { "rules": { ".read": true, ".write": "auth != null" } } Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 117 Capítulo 6 – Implementación En este apartado se describen los detalles de implementación de la aplicación móvil. Primero se detallarán los aspectos relacionados con el servidos, después con las tecnologías utilizadas, seguido de las herramientas empleadas, a continuación, los detalles de implementación y por último los detalles de despliegue. 6.1. Servidor Como se ha descrito en diferentes puntos de la documentación, se ha configurado un servidor proporcionado por Google como servicio (SAAS), llamado Firebase, al cual se conectará nuestra aplicación móvil para todas aquellas funciones remotas. La motivación para la elección de esta solución se basa en la innovación que trae este servicio. Aunque tenga pocos años de uso, Google se ha preocupado de construir una plataforma que nos proporcione desde un mismo lugar numerosas y variadas funcionalidades para que aplicaciones web, IOS y, en nuestro caso, Android las puedan usar. La principal ventaja de Firebase es que sus diferentes módulos están diseñados para una fácil relacion y comunicación entre ellos, independientemente del tipo de aplicación. Además, permite implementar todos los módulos de una manera rápida y sencilla, solo hay que saber cómo trabajar con los diferentes módulos, y tampoco hay que preocuparse de administrar la infraestructura. Otra característica es que contamos con el respaldo de Google, por lo que tenemos la confianza de manejar un entorno seguro donde nuestros datos e infraestructura son siempre accesibles y escalables. Además de contar con la colaboración con otras plataformas como Slack para la integración de Firebase en las mismas, como se explica en https://firebase.google.com/integrations/. Hablando de los diferentes módulos que nos proporciona Firebase, los podemos dividir en 3 categorías.  Desarrollo y compilación de apps. Dentro de esta categoría se han utilizado los siguientes módulos: o Realtime Database o Authentication o Cloud Functions o Cloud Storage  Mejora de la calidad  Herramientas de crecimiento. Dentro de esta categoría se han utilizado los siguientes módulos: o Google Analytics 6.1.1. Módulo de Realtime Database Almacena y sincroniza datos con nuestra base de datos NoSQL alojada en la nube. Los datos se sincronizan con todos los clientes en tiempo real y se mantienen disponibles cuando la app no tiene conexión. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 118 Firebase Realtime Database es una base de datos alojada en la nube. Los datos se almacenan en formato JSON y se sincronizan en tiempo real con cada cliente conectado. Cuando compilas apps multiplataforma con los SDK de iOS, Android y JavaScript, todos los clientes comparten una instancia de Realtime Database y reciben actualizaciones automáticamente con los datos más recientes. Características clave:  Tiempo real: En lugar de solicitudes HTTP típicas, Firebase Realtime Database usa la sincronización de datos (cada vez que cambian los datos, los dispositivos conectados reciben esa actualización en milisegundos). Proporciona experiencias colaborativas y envolventes sin pensar en el código de red.  Sin conexión: Las apps de Firebase continúan respondiendo, incluso sin conexión, dado que el SDK de Firebase Realtime Database hace que tus datos persistan en el disco. Cuando se restablece la conexión, el dispositivo cliente recibe los cambios que faltaban y los sincroniza con el estado actual del servidor.  Acceso desde dispositivos cliente: Se puede acceder a Firebase Realtime Database directamente desde un dispositivo móvil o un navegador web; no se necesita un servidor de aplicaciones. La seguridad y la validación de datos están disponibles a través de las reglas de seguridad de Firebase Realtime Database: reglas basadas en expresiones que se ejecutan cuando se leen o se escriben datos.  Escalamiento en varias bases de datos: Firebase Realtime Database dispone de un plan de precios Blaze para satisfacer las necesidades de datos de la app a gran escala: podrás dividir la información en diversas instancias de bases de datos dentro del mismo proyecto de Firebase. Toda esta información e información adicional necesaria se puede encontrar en el siguiente sitio web, https://firebase.google.com/docs/database/ 6.1.2. Módulo de Authentication La mayoría de las apps necesitan identificar a los usuarios. Conocer la identidad de un usuario permite que una app guarde sus datos en la nube de forma segura y proporcione la misma experiencia personalizada en todos los dispositivos del usuario. Firebase Authentication proporciona servicios de backend, SDK fáciles de usar y bibliotecas de IU ya elaboradas para autenticar a los usuarios en tu app. Admite la autenticación mediante contraseñas, números de teléfono, proveedores de identidad federada populares, como Google, Facebook y Twitter, y mucho más. Firebase Authentication se integra estrechamente en otros servicios de Firebase y aprovecha los estándares de la industria como OAuth 2.0 y OpenID Connect, por lo que se puede integrar fácilmente con tu backend personalizado. Características clave:  Autenticación basada en correo electrónico y contraseña: Autentica a los usuarios con sus direcciones de correo electrónico y contraseñas. El SDK de Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 119 Firebase Authentication proporciona métodos a fin de crear y administrar usuarios que utilizan sus direcciones de correo electrónico y contraseñas para acceder. Firebase Authentication también maneja el envío de correos electrónicos para restablecer la contraseña.  Integración con proveedores de identidad federada: Autentica usuarios mediante la integración con proveedores de identidad federada. El SDK de Firebase Authentication proporciona métodos que permiten a los usuarios acceder con sus cuentas de Google, Facebook, Twitter y GitHub.  Autenticación con número de teléfono: Envía mensajes SMS a los teléfonos de los usuarios para autenticarlos.  Integración con sistemas de autenticación personalizados: Conecta el sistema de acceso existente de tu app al SDK de Firebase Authentication y obtén acceso a Firebase Realtime Database y otros servicios de Firebase.  Autenticación anónima: Crea cuentas anónimas temporales para permitir el uso de funciones que requieran autenticación sin exigir que los usuarios accedan primero. Si posteriormente el usuario opta por registrarse, puedes actualizar la cuenta anónima y convertirla en una normal, de manera que el usuario pueda reanudar la actividad donde la interrumpió. Toda esta información e información adicional necesaria se puede encontrar en el siguiente sitio web, https://firebase.google.com/docs/auth/. 6.1.3. Módulo de Cloud Functions Cloud Functions para Firebase te permite ejecutar de forma automática el código de backend en respuesta a eventos activados por las funciones de Firebase y las solicitudes HTTPS. Tu código se almacena en la nube de Google y se ejecuta en un entorno administrado. No necesitas administrar ni escalar tus propios servidores. Características clave:  Integra la plataforma de Firebase: Las funciones que escribas pueden responder a eventos generados por estas otras funciones de Firebase y Google Cloud: o Activadores de Cloud Firestore o Activadores de Realtime Database o Activadores de Remote Config o Activadores de Firebase Authentication o Activadores de Google Analytics para Firebase o Activadores de Crashlytics o Activadores de Cloud Storage o Activadores de Cloud Pub/Sub o Activadores HTTP Integra en distintas características de Firebase con el SDK de Admin y Cloud Functions y, para integrar con servicios de terceros, escribe tus propios webhooks. Cloud Functions minimiza el código estándar, lo que facilita el uso de Firebase y Google Cloud en tu función. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 120  Sin mantenimiento: Implementa tu código de JavaScript o TypeScript en sus servidores con un comando desde la línea de comandos. Después de eso, Firebase aumenta los recursos de procesamiento automáticamente según los patrones de uso de los usuarios. No tendrás que preocuparte por las credenciales, la configuración de servidores, el aprovisionamiento de servidores nuevos ni por sacar de servicio los servidores antiguos.  Protege la privacidad y seguridad de tu lógica: En muchos casos, los desarrolladores prefieren controlar la lógica de la aplicación en el servidor para evitar alteraciones del lado del cliente. A veces, no es recomendable permitir que se aplique ingeniería inversa a ese código. Cloud Functions está completamente aislada del cliente, de manera que puedes estar seguro de su privacidad y de que siempre hará exactamente lo que quieres. Toda esta información e información adicional necesaria se puede encontrar en el siguiente sitio web, https://firebase.google.com/docs/functions. 6.1.4. Módulo de Cloud Storage Cloud Storage se creó para programadores de apps que necesitan almacenar y publicar contenido generado por usuarios, como fotos o videos. Cloud Storage para Firebase es un servicio de almacenamiento de objetos potente, simple y rentable construido para la escala de Google. Los SDK de Firebase para Cloud Storage agregan la seguridad de Google a las operaciones de carga y descarga de archivos para tus apps de Firebase, sin importar la calidad de la red. Puedes usar nuestros SDK para almacenar imágenes, audio, video y otros tipos de contenido generado por el usuario. En el servidor, puedes usar Google Cloud Storage para acceder a los mismos archivos. En nuestro caso, lo utilizaremos para almacenar los archivos PDF que representan los planos de las diferentes plantas. Es cierto que esta funcionalidad se podría haber solucionado a través de otras herramientas de almacenamientos como Dropbox, pero se decidió usar Cloud Storage para disfrutar de la comunicación entre módulos que dispone Firebase y así iniciar su uso para posibles necesidades de almacenamiento futuras. Características clave:  Operaciones robustas: Los SDK de Firebase para Cloud Storage realizan las operaciones de carga y descarga sin importar la calidad de la red. Las cargas y descargas son robustas, lo que significa que se reinician en el punto en el que se interrumpieron para así ahorrar tiempo y ancho de banda a los usuarios.  Seguridad sólida: Los SDK de Firebase para Cloud Storage se integran con Firebase Authentication a fin de brindar autenticación intuitiva y sencilla para los programadores. Se puede usar su modelo de seguridad declarativa para permitir el acceso según el nombre de archivo, el tamaño, el tipo de contenido y otros metadatos.  Gran escalabilidad: Cloud Storage para Firebase está diseñado para escalar a exabytes si tu app se vuelve viral. Pasa fácilmente de la fase prototipo a la de producción con la misma infraestructura que respalda a Spotify y Google Fotos. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 121 Toda esta información e información adicional necesaria se puede encontrar en el siguiente sitio web, https://firebase.google.com/docs/storage. 6.1.5. Módulo de Google Analytics Google Analytics para Firebase es una solución de medición de apps gratuita que proporciona estadísticas sobre el uso de la app y la participación de los usuarios. Google Analytics para Firebase es una solución de análisis ilimitada y gratuita que constituye uno de los componentes fundamentales de Firebase. Analytics se integra a diversas funciones de Firebase y brinda la capacidad de generar informes sin límites de hasta 500 eventos diferentes que puedes definir con el SDK de Firebase. Los informes de Analytics te permiten entender claramente cómo se comportan tus usuarios para que puedas tomar decisiones fundamentadas en relación con el marketing de tu app y las optimizaciones del rendimiento. Características clave:  Informes sin límites: Analytics ofrece informes ilimitados de hasta 500 eventos distintos.  Segmentación del público: Puedes definir públicos personalizados en Firebase console en función de los datos del dispositivo, eventos personalizados o propiedades del usuario. Estos públicos pueden usarse con otras funciones de Firebase para orientar funciones nuevas o mensajes de notificación. Toda esta información e información adicional necesaria se puede encontrar en el siguiente sitio web, https://firebase.google.com/docs/analytics. 6.2. Tecnologías utilizadas En este apartado se detallarán todas aquellas tecnologías que son necesarias para implementar las funcionalidades descritas en este documento:  Java: Esta aplicación está destinada a dispositivos móviles con sistema operativo Android, por lo que está desarrollada en Java con algunas variaciones en el lenguaje y estructuración de datos orientados a este sistema operativos, como son los activities, fragmentes, manejo de layouts, entre otras.  XML: Para el diseño de las interfaces que mostrarán las diferentes pantallas se utiliza el lenguaje basado en etiquetas XML. No ha habido una motivación adicional para elegirlo como lenguaje de estructuración de componentes, más que es el lenguaje que se utiliza por defecto para realizar esta tarea en Android Studio. A pesar de esto, este lenguaje se integra muy bien con esta herramienta ya que está preparada para ello, hasta dispone de un simulador gráfico para ir viendo en tiempo real aquellos layouts que vamos diseñando. La manera de trabajar con XML es muy similar a otros lenguajes basados en etiquetas, solo necesitamos estructurar diferentes componentes con una serie de atributos que harán de sus propiedades. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 122  JavaScript, JS. Es un lenguaje de programación interpretado. Es utilizado en el lado cliente aumentando la experiencia de los usuarios con páginas web. Aunque en nuestro caso lo utilizaremos para construir las diferentes funciones destinadas a Firebase Cloud Functions con ayuda de NodeJS.  Google Sceneform Tools (Beta) Plugin: Es un plugin que se instala en Android Studio y nos permite transformar ficheros .obj/.fbx junto con su fichero .mtl y texturas, en ficheros entendibles para el motor de realidad aumentada ARcore y así poder trabajar con ellos. También integra un visor para los modelos 3D que importa. Como su nombre indica, este plugin aún está en una fase beta, por lo que es posible que, de algún fallo o advertencia, pero al ser desarrollado por Google nos proporciona una serie de actualizaciones para corregir errores y así mejorar la herramienta.  SDK Firebase: En este punto agrupo todas aquellas dependencias que necesitamos para implementar todos los módulos de Firebase que necesitemos. Este SDK integra todas aquellas clases que permiten desarrollar en Java las funcionalidades anteriormente descritas.  ARcore: Es un framework, distribuido por Google, que proporciona un motor lógico de AR para aplicaciones desarrolladas en Android Studio. Integra diferentes funcionalidades como escaneo de caras, creación de escenas compartidas a través de un servidor que crea una sala y diferentes usuarios acceden a ella, y las que se van a utilizar en nuestra aplicación, que son el escaneo de una superficie plana y escaneo de imágenes para colocar elementos sobre ellas (imágenes, vídeos, objetos 3D). Para poder utilizar este motor, y por tanto las funcionalidades de AR, es necesario que nuestro dispositivo sea compatible y disponga de la aplicación ARcore instalada. A pesar de esta contrariedad, Google está trabajando en esta tecnología para ampliar la lista de dispositivos compatibles, optimizar el rendimiento y reducir el gasto de recursos y batería.  Sceneform: Es un framework orientado a envolver a OpenGL para permitir a los desarrolladores trabajar con modelos 3D en código de una forma mucho más rápida y sencilla. En nuestro caso lo utilizaremos junto con ARcore para la construcción y manejo de los elementos AR que se colocarán en las escenas creadas.  Play-servicies-vision: Es una herramienta que proporciona los servicios de Google Play y que se utilizará para implementar la funcionalidad del lector QR.  Google drive: Es una herramienta de almacenamiento y trabajo con ficheros en diferentes formatos. Pero para nuestra aplicación, únicamente se utilizará su lector de PDF. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 123 6.3. Herramientas utilizadas En este apartado se definen las herramientas que se utilizan para el desarrollo del sistema:  Android OS: Sistema operativo basado en Linux. Fue diseñado principalmente para dispositivos móviles con pantalla táctil (Smartphones, tablets o relojes). Es un sistema operativo muy intuitivo, lo que le ha llevado a tener la mayor cuota de marcado.  Android Studio (versión 3.3.2): Es un entorno de desarrollo integrado oficial para la plataforma Android. Proporciona las herramientas para crear aplicaciones en cada tipo de dispositivo Android. Posee soporte para desarrolladores y gran cantidad de información (guías y documentación).  Firebase Console: Es un entorno de administración de proyectos Firebase y de todos los módulos que integre. Con una interfaz muy sencilla nos proporciona información sobre la configuración, implementación y uso de dichos proyectos.  Atom: es un editor de código de fuente de código abierto para macOS, Linux, y Windows1 con soporte para multiples plug-in escritos en Node.js y control de versiones Git integrado, desarrollado por GitHub. Atom es una aplicación de escritorio construida utilizando tecnologías web.2  Node JS: es un entorno en tiempo de ejecución multiplataforma, de código abierto, para la capa del servidor (pero no limitándose a ello) basado en el lenguaje de programación ECMAScript, asíncrono, con I/O de datos en una arquitectura orientada a eventos y basado en el motor V8 de Google. En nuestro caso, nos servirá para desplegar las funciones que creemos con JavaScript y Atom en el servidor Firebase Cloud Functions.  Postman: Se trata de una herramienta dirigida a desarrolladores web que permite realizar peticiones HTTP a cualquier API. Postman es muy útil a la hora de programar y hacer pruebas, puesto que nos ofrece la posibilidad de comprobar el correcto funcionamiento de nuestros desarrollos.  pCon.plannerSTD: Es una aplicación profesional que permite crear ambientes complejos de manera sencilla. El programa está diseñado teniendo en cuenta al arquitecto de interiores o diseñador profesional, pero es tan fácil de usar que el usuario particular puede sacar provecho fácilmente a la hora de planificar una cocina o salón.  Git: Es una herramienta para el control de versiones que ayuda a los desarrolladores a controlar diferentes partes y momentos del proyecto para que puedan trabajar en paralelo sin afectar el trabajo de otros. En este caso ha servido únicamente para ir guardando en un proyecto remoto los cambios que se iban desarrollando de la aplicación móvil.  Gitkraken: Es una potente y elegante interfaz gráfica multiplataforma para git desarrollada con Electron. De forma muy sencilla podemos llevar el completo seguimiento de nuestros repositorios, ver ramas, tags, crear nuevos, todo el historial de nuestro trabajo, commits etcétera.  Ninjamok: Es una aplicación web que nos permite diseñar bocetos de manera rápida y sencilla. Posee una versión de pago donde hay más elementos de diseño y evita marcas de agua, pero para evitar aumentar los costes se ha utilizado la versión gratuita. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 124  OpenProj: OpenProj es una aplicación gratuita y de código abierto para la gestión de proyectos y tareas avanzado que destaca por su usabilidad y es gratuito.  StarUML: StarUML es una herramienta para el modelamiento de software basado en los estándares UML (Unified Modeling Language) y MDA (Model Driven Arquitecture), que en un principio era un producto comercial y que hace cerca de un año paso de ser un proyecto comercial (anteriormente llamado plastic) a uno de licencia abierta GNU/GPL. 6.4. Detalles de implementación En este apartado se van a dar detalles de la implementación del sistema. Para ello se expondrá el código de ciertas partes o funcionalidades del sistema más representativas o importantes que merezcan o necesites una mayor explicación. Figura 42 Extracto de layout parte 1 Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 125 Figura 43 Extracto de layout parte 2 Figura 44 Extracto de layout parte 3 Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 132 Figura 54 Consola de Firebase para Storage En esta imagen vemos cómo se representan los datos almacenados en Storage, y al igual que en RealtimeDatabase, podemos gestionar su acceso y uso. Figura 55 Consola de Firebase para Functions En esta imagen vemos cómo se representa lista de Cloud Functions que tengamos subidas a nuestro proyecto de Firebase. También tenemos otros apartados que nos permiten ver datos como el éxito de las operaciones, el tiempo que han tardado en realizarse, etc. El despliegue y desarrollo de las Cloud Functions funcionan de diferente manera que el resto de módulos de Firebase. En este caso tenemos que usar el siguiente tutorial, https://firebase.google.com/docs/functions/get-started?authuser=0 , y disponer de las herramientas necesarias para su despliegue, serían NodeJS y un editor de código JS como Atom. 6.5.2. Arcore – Sceneform Como ya se ha comentado en otros apartados, para implementar realidad aumentada en nuestra aplicación Android a través de Android Studio necesitamos un motor lógico y un motor de contenido. Para nuestro sistema se ha elegido ARcore como motor lógico porque es una herramienta creada por Google permitiendo una fácil implementación en otros sistemas con otras tecnologías de Google como el nuestro. Está en constante desarrollo y crecimiento, y Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 133 aunque aún no está en los mejores puestos, es una de las mejores herramientas gratuitas para nuestro propósito. El despliegue de ARcore es muy sencillo siguiendo el siguiente tutorial, https://developers.google.com/ar/develop/java/enable-arcore .  Primero tenemos que declarar qué tipo de requerimientos de ARcore vamos a definir en el manifiesto. Siendo AR Optional el valor que tenemos que definir si queremos que nuestra aplicación se pueda instalar, aunque no sea compatible con Arcore (podemos comprobar la lista de dispositivos compatibles aquí https://developers.google.com/ar/discover/supported-devices ), o AR Required sino. En nuestro caso se ha elegido AR Required.  Segundo tenemos que añadir las dependencias necesarias a los archivos de configuración de la aplicación.  Por último, tenemos que implementar una serie de comprobaciones en el código para verificar aspectos como si nuestro dispositivo es compatible con Arcore, si lo es verificar si tenemos instalado Arcore y los permisos de la cámara. Figura 56 Comprobaciones de compatibilidad e instalación de ARcore Una vez tengamos desplegado Arcore en nuestra aplicación podemos usar una herramienta que nos ayudará al desarrollo de funciones de AR. Esta herramienta es arcoreimg tool y como dice en la página de referencia, https://developers.google.com/ar/develop/java/augmented-images/arcoreimg, nos ayuda a generar bases de datos de las imágenes que vayamos a usar en Augmented Images y a evaluar dichas imágenes para saber si son lo suficientemente buenas como para dar una buena experiencia de usuario. La evaluación de 0 a 100 siendo 75 la nota mínima recomendable para decir que es una imagen suficientemente buena. Como motor de contenido se ha elegido Sceneform porque, a pesar de proporcionar menos funcionalidades que si lo hiciéramos con OpenGl de manera nativa, proporciona Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 134 mayor facilidad de desarrollo. Podemos acudir a la página de ejemplos para saber qué funcionalidades están disponibles, https://github.com/google-ar/sceneform-androidsdk/releases, además de las novedades que trae cada versión. El despliegue de Sceneform es muy sencillo siguiendo este tutorial, https://developers.google.com/ar/develop/java/sceneform/:  Primero debemos instalar el plugin Google Sceneform Tools (Beta) que nos permita importar los modelos 3D.  Añadir las dependencias de Sceneform a los archivos de configuración.  Por último, tenemos que incluir el código que nos permita crear los Renderables, que son los objetos que contienen los modelos 3D, y la escena. 6.5.3. Cron-job Para la tarea de automatizar el borrado de aquellos eventos que han concluido, necesitamos un servicio externo, ya que Firebase de momento no lo dispone. Entre las diferentes opciones, se ha seguido la recomendación de la documentación de Google y se ha optado por Cron-job. Para usar este servicio, solo necesitamos:  Crearnos una cuenta en su plataforma  Crear un proyecto indicando qué petición HTTP tiene que mandar, la hora y la frecuencia con la que lo haga. En nuestro caso, la petición HTTP es aquella que hayamos generado con la Cloud Function que se encargue de este proceso que vamos a automatizar. Al igual que Firebase, Cron-job dispone de una consola para analizar el comportamiento de este servicio. Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 135 Figura 57 Creación de una tarea automática en Cron-job Figura 58 Lista de tareas en Cron-job Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 136 Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 137 Capítulo 7 – Pruebas En este apartado se explicarán las diferentes pruebas que se han realizado para comprobar el correcto funcionamiento de la aplicación. Para ello se han empleado diferentes pruebas de caja negra, que consisten en el estudio de la respuesta obtenida a partir de una entrada sin importar cómo se comporte el algoritmo de forma interna, sino si realiza la tarea que tiene encomendada. Figura 59 Prueba caja negra 7.1. Pruebas de caja negra Durante la etapa de desarrollo de UVassistantSG, se han realizado una serie de pruebas, pero para no extender demasiado este capítulo, se han seleccionado aquellas pruebas más relevantes y por tanto las que necesitan de más observación debido a que son operaciones críticas o que pueden presentar diferentes respuestas. Identificador PCN-01 Identificarse Propósito Autenticarse en el sistema Prerrequisitos Haberse registrado en el sistema Entrada Correo, contraseña Salida esperada Redirección a MainFragment con sesión creada y datos del usuario guardados Salida obtenida Aparición mensaje de error por falta de verificación Cambios realizados Indicar la necesidad de verificar el correo cuando se registra el usuario y enviar correo de verificación Salida esperada Redirección a MainFragment con sesión creada y datos del usuario guardados Salida recibida Redirección a MainFragment con sesión creada y datos del usuario guardados Tabla 79 PCN-01 Identificarse Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 138 Identificador PCN-02 Registrarse en la plataforma Propósito Registrarse en el sistema Prerrequisitos Ninguno Entrada Correo, nombre , contraseña, repetición de contraseña, rol y carrera (siempre que sea su rol Alumno) Salida esperada Redirección a MainFragment indicando la necesidad de verificar el correo y guardado de la información del usuario en Firebase Salida obtenida Datos guardados en Firebase Authentification pero no en RealtimeDatabase Cambios realizados Utilizar promesas para verificar que ambos procesos se realizan Salida esperada Redirección a MainFragment indicando la necesidad de verificar el correo y guardado de la información del usuario en Firebase Salida recibida Redirección a MainFragment indicando la necesidad de verificar el correo y guardado de la información del usuario en Firebase Tabla 80 PCN-02 Registrarse en la plataforma Identificador PCN-03 Cerrar sesión Propósito Cerrar la sesión del usuario Prerrequisitos Tener una sesión iniciada Entrada Ninguna Salida esperada Redirección a LoginActivity y haber borrado los datos de la sesión Salida obtenida Redirección a LoginActivity pero los datos del usuario no fueron borrados ni la aplicación despersonalizada Cambios realizados Borrar los datos del usuario de las SharedPreferences Salida esperada Redirección a LoginActivity y haber borrado los datos de la sesión Salida recibida Redirección a LoginActivity y haber borrado los datos de la sesión Tabla 81 PCN-03 Cerrar sesión Identificador PCN-04 Modificar evento Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 139 Propósito Modificar un evento que haya creado su propietario. Prerrequisitos Ser el creador del evento que se va a modificar Entrada Los nuevos datos que se quieran cambiar que son título, descripción o fecha Salida esperada Redirección a EventoDetailFragment con los datos actualizados Salida obtenida Redirección a EventoDEtailFragment pero no todos los nodos necesarios de la base de datos fueron actualizados Cambios realizados Utilizar un mapeo de datos para asegurar la atomicidad de la consulta Salida esperada Redirección a EventoDetailFragment con los datos actualizados Salida recibida Redirección a EventoDetailFragment con los datos actualizados Tabla 82 PCN-04 Modificar evento Identificador PCN-05 Abrir lector QR Propósito Utilizar la cámara del dispositivo para poder escanear códigos QR Prerrequisitos Estar logeado como Alumno Entrada Ninguna Salida esperada Mostrar en pantalla lo que recogía la cámara Salida obtenida El visor de la cámara en pantalla se quedaba negro Cambios realizados Gestionar el uso de los permisos de la cámara Salida esperada Mostrar en pantalla lo que recogía la cámara Salida recibida Mostrar en pantalla lo que recogía la cámara Tabla 83 PCN-05 Abrir lector QR Identificador PCN-06 Visualizar webs de la UVa Propósito Utilizar un navegador integrado en la mis app para poder acceder a páginas académicas Prerrequisitos Ninguno Entrada Ninguna Salida esperada Abrir un WebView donde poder visualizar y utilizar correctamente las páginas web Salida obtenida Gran dificultad para manejar los sitios web no preparados para dispositivos Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 140 móviles e incapacidad para una correcta navegación entre las mismas. Cambios realizados Añadir funciones para controlar de manera propia el acceso y manejo de aplicaciones webs problemáticas y añadir elementos de control para el acceso a la página web anterior Salida esperada Abrir un WebView donde poder visualizar y utilizar correctamente las páginas web Salida recibida Abrir un WebView donde poder visualizar y utilizar correctamente las páginas web Tabla 84 PCN-06 Visualizar webs de la Uva Identificador PCN-07 Escaneo de imágenes AR Propósito Representar contenido en una escena AR al escanear una imagen guardada Prerrequisitos Estar logeado como alumno Entrada Ninguna Salida esperada Visualizar en pantalla el contenido relacionado con la imagen escaneada en AR Salida obtenida Fallos al mostrar el contenido y dificultad a la hora de anclarlo a la escena Cambios realizados Utilizar imágenes para escanear con mayor calidad para este propósito Salida esperada Visualizar en pantalla el contenido relacionado con la imagen escaneada en AR Salida recibida Visualizar en pantalla el contenido relacionado con la imagen escaneada en AR Tabla 85 PCN-07 Escaneo de imágenes AR Identificador PCN-08 Crear foro de asistencia Propósito Crear un foro de consulta sobre un tema universitario Prerrequisitos Estar logeado como alumno Entrada Título, descripción Salida esperada Indicar el éxito de la creación del foro y guardar dicho foro en la base de datos Salida obtenida Indicar el éxito de la creación del foro y guardar dicho foro en la base de datos Tabla 86 PCN-08 Crear foro de asistencia Sergio Muñoz Gómez EUI de Segovia Universidad de Valladolid 141 Identificador PCN-09 Escribir comentario Propósito Añadir un comentario en un foro o evento Prerrequisitos Estar logeado Entrada Texto del comentario Salida esperada Guardar el comentario en la base de datos y mostrarlo en la lista de comentarios Salida obtenida Guardar el comentario en la base de datos y mostrarlo en la lista de comentarios Tabla 87 PCN-09 Escribir comentario Identificador PCN-10 Buscar usuario Propósito Encontrar el perfil buscado dentro de una lista de usuario Prerrequisitos Estar logeado Entrada Nombre del usuario Salida esperada Lista de perfiles cuyo nombre empieza por el nombre introducido Salida obtenida Lista de perfiles cuyo nombre empieza por el nombre introducido Tabla 88 PCN-10 Buscar usuario