Desarrollo de un sistema de rastreo para la Covid-19 Development of a tracking system of Covid-19
←
→
Transcripción del contenido de la página
Si su navegador no muestra la página correctamente, lea el contenido de la página a continuación
Desarrollo de un sistema de rastreo para la
Covid-19
Development of a tracking system of
Covid-19
Trabajo Fin de Grado
Curso 2020-2021
Autores
Fátima Irene García Delgado
Marina Lozano Lahuerta
Director
Antonio Sarasa Cabezuelo
Grado en Ingeniería del Software
Facultad de Informática
Universidad Complutense de Madrid
13 de septiembre de 2021
Desarrollo de un sistema de rastreo para la
Covid-19
Development of a tracking system of
Covid-19
Grado en Ingeniería del Software
Autores
Fátima Irene García Delgado
Marina Lozano Lahuerta
Director
Antonio Sarasa Cabezuelo
Convocatoria: septiembre 2021
Trabajo Fin de Grado en Ingeniería del Software
Facultad de Informática
Universidad Complutense de Madrid
13 de septiembre de 2021
Agradecimientos
0.1. Fátima Irene García Delgado
Quisiera trasmitir mi más sincero agradecimiento a todas aquellas personas que me han
ayudado a lo largo del desarrollo del Trabajo de Fin de Grado, y han ayudado de manera
directa o indirectamente en esta investigación.
En primer lugar, a mi tutor, Antonio Sarasa, por su ayuda en la planificación y organi-
zación en este Trabajo de Fin de Grado.
En segundo lugar, a mi familia; mi madre Angelines y mi padre Jesús. A mis fieles amigos
y a mi pareja, que han estado a lo largo de todo mi desarrollo formativo apoyándome
en todo momento y animándome a seguir adelante, incluso cuando yo no veía fin a las
temporadas de exámenes.
Por último, a mis compañeros de clase, ha sido un período de aprendizaje y desarollo
conjunto, donde entre todos o la mayoría, hemos intentando siempre lo mejor para la
clase.
A todos ellos, muchísimas gracias.
0.2. Marina Lozano Lahuerta
En primer lugar, quiero agradecer especialmente a mi familia, a mis padres y a mis
hermanos, por todo el apoyo que siempre me han dado, por estar ahí siempre animándome
a seguir. También a mis amigos, que me han acompañado a lo largo del camino.
Por otro lado, quiero agradecer a todos los compañeros maravillosos que me he ido encon-
trando a lo largo de mi carrera académica a los que, a algunos de ellos, tengo la suerte de
llamar amigos, su ayuda y apoyo ha sido imprescindible para mí, me alegra haber podido
compartir esta etapa de mi vida con ellos y haber podido crecer juntos.
Y por supuesto, a mi tutor del Trabajo de Fin de Grado, Antonio Sarasa, por toda su
ayuda a lo largo de todo el desarrollo del proyecto.
v
Resumen
El presente Trabajo de Fin de Grado consiste en una aplicación Android que permite
a los usuarios que interactúan con ella llevar un control de su exposición frente a la Covid-
19. Para ello, los usuarios que usen esta plataforma, podrán consultar el riesgo de contagio
actual, calculado según las localizaciones en las que ha estado o, en caso de dar positivo,
notificarlo y alertar al resto de usuarios. Permitiendo de esta manera una monitorización
de la exposición al virus, y a su vez ayudando a que otros usuarios hagan lo mismo, siendo
una relación simbiótica entre usuarios.
Por otro lado, los rastreadores que utilicen la aplicación pueden usar esas ubicaciones
para avisar a otras personas de su situación con respecto a su exposición al virus y añadir
ubicaciones de usuarios no registrados aumentando la fiabilidad de la aplicación.
Se han utilizado las técnicas más usadas para el desarrollo de este tipo de aplicaciones,
con tecnologías modernas, que ofrecen una mayor seguridad tanto para el desarrollador
como los usuarios que interactúan con ella.
El principal objetivo esta aplicación es lograr un control sobre un virus altamente
contagioso, como lo es la Covid-19, además de reducir la incidencia y parar la cadena de
contagio avisando a los usuarios de la exposición real en cada momento.
vi
Palabras clave
• Covid
• Coronavirus
• Android
• API
• Java
• REST
• Spring
vii
Abstract
This Final Degree Project consists of an Android application that allows users who
interact with it to keep track of their exposure to Covid-19. To do this, users who use
this platform will be able to consult the current contagion risk, calculated according to
the locations where they have been or, in case of testing positive, notify and alert other
users. Allowing in this way a monitoring of exposure to the virus, and in turn helping
other users to do the same, being a symbiotic relationship between users.
On the other hand, trackers using the application can use these locations to alert
other people to their situation regarding their exposure to the virus and add unregistered
user locations increasing the reliability of the application.
The most commonly used techniques have been used for the development of this
type of application, with modern technologies, which offer greater security for both the
developer and the users who interact with it.
The main objective of this application is to achieve control over a highly contagious
virus, such as Covid-19, in addition to reducing the incidence and stopping the chain of
contagion by notifying users of the actual exposure at all times.
viii
Key Words
• Covid
• Coronavirus
• Android
• API
• Java
• REST
• Spring
ix
Índice
0.1. Fátima Irene García Delgado . . . . . . . . . . . . . . . . . . . . . . . . v
0.2. Marina Lozano Lahuerta . . . . . . . . . . . . . . . . . . . . . . . . . . . v
1. Introducción 1
1.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1. Introduction 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Document’s structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Estado del arte 5
3. Especificación de requisitos y Casos de uso. 7
3.1. Actores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2. Rastreador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.3. Administrador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Módulo funcional “Gestión de usuarios” . . . . . . . . . . . . . . . . . . . 9
3.3. Módulo funcional “ubicaciones” . . . . . . . . . . . . . . . . . . . . . . . 18
3.4. Módulo funcional “rastreadores” . . . . . . . . . . . . . . . . . . . . . . . 22
4. Planificación 25
5. Tecnologías 26
5.1. Spring Java Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2. Retrofit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3. Android Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.4. Firebase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.5. Google API - Firebase Cloud Messaging (FCM) . . . . . . . . . . . . . . 27
5.6. Google API - Google Maps . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.7. XAMPP y phpMyAdmin . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.8. MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.9. Postman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.10. Git y Github . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
xÍNDICE xi
6. Arquitectura y modelo de datos 30
6.1. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.1.1. API Rest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2. Patrones de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2.1. Modelo-Vista-Controlador . . . . . . . . . . . . . . . . . . . . . . 31
6.2.2. Singleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.2.3. DAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.2.4. Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.3. Modelo de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7. Implementación 38
7.1. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.1.1. Elementos de Android . . . . . . . . . . . . . . . . . . . . . . . . 38
7.2. Clases principales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.2.1. AndroidManifest . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.2.2. Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.2.3. Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.2.4. Gradle Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.3. Implementación de la API REST . . . . . . . . . . . . . . . . . . . . . . 46
7.4. Acceso al repositorio Github del proyecto . . . . . . . . . . . . . . . . . . 48
8. Conclusiones y trabajo a futuro 49
8.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
8.2. Trabajo a futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8. Conclusions and future work 51
8.1. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.2. Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
9. Aportaciones individuales 53
9.1. Fátima Irene García Delgado . . . . . . . . . . . . . . . . . . . . . . . . 53
9.2. Marina Lozano Lahuerta . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Bibliografía y enlaces de referencia 55
Anexos. 59
I. Manual de Instalación 59
I.1. Herramientas necesarias . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
I.1.1. Xampp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
I.1.2. Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
I.1.3. Android Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
I.2. Ejecución de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . 60
II. Manual de Usuario 62
II.1. Registro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
II.2. Solicitud de Registro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
II.3. Iniciar y/o cerrar Sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . 64xii ÍNDICE
II.4. Opciones de Usuarios registrados . . . . . . . . . . . . . . . . . . . . . . 65
II.4.1. Inicio / Home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
II.4.2. Consultar alertas . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
II.4.3. Exposición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
II.4.4. Modificar datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
II.4.5. Ubicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
II.4.6. Darse de baja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
II.5. Opciones de Rastreadores . . . . . . . . . . . . . . . . . . . . . . . . . . 69
II.5.1. Inicio / Home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
II.5.2. Gestión usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
II.5.3. Añadir usuarios anónimos . . . . . . . . . . . . . . . . . . . . . . 71
II.5.4. Ubicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
II.6. Opciones de Administradores . . . . . . . . . . . . . . . . . . . . . . . . 73
II.6.1. Inicio / Home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
II.6.2. Listar usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
II.6.3. Solicitudes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Índice de figuras
3.1. Casos de uso de Gestión de Usuarios . . . . . . . . . . . . . . . . . . . . 9
3.2. Casos de uso de Gestión de Ubicaciones . . . . . . . . . . . . . . . . . . . 18
3.3. Casos de uso de Gestión de Rastreadores . . . . . . . . . . . . . . . . . . 23
5.1. Diagrama de Tecnologías implementadas en Covrad . . . . . . . . . . . . 29
6.1. Diagramas de componentes . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.2. Esquema básico de arquitectura API Rest . . . . . . . . . . . . . . . . . 31
6.3. Entidad Usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.4. Controlador Usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.5. Ejemplo de implementación de Singleton, . . . . . . . . . . . . . . . . . . 33
6.6. ejemplo de implementación de DAO . . . . . . . . . . . . . . . . . . . . . 34
6.7. Patrón Adapter aplicado a las listas de localizaciones del proyecto . . . . 34
6.8. Modelo Entidad-Relación . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.9. Modelo Relacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.1. Estructura de carpetas en Android Studio. . . . . . . . . . . . . . . . . . 39
7.2. Nombre definido en el Manifest . . . . . . . . . . . . . . . . . . . . . . . 40
7.3. Componentes definidos en el Manifest . . . . . . . . . . . . . . . . . . . . 41
7.4. Permisos definidos en el Manifest . . . . . . . . . . . . . . . . . . . . . . 41
7.5. Organización de carpetas de Activities. . . . . . . . . . . . . . . . . . . . 42
7.6. Ejemplo de Activity. LoginActivity. . . . . . . . . . . . . . . . . . . . . . 43
7.7. Ejemplo de Model. Location. . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.8. Ejemplo de Servicio. UserService. . . . . . . . . . . . . . . . . . . . . . . 44
7.9. Configuración de depencias en Gradle . . . . . . . . . . . . . . . . . . . . 46
7.10. Configuración de recursos en Gradle . . . . . . . . . . . . . . . . . . . . . 46
7.11. Objeto Repository de las alertas . . . . . . . . . . . . . . . . . . . . . . . 47
7.12. Objeto Entity de las alertas . . . . . . . . . . . . . . . . . . . . . . . . . 48
I.1. Arranque de los servicios Apache y MySQL en Xampp . . . . . . . . . . 60
I.2. Arranque de API REST en Eclipse . . . . . . . . . . . . . . . . . . . . . 60
I.3. IP en Android Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
I.4. Ejecutar aplicación en Android Studio . . . . . . . . . . . . . . . . . . . 61
II.1. Navegación de Login a Registro . . . . . . . . . . . . . . . . . . . . . . . 62
II.2. Ejemplo formulario de registro relleno. . . . . . . . . . . . . . . . . . . . 63
II.3. Ejemplo formulario para solicitar un registro . . . . . . . . . . . . . . . . 63
II.4. Iniciar sesión. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
II.5. Cerrar sesión. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
xiiixiv ÍNDICE DE FIGURAS II.6. Menu de Usuario registrado. . . . . . . . . . . . . . . . . . . . . . . . . . 65 II.7. Inicio de Usuario registrado. . . . . . . . . . . . . . . . . . . . . . . . . . 65 II.8. Estados del Usuario registrado. . . . . . . . . . . . . . . . . . . . . . . . 66 II.9. Consultar alertas de Usuario registrado. . . . . . . . . . . . . . . . . . . 66 II.10.Exposicion de Usuario, según su estado. . . . . . . . . . . . . . . . . . . 67 II.11.Edición de datos del usuario. . . . . . . . . . . . . . . . . . . . . . . . . . 67 II.12.Mensaje de solicitud de contraseña. . . . . . . . . . . . . . . . . . . . . . 68 II.13.Ubicaciones del usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 II.14.Darse de baja de un usuario . . . . . . . . . . . . . . . . . . . . . . . . . 69 II.15.Menú de un rastreador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 II.16.Inicio de un rastreador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 II.17.Gestión de usuarios de un rastreador. . . . . . . . . . . . . . . . . . . . . 71 II.18.Agregar usuarios anónimos de un rastreador. . . . . . . . . . . . . . . . . 71 II.19.Ubicaciones de un rastreador. . . . . . . . . . . . . . . . . . . . . . . . . 72 II.20.Registro de una ubicación de un rastreador. . . . . . . . . . . . . . . . . 73 II.21.Menú de un administrador. . . . . . . . . . . . . . . . . . . . . . . . . . . 73 II.22.Inicio de un administrador. . . . . . . . . . . . . . . . . . . . . . . . . . . 74 II.23.Listar usuarios de un administrador. . . . . . . . . . . . . . . . . . . . . 75 II.24.Solicitudes de un administrador. . . . . . . . . . . . . . . . . . . . . . . . 76
Índice de tablas
3.1. Requisito Iniciar sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Requisito Cerrar sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Requisito Mostrar datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4. Requisito Modificar datos . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5. Requisito Modificar estado . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.6. Requisito Consultar alertas . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.7. Requisito Dar de alta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.8. Requisito Registrar usuarios anónimos . . . . . . . . . . . . . . . . . . . 14
3.9. Requisito Solicitar darse de alta . . . . . . . . . . . . . . . . . . . . . . . 14
3.10. Requisito Dar de baja . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.11. Requisito Listar usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.12. Requisito Listar solicitudes de alta . . . . . . . . . . . . . . . . . . . . . 16
3.13. Requisito Gestionar solicitudes de alta . . . . . . . . . . . . . . . . . . . 17
3.14. Requisito Dar de baja . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.15. Requisito Registrar ubicación manual . . . . . . . . . . . . . . . . . . . . 19
3.16. Requisito Registrar ubicación automática . . . . . . . . . . . . . . . . . . 20
3.17. Requisito Listar ubicaciones . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.18. Requisito Listar ubicaciones por usuario . . . . . . . . . . . . . . . . . . 21
3.19. Filtrar ubicaciones por usuario . . . . . . . . . . . . . . . . . . . . . . . . 21
3.20. Filtrar ubicaciones por estado . . . . . . . . . . . . . . . . . . . . . . . . 22
3.21. Requisito Eliminar ubicación . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.22. Requisito Notificar alerta . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.23. Requisito Modificar estado de usuario específico . . . . . . . . . . . . . . 24
3.24. Requisito registrar ubicación de usuario usuario específico . . . . . . . . . 24
6.1. Tabla Usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2. Tabla Alertas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.3. Tabla Ubicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.4. Tabla Solicitudes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
xvCapítulo 1
Introducción
1.1. Motivación
El contexto actual de crisis sanitaria provocada por la COVID-19, ha afectado a
todas las actividades de la sociedad y economía, ya que el riesgo de contagio es muy alto
en las interacciones sociales. En este sentido, el contacto cercano entre personas es la
forma más fácil de propagar el virus.
La finalidad de este proyecto es desarrollar una aplicación móvil que indique a la
persona que la utilice, en tiempo real, su riesgo de exposición actual dada su localiza-
ción.
La aplicación mantendrá actualizada la exposición de la persona, avisándole en caso
de correr riesgo de contagio, intentando de esta manera reducir el número de conta-
gios.
1.2. Objetivos
El objetivo principal de este proyecto es desarrollar una aplicación que permita a
una persona consultar su exposición a la Covid-19 dada su localización. Este objetivo se
puede desglosar en los siguientes objetivos más específicos:
• Desarrollar una aplicación móvil que permita a un usuario consultar su nivel de
exposición al virus a partir de las localizaciones en las que ha estado.
• Recibir alertas y/o notificaciones sobre su nivel de exposición.
• Permitir a los rastreadores registrar a personas que se hayan hecho las pruebas del
Covid-19 y mejorar la capacidad predictiva de la aplicación.
• Presentar una aplicación amigable y sencilla al usuario.
• Mostrar al usuario datos fiables y reales.
• Desarrollar una aplicación robusta y estable.
12 Capítulo 1. Introducción
1.3. Estructura de la memoria
La memoria de este proyecto se estructura de la siguiente manera.
En el capítulo 1 se plantea la motivación y los objetivos que se pretenden conseguir
con el desarrollo de esta aplicación.. Así mismo se describe la estructura de la memo-
ria.
En el capítulo 2 se revisan algunas soluciones con una funcionalidad semejante a la
desarrollada en este trabajo.
En el capítulo 3 describen los casos de uso de la aplicación agrupados en tres módulos:
gestión de usuarios, ubicación y rastreador.
En el capítulo 4 se describe la planificación del desarrollo del proyecto.
En el capítulo 5 se comenta la tecnología empleada para la implementación de la
aplicación.
El capítulo 6 presenta la arquitectura y los patrones de diseño utilizados en la apli-
cación, así como el modelo de datos utilizado.
El diseño y funcionalidad de la aplicación móvil desarrollada se describe en el capítulo
7.
Las conclusiones y el trabajo futuro, y las aportaciones individuales se desarrollan
en los capítulos 8, y 9, respectivamente.
En último lugar se encuentra la bibliografía y los anexos, en los que se incluyen una
guía de instalación de la aplicación y una guía de uso.Capítulo 1
Introduction
1.1. Motivation
The current context of the health crisis caused by COVID-19 has affected all activities
of society and the economy, since the risk of contagion is very high in social interactions.
Close contact between people is the easiest way to spread the virus.
The purpose of this project is to develop a mobile application that indicates to the
person who uses it, in real time, their current risk of exposure given their location.
The application will keep the person’s exposure up to date, warning them in case of
risk of contagion, thus trying to reduce the number of infections.
1.2. Goals
The main goal of this project is to develop an application that allows a person to
consult their exposure to Covid-19 given their location. This objective can be broken
down into the following more specific objectives:
• Develop a mobile application that allows a user to check their level of exposure to
the virus from the locations where they have been.
• Receive alerts and/or notifications about your level of exposure.
• Allow health personnel to register people who have been tested for Covid-19 and
improve the predictive capacity of the application.
• Present a friendly and simple application to the user.
• Show the user reliable and real data.
• Develop a robust and stable application.
34 Capítulo 1. Introduction
1.3. Document’s structure
This document is structured as follows.
Chapter 1 raises the motivation and objectives to be achieved with the development
of this application. Likewise, the memory structure is described.
In chapter 2 some solutions with a similar functionality to that developed in this
work are reviewed.
In Chapter 3 the use cases of the application are described and grouped into three
modules: user management, location and tracker.
Chapter 4 describes project development planning.
In chapter 5 the technology used to implement the application is discussed.
Chapter 6 presents the architecture and design patterns used in the application, as
well as the data model used.
The design and functionality of the developed mobile application is described in
chapter 7.
The conclusions and future work, and individual contributions are developed in chap-
ters 8 and 9, respectively.
Lastly, there is the bibliography and the annexes, which include an application ins-
tallation guide and a user guide.Capítulo 2
Estado del arte
Teniendo en cuenta la situación que está viviendo el planeta entero con la Covid-19
y siendo un tema tan importante se han desarrollado varias aplicaciones semejantes a al
proyecto implementado, muchas de ellas puestas en marcha por los propios gobiernos de
distintos países.
Algunas aplicaciones móviles que encontramos son:
• Radar Covid [1]
Es una aplicación oficial del gobierno de España la cual lleva un registro de los
usuarios con los que se ha tenido un contacto estrecho, utilizando esa informa-
ción para determinar el riesgo de haberse infectado por la Covid-19. Utiliza la
API de notificación creada por Android y Apple [2], la cuál no recopila ningún
dato de geolocalización sino que utiliza Bluetooth Low Energy para intercam-
biar códigos que cambian varias veces cada hora. Estos códigos son guardados
durante 14 días.
• CovTracer [3]
Es la aplicación oficial del gobierno de Chipre. Esta aplicación, al igual que
la anterior, utiliza tecnología Bluetooth para medir la distancia y la duración
del contacto entre personas (generalmente más de quince minutos en menos de
dos metros). Utiliza claves aleatorias diarias que comparte con los dispositivos
cercanos y en caso de que un usuario resulte positivo se alerta a los usuarios
que han estado en contacto con esa persona.
• SwissCovid [4]
Esta aplicación funciona de manera similar a las anteriores, todas ellas uti-
lizan el SDK de Android DP3T (Decentralised Privacy-Preserving Proximity
Tracing) [5] que se basa en las notificaciones de exposición de Google y Apple.
• HaMagen [6]
Es una aplicación lanzada por el Ministerio de Salud de Israel. HaMagen noti-
fica a aquellos usuarios que han estado en contacto estrecho con un positivo en
la Covid-19. Utiliza el historial de ubicaciones (GPS) de las últimas dos sema-
nas y el historial de las redes inalámbricas WIFI para comprobar la exposición
56 Capítulo 2. Estado del arte
a personas contagiadas.
Esta última aplicación al igual que la aplicación implementada utiliza la localización
que provee el dispositivo móvil para hacer referencias cruzadas con las de otros usuarios
y poder, de esta forma, calcular el nivel de exposición de los usuarios.Capítulo 3
Especificación de requisitos y Casos de
uso.
En este capítulo se van a especificar los requisitos de la aplicación desarrollada. Para
ello, en primer lugar se describirán los actores que interactuarán con la aplicación, y a
continuación se desarrollarán los casos de uso en los que intervienen los actores agrupados
por módulos funcionales.
3.1. Actores
En la aplicación planteada en este proyecto se han definido los siguientes acto-
res:
3.1.1. Usuario
Son aquellas personas que compartirán sus datos de localización y su estado de salud
para facilitar el control de los brotes de contagios.
• Usuario registrado.
Aquellas personas que manualmente se han descargado la aplicación y se han regis-
trado en el sistema ellos mismos.
• Usuario anónimo.
Aquellas personas que directa o indirectamente han estado en contacto con un
usuario registrado positivo y no se han dado de alta voluntariamente en la aplicación
sino que han sido de alta por un rastreador.
3.1.2. Rastreador
Aquellas personas encargadas de localizar, identificar y seguir casos positivos de
contagio de la enfermedad.
78 Capítulo 3. Especificación de requisitos y Casos de uso.
3.1.3. Administrador
Son aquellas personas encargadas de gestionar los usuarios dentro de la aplica-
ción.
La funcionalidad de la aplicación se ha agrupado en módulos funcionales:
• GESTIÓN DE USUARIOS
• UBICACIÓN
• RASTREADOR
En los siguientes apartados se desarrollan cada uno de estos módulos.3.2. Módulo funcional “Gestión de usuarios” 9
3.2. Módulo funcional “Gestión de usuarios”
En este módulo se ha agrupado toda la funcionalidad referente a la gestión de la
información de los usuarios.
Figura 3.1: Casos de uso de Gestión de Usuarios
A continuación se van a describir los casos de uso que forman parte de este módulo
como se muestra en la Figura 3.1:10 Capítulo 3. Especificación de requisitos y Casos de uso.
RADCOV01 Iniciar Sesión
Actor Usuario, rastreador, administrador
Descripción Acceso de un usuario registrado en la aplicación.
Precondición El usuario debe existir dentro del sistema, y no tener
una sesión ya iniciada.
Secuencia normal
a). El usuario clica sobre inicio de sesión, donde
se mostrará un formulario con las credenciales
necesarias para poder iniciar sesión en la apli-
cación.
b). El usuario introduce sus credenciales
c). El sistema verifica las credenciales.
d). Se muestra la pantalla de inicio del usuario iden-
tificado.
Postcondición El usuario tiene una sesión activa.
Excepciones
Pto. a: datos erróneamente introducidos, serán
marcados a través de un mensaje de error.
Pto. b: credenciales erróneas. Se muestra men-
saje de error y se vuelve a la pantalla del for-
mulario.
Comentarios
Tabla 3.1: Requisito Iniciar sesión
RADCOV02 Cerrar Sesión
Actor Usuario, rastreador, administrador
Descripción Se cierra la sesión del usuario.
Precondición El usuario tiene que tener una sesión activa.
Secuencia normal
a). El usuario clica sobre cerrar sesión.
b). El sistema borra la sesión del usuario.
c). Se vuelve a la pantalla de inicio (inicio de sesión)
de la aplicación.
Postcondición No hay ninguna sesión activa del usuario.
Excepciones
Pto. a: error en el cierre de sesión. Se manda
mensaje de error.
Comentarios
Tabla 3.2: Requisito Cerrar sesión3.2. Módulo funcional “Gestión de usuarios” 11
RADCOV03 Mostrar datos
Actor Usuario, rastreador, administrador
Descripción Muestra los datos de un usuario del sistema.
Precondición El usuario tiene que estar dado de alta y con la sesión
activa en el sistema.
Secuencia normal
a). Usuario selecciona la opción para ver sus datos.
b). El sistema carga los datos del usuario y los
muestra.
Postcondición El usuario tiene acceso a los datos de su perfil. No se
modifica la base de datos.
Excepciones
Comentarios Cada actor tiene sus atributos propios y/o comunes
para mostrar.
Tabla 3.3: Requisito Mostrar datos
RADCOV04 Modificar datos
Actor Usuario
Descripción Modifica los datos de un usuario del sistema.
Precondición El usuario tiene que estar dado de alta en el sistema.
Secuencia normal
a). Se modifican aquellos datos que el sistema per-
mita.
b). Confirmación de desear cambiar esos datos.
c). Actualización de los datos en el sistema.
d). Mensaje de satisfacción al usuario.
Postcondición Usuario con los datos actualizados en el sistema.
Excepciones
Pto. a: en caso de haber errores, se notifican los
errores para que los corrijan.
Pto. b: en caso de producirse un error al actua-
lizar los datos se notificará error al usuario.
Comentarios Cada actor tiene sus atributos propios y/o comunes
para mostrar.
Tabla 3.4: Requisito Modificar datos12 Capítulo 3. Especificación de requisitos y Casos de uso.
RADCOV05 Modificar estado
Actor Usuario
Descripción Modifica el estado del usuario.
Precondición El usuario tiene que estar dado de alta en el sistema.
Secuencia normal
a). El usuario cambia su estado de positivo a nega-
tivo o viceversa.
b). Confirmación de cambio de estado.
c). Actualización de los datos en el sistema.
d). Mensaje de satisfacción al usuario.
Postcondición Usuario con el estado actualizado en el sistema.
Excepciones
Pto. a: en caso de cancelar, se mantiene el estado
inicial.
Pto. b: en caso de producirse un error al actua-
lizar los datos se notificará error al usuario.
Comentarios Cuando se produce un cambio de estado, el sistema
se encarga de buscar otros usuarios que puedan haber
estado en contacto para mandar una alerta.
Tabla 3.5: Requisito Modificar estado
RADCOV06 Consultar alertas
Actor Usuario
Descripción Muestra registro de alertas que el sistema ha notifi-
cado.
Precondición Deben existir alertas registradas en el sistema.
Secuencia normal
a). El usuario clica sobre “Consultar alertas”.
b). Se cargar las notificaciones que se han registrado
por parte del sistema.
Postcondición Usuario con el estado actualizado en el sistema.
Excepciones
Comentarios
Tabla 3.6: Requisito Consultar alertas3.2. Módulo funcional “Gestión de usuarios” 13
RADCOV07 Dar de alta
Actor Usuario, administrador
Descripción Añadir un nuevo usuario al sistema de la aplicación
con sus datos (nombre, DNI, email, . . . )
Precondición Hay campos obligatorios que debe rellenar el usuario
para poder darse de alta en el sistema.
Secuencia normal
a). Se muestra formulario de inscripción al usuario.
b). Se pide confirmación de alta al usuario.
c). Alta del usuario en el sistema.
d). Se manda mensaje de confirmación del alta.
Postcondición Se genera un identificador único asociado al nuevo
usuario dentro del sistema.
Excepciones
Pto. a: si rechaza el alta, volverá a la página de
registro.
Pto. b: usuario ya registrado con algunos datos
unívocos. Se notifica al usuario que revise los
datos.
Comentarios Este requisito es padre de:
RADCOV08 Registrar usuarios anóni-
mos: un rastreador puede registrar usuarios
anónimos positivos, que se tendrán en cuenta
dentro del sistema.
RADCOV13 Gestionar solicitudes de al-
ta: a través de una solicitud, un administrador
gestionará las solicitudes.
Tabla 3.7: Requisito Dar de alta14 Capítulo 3. Especificación de requisitos y Casos de uso.
RADCOV08 Registrar usuarios anónimos
Actor Rastreador.
Descripción Registra un nuevo usuario anónimo según el Requisito
RADCOV07-02 de la tabla [3.7]
Precondición
Secuencia normal
a). Se rellena el formulario para el registro de un
usuario anónimo.
b). Se indica si el usuario es Positivo/Negativo.
c). Se confirma registro.
Postcondición Se registra nuevo usuario tipo Anónimo en la base de
datos.
Excepciones Pto. c: Salta una mensaje de error de registro.
Comentarios
Tabla 3.8: Requisito Registrar usuarios anónimos
RADCOV09 Solicitar darse de alta
Actor Rastreador, administrador
Descripción Se solicita al administrador que registre nuevos ras-
treadores/administradores en el sistema.
Precondición Debe existir algún administrador en el sistema.
Secuencia normal
a). Se rellena formulario de inscripción.
b). Se sube formulario al sistema y se selecciona el
tipo de solicitud (Administrador/ Rastreador).
c). Se confirma la solicitud.
Postcondición Se registrará la solicitud en el sistema.
Excepciones
Pto. a: error en el formato del formulario. Se
notifica error.
Comentarios Una vez recibido el formulario el proceso continuará
con el Req. RADCOV07 [3.7]: Dar de alta.
Tabla 3.9: Requisito Solicitar darse de alta3.2. Módulo funcional “Gestión de usuarios” 15
RADCOV10 Dar de baja
Actor Usuario, adminsitrador
Descripción Se elimina usuario del sistema.
Precondición El usuario tiene que estar dado de alta en el sistema.
Secuencia normal
a). Usuario marca botón de darse de baja en su
interfaz.
b). Se pide confirmación de querer darse de baja.
c). Se elimina al usuario del sistema.
d). Se indica mensaje de confirmación de la baja.
e). Se vuelve a la pantalla de inicio/registro de la
aplicación.
Postcondición Usuario inactivo dentro del sistema.
Excepciones
Comentarios Un usuario registrado puede darse de baja a sí mismo.
En caso de ser un rastreador o administrador solo se
puede gestionar su baja a través de otro administra-
dor.
Tabla 3.10: Requisito Dar de baja
RADCOV11 Listar usuarios
Actor Rastreador, administrador
Descripción Lista de los usuarios registrados en el sistema.
Precondición Debe existir al menos un usuario registrado en el sis-
tema.
Secuencia normal
a). El administrador clica sobre la opción de listar
usuarios.
b). El sistema carga los datos.
c). Se muestran los usuarios activos en el sistema.
Postcondición Se tendrá acceso a los usuarios. No se realiza ninguna
modificación en la base de datos.
Excepciones
Pto b: No existen usuarios, se muestra mensaje
de error.
Comentarios Un rastreador solo podrá visualizar a los usuarios re-
gistrados y/o anónimos. Un administrador, podrá ver
a usuarios registrados/anónimos, rastreadores y/o ad-
ministradores.
Tabla 3.11: Requisito Listar usuarios16 Capítulo 3. Especificación de requisitos y Casos de uso.
RADCOV12 Listar Solicitudes de alta
Actor Administrador
Descripción Lista las solicitudes de alta por parte de un rastrea-
dor/administrador.
Precondición Para mostrar solicitudes disponibles, deben haber
completado el cuestionario de registro previamente
indicado en Req. RADCOV09 [3.9] Solicitar dar
de alta.
Secuencia normal
a). El administrador clica sobre la opción de listar
solicitudes.
b). El sistema carga los datos.
c). Se muestran los solicitudes registradas en el sis-
tema.
Postcondición No se realiza ninguna modificación en la base de da-
tos.
Excepciones
Pto b: No existen solicitudes, se muestra men-
saje de error.
Comentarios
Tabla 3.12: Requisito Listar solicitudes de alta3.2. Módulo funcional “Gestión de usuarios” 17
RADCOV13 Gestionar solicitudes de alta
Actor Administrador
Descripción Dada una lista de peticiones, se podrán aceptar o re-
chazar.
Precondición Debe existir al menos una solicitud en el sistema de
base de datos en base al Req. RADCOV09 [3.9]
Solicitar dar de alta.
Secuencia normal
a). El administrador clica sobre la opción de listar
solicitudes.
b). El administrador podrá seleccionar 2 botones en
cada solicitud:
a) Aceptar: si se pulsa esta opción. Se regis-
trará un nuevo usuario en la base de datos
con los datos de la solicitud.
b) Rechazar: se pedirá mensaje de confirma-
ción. La solicitud queda en estado rechaza-
do.
Postcondición Nuevo usuario tipo rastreador/administrador en el
sistema.
Excepciones
Pto a.a: Los datos del nuevo usuario son erró-
neos. Se notificará a través del email de registro
que no se ha podido dar de alta.
Comentarios
Tabla 3.13: Requisito Gestionar solicitudes de alta18 Capítulo 3. Especificación de requisitos y Casos de uso.
RADCOV14 Dar de baja
Actor Usuario registrado, administrador
Descripción Dado una lista de usuarios, se podrá/n dar de baja
del sistema.
Precondición Debe existir al menos dos usuarios en el sistema de
base de datos.
Secuencia normal
a). El administrador podrá seleccionar 1 botón de
borrado sobre un listado de usuarios:
a) Borrar: si se pulsa esta opción. Se confir-
mará la solicitud de baja del usuario selec-
cionado:
1) Se acepta: se eliminará dicho usuario.
2) Se cancela: se vuelve al listado de
usuarios.
Postcondición Usuario borrado de la base da datos.
Excepciones
Comentarios Un usuario registrado puede darse de baja a sí mismo.
Un rastreador/administrador deben ser dados de baja
por otro administrador.
Tabla 3.14: Requisito Dar de baja
3.3. Módulo funcional “ubicaciones”
En este módulo se ha agrupado la funcionalidad referente a la gestión de la informa-
ción de las ubicaciones de los usuarios.
Figura 3.2: Casos de uso de Gestión de Ubicaciones3.3. Módulo funcional “ubicaciones” 19
A continuación se van a describir los casos de uso que forman parte de este módulo
como se muestra en la Figura [3.2]:
RADCOV15 Registrar ubicación manual
Actor Usuario registrado, rastreador
Descripción Añadir una ubicación manualmente al sistema de la
aplicación con sus datos (coordenadas, usuario, hora).
Precondición Debe existir al menos un usuario registrado en el sis-
tema.
Secuencia normal
a). El sistema muestra un mapa interactivo, se
mantiene pulsado sobre la ubicación que se
desee registrar.
b). EL usuario clica sobre la opción .Añadir ubica-
ción".
c). El sistema informa de que la ubicación ha sido
registrada correctamente.
Postcondición El sistema registra una nueva ubicación la cual ya
puede ser utilizada para realizar el rastreo.
Excepciones
Pto a: Coordenadas erróneas, se muestra men-
saje de error de las coordenadas y se pide volver
a introducirlo.
Pto c: Error al registrar los datos en la base de
datos, se muestra mensaje de error.
Comentarios Un usuario registrado puede darse de baja a sí mismo.
Un rastreador/administrador deben ser dados de baja
por otro administrador.
Tabla 3.15: Requisito Registrar ubicación manual20 Capítulo 3. Especificación de requisitos y Casos de uso.
RADCOV16 Registrar ubicación automática
Actor Sistema
Descripción Añadir una ubicación al sistema de la aplicación con
sus datos (coordenadas, usuario, hora)
Precondición Debe existir al menos un usuario registrado en el sis-
tema.
Secuencia normal
a). El sistema cada x minutos o cada vez que se
cambie la ubicación registra una nueva ubica-
ción.
Postcondición El sistema registra una nueva ubicación la cual ya
puedeser utilizada para realizar el rastreo.
Excepciones
Comentarios Requisito propio del sistema.
Tabla 3.16: Requisito Registrar ubicación automática
RADCOV17 Listar ubicaciones
Actor Usuario registrado, rastreador.
Descripción Se muestran todas las ubicaciones y los datos de las
ubicaciones.
Precondición Debe haber al menos una ubicación registrada en el
sistema.
Secuencia normal
a). Se selecciona el filtro por el que se quiere buscar
y se indica un valor.
b). El sistema muestra una lista con todas las ubi-
caciones.
Postcondición Se mostrarán los datos de las ubicaciones. No se mo-
difica ningún dato en la base de datos.
Excepciones
Comentarios Los filtros serán únicamente para los rastreadores. Los
usuarios registrados tendrán acceso solo a sus ubica-
ciones.
Tabla 3.17: Requisito Listar ubicaciones3.3. Módulo funcional “ubicaciones” 21
RADCOV18 Listar ubicaciones por usuario
Actor Usuario registrado.
Descripción Se muestran todas las ubicaciones y los datos de las
ubicaciones del usuario que ha iniciado sesión.
Precondición Debe haber al menos una ubicación registrada en el
sistema.
Secuencia normal
a). El sistema muestra una lista con todas las ubi-
caciones del usuario.
Postcondición Se mostrarán los datos de las ubicaciones. No se mo-
difica ningún dato en la base de datos.
Excepciones
Comentarios
Tabla 3.18: Requisito Listar ubicaciones por usuario
RADCOV19 Filtrar ubicaciones por usuario
Actor Rastreador.
Descripción Se muestran las ubicaciones y los datos de las ubica-
ciones del usuario seleccionado.
Precondición Debe haber al menos una ubicación registrada en el
sistema.
Secuencia normal
a). Se introduce el id del usuario por el que se quiere
buscar.
b). El sistema muestra una lista con todas las ubi-
caciones del usuario introducido.
Postcondición Se mostrarán los datos de las ubicaciones. No se mo-
difica ningún dato en la base de datos.
Excepciones
Comentarios
Tabla 3.19: Filtrar ubicaciones por usuario22 Capítulo 3. Especificación de requisitos y Casos de uso.
RADCOV20 Filtrar ubicaciones por estado
Actor Rastreador.
Descripción Se muestran las ubicaciones y los datos de las ubica-
ciones de los usuarios con el estado seleccionado.
Precondición Debe haber al menos una ubicación registrada en el
sistema.
Secuencia normal
a). Se selecciona el estado del usuario por el que se
quiere buscar.
b). El sistema muestra una lista con todas las ubi-
caciones de los usuarios con el estado seleccio-
nado.
Postcondición Se mostrarán los datos de las ubicaciones. No se mo-
difica ningún dato en la base de datos.
Excepciones
Comentarios
Tabla 3.20: Filtrar ubicaciones por estado
RADCOV21 Eliminar ubicación
Actor Rastreador.
Descripción Se elimina la ubicación del sistema..
Precondición Debe existir al menos una ubicación registrada en el
sistema.
Secuencia normal
a). Se pide confirmación para eliminar las ubicacio-
nes.
b). Se elimina la ubicación del sistema.
Postcondición Ubicación eliminada del sistema.
Excepciones
Comentarios
Tabla 3.21: Requisito Eliminar ubicación
3.4. Módulo funcional “rastreadores”
En este módulo se ha agrupado toda la funcionalidad referente a la gestión de los
niveles de riesgo de los usuarios y las alertas que se producen en función de los niveles de
riesgo.3.4. Módulo funcional “rastreadores” 23
Figura 3.3: Casos de uso de Gestión de Rastreadores
A continuación se van a describir los casos de uso que forman parte de este módulo
como se muestra en la Figura [3.3]:
RADCOV22 Notificar alerta
Actor Sistema
Descripción Se invoca una alerta y se envía a el/los usuario/s se-
leccionado/s.
Precondición Debe existir al menos un usuario registrado en el sis-
tema.
Secuencia normal
a). Se escogen los usuarios que recibirán la alerta de
la lista de usuarios según su exposición a otra
persona contagiada.
b). El sistema envía la notificación al usuario.
Postcondición Se registra una nueva alerta en el sistema.
Excepciones
Comentarios
Tabla 3.22: Requisito Notificar alerta24 Capítulo 3. Especificación de requisitos y Casos de uso.
RADCOV23 Modificar estado de usuario específico
Actor Usuario
Descripción Modifica el estado del usuario.
Precondición El usuario tiene que estar dado de alta en el sistema.
Secuencia normal
a). El rastreador cambia el estado del usuario, el
estado puede ser: positivo, negativo o alerta/-
riesgo.
b). Confirmación de cambio de estado.
c). Actualización de los datos en el sistema.
d). Mensaje de satisfacción al usuario.
Postcondición Usuario con el estado actualizado en el sistema.
Excepciones
Pto. a: en caso de cancelar, se mantiene el estado
inicial.
Pto. b: en caso de producirse un error al actua-
lizar los datos se notificará error al usuario.
Comentarios Se accede a esta opción a través de una lista de usua-
rios.
Tabla 3.23: Requisito Modificar estado de usuario específico
RADCOV24 Registrar ubicación de usuario específico
Actor Rastreador.
Descripción Registra una nueva ubicación de un usuario según el
el Req. RADCOV14 [3.15]: Registrar ubicación
manual.
Precondición
Secuencia normal
a). Se selecciona un punto en el mapa interactivo.
b). Se indica el usuario relacionado a esa ubicación.
a) Se selecciona un usuario registrado.
b) No se selecciona un usuario registrado.
c) Se selecciona la fecha y hora de la ubica-
ción.
c). Se confirma registro.
Postcondición Se registra la ubicación de un usuario en la base de
datos.
Excepciones Pto. c: Salta una mensaje de error de registro.
Comentarios
Tabla 3.24: Requisito registrar ubicación de usuario usuario específicoCapítulo 4
Planificación
Durante los primeros meses del curso: octubre, noviembre y diciembre; se realizó una
fase de búsqueda e investigación de las herramientas que se utilizarían en el proyecto.
Además, durante ese tiempo, se comenzó a definir las funcionalidades del proyec-
to.
Posteriormente se comenzó a trabajar en el código, para ello se hizo primero la
estructura de la base de datos, y una vez terminada se realizó la estructura del código
tanto del backend en la REST API como en el frontend en Android Studio. Se planteó
el diseño de la aplicación, realizando bocetos de las vistas para luego poder reproducirlas
en la aplicación. Una vez terminado todo el trabajo de planteamiento del proyecto se
repartió el trabajo.
Se comenzó a realizar la parte backend y frontend por separado, probando las funcio-
nalidades a la vez que se iban finalizando. Para probar las partes del backend se utilizaba
Postman y para las del frontend se utilizaban datos locales en el propio Android Stu-
dio.
Una vez probadas por separado ambas partes se realizaba la conexión y se volvía a
probar.
Cada vez que se terminaba alguna funcionalidad se realizaba una reunión para rea-
lizar las pruebas y seguir repartiendo el trabajo.
Por último, una vez terminada la implementación de la aplicación se comenzó con la
redacción de la memoria.
25Capítulo 5
Tecnologías
En este capítulo se van a presentar las tecnológias utilizadas para el desarrollo de
Covrad. Se puede observar un resumen de éstas tecnologías en la Figura [5.1].
5.1. Spring Java Framework
Spring [7] es un framework de código abierto creado para el desarrollo de aplicaciones
muy variadas, pero a día de hoy, su uso se está viendo incrementado en el desarrollo de
aplicaciones web. Spring se divide en diversos módulos, que ofrecen multitud de funcio-
nalidades. Las inyecciones de dependencias a los distintos componentes hacen el código
más ágil y fácil de programar incluyendo también el uso de patrones que se nombran en
el Capítulo 6.
Principalmente se emplea este framework para la parte lógica de Covrad. Se ha
utilizado la funcionalidad Web, que crea los controladores web para las aplicaciones REST,
en este caso es el punto de conexión con las vistas de Android. Otra parte implementada
en Spring es el acceso de datos a través de conectores, para poder validar las interacciones
con la aplicación.
5.2. Retrofit
Retrofit [8] es un cliente de servidores REST para Android y Java. Retrofit produce
llamadas HTTP para obtener resultados estructurados acorde a lo que se solicite. Permite
hacer peticiones al servidor de tipo: GET, POST, PUT, DELETE, entre otras. Éstas
peticiones pueden llevar parámetros que el servidor luego puede interpretar por un tipo
de dato en concreto. A través de este cliente se ha podido interactuar entre la parte del
frontend (Android) y la parte del backend (Spring Java), haciendo el intercambio de datos
muy fácil de configurar.
265.3. Android Studio 27
5.3. Android Studio
Android Studio [9] es una herramienta que permite el desarrollo de aplicaciones An-
droid en diferentes plataformas (tablets, móviles, relojes, televisiones, etc. . . ). El código
elegido para el desarrollo ha sido Java, pero también está disponible Kotlin. Android
Studio incluye un gestor de dispositivos virtuales de Android (AVD), que permiten si-
mular y lanzar la aplicación desarrollada. Éstos dispositivos se pueden configurar con
diferentes versiones de android, RAM y niveles de señal, entre otras características, lo
que resulta muy útil para poder ver el comportamiento de la aplicación en diferentes
escenarios).
Se decide usar esta herramienta dada la gran documentación que hay, y que todos
los ejemplos para la iniciación en Android, usan este programa para sus tutoriales.
5.4. Firebase
Firebase [10] es una plataforma cloud para el desarrollo de aplicaciones web y móviles.
Permite conectarse con dispositivos Android, iOS y web. Firebase presenta una base de
datos en tiempo real. Ofrece muchas funcionalidades como por ejemplo: monitoreo de
compilación, como se utiliza en las autenticaciones de los usuarios que usan la aplicación
o acceso a la base de datos en tiempo real.
La decisión de usar Firebase para el desarrollo se tomó debido a la funcionalidad de
gestión de usuarios que ofrece, haciendo esta parte fácil y segura. La autenticación de
usuarios así como el registro ofrecen esa seguridad y facilidad, tanto para el desarrollador
como para el usuario, ya que con solo indicar su correo electrónico y contraseña, ya se
registra correctamente en el sistema. También la gestión de las notificaciones es decisiva
para usar Firebase para Covrad, punto que se explica a continuación.
5.5. Google API - Firebase Cloud Messaging (FCM)
Para la gestión de notificaciones a los usuarios a su dispositivo móvil, se ha usado
FCM [11]. FCM proporciona una conexión rápida y fiable entre el servidor y los disposi-
tivos móviles de los usuarios. Con esta herramienta se ha conectado este servicio con el
servidor backend (desarrollada en Spring), el cuál es el encargado de mandar las notifi-
caciones en tiempo real a los distintos usuarios que hay conectados en Firebase.
5.6. Google API - Google Maps
Para la interacción del usuario con las localizaciones de la aplicación, se ha usa-
do Google Maps API [12]. Esta API permite tener comunicación de la aplicación con
los servicios de Google Maps. Los usuarios pueden visualizar el mapa, personalizando
e incorporando ubicaciones a la aplicación. Para ello se ha usado SDK de Maps para28 Capítulo 5. Tecnologías
Android. Posteriormente, las localizaciones se guardan en una base de datos diferente a
la Firebase.
5.7. XAMPP y phpMyAdmin
Xampp [13] es un software que integra en una sola aplicación un servidor web Apache
y un servidor de bases de datos MySQL. Haciendo la configuración del servidor backend
muy sencilla. La instalación es intuitiva y permite integrar la misma base de datos en
diferentes entornos.
Xampp incluye phpMyAdmin que es un herramienta que ofrece una interfaz web
para el manejo de bases de datos, muy amigable para el desarrollador.
5.8. MySQL
MySQL [14] es un sistema de administración de base de datos relacional. Todos
los datos de notificaciones, usuarios y demás objetos han sido persistidos en este tipo
de base de datos. Se eligió este tipo de bases de datos, dado el conocimiento de ambas
desarrolladoras a lo largo de otros proyectos. El hecho de ser gratuita y familiar también
fueron detonantes para el uso de esta base de datos.
5.9. Postman
Postman [15] es una herramienta que permite crear peticiones al servidor backend
para poder probar las API’s, así como si los datos que se están manipulando son los
correctos. Postman ofrece además una extensión de Google Chrome fácil de usar y ligera,
sin necesidad de descargar el programa, y gratuito. Se decidió usar esta aplicación para
el testeo de la implementación API REST en la parte de negocio ya que permitía simular
el envío de las peticiones a través de peticiones HTTP.
5.10. Git y Github
Git [16] es una herramienta para el sistema de control de versiones y desarrollo
continuo entre los desarrolladores de un mismo proyecto. La flexibilidad que permite git
es idóneo para el desarrollo de la aplicación. Cada desarrollador puede trabajar de manera
independiente y una vez finalizada la parte de desarrollo integrarlo directamente en la
rama principal, y en caso de tener conflictos resolverlos manteniendo seguro el código
desarrollado.
Github [17] es un servicio para importar y gestionar proyectos utilizando el sistema
de control de versiones de Git mencionado en el párrafo anterior. Desde Github se pueden
rastrear y gestionar todos los cambios que se realizan en el repositorio que contiene el5.10. Git y Github 29
código en tiempo real. La interfaz que ofrece Github hace más fácil la gestión de las
versiones, así como la creación de ramas, y fusiones entre varias ramas.
Figura 5.1: Diagrama de Tecnologías implementadas en CovradCapítulo 6
Arquitectura y modelo de datos
Este capítulo se centra en presentar el enfoque metodológico enseñando la arqui-
tectura y el modelo de datos llevados a cabo para el desarollo de Covrad tal y como se
muestra en el diagrama de la Figura [6.1].
Figura 6.1: Diagramas de componentes
6.1. Arquitectura
En la arquitectura se encuentran los servicios de frontend implementados en Android
Studio y de backend implementados en la API REST. El desarrollo de frontend se enfoca
en la experiencia del usuario con la aplicación, mientras que en el backend se proporciona
acceso a los datos, los servicios y otros sistemas actuales que permiten el funcionamiento
de la aplicación en su conjunto. Se ha utilizado un sistema de capas. El cliente puede
306.2. Patrones de diseño 31
estar conectado mediante la interfaz al servidor, y éste se conectará al servidor para que
le proporcione los datos que se soliciten.
6.1.1. API Rest
Se trata de una arquitectura principalmente para desarrollo web que se usa en clien-
tes HTTP para poder recibir o enviar operaciones sobre datos en diferentes formatos.
Con esta arquitectura se puede dar una mayor escalabilidad a la aplicación, en caso de
querer interactuar con otros componentes a través del protocolo HTTP, que actualmente
son muchos como por ejemplo Twitter, Google o Amazon
Esta arquitectura mostrada en la Figura [6.2] como se puede ver es intuitiva ya que
presenta un conjunto de operaciones simples para poder obtener los recursos necesarios.
El uso de capas o servidores intermedios se usa para aumentar la escalabilidad y/o
para implementar políticas de seguridad de una forma accesible de forma que el usuario
solo tiene que solicitar información y recibir lo que solicita, sin entrar en detalle de cómo
se le proporciona esa información.
Figura 6.2: Esquema básico de arquitectura API Rest
6.2. Patrones de diseño
Los patrones que se han empleado ofrecen una solución general para el diseño de la
aplicación Covrad. A continuación se nombran los patrones principales aplicados.
6.2.1. Modelo-Vista-Controlador
Este patrón se ha utilizado en la API REST para separar y estructurar los datos
de la aplicación, la interfaz y la lógica en componentes diferentes. Esto ha permitido
en el desarollo del proyecto organizados los diferentes componentes, siguiendo un flujo
ordenado y fácil de programar.También puede leer
