1
ÍNDICE
Aplicación
multiplataforma para
el control de aforo
Grado en Ingeniería Informática
Trabajo Fin de Grado
Autor:
Soufyan Rhazili Raoui
Tutor/es:
Estela Saquete Boro
Julio 2021
2
3
Agradecimientos
Por una parte, me gustaría agradecer a mi familia por todo el apoyo y confianza puesta en mí
siempre y en especial a lo largo de la realización de mis estudios, sin ellos nada habría sido
posible.
Por otra parte, me gustaría agradecer a mi tutora en este trabajo, Estela Saquete Boro, por su
apoyo y orientación en la realización de este trabajo, y a todos los profesores/as que han estado
presentes durante mi etapa universitaria, siempre contando con su apoyo.
Y finalmente, también me gustaría agradecer, a todos mis amigos y compañeros de clase que
me han acompañado durante esta etapa, y a todas aquellas terceras personas que han
proporcionado su ayuda y conocimientos y que han sido de gran apoyo durante la realización
del grado.
4
5
Índice
1. Introducción .................................................................................................................. 11
1.1. Resumen. .......................................................................................................................... 11
1.2. Motivación y estudio de mercado. ................................................................................... 11
1.2.1. Afority ........................................................................................................................ 12
1.2.2. Clicker&Go ................................................................................................................. 12
1.2.3. AppforoLimitado ....................................................................................................... 13
1.3. Objetivo. ........................................................................................................................... 13
2. Herramientas, tecnologías y lenguajes de programación empleados ............................... 14
2.1. Herramientas. ................................................................................................................... 14
2.1.1. Visual Studio Code ..................................................................................................... 14
2.1.2. Google Chrome ......................................................................................................... 15
2.1.3. Android Studio .......................................................................................................... 16
2.1.4. XCode ........................................................................................................................ 16
2.2. Otros recursos utilizados. ................................................................................................. 17
2.2.1. Github ........................................................................................................................ 17
2.1.2. Balsamiq Wireframes ................................................................................................ 18
2.1.3. Lucidchart .................................................................................................................. 18
2.3. Tecnologías y lenguajes de programación. ...................................................................... 19
2.3.1. NodeJS ....................................................................................................................... 19
2.3.2. React .......................................................................................................................... 19
2.3.3. Typescript .................................................................................................................. 20
2.3.4. Ionic ........................................................................................................................... 20
2.3.5. Capacitor ................................................................................................................... 21
3. Planificación y gestión del proyecto ................................................................................ 22
3.1. Metodología ..................................................................................................................... 22
3.1.1. Trello.......................................................................................................................... 23
3.2. Estimación temporal ........................................................................................................ 24
3.3. Sistema de control de versiones ...................................................................................... 25
3.4. Integración continua ........................................................................................................ 26
3.4.1. Travis CI ..................................................................................................................... 26
4. Análisis del sistema ........................................................................................................ 28
4.1. Requisitos funcionales ...................................................................................................... 28
4.2. Requisitos no funcionales ................................................................................................ 31
4.3. Casos de uso ..................................................................................................................... 31
6
5. Diseño ........................................................................................................................... 35
5.1. Mockups ........................................................................................................................... 35
5.2. Diseño final ....................................................................................................................... 39
6. Arquitectura .................................................................................................................. 40
6.1. Flux ................................................................................................................................... 40
6.2. DOM Virtual...................................................................................................................... 41
6.3. Diagrama arquitectura de la aplicación ........................................................................... 42
7. Implementación ............................................................................................................. 42
7.1. Front-end .......................................................................................................................... 42
7.1.1. Propiedades y estado de los componentes .............................................................. 44
7.1.2. React Hooks ............................................................................................................... 45
7.1.3. Enrutamiento y navegación entre componentes ...................................................... 46
7.1.4. Comunicación con servidor y consumo de datos ...................................................... 46
7.1.5. Uso de plugins de Capacitor ...................................................................................... 47
7.1.6. Implementación y ejecución de la aplicación en diferentes plataformas................. 48
7.2. Back-end ........................................................................................................................... 49
7.2.1. Firebase. .................................................................................................................... 49
7.2.2. Firebase Authentication ............................................................................................ 49
7.2.3. Firebase Cloud Firestore ........................................................................................... 50
7.2.4. Firebase Cloud Messaging ......................................................................................... 52
7.2.5. Firebase Cloud Storage.............................................................................................. 53
7.2.6. Configuración de Firebase en el proyecto................................................................. 54
8. Seguridad ...................................................................................................................... 54
8.1. Seguridad en el servidor ................................................................................................... 54
8.2. Seguridad en el cliente ..................................................................................................... 55
9. APIS utilizadas ............................................................................................................... 57
9.1. OAuth2 Google ................................................................................................................. 57
9.2. OAuth2 Facebook ............................................................................................................. 57
10. Pruebas ....................................................................................................................... 58
10.1. Pruebas unitarias. ........................................................................................................... 58
10.1.1. Jest ........................................................................................................................... 59
10.2. Pruebas de aceptación ................................................................................................... 60
10.2.1. Selenium IDE ........................................................................................................... 60
11. Ejemplo de funcionamiento .......................................................................................... 61
12. Conclusiones, trabajos futuros y posibles mejoras ........................................................ 70
13. Referencias .................................................................................................................. 71
7
Índice de figuras
Figura 1. Aplicación Afority ......................................................................................................... 12
Figura 2. Panel web de la aplicación Clicker&Go……………………………………………………………………. 13
Figura 3. Aplicación AppforoLimitado ......................................................................................... 13
Figura 4. Proyecto en Visual Studio Code. .................................................................................. 15
Figura 5. Ejecución de la aplicación en simulador en navegador Google Chrome. .................... 15
Figura 6. Ejecución de la aplicación en Android studio. .............................................................. 16
Figura 7. Aplicación en Xcode. .................................................................................................... 17
Figura 8. Repositorio del proyecto en Github. ............................................................................ 17
Figura 9. Captura herramienta Balsamiq Wireframes. ............................................................... 18
Figura 10. Diagrama caso de uso en herramienta Lucidchart. .................................................... 18
Figura 11. Logo nodeJS y npm. .................................................................................................... 19
Figura 12. Logo React .................................................................................................................. 20
Figura 13. Logo Typescript .......................................................................................................... 20
Figura 14. Logo Ionic ................................................................................................................... 21
Figura 15. Integración de Ionic con Capacitor y diversas plataformas ....................................... 22
Figura 16. Diagrama representativo de la metodología SCRUM ................................................ 23
Figura 17. Estado de las tareas del proyecto en mitad de desarrollo de la aplicación. .............. 24
Figura 18. Diagrama de Gantt del proyecto. ............................................................................... 25
Figura 19. Ramas de trabajo de nuestro proyecto. ..................................................................... 25
Figura 20. Ejemplo de una Pull Request. ..................................................................................... 26
Figura 21. Herramienta Travis CI en nuestro proyecto Github. .................................................. 27
Figura 22. Ejecución de un Job en Travis CI. ............................................................................... 28
Figura 23. Diagrama de caso de uso CU-01. ................................................................................ 32
Figura 24. Diagrama de caso de uso CU-02. ................................................................................ 33
Figura 25. Diagrama de caso de uso CU-03. ................................................................................ 34
Figura 26. Diagrama de caso de uso CU-04. ................................................................................ 34
Figura 27. Mockup interfaz inicio de sesión………………………………………………………………………….. 35
Figura 28. Mockups interfaz registro……………………………………………………………………………………. 35
Figura 29. Mockup interfaz home aplicación………………………………………………………………………… 36
Figura 30. Mockup interfaz listado de espacios. ......................................................................... 36
Figura 31. Mockup interfaz descripción de un espacio………………………………………………………….. 36
Figura 32. Mockup listado de usuarios en un espacio…………………………………………………………… 36
Figura 33. Mockup interfaz para modificar el aforo………………………………………………………………. 37
Figura 34. Mockup interfaz para consultar el aforo……………………………………………………………….. 37
Figura 35. Mockup interfaz acceso a un espacio……………………………………………………………………. 37
Figura 36. Mockup interfaz perfil de usuario…………………………………………………………………………. 37
Figura 37. Mockup interfaz consulta espacio actual……………………………………………………………… 38
Figura 38. Mockup interfaz notificaciones……………………………………………………………………………. 38
Figura 39. Mockup interfaz mensajes. ........................................................................................ 38
Figura 40. Interfaz de registro en una PWA ................................................................................ 39
Figura 41. Interfaz de inicio de sesión en Android…………………………………………………………………. 39
Figura 42. Interfaz listado de espacios en iOS………………………………………………………………………… 39
Figura 43. Diagrama arquitectura Flux de React ......................................................................... 40
8
Figura 44. Ejemplo funcionamiento del DOM Virtual ................................................................. 41
Figura 45. Resumen de la arquitectura de nuestra aplicación. ................................................... 42
Figura 46. Capas de una aplicación desarrollada con React, Ionic y Capacitor........................... 43
Figura 47. Estructura de directorios de nuestro proyecto. ......................................................... 44
Figura 48. Ejemplo de props y estado en React. ......................................................................... 45
Figura 49. Ejemplo de hooks de estado en React. ...................................................................... 45
Figura 50. Ejemplo de hook de efecto en React.......................................................................... 46
Figura 51. Enrutado de cada componente en React………………………………………………………………. 46
Figura 52. Enrutado global de la aplicación en React……………………………………………………………. 46
Figura 53. Importación de Firebase en los componentes………………………………………………………. 46
Figura 54. Invocaciones a servicios de Firebase…………………………………………………………………….. 46
Figura 55. Consulta a la base de datos desde el Front-end. ....................................................... 47
Figura 56. Uso de plugin de cámara en la aplicación. ................................................................. 48
Figura 57. Comandos para la ejecución de la aplicación en diferentes plataformas. ................. 49
Figura 58. Logo de Firebase......................................................................................................... 49
Figura 59. Panel web con el listado de usuarios registrados en nuestra aplicación. .................. 50
Figura 60. Panel web con la estructura de nuestra base de datos. ............................................ 51
Figura 61. Estructura colección usuarios..................................................................................... 51
Figura 62. Adicción de un nuevo documento a nuestra base de datos. ..................................... 52
Figura 63. Índices creados en nuestra base de datos. ................................................................ 52
Figura 64. Notificaciones push configuradas para nuestra aplicación. ....................................... 53
Figura 65. Panel web con archivos multimedia en Cloud Storage. ............................................. 53
Figura 66. Configuración de Firebase en nuestro proyecto. ....................................................... 54
Figura 67. Reglas de seguridad en Cloud Firestore. .................................................................... 55
Figura 68. Gráfica con total de autorizaciones, rechazos y errores en nuestra base de datos. . 55
Figura 69. Funciones de cifrado y descifrado con el protocolo AES. .......................................... 56
Figura 70. Proveedores de acceso proporcionados por Firebase. .............................................. 57
Figura 71. Configuración de la aplicación en Facebook for Developers. .................................... 58
Figura 72. Guía para iniciar sesión con Facebook con diversas plataformas en nuestra
aplicación. ................................................................................................................................... 58
Figura 73. Implementación de algunos casos de prueba y ejecución de un caso de prueba
mediante Jest. ............................................................................................................................. 60
Figura 74. Ejecución de un test script con Selenium. .................................................................. 61
Figura 75. Inicio de sesión de la aplicación……………………………………………………………………………. 62
Figura 76. Home (dashboard) de la aplicación. ........................................................................... 62
Figura 77. Menú de la aplicación. ............................................................................................... 62
Figura 78. Lista de espacios controlados por un usuario……………………………………………………….. 63
Figura 79. Descripción y página principal del espacio……………………………………………………………. 63
Figura 80. Interfaz modificar el aforo del interior espacio…………………………………………………….. 64
Figura 81. Interfaz modificar el aforo de la terraza……………………………………………………………….. 64
Figura 82. Consultar aforo actual en interior del espacio……………….......................................... 64
Figura 83. Consultar aforo actual en terraza del espacio………………………………………………………. 64
Figura 84. Detalles del espacio. ................................................................................................... 65
Figura 85. Modal para añadir nuevo espacio………………………………………………………………………… 65
Figura 86. Lista de espacios favoritos……………………………………………………………………………………. 65
Figura 87. Filtrado de usuarios por fecha de acceso……………………………………………………………… 66
Figura 88. Lista de usuarios en un espacio sin filtro………………………………………………………………. 66
Figura 89. Modal con detalles del usuario en el espacio. ........................................................... 66
9
Figura 90. Interfaz para entrada al espacio……………………………………………………………………………. 67
Figura 91. Interfaz para salida del espacio…………………………………………………………………………….. 67
Figura 92. Lista de notificaciones sin filtro…………………………………………………………………………….. 68
Figura 93. Lista de notificaciones con filtro……………………………………………………………………………. 68
Figura 94. Perfil de usuario……………………………………………………………………………………………………. 68
Figura 95. Modal para cambiar datos perfil de usuario. ............................................................. 68
Figura 96. Lista de usuarios que han enviado mensajes………………………………………………………… 69
Figura 97. Detalle del mensaje recibido……………………………………………………………………………….. 69
Figura 98. Envío de un nuevo mensaje a un usuario .................................................................. 69
10
Índice de tablas
Tabla 1. Requisito funcional RF-1 ................................................................................................ 28
Tabla 2. Requisito funcional RF-2 ................................................................................................ 29
Tabla 3. Requisito funcional RF-3 ................................................................................................ 29
Tabla 4. Requisito funcional RF-4 ................................................................................................ 29
Tabla 5. Requisito funcional RF-5 ................................................................................................ 29
Tabla 6. Requisito funcional RF-6 ................................................................................................ 29
Tabla 7. Requisito funcional RF-7 ................................................................................................ 29
Tabla 8. Requisito funcional RF-8 ................................................................................................ 29
Tabla 9. Requisito funcional RF-9 ................................................................................................ 30
Tabla 10. Requisito funcional RF-10 ............................................................................................ 30
Tabla 11. Requisito funcional RF-11 ............................................................................................ 30
Tabla 12. Requisito funcional RF-12 ............................................................................................ 30
Tabla 13. Requisito funcional RF-13 ............................................................................................ 30
Tabla 14. Requisito funcional RF-14 ............................................................................................ 30
Tabla 15. Requisito no funcional RNF-1 ...................................................................................... 31
Tabla 16. Requisito no funcional RNF-2 ...................................................................................... 31
Tabla 17. Requisito no funcional RNF-3 ...................................................................................... 31
Tabla 18. Requisito no funcional RNF-4 ...................................................................................... 31
Tabla 19. Requisito no funcional RNF-5 ...................................................................................... 31
Tabla 20. Requisito no funcional RNF-6 ...................................................................................... 31
Tabla 21. Tabla de Caso de uso CU-01. ....................................................................................... 32
Tabla 22. Tabla de Caso de uso CU-02. ....................................................................................... 32
Tabla 23. Tabla de Caso de uso CU-03. ....................................................................................... 33
Tabla 24. Tabla de Caso de uso CU-04. ....................................................................................... 34
11
1. Introducción
Hoy en día, y más con la situación pandémica que vivimos actualmente (COVID-19), controlar el
aforo en los diferentes espacios o zonas comunes se ha convertido en una tarea indispensable
para poder controlar la propagación del virus, y acreditar la seguridad de los espacios e
instalaciones, y consecuentemente la de las personas, además de cumplir legalmente con los
aforos establecidos por el ministerio de sanidad. Incumplir el aforo en los espacios conlleva una
gran sanción. Con todo ello, han surgido una gran variedad de aplicaciones para facilitar esta
tarea.
1.1. Resumen. Actualmente, muchas empresas y organizaciones públicas están en proceso de adquisición de
herramientas para controlar el aforo en sus establecimientos, de forma que se ha incrementado
la demandada de este tipo de aplicaciones.
La realización de este proyecto busca proporcionar una herramienta que sirva para automatizar
el proceso de control de aforo en diversos espacios, reservas de plazas por parte de los usuarios
en determinados espacios, entrada y salida de los usuarios de una forma organizada y
automática, etc.
A lo largo de este documento se presenta la aplicación realizada, realizando primero un estudio
de mercado de las aplicaciones actuales que pretenden llevar a cabo la función de control de
aforo, y profundizando en las herramientas utilizadas para llevar a cabo la aplicación, además
de los requisitos, la arquitectura, el diseño y la implementación detallada de la aplicación.
Finalmente se mostrará un ejemplo de funcionamiento real de la aplicación y la conclusiones
obtenidas de la realización de este proyecto.
1.2. Motivación y estudio de mercado. El principal motivo para desarrollar esta aplicación surge con la pandemia que estamos viviendo
actualmente (COVID-19), en el que los espacios (aulas, supermercados, bares, restaurantes, etc.)
son restringidos y controlados en cuanto al aforo. El objetivo de los propietarios o encargados
de estos espacios es controlar el aforo para cumplir legalmente con los límites de aforo. Para
llevar a cabo este objetivo, conviene controlar el aforo de una manera ágil y eficiente, y esto lo
podemos conseguir con una aplicación para controlar el aforo en tiempo real, tanto la entrada
como salida de personas en todo momento. Además, con esta situación, nos puede interesar
saber que personas han estado en un determinado espacio a una determinada hora, y esto
también lo podemos conseguir con una aplicación que además de controlar el aforo, controla el
tiempo que ha estado una persona en un determinado espacio, registrando la hora de entrada
y salida del espacio.
La seguridad en lo que se refiere al aforo de cualquier espacio o recinto es un tema importante
para todos: gestores del espacio, visitantes y administración pública. Es importante para todos
ellos estar seguros de que no se producirán posibilidad de contagios por exceso de aforo (debido
a que cuanto mayor sea el aforo mayor será cercanía entre las personas y mayores posibilidades
de contagio), o accidentes causados por un exceso en el límite de aforo de un espacio.
Además, otro de los motivos es la alta demanda que habrá de festivales de música, conferencias,
eventos, etc. que no se han podido celebrar en esta época de pandemia, y que se tiene previsto
celebrar cuando se supere esta pandemia. Esto conlleva el control de aforo de estos espacios, y
contar con una aplicación para agilizar este proceso.
12
Como se ha comentado anteriormente, existen diferentes aplicaciones que controlan el aforo
de diferentes espacios. Vamos a ver algunos ejemplos:
1.2.1. Afority Afority [1] es una aplicación multiplataforma que se encarga de controlar el aforo en tiempo real
y de forma automática de una o diversos espacios o instalaciones. Gestiona las entradas y salidas
de los usuarios en el espacio controlado por medio de tickets por código QR que se sitúan en las
entradas y salidas de dichos espacios y los usuarios escanean con su dispositivo móvil. Además,
dispone de un registro de asistentes por horas que permite el seguimiento de los usuarios que
han estado en un momento determinado en algún espacio concreto.
Figura 1. Aplicación Afority Fuente: https://afority.com/
1.2.2. Clicker&Go Clicker&Go [2] es una aplicación que nos permite controlar el aforo de una manera bastante
intuitiva. Dispone de un sistema de alertas, que consiste en notificaciones que recibe el usuario
que controla el aforo de un espacio o recinto cuando se está alcanzando el máximo aforo
permitido. Esta aplicación es adaptable a cualquier espacio , desde supermercados hasta
restaurantes o playas. Además, dispone de Big Data para el análisis de flujos en los diferentes
espacios, que nos permite conocer datos como tiempo de permanencia, media semanal de
aforo, estadísticas de aforo, etc.
Otra de las ventajas de esta aplicación es que nos permite sincronizar diferentes dispositivos
móviles para realizar el conteo de personas de uno o varios espacios. Los dispositivos se
sincronizan entre sí para mostrar el aforo global de un determinado espacio.
Y destacar también, que se dispone de un panel web para la configuración de los espacios, y los
dispositivos móviles sincronizados, y nos muestra la información generada y recopilada de los
espacios en los que se está realizando un control de aforo.
13
Figura 2. Panel web de la aplicación Clicker&Go. Fuente: https://clickergo.com/es
1.2.3. AppforoLimitado AppforoLimitado [3] es una aplicación que permite controlar los accesos a espacios, conociendo
en todo momento los datos de los usuarios que acceden a dichos espacios. Registra los usuarios
que acceden a los espacios y controla el aforo en tiempo real. Permite seleccionar el acceso, es
decir, el lugar donde va a acceder el usuario. Computa las entradas y salidas, escaneando los
datos de las personas, o simplemente notificando su entrada y/o salida. También, se pueden
consultar todos los datos recogidos a través de cualquier ordenador o dispositivo móvil y filtrar
dichos datos según nuestras necesidades.
Figura 3. Aplicación AppforoLimitado Fuente: https://www.appforolimitado.com/
1.3. Objetivo. Una vez estudiado el mercado, y analizando las fortalezas y debilidades del mismo, el objetivo
de esta aplicación es proporcionar una solución eficaz y eficiente para controlar el aforo de
diversos espacios o instalaciones, desde pequeños espacios como aulas o bares y restaurantes
hasta grandes espacios como centros comerciales o conferencias. Esta aplicación está destinada
principalmente a cualquier persona que quiera controlar uno o más espacios de forma íntegra,
controlando tanto el número de personas que se encuentran de forma simultánea en dicho
espacio en tiempo real, como que personas están actualmente o el intervalo que han estado en
un determinado espacio, entre otras tantas funcionalidades.
Se trata por tanto de una herramienta que garantiza la seguridad de los espacios y ofrece una
gran información en tiempo real de los mismos. Además, esta solución permite controlar de
14
manera automática el nivel de ocupación de un establecimiento para garantizar que no se
supere el límite de ocupación (aforo) fijado.
También se pretende que la aplicación tenga muchas más funcionalidades además de la
funcionalidad básica de control de aforo, como, por ejemplo, organización de los usuarios en los
espacios, accesos automáticos a los espacios mediante códigos QR, interacción de los usuarios
que usan la aplicación mediante mensajería, reservas de plazas en espacios administrados por
usuarios, notificaciones al usuario del estado de los espacios controlados y todos los espacios
disponibles, etc.
Para cumplir este objetivo en un tiempo razonable y contar con una aplicación de gran calidad,
se pretende desarrollar una aplicación híbrida o multiplataforma [4], optando por esta
aproximación en lugar de una aplicación nativa. Las aplicaciones multiplataforma nos permiten
crear una aplicación de forma más rápida en detrimento del rendimiento, que es mucho menor
que en una aplicación nativa, sin ser en este caso un factor determinante a tener en cuenta. Las
aplicaciones multiplataforma son aplicaciones web, elaboradas en su núcleo con lenguajes como
HTML5, CSS o JavaScript, normalmente utilizados bajo alguna librería o framework de desarrollo
para este tipo de aplicaciones. Estas aplicaciones deberán ser procesadas por un empaquetador
para la plataforma específica que se desee, generando una aplicación interpretable por cada
plataforma. Este tipo de aplicaciones tendrá acceso a recursos internos propios del dispositivo,
dependiendo el nivel de acceso a estos recursos por la plataforma de desarrollo utilizada. Pese
a esto, cada vez el acceso a los recursos de los dispositivos es más amplio, por lo que la
experiencia con este tipo de aplicaciones cada vez se acerca más a las aplicaciones nativas.
2. Herramientas, tecnologías y lenguajes de
programación empleados
En este apartado se mostrarán las diferentes herramientas y tecnologías, así como lenguajes de
programación empleados para llevar a cabo la aplicación.
2.1. Herramientas.
2.1.1. Visual Studio Code Visual Studio Code [5] es un editor de código fuente muy potente y ligero desarrollado por
Microsoft, que está disponible para cualquier sistema operativo: Windows, Linux, macOS.
Incluye muchas herramientas como depuración, control de versiones con Git, y diversas
extensiones que podemos instalar fácilmente y nos facilitan nuestro trabajo, como por ejemplo
el debugger para Chrome, GitHub Pull Request, Jest para pruebas unitarias, etc.
Esta herramienta será utilizada para desarrollar la parte del Front-end de nuestra aplicación.
15
Figura 4. Proyecto en Visual Studio Code.
2.1.2. Google Chrome Google Chrome [6] es un navegador web desarrollado por Google, y uno de los navegadores
más usados del mundo, que nos ofrece herramientas para desarrolladores, conocidas también
como DevTools, que son muy útiles para el desarrollo web y nos proporcionan diversas
herramientas como el debug, que nos permite encontrar y arreglar errores en nuestra
aplicación.
También disponemos de la consola de Chrome, que es una herramienta accesible desde este
navegador, muy útil para el desarrollo de aplicaciones web, que nos permite visualizar los
errores que contiene nuestra aplicación, indicando en que fichero y línea se está provocando el
error, en caso de que lo hubiera, visualizando los logs y excepciones del código implementado.
También nos permite inspeccionar los elementos HTML de nuestra página web y examinar los
estilos (CSS) de nuestra aplicación.
Figura 5. Ejecución de la aplicación en simulador en navegador Google Chrome.
16
2.1.3. Android Studio Android Studio [7] es un entorno de desarrollo (IDE) oficial de Google que nos proporciona
herramientas y servicios para desarrollar aplicaciones en el sistema operativo Android. Esta
herramienta es de uso gratuito, y está disponible en cualquier plataforma (Linux, Windows, iOS,
…). Nos permite editar y previsualizar el diseño de las interfaces de nuestra aplicación con
diferentes configuraciones de tamaño, etc.
Otra de las funcionalidades más interesantes de Android Studio es que nos proporciona un
emulador integra que simula dispositivos Android en nuestro ordenador para poder realizar
pruebas y debuggear la aplicación. El emulador nos permite configurar dispositivos móviles,
tablets, etc. Posee casi todas las funciones de un dispositivo Android real, permitiendo simular
llamadas, mensajes, ubicación del dispositivo, etc. También nos permite ejecutar nuestra
aplicación usando la depuración USB, de forma que podemos visualizar nuestra aplicación en
nuestro smartphone Android.
También podemos elegir la versión de Android en la que queremos probar nuestra aplicación.
Figura 6. Ejecución de la aplicación en Android studio.
2.1.4. XCode Xcode [8] es un entorno de desarrollo creado por Apple, con el que se pueden desarrollar,
compilar y ejecutar aplicaciones iOS. Es una herramienta gratuita pero solo está disponible en
sistemas operativos iOS. Dispone de un simulador integrado en el que podemos probar nuestra
aplicación sin disponer de un dispositivo físico, en el que podemos probar las funcionalidades
de nuestra aplicación. Cabe destacar que es un simulador muy rápido en iniciarse y ejecutar la
aplicación, notándose la diferencia con Android Studio, que es un poco más lento.
17
Figura 7. Aplicación en Xcode.
2.2. Otros recursos utilizados.
2.2.1. Github GitHub [9] es una plataforma de desarrollo que permite alojar proyectos siguiendo el control de
versiones de Git. El control de versiones Git, como su propio nombre indica, permite llevar un
control de los cambios producidos en un proyecto, anotar cada cambio, cada funcionalidad,
deshacer uno o más cambio.
Además, otra de las muchas funcionalidades de Git es la posibilidad de trabajar con ramas, lo
cual es muy útil para el trabajo en grupo (cada desarrollador trabaja en su propia rama), aunque
en esta aplicación se ha llevado a cabo individualmente, con lo cual, no ha habido grandes
problemas para mantener una rama totalmente funcional (generalmente la master) al mismo
tiempo que se tiene otra en la que se están desarrollando las nuevas funcionalidades.
Figura 8. Repositorio del proyecto en Github.
18
2.1.2. Balsamiq Wireframes Balsamiq Wireframes [10] es una herramienta que nos permite elaborar bocetos o mockups de
las interfaces de usuario de la aplicación. Es muy fácil de usar y nos proporciona diversos
elementos para elaborar unos mockups de gran calidad.
Figura 9. Captura herramienta Balsamiq Wireframes.
2.1.3. Lucidchart Lucidchart [11] es una herramienta de visualización e infografía de datos basada en la web. Esta
herramienta nos permite crear diagramas de distinta índole como diagramas de flujo, diagramas
de casos de uso, diseños UML, etc.
En el caso de este proyecto, su uso está destinado a la creación de diagramas de casos de uso,
que veremos más adelante.
Figura 10. Diagrama caso de uso en herramienta Lucidchart.
19
2.3. Tecnologías y lenguajes de programación.
2.3.1. NodeJS NodeJS [12] es un entorno de ejecución de Javascript orientado a eventos asíncronos, diseñado
para construir aplicaciones escalables. Utiliza una programación orientada a eventos, la entrada
y salida no es bloqueante, además de ser de código abierto, está disponible para los sistemas
operativos más utilizados: Windows, Linux y Mac OS.
En este proyecto se ha utilizado NodeJS para desplegar la aplicación en nuestro local,
utilizándose la versión 14.16.0.
Figura 11. Logo nodeJS y npm. Fuente: https://nodejs.org/es/
NodeJS hace uso del gestor de paquetes npm, en el cual encontramos un gran ecosistema de
librerías de open source.
Node package manager (npm)
Cuando se instala NodeJS, se instala con muy pocos paquetes. Para la gestión y adicción de
nuevos paquetes, se utiliza la tecnología npm [13], que es el gestor de paquetes de NodeJS.
Además de la instalación de paquetes, npm tiene otras utilidades como puede ser la ejecución
de scripts de inicio en la parte del servidor, como, por ejemplo, npm start, que se encarga de
inicializar la aplicación en nuestro local. Los scripts vienen detallados en el fichero package.json
que todo proyecto posee. Los paquetes que se van instalando se encuentran en la carpeta
node_modules, que puede eliminarse y volver a instalarse con el comando “npm install”.
Existe una tecnología novedosa y similar a npm, que se utilizó al principio del desarrollo de la
aplicación, y se trata de yarn, que es un instalador de paquetes que funciona de forma similar a
npm y es compatible con éste, y destaca por su rapidez en la instalación de paquetes. Al final se
optó por utilizar npm por su versatilidad y gran documentación.
2.3.2. React React [14] es una biblioteca de JavaScript de código abierto creada y mantenida por Facebook,
usada para elaborar componentes interactivos y reutilizables para interfaces de usuario. React
está basado en el paradigma llamado programación orientada a componentes, en el que cada
componente es una pieza con la que el usuario puede interactuar. Estos componentes se crean
usando una sintaxis llamada JSX (para Javascript), o TSX (para Typescript) en nuestro caso,
permitiendo escribir HTML y CSS dentro de objetos Javascript o Typescript. Estos componentes
son reutilizables y se combinan para crear componentes mayores hasta configurar una web o
aplicación completa.
React aporta una serie de claras ventajas, como son sus facilidades para el desarrollo unido al
rendimiento, la flexibilidad y organización del código, que convierten a esta librería en una de
las librerías/frameworks más usados actualmente para el desarrollo web, junto con Angular y
VueJS.
20
React tiene un algoritmo muy eficiente para determinar las diferencias entre la representación
virtual de la página actual y la nueva. A partir de esas diferencias, hace el conjunto mínimo de
cambios necesarios en el DOM. Utiliza un concepto denominado DOM virtual, que veremos más
adelante en detalle.
Figura 12. Logo React. Fuente: https://es.reactjs.org/
2.3.3. Typescript Typescript [15] es un lenguaje de programación desarrollado y mantenido por Microsoft, de
código abierto, siendo un superconjunto de Javascript, es decir, amplía Javascript con una nueva
sintaxis que añade, entre otras cosas, el tipado estático opcional, genéricos y elementos de POO
(Programación orientada a objetos) como interfaces. El poder agregar tipado nos permite tener
un mayor control de la asignación de valores y prevenir algunos errores durante el proceso de
compilación.
Typescript compila código Javascript que se ejecuta en cualquier navegador, sistema operativo
o motor de Javascript. Además, una de las razones por las cuales surgió Typescript es que trata
de resolver la mayoría de los problemas de Javascript centrándose en mejorar la experiencia y
productividad de los desarrolladores, permitiendo utilizar técnicas comentadas anteriormente
como el tipado estático y encapsulación para generar un código mucho más limpio, mantenible
y escalable que con Javascript, sin perder el carácter dinámico del mismo.
Actualmente la popularidad de Typescript se ha disparado y se perfila como uno de los lenguajes
más usados y con mayor futuro.
Figura 13. Logo Typescript. Fuente: https://www.typescriptlang.org/
2.3.4. Ionic Ionic [16] es un framework gratuito y de código abierto optimizado para el desarrollo de
aplicaciones móviles multiplataforma. Una gran ventaja para nosotros es que este framework
se basa en AngularJS, HTML y CSS, por lo que resulta ideal para nuestra aplicación, ya que
nosotros utilizaremos React (Typescript), HTML y CSS. Por tanto, con Ionic ya tenemos todo lo
necesario para la elaboración de nuestra aplicación móvil, y que esta tenga un aspecto elegante
junto con una arquitectura interna robusta.
Ionic está inspirado en los principales SDK de desarrollo de las plataformas móviles más
populares, como pueden ser iOS y Android. Además, trabaja sobre la herramienta Apache
Cordova y Capacitor (siendo el creador de éste), por lo que también puede hacer uso de los
21
innumerables plugins existentes para interaccionar con los distintos aspectos internos de los
dispositivos, como puede ser la cámara, GPS, almacenamiento interno, etc.
Lo realmente interesante, junto con todo lo anterior, es que nos proporciona una biblioteca de
componentes muy amplia para la elaboración de nuestra interfaz de usuario, y también tenemos
acceso a una documentación muy extensa al respecto. Con estos componentes que nos
proporciona Ionic es muy difícil distinguir una de estas aplicaciones híbridas con una aplicación
nativa. La forma de trabajar con Ionic es realmente cómoda e intuitiva, ya que desde una
terminal podemos crear proyectos vacíos o con estructuras predeterminadas, añadirle plugins,
compilar los proyectos, ejecutarlos en simuladores o en nuestro propio dispositivo si este está
conectado con USB a nuestro ordenador (siempre que lo configuremos en modo desarrollador).
Además, a partir de la creación de un proyecto en una carpeta determinada, ya nos estructurará
las distintas carpetas de una forma organizada.
En definitiva, este framework nos permite desarrollar aplicaciones híbridas con una arquitectura
robusta, y, en consecuencia, con un muy buen rendimiento y con una apariencia elegante y de
aplicación nativa.
Figura 14. Logo Ionic. Fuente: https://ionicframework.com/
2.3.5. Capacitor Capacitor [17] es un framework creado y mantenido por Ionic, que ejecuta aplicaciones web de
forma nativa en iOS y Android y como una PWA (Progressive Web Apps). Nos proporciona un
conjunto de APIs enfocados en la web que permite que una aplicación se mantenga lo más
cercana posible a los estándares web, al tiempo que se accede a funciones de dispositivos
nativos en plataformas como iOS y Android.
Capacitor es similar a la herramienta Apache Cordova. Al igual que ésta, es capaz de convertir
una aplicación web en una aplicación nativa y acceder a características propias del dispositivo.
Si Apache Cordova hace esto mediante plugins, en Capacitor son denominados APIs. Por otro
lado, cabe destacar que mientras Apache Cordova tiene que esperar a que el dispositivo esté
listo antes de realizar llamadas a la funcionalidad nativa seleccionada, Capacitor exportará
código Javascript en el arranque de la aplicación para que esto no sea necesario. Además,
Capacitor se instala de forma local en los proyectos, lo que facilita el mantenimiento de
diferentes versiones en múltiples proyectos. Su velocidad de funcionamiento es algo superior al
de Apache Cordova. Por último, cabe destacar que en caso de que una API de Capacitor no cubra
el uso de una característica del dispositivo que estemos utilizando, es capaz de implementar una
gran cantidad de plugins del propio Apache Cordova sin comprometer el funcionamiento de la
aplicación, salvo unos pocos plugins de Apache Cordova que son incompatibles con Capacitor, y
que veremos más adelante.
En definitiva, el único inconveniente de Capacitor frente a Cordova es que será necesario
emplear alguno de los plugins de Apache Cordova dentro del propio Capacitor para acceder a
alguna de las características del dispositivo no cubiertas por alguna API de Capacitor. Por lo
demás, Capacitor ha sido desarrollado por el propio Ionic, lo cual siempre es positivo cuando se
trabaja en un proyecto Ionic. Además, cabe destacar que el rendimiento y la fluidez de las
aplicaciones en Capacitor son superiores a Apache Cordova. En la Figura 15 podemos ver un
22
ejemplo de cómo se integran las tecnologías Ionic y Capacitor para llegar a construir aplicaciones
multiplataforma.
Figura 15. Integración de Ionic con Capacitor y diversas plataformas. Fuente: https://capacitorjs.com/
3. Planificación y gestión del proyecto
La correcta planificación de un proyecto es fundamental para su éxito. Es por ello por lo que la
metodología de trabajo es algo prioritario en el desarrollo de un proyecto.
A largo de este apartado, vamos a detallar la metodología utilizada en nuestro proyecto, así
como la estimación temporal y algunos aspectos relacionados con la planificación.
3.1. Metodología Se ha seguido una metodología ágil para el desarrollo del proyecto. Las metodologías ágiles
desarrollan software de manera iterativa e incremental. La metodología seguida en este
proyecto sigue una aproximación basada en Scrum.
Scrum [18] es un proceso en el cual se aplican una serie de buenas prácticas para el trabajo
colaborativo, para obtener el mejor resultado posible de un proyecto y dotar al proyecto en
desarrollo de un mayor valor de negocio.
23
Figura 16. Diagrama representativo de la metodología SCRUM. Fuente: https://proyectosagiles.org/que-es-scrum/
Cada iteración (sprint) ha tenido una duración aproximada de 4 semanas. Cada iteración nos ha
proporcionado un incremento o avance en las características de la aplicación.
Al principio de cada sprint, se añaden a dicho sprint las tareas priorizadas por el valor que aporta
a la aplicación y la prioridad que tiene. Se desarrollan en cada sprint una serie de tareas y sus
respectivas pruebas automáticas. Al final de cada sprint, se hace una reunión con la tutora de
este proyecto, para mostrar las tareas llevadas a cabo y que tareas no se han podido terminar,
para pasarlas al siguiente sprint. También se discute al final de cada sprint las siguientes tareas
que irán al siguiente sprint.
La gran mayoría de los requisitos se definieron al principio del desarrollo en reuniones,
posteriormente durante el desarrollo y las verificaciones se han ido adaptando y añadiendo
requisitos para lograr el objetivo deseado. A lo largo de las iteraciones realizadas el proyecto ha
avanzado de forma correcta y mejorado con cada una de ellas.
3.1.1. Trello Para la gestión y seguimiento de las tareas del proyecto se ha utilizado la herramienta Trello.
Trello [19] es una herramienta para la gestión de proyectos colaborativos. Se basa en el
paradigma Kanban [20], y está diseñada para gestionar todo el proceso de desarrollo de un
proyecto, facilitando el trabajo y la colaboración de miembros de un equipo, aunque en este
proyecto se ha llevado a cabo por una sola persona. Permite crear tareas mediante tarjetas, y
asignar a dichas tarjetas, la estimación temporal de ellas, el autor de la tarea, las fecha de inicio
y fin de la tarea, la prioridad, una descripción, etc. Podemos ver en la Figura 17 un ejemplo del
reparto de tareas en tres estados diferentes: To Do (tareas por hacer), In Progress (tareas en
progreso) y Done (tareas completadas).
24
Figura 17. Estado de las tareas del proyecto en mitad de desarrollo de la aplicación.
3.2. Estimación temporal Una vez definidas las tareas que conformarán nuestro proyecto, realizaremos la planificación
temporal, estimando la duración de las tareas y la realización de cada etapa del proyecto o
aplicación.
Para mostrar la planificación temporal se realizará un diagrama de Gantt distribuido en
iteraciones de 4 semanas. Como podemos observar en la Figura 18, las actividades que más
estimación y más tiempo han llevado a cabo han sido las relacionadas con el desarrollo de la
aplicación, ya que ha sido la parte gruesa del desarrollo de este proyecto. Cabe destacar que en
algunas iteraciones no se ha dispuesto del tiempo en un principio planificado para dicha
iteración, por ello se han pasado algunas actividades de iteraciones anteriores a sucesivas
iteraciones, pero siempre intentando adecuarse al tiempo del que se disponía por iteración.
25
Figura 18. Diagrama de Gantt del proyecto.
3.3. Sistema de control de versiones Disponemos de un repositorio privado en Github, donde se aloja nuestro proyecto.
Al ser un proyecto realizado individualmente, se ha trabajado solo con dos ramas: la rama
master, que contendrá las releases [21] y es la rama principal y donde se encuentra la última
versión desplegada de la aplicación , y la rama development, en la cual se ha trabajado
habitualmente durante la realización de cada sprint y de nuevas funcionalidades en la aplicación
y/o corrección de bugs que hayan aparecido durante el desarrollo de la aplicación.
Figura 19. Ramas de trabajo de nuestro proyecto.
Cada vez que se cubría una nueva funcionalidad definida en los requisitos de la aplicación, se
subían los cambios al repositorio mediante una PR (Pull Request) [22], como podemos ver en la
26
Figura 20. Si todos los test pasaban correctamente, se fusionaba la rama development a la rama
master, para tener los últimos cambios en la aplicación en la rama principal (rama master).
Figura 20. Ejemplo de una Pull Request.
3.4. Integración continua Para asegurarnos de que las implementaciones continuas de nuevas funcionalidades en la
aplicación se integran y funcionan correctamente con las ya existentes, se ha utilizado un
sistema de integración continua, en este caso, Travis CI.
3.4.1. Travis CI Travis CI [23] es un sistema de integración continua que funciona junto con Github. Podemos
crear y lanzar Jobs que son iniciados cuando se hace un push del trabajo realizado localmente
en nuestro repositorio remoto en Github donde se hospeda nuestro proyecto, o también son
lanzados cuando fusionamos una rama, por ejemplo, fusionamos todo el contenido de la rama
development a la rama master.
Primero nos creamos una cuenta en Travis CI, y seguimos los respectivos pasos [24] para hacer
uso de esta tecnología en nuestro proyecto. También podemos configurar Travis CI desde
nuestro repositorio en Github, en el apartado “Settings/Integrations”, como podemos observar
en la Figura 21.
27
Figura 21. Herramienta Travis CI en nuestro proyecto Github.
La configuración de Travis CI se realiza de una manera sencilla, a través de un archivo con
extensión .yaml, llamado .travis.yml, que crearemos en la raíz de nuestro proyecto. Cuando se
realiza un nuevo push o alguna otra acción en nuestro repositorio de Github, el sistema Travis
CI consulta el archivo .travis.yml de nuestro proyecto, y empieza a ejecutar en orden los pasos
que se detallan en dicho archivo, como, por ejemplo, ejecutar el comando “npm install”, “npm
test”, … Además, en este archivo indicamos la versión de NodeJS con la que hemos trabajado en
nuestro proyecto, en este caso la versión 14.16.0.
Podemos visualizar si nuestra acción se ha llevado a cabo (se ha integrado bien los nuevos
cambios en nuestro proyecto) y han pasado todos los test.
Las ejecuciones en Travis CI se basan en los Jobs. Un Job es un proceso automatizado que clona
nuestro repositorio en un entorno virtual y realiza una serie de fases como compilar el código,
ejecutar los test, etc. Estos Jobs se ejecutan cuando se detecta un nuevo cambio en nuestro
repositorio, como la subida de nuevos archivos o modificación de archivos ya existentes en
nuestro repositorio remoto en Github. En caso de que haya un fallo en dichos Jobs, se marcará
la acción en rojo como fallida, y esto puede deberse a que fallen los test o que haya algún error
de compilación, entre otros errores. Cuando los Jobs están en ejecución, se mostrará en color
amarillo, y podremos ver en el Job log los comandos y archivos que están en ejecución (Figura
22).
28
Figura 22. Ejecución de un Job en Travis CI.
4. Análisis del sistema
Vamos a detallar los principales requisitos de nuestra aplicación. Estos requisitos se dividen en
dos tipos: requisitos funcionales, que son los requisitos que definen la funcionalidad de nuestra
aplicación (comportamientos de nuestra aplicación), y los requisitos no funcionales, que son los
correspondientes a aquellos requisitos que nos indican características generales o restricciones
del sistema, entre ellos, la fiabilidad, seguridad o escalabilidad de nuestra aplicación. Además,
también veremos los casos de uso de nuestra aplicación.
4.1. Requisitos funcionales Vamos a dividir los requisitos funcionales según el rol: usuario no registrado y usuario registrado.
En la tabla de requisitos funcionales del usuario registrado, dispondremos además de una fila
denominada “Actor”, tomando los posibles valores: administrador y/o usuario.
Usuario no registrado:
RF-1
Nombre Registrarse
Prioridad Alta
Descripción La aplicación permite el registro de un usuario no registrado.
Tabla 1. Requisito funcional RF-1
Usuario registrado:
RF-2
Nombre Iniciar sesión
Actor Administrador y usuario
Prioridad Alta
29
Descripción La aplicación permite iniciar sesión al usuario mediante diversas formas: con email y contraseña, y Google y Facebook.
Tabla 2. Requisito funcional RF-2
RF-3
Nombre Cerrar sesión
Actor Administrador y usuario
Prioridad Alta
Descripción La aplicación permite cerrar sesión al usuario autenticado.
Tabla 3. Requisito funcional RF-3
RF-4
Nombre Restablecer contraseña
Prioridad Alta
Descripción La aplicación permite al usuario restablecer su contraseña.
Tabla 4. Requisito funcional RF-4
RF-5
Nombre Crear espacio
Actor Administrador
Prioridad Alta
Descripción La aplicación permite al usuario crear, visualizar, modificar y eliminar espacios.
Tabla 5. Requisito funcional RF-5
RF-6
Nombre Eliminar espacio
Actor Administrador
Prioridad Alta
Descripción La aplicación permite al usuario crear, visualizar, modificar y eliminar espacios.
Tabla 6. Requisito funcional RF-6
RF-7
Nombre Añadir/Listar espacios favoritos
Actor Administrador y usuario
Prioridad Alta
Descripción La aplicación permite al usuario añadir y listar sus espacios favoritos.
Tabla 7. Requisito funcional RF-7
RF-8
Nombre Consultar aforo actual espacio
Actor Administrador y usuario
Prioridad Alta
Descripción La aplicación muestra al usuario el aforo actual de un determinado espacio.
Tabla 8. Requisito funcional RF-8
30
RF-9
Nombre Modificar aforo actual espacio
Actor Administrador
Prioridad Alta
Descripción La aplicación permite al usuario modificar el
aforo de un determinado espacio.
Tabla 9. Requisito funcional RF-9
RF-10
Nombre Listar usuarios en espacio
Actor Administrador
Prioridad Alta
Descripción La aplicación permite al usuario listar los
usuarios que hay actualmente en un espacio
concreto o filtrar por fechas de entrada y
salida de los usuarios.
Tabla 10. Requisito funcional RF-10
RF-11
Nombre Acceso espacio
Actor Administrador y usuario
Prioridad Alta
Descripción La aplicación permite al usuario entrar y/o
salir de un espacio concreto.
Tabla 11. Requisito funcional RF-11
RF-12
Nombre Ver/Modificar perfil
Actor Administrador y usuario
Prioridad Alta
Descripción La aplicación permite al usuario ver y modificar su perfil.
Tabla 12. Requisito funcional RF-12
RF-13
Nombre Ver/Recibir notificaciones
Actor Administrador y usuario
Prioridad Alta
Descripción La aplicación permite al usuario ver y recibir notificaciones.
Tabla 13. Requisito funcional RF-13
RF-14
Nombre Ver/Enviar mensajes
Actor Administrador y usuario
Prioridad Alta
Descripción La aplicación permite al usuario ver mensajes recibidos y enviar nuevos mensajes a otros usuarios.
Tabla 14. Requisito funcional RF-14
31
4.2. Requisitos no funcionales
RNF-1
Nombre Comunicación segura entre Front-end y Back-end
Prioridad Alta
Descripción Debe existir una encriptación de la comunicación entre el cliente (Front-end) y el servidor (Back-end).
Tabla 15. Requisito no funcional RNF-1
RNF-2
Nombre Concurrencia
Prioridad Alta
Descripción La aplicación debe permitir al menos 100 usuarios concurrentes.
Tabla 16. Requisito no funcional RNF-2
RNF-3
Nombre Acceso por roles
Prioridad Alta
Descripción La aplicación distinguirá entre varios roles, donde cada rol accede a los recursos autorizados para dicho rol.
Tabla 17. Requisito no funcional RNF-3
RNF-4
Nombre Compatibilidad con navegadores y plataformas
Prioridad Alta
Descripción La aplicación será compatible con todos los navegadores (Google Chrome, Firefox, Safari, …) y en varias plataformas (iOS y Android).
Tabla 18. Requisito no funcional RNF-4
RNF-5
Nombre Disponibilidad de la aplicación
Prioridad Alta
Descripción La aplicación debe estar disponible al menos el 95% de tiempo.
Tabla 19. Requisito no funcional RNF-5
RNF-6
Nombre Velocidad transacciones y peticiones
Prioridad Alta
Descripción Las transacciones y peticiones del sistema al servidor no deben superar los 5 segundos.
Tabla 20. Requisito no funcional RNF-6
4.3. Casos de uso Un caso de uso es una descripción de las acciones que puede realizar el usuario con el sistema.
Se representan gráficamente mediante un Diagrama de Casos de Uso. Esta especificación de
32
casos de uso facilita la comprensión del sistema y expresa la intención con la que el usuario
interactuará con la aplicación, profundizando así en dichas necesidades, y que,
complementándose con los requisitos funcionales anteriormente descritos, establece una firme
base a la hora de comenzar con la fase de diseño de la aplicación.
A continuación, se detallarán los casos de uso, describiendo todas las posibles interacciones del
entre el usuario y la aplicación.
Identificador caso de uso CU-01
Resumen Inicio de sesión de los usuarios, cierre de sesión, y restablecimiento de contraseña.
Actor Administrador y usuario
Precondiciones El usuario debe estar registrado.
Postcondiciones Ninguna. Tabla 21. Tabla de Caso de uso CU-01.
Figura 23. Diagrama de caso de uso CU-01.
Identificador caso de uso CU-02
Resumen Interacciones de los usuarios (Administrador y usuario) con los espacios.
Actor Administrador y usuario
Precondiciones Los usuarios deben estar registrados en la aplicación. Para la creación, modificación (modificar aforo y detalles del espacio) y eliminación de espacios, el usuario debe tener rol de administrador. Para listar los usuarios que se encuentran en un determinado espacio, el usuario debe tener rol de administrador.
Postcondiciones Ninguna. Tabla 22. Tabla de Caso de uso CU-02.
33
Figura 24. Diagrama de caso de uso CU-02.
Identificador caso de uso CU-03
Resumen Mensajería de la aplicación.
Actor Administrador y usuario
Precondiciones El usuario debe estar registrado.
Postcondiciones Ninguna. Tabla 23. Tabla de Caso de uso CU-03.
34
Figura 25. Diagrama de caso de uso CU-03.
Identificador caso de uso CU-03
Resumen Los usuarios pueden ver notificaciones de los espacios, filtrar y borrar notificaciones.
Actor Administrador y usuario
Precondiciones El usuario debe estar registrado.
Postcondiciones Ninguna. Tabla 24. Tabla de Caso de uso CU-04.
Figura 26. Diagrama de caso de uso CU-04.
35
5. Diseño
En cuanto al diseño de las interfaces de usuario que componen la aplicación, se ha utilizado la
herramienta Balsamiq Wireframe.
En un principio se diseñaron los bocetos o mockups de la aplicación, y en base a dichos mockups,
se fue elaborando la interfaz de la aplicación.
5.1. Mockups La primera vista que visualizará el usuario será la vista de inicio de sesión (Figura 27). También
habrá una interfaz para el registro de un usuario no registrado (Figura 28). Una vez iniciada
sesión, se redirigirá al usuario a su página principal o dashboard (Figura 29), que contendrá
tarjetas, en las cuales pulsando sobre cada tarjeta se redirigirá al usuario a una nueva interfaz
que veremos a continuación.
Figura 27. Mockup interfaz inicio de sesión. Figura 28. Mockups interfaz registro.
.
36
Figura 29. Mockup interfaz home aplicación. Figura 30. Mockup interfaz listado de espacios.
Existirá una interfaz que contendrá el listado de los espacios controlados por un usuario (Figura
30). También se dispondrá de una interfaz que muestra una descripción del espacio junto con
unos botones para modificar y consultar el aforo actual, además de mostrar más detalles sobre
el espacio en cuestión (Figura 31). Además, se dispondrá de otra interfaz en la que el usuario
que administra determinados espacios podrá consultar que usuarios están actualmente en el
espacio o filtrar por fechas de entrada y salida del espacio por los usuarios (Figura 32).
Figura 31. Mockup interfaz descripción de un espacio. Figura 32. Mockup listado de usuarios en un espacio.
37
La aplicación dispondrá de una interfaz para que el usuario pueda consultar (Figura 33) y/o
modificar (Figura 34) el aforo de un espacio concreto.
Figura 33. Mockup interfaz para modificar el aforo. Figura 34. Mockup interfaz para consultar el aforo.
Además, la aplicación dispondrá de una interfaz para que el usuario pueda acceder a un
determinado espacio o salir del espacio actual (Figura 35). Asimismo, el usuario podrá consultar
en que espacio se encuentra actualmente (Figura 36).
Figura 35. Mockup interfaz acceso a un espacio. Figura 36. Mockup interfaz perfil de usuario.
38
El usuario podrá consultar y modificar su perfil (Figura 37). Además, se dispondrá de una interfaz
para mostrar las notificaciones enviadas al usuarios (Figura 38).
Figura 37. Mockup interfaz consulta espacio actual. Figura 38. Mockup interfaz notificaciones.
Finalmente, se dispondrá de una interfaz en la cual el usuario podrá ver mensajes recibidos por
el usuario y enviar mensajes a otros usuarios (Figura 39).
Figura 39. Mockup interfaz mensajes.
39
5.2. Diseño final A continuación, vamos a visualizar el diseño final de un par de interfaces de nuestra aplicación.
En el apartado 11 de este documento (Ejemplo de funcionamiento) podremos ver todas las
interfaces desarrolladas en la aplicación y su respectiva funcionalidad.
Procedemos a mostrar algunas interfaces con los tres tipos de diseño que puede adoptar nuestra
aplicación: diseño como PWA o aplicación web (Figura 40), diseño en Android (Figura 41), y
diseño en iOS (Figura 42).
Figura 40. Interfaz de registro en una PWA.
Figura 41. Interfaz de inicio de sesión en Android. Figura 42. Interfaz listado de espacios en iOS.
40
6. Arquitectura
Es importante destacar que en cualquier proyecto software o desarrollo de una aplicación, como
es nuestro caso, escoger el tipo de arquitectura de nuestra aplicación es una de las partes más
importantes y fundamentales para realizar una aplicación potente, y fácilmente mantenible y
escalable en un futuro. Es por ello por lo que antes del diseño de la aplicación, se ha investigado
sobre las diferentes arquitecturas que ofrecían los diferentes frameworks (Angular o VueJS) o
librerías disponibles (React), para escoger alguno y ver cual se adaptaba mejor a la aplicación
que se quería elaborar.
Como se ha detallado en puntos anteriores en este documento, se ha escogido la librería React
para desarrollar la aplicación, en concreto la parte del Front-end. La parte del Back-end se ha
implementado con la tecnología Firebase, como veremos más adelante.
6.1. Flux A diferencia de otras librerías o frameworks, como Angular, que utilizan una arquitectura basada
en el Modelo Vista-Controlador (MVC), React maneja una arquitectura llamada Flux [25], que es
similar a MVC, y que vamos a ver a continuación en detalle.
Flux es la arquitectura Front-end que se utiliza para crear aplicaciones web. Complementa los
componentes de vista componible de React utilizando un flujo de datos unidireccional, es decir,
los datos se propagan descendentemente de componentes padres a componentes hijos, en este
orden estrictamente.
Los datos van desde la vista por medio de acciones y llegan a un Store desde el cual se actualizará
la vista de nuevo. El Store sería equivalente al modelo de la aplicación, el cual guarda los datos
y estado de la aplicación en cada momento.
Figura 43. Diagrama arquitectura Flux de React. Fuente: https://es.survivejs.com/react/implementing-kanban/react-and-flux/
Action: Son objetos simples con una propiedad de tipo y algunos datos. Son métodos expuestos
por el Dispatcher, para desencadenar un envío al Store.
Dispatcher: Actúa como un eje central. El Dispatcher procesa acciones (por ejemplo,
interacciones del usuario) e invoca devoluciones de llamada que las tiendas han registrado con
él. Es un objeto que transmite un tipo de acción al Store para actualizar el estado de la aplicación.
Despacha un tipo de acción y puede llevar una carga útil en caso de que se pase un nuevo
conjunto de datos al Store para actualizar el estado de la aplicación.
41
Store: Contienen el estado y la lógica de la aplicación. Es el responsable de la gestión del estado
de la aplicación, en otras palabras, es un objeto que gestiona todo el estado de la aplicación a
través de métodos. Envía los datos para actualizar la vista en función del envío recibido por parte
del Dispatcher.
View: Es el componente que representa la interfaz de usuario y determina como interactúa el
usuario con la aplicación. Las interfaces de usuario escuchan los eventos del usuario y se vuelven
a procesar y renderizar cuando cambia el estado de la aplicación.
6.2. DOM Virtual React tiene una gran ventaja en cuanto al rendimiento de la aplicación a diferencia de otros
frameworks o librerías, ya que implementa el DOM Virtual [26].
El DOM virtual (VDOM) es un concepto de programación donde una representación ideal o
“virtual” de la UI (interfaz gráfica) se mantiene en memoria y en sincronía con el DOM “real”,
mediante una biblioteca como ReactDOM. Es una representación del DOM que permite
comparar el DOM activo con el nuevo DOM resultante. De esta comparación surgen el menor
número de instrucciones para transformar un DOM en otro, lo cual lo hace tener un mejor
rendimiento.
Cuando se actualiza una vista, lo que cambia en React es el DOM Virtual, que es mucho más
rápido que actualizar el DOM del navegador. Cuando React compara el DOM Virtual con el DOM
del navegador actualiza sólo las partes que son necesarias y no la vista completa. Este
comportamiento es clave en React y causante de su alto rendimiento, ya que cuando cambia un
dato en la aplicación no se necesita actualizar la vista entera.
Este enfoque hace posible la API declarativa de React: le decimos a React en qué estado
queremos que esté la UI, y se hará cargo de llevar el DOM a ese estado. Esto abstrae la
manipulación de atributos, manejo de eventos y actualización manual del DOM que de otra
manera tendríamos que usar para construir nuestra aplicación. Podemos ver un ejemplo de ello
en la Figura 44.
Figura 44. Ejemplo funcionamiento del DOM Virtual. Fuente: https://es.reactjs.org/docs/faq-internals.html#:~:text=El%20DOM%20virtual%20(VDOM)%20es,proceso%20se%20conoce%20como%20reconciliaci%C3%B3n
42
6.3. Diagrama arquitectura de la aplicación La arquitectura que sigue nuestra aplicación es la típica arquitectura cliente – servidor, donde
existen dos partes bien diferenciadas, por un lado, la parte del cliente (Front-end), que es la
parte con la que el usuario interacciona con la aplicación, la cual como veremos en el siguiente
punto de implementación hemos desarrollado con React, Ionic y Capacitor. Por otro lado,
tenemos la parte del servidor (Back-end), desarrollada con Firebase, como persistencia de los
datos de nuestra aplicación y que nos ofrece multitud de servicios, como autenticación de
usuarios, almacenamiento de archivos multimedia, notificaciones push, etc. La interacción entre
el Front-end y Back-end se realiza de forma segura, con todas las comunicaciones encriptadas,
haciendo uso del protocolo TLS, que veremos más adelante.
Podemos observar en la siguiente Figura 45 en un diagrama de forma muy resumida la
arquitectura de nuestra aplicación.
Figura 45. Resumen de la arquitectura de nuestra aplicación.
7. Implementación
Nuestra aplicación se divide en dos bloques bien diferenciados: el Front-end, que viene siendo
la parte del cliente, y el Back-end, que se trata de la parte del servidor.
La mayoría del desarrollo de la aplicación ha sido enfocada en la parte del Front-end, ya que
como veremos a continuación, la parte del Back-end, se ha implementado en su totalidad con
la tecnología Firebase, que ya nos proporciona casi todo lo necesario para el desarrollo de
nuestra aplicación, y solo tenemos que ser las guías oficiales y ajustar las funcionalidades
proporcionadas a nuestras necesidades.
7.1. Front-end La parte del Front-end se ha desarrollado con las siguientes tecnologías web: HTML, CSS y
Typescript, con React, haciendo también uso de las tecnologías Ionic y Capacitor. Como
podemos observar en la Figura 46, cada herramienta o tecnología se relaciona con la otra para
implementar la aplicación, desde las capas superiores que son las herramientas o tecnologías
relacionadas con el desarrollo de las interfaces del usuario hasta las capas inferiores que se
43
encargan de empaquetar y transformar el código de la aplicación en código interpretable para
las diversas plataformas, iOS (Swift) y Android (Java), todo ello a través de Capacitor.
Figura 46. Capas de una aplicación desarrollada con React, Ionic y Capacitor. Fuente: https://ionicframework.com/blog/announcing-capacitor-1-0/
Nota: Durante el desarrollo de la aplicación se ha trabajado con los sistemas operativos
Windows, y de una forma más activa con Linux, en concreto la versión Ubuntu 20.04, con lo cual,
los comandos mostrados en este punto se ejecutan en este sistema operativo.
Primero, instalamos la versión de NodeJS con la cual vamos a trabajar, que ha sido la versión
14.16.0, y el gestor de paquetes de node, npm:
$ sudo apt install nodejs
$ sudo apt install npm
$ sudo nvm install 14.16.0
$ sudo nvm use 14.16.0
Como primer paso, instalamos el cliente de Ionic con el siguiente comando:
$ npm i -g @ionic/cli
Seguidamente, creamos nuestro proyecto en Ionic con el siguiente comando:
$ ionic start app –type=react
Podemos ejecutar nuestra aplicación con uno de los siguientes comandos, siendo en este casi
que el primer comando ejecuta la aplicación en localhost:8081 y el segundo en localhost:3000:
$ ionic serve
$ npm start
Con nuestro proyecto Ionic en marcha, ya se puede desarrollar las nuevas funcionalidades de la
aplicación.
44
Por defecto, Ionic ya nos crea una estructura predefinida, con algunos archivos de configuración
y algunos componentes de prueba. A partir de esto, ya podemos incluir nuestros propios
componentes y archivos de configuración, archivos de estilos, etc.
Figura 47. Estructura de directorios de nuestro proyecto.
7.1.1. Propiedades y estado de los componentes Los componentes web son elementos que representan la interfaz de usuario. Son
independientes y pueden ser reutilizados, además, describen cómo tienen que visualizarse y
cómo tienen que comportarse una determinada interfaz de usuario.
Para que los componentes puedan usar toda la información necesaria se hace uso de las props
y del state.
Las props son las propiedades que se le pasan desde un componente padre a un componente
hijo. Estas propiedades solo pueden ser modificadas por el componente padre, con lo cual son
de sólo lectura para los componentes hijo. Estas propiedades son atributos HTML y se configuran
al momento de instanciar un componente.
El state o estado, es el conjunto de valores internos de las propiedades de un componente. El
estado es modificado por los métodos del mismo componente. Cuando se inicializa un
componente, se inicializan los estados de este componente, mediante el constructor del
componente.
Las props son externas al componente, se configuran y modifican desde el componente padre,
y nunca desde el mismo componente. El state es interno del componente, se configura en el
constructor de éste y se modifica en el mismo componente (Figura 48). En el instante en el que
cambian las propiedades o el estado, React vuelve a renderizar los componentes con los nuevos
valores.
45
Figura 48. Ejemplo de props y estado en React.
7.1.2. React Hooks Los Hooks [27] son una novedosa API de React que nos permiten usar y “enganchar” el estado
de React y el ciclo de vida desde componentes de función, sin ser necesario el uso de clases.
En esta aplicación se han hecho uso fundamentalmente de los dos principales Hooks de React:
Hook de estado, useState [28], y Hook de efecto, useEffect [29].
Hacemos uso del hook de estado, useState, para agregarle un estado local al componente de
función. Gracias a este hook se mantiene el estado entre re-renderizados de la página. El hook
useState nos devuelve un par de valores, el valor del estado actual y una función que nos permite
actualizarlo (Figura 49).
Figura 49. Ejemplo de hooks de estado en React.
Hacemos uso del hook de efecto, useEffect, ya que agrega la capacidad de realizar efectos
secundarios desde un componente de función. Los efectos se declaran dentro del componente
para que tengan acceso a sus props y estado. De forma predeterminada, React ejecuta los
efectos después de cada renderizado. Dentro de este hook de efecto, hacemos una petición al
servidor, y éste nos devuelve los datos actualizados (Figura 50).
46
Figura 50. Ejemplo de hook de efecto en React.
7.1.3. Enrutamiento y navegación entre componentes En nuestra aplicación hemos utilizado un enrutamiento dinámico, haciendo uso de react-router.
Este tipo de enrutamiento hace uso de componentes para definir las rutas. Los componentes
que se encargan de mostrar las diferentes rutas siempre se renderizan.
Para definir las diferentes rutas de nuestra aplicación, podemos usar el componente Route. La
función de este componente es elegir que renderizar según la locación actual. Al componente
Route le pasamos un componente y una ruta (Figura 51). Definimos las rutas de nuestra
aplicación en el fichero principal del proyecto: App.tsx (Figura 52).
Figura 51. Enrutado de cada componente en React. Figura 52. Enrutado global de la aplicación en React.
7.1.4. Comunicación con servidor y consumo de datos Para poder utilizar las funciones que nos proporciona firebase, necesitamos importar firebase
en nuestros componentes (Figura 53), y declarar como constantes las variables que representan
llamadas a los servicios de Firebase, como por ejemplo el usuario actual que esta logeado, o la
base de datos donde tenemos todos nuestros datos (Figura 54).
Figura 53. Importación de Firebase en los componentes. Figura 54. Invocaciones a servicios de Firebase.
47
El Front consume los datos necesarios del servidor (Firebase) mediante peticiones a éste. Se
hacen peticiones directamente de Firestore (Figura 55), con lo cual no necesitamos ninguna API
que haga de intermediario para acceder a el contenido de la base de datos. El servicio Cloud
Firestore nos devuelve la información solicitada en formato JSON
Figura 55. Consulta a la base de datos desde el Front-end.
7.1.5. Uso de plugins de Capacitor Los plugins en Capacitor permiten interactuar a la aplicación desarrollada con React e Ionic
directamente con las API nativas, como son la cámara, la geolocalización, el almacenamiento
interno en el dispositivo, etc.
Capacitor dispone de sus propios plugins [30]. Además, también hace uso de algunos plugins de
Cordova que son compatibles, aunque hay varios plugins que no son compatibles con Capacitor
[31] y veremos uno de ellos en este apartado.
Hemos hecho uso del plugin de la cámara (Figura 56), para que un usuario pueda hacer una foto
y guardarla como foto de perfil.
48
Figura 56. Uso de plugin de cámara en la aplicación.
También cabe destacar que se ha intentado hacer uso del plugin cordova-plugin-qrscanner de
Cordova para el escaneo de códigos QR, ya que por el momento Capacitor no dispone de uno
propio, pero éste plugin de Cordova es incompatible con Capacitor, con lo cual no se ha podido
llevar a cabo la funcionalidad completa de escaneo de códigos QR. Como veremos en el punto
11 de este documento (Ejemplo de funcionamiento), cuando un usuario accede a un espacio,
dicho acceso (tanto entrada como salida del espacio) se produce mediante el escaneo de un
código QR del que dispone cada espacio. Se buscaron soluciones para paliar el problema de
incompatibilidad de plugins, buscando soluciones “no oficiales” para usar un plugin que permita
escanear el código QR, pero todas no funcionaron satisfactoriamente. En las siguientes releases
de la aplicación, se buscará solucionar este problema (de prioridad alta) creando una API con un
sistema de gestión de códigos QR propio o buscando otra alternativa funcional.
7.1.6. Implementación y ejecución de la aplicación en diferentes plataformas Nuestra aplicación se ha desarrollado como una aplicación multiplataforma, es decir, que la aplicación pueda desplegarse y ejecutarse en diferentes plataformas implementado solo un código, esto es, un código manejable por estas tres plataformas: iOS, Android y PWA (Progressive Web Application). Esto es posible gracias a Capacitor, ejecutando unos comandos específicos que podemos ver en la siguiente Figura 57.
49
Figura 57. Comandos para la ejecución de la aplicación en diferentes plataformas.
7.2. Back-end La parte del Back-end de la aplicación se ha desarrollado por completo con la tecnología
Firebase.
7.2.1. Firebase. Firebase [32] es una plataforma creada por Google para el desarrollo de aplicaciones web y
móvil de elevada calidad de una forma rápida. Nos proporciona muchas herramientas gratuitas,
con el plan Spark, que es la cuota más básica, y nos proporciona límites de lectura y escritura de
datos, y límite de almacenamiento de datos, aunque cabe destacar que, para llevar a cabo esta
aplicación, ha sido suficiente con este plan, ya que se trata de una aplicación pequeña.
Esta plataforma nos proporciona varias herramientas muy interesantes y de gran utilidad, que
nos permiten un desarrollo ágil de nuestras aplicaciones sin preocuparnos mucho por la
implementación del servidor.
A continuación, vamos a detallar la configuración de Firebase en nuestro proyecto y los servicios
que nos proporciona Firebase de los que se han hecho uso en dicho proyecto.
Figura 58. Logo de Firebase. Fuente: https://firebase.google.com/
7.2.2. Firebase Authentication Es un servicio que nos permite autenticar a los usuarios que van a utilizar nuestra aplicación.
Incluye diversos tipos de autenticación, de las cuales hemos hecho uso de la autenticación básica
mediante correo y contraseña, y autenticación mediante proveedores como Google, Facebook,
Twitter, etc.
En la consola de Firebase podemos controlar todos los usuarios que han creado una cuenta en
nuestra aplicación con su identificador, además de la fecha de creación de dicha cuenta y la
última fecha de acceso del usuario a la aplicación (Figura 59).
50
Figura 59. Panel web con el listado de usuarios registrados en nuestra aplicación.
7.2.3. Firebase Cloud Firestore Es una base de datos flexible y escalable para el desarrollo en servidores, dispositivos móviles y
la Web desde Firebase. Está basado en una base de datos NoSQL (base de datos no relacional).
Se organiza en forma de documentos agrupados en colecciones, identificados por un ID único,
y en dichos documentos se pueden incluir cualquier campo con alguno de los siguientes tipos
permitidos: cadena de texto (string), número (number), marca de tiempo (timestamp), objeto
(map), booleano (boolean), entre otros.
Cloud Firestore mantiene los datos sincronizados de la aplicación través de objetos de escucha
en tiempo real y ofrece soporte sin conexión para dispositivos móviles y la Web, por lo que es
posible compilar aplicaciones con capacidad de respuesta que funcionan sin importar la latencia
de la red ni la conectividad a Internet.
Diseño de la base de datos
Para el diseño de la base de datos se ha utilizado el servicio Cloud Firestore. Se trata de una base
de datos NoSQL (no relacional) orientada a colecciones y documentos. A diferencia de una base
de datos SQL, en las bases de datos NoSQL no existen tablas ni filas, en su lugar se almacenan
todos los datos (campos) en los documentos, que se organizan en colecciones. En la Figura 60,
podemos observar las colecciones en la parte izquierda de la imagen, todos los documentos que
pertenecen a una determinada colección en la parte central de la imagen, y en la parte derecha
tendríamos los campos que conforman primer documento identificado con un ID único que lo
identifica inequívocamente de los demás documentos. Podemos crear tantas colecciones como
documentos y campos queramos en nuestra base de datos, donde cada documento puede tener
diferentes campos a otro documento de la misma colección. En nuestro caso, se ha seguido un
patrón en todos los documentos, para que éstos tengan los mismos campos.
51
Figura 60. Panel web con la estructura de nuestra base de datos.
En nuestro caso, tenemos cuatro colecciones: usuarios, espacios, mensajes y notificaciones. Para
guardar la información de los usuarios, tendríamos la siguiente estructura:
Figura 61. Estructura colección usuarios.
Asimismo, cabe destacar que, en los documentos relacionados con la información de los
usuarios, no guardamos sus contraseñas, ya que éstas se guardan con el servicio Firebase
Authentication, para una mayor seguridad de estos datos.
Para añadir, ver, actualizar y borrar campos de la base de datos (operaciones CRUD), se ha hecho
uso de las funciones que nos proporciona este servicio. Podemos ver un ejemplo de ello en la
siguiente Figura 62.
52
Figura 62. Adicción de un nuevo documento a nuestra base de datos.
Creación de índices
Además, para garantizar un alto rendimiento de las consultas a la base de datos, podemos usar
índices. Los índices son un factor importante del rendimiento de la base de datos. Si no hacemos
uso de los índices, las consultas provocan que las bases de datos rastreen el contenido elemento
por elemento, lo cual resulta muy ineficiente, y empeora a medida que aumenta el tamaño de
la base de datos.
Cloud Firestore por defecto, nos crea automáticamente un índice para cada campo creado en
un documento. Estos índices de campo único hacen que las consultas en Firebase se resuelvan
casi instantáneamente.
Además, tenemos la opción de crear índices compuestos para las consultas más básicas y
frecuentes, como por ejemplo en la Figura 63 podemos ver un ejemplo, donde tenemos índices
para el aforo actual de un espacio (índice por nombre del espacio y aforo actual), o el usuario
que se encuentra en un determinado espacio (índice por nombre del usuario y espacio).
Figura 63. Índices creados en nuestra base de datos.
7.2.4. Firebase Cloud Messaging Con este servicio podemos enviar notificaciones push [33] a nuestra aplicación. Podemos
programarlas para que se envíen cada día o por franjas horarias, por ejemplo, para avisar al
53
usuario la posibilidad de consultar los espacios disponibles que hay actualmente y reservar
alguna plaza en el espacio contactando con el administrador de dicho espacio, o avisar al usuario
de nuevas actualizaciones en la aplicación, etc. Podemos ver un ejemplo de notificaciones
programadas y enviadas a usuarios en la siguiente Figura 64.
Figura 64. Notificaciones push configuradas para nuestra aplicación.
7.2.5. Firebase Cloud Storage Cloud Storage se creó para los desarrolladores de aplicaciones que necesitan almacenar y
entregar contenido multimedia generado por usuarios, como fotos o videos.
Con este servicio podemos almacenar nuestros archivos multimedia de los que haremos uso en
la aplicación, de una forma segura (Figura 65). En iteraciones avanzadas en el desarrollo de la
aplicación, se dejó de usar este servicio, ya que se optó por almacenar los contenidos
multimedia, las imágenes principalmente, en la base de datos Cloud Firestore, en formato URL,
como un campo más dentro de los respectivos colecciones y documentos, con el fin de seguir
un patrón en las peticiones a la base de datos y que en el Front se pueda recibir toda la
información conjunta en una petición, en formato JSON, como se ha comentado anteriormente.
Figura 65. Panel web con archivos multimedia en Cloud Storage.
54
7.2.6. Configuración de Firebase en el proyecto Para inicializar y poder hacer uso de Firebase en nuestra aplicación, debemos crear un archivo
de configuración en nuestro proyecto con la configuración del proyecto de Firebase (Figura 66).
Figura 66. Configuración de Firebase en nuestro proyecto.
8. Seguridad
Las comunicaciones de nuestra aplicación con el servidor se producen de manera segura, todas
ellas protegidas y encriptadas con el protocolo TLS [34], con lo cual ya existe una capa de
seguridad en nuestra aplicación que viene por defecto con Firebase.
8.1. Seguridad en el servidor Disponemos de las reglas de seguridad de Firebase, que son una característica muy potente que
ofrece el servicio de base de datos en tiempo real de Firebase. Con ellas podemos definir
criterios específicos para otorgar o denegar permisos para realizar diferentes acciones sobre la
base de datos de nuestro proyecto. Las reglas de seguridad proporcionan control de acceso y
validación de datos en un formato simple, pero claro y eficaz.
Como observamos en la Figura 67, podemos introducir la fecha límite para hacer peticiones a la
base de datos. Como estamos en un entorno de desarrollo y prueba de la aplicación, y no se
trata de una aplicación muy grande, se ha decidido dejar a los usuarios consultar y enviar
peticiones a la base de datos como fecha límite hasta el 20/09/2021. Dichas reglas se pueden
modificar en cualquier momento del desarrollo de la aplicación.
55
Figura 67. Reglas de seguridad en Cloud Firestore.
Con Firebase Authentication y las reglas de seguridad de Cloud Firestore podremos manejar la
autenticación, autorización y validación de los datos.
Además, podemos visualizar mediante una gráfica el total de autorizaciones, rechazos y errores
de peticiones sobre nuestra base de datos, filtrando por la fecha por la cual queremos ver dichas
peticiones, por ejemplo, en los últimos 30 días, como se muestra en la Figura 68.
Figura 68. Gráfica con total de autorizaciones, rechazos y errores en nuestra base de datos.
8.2. Seguridad en el cliente Los usuarios que hacen uso de la aplicación guardan datos sensibles en su dispositivo en
memoria, como pueden ser el usuario y contraseña o mensajes enviados y recibidos. Es por ello
por lo cual es necesario dotar de alguna capa de seguridad a la aplicación para proteger estos
datos. En este caso, se ha escogido una de las formas más básicas y eficaces para proteger los
datos, y es haciendo uso de la encriptación.
Para la encriptación de estos datos, se ha hecho uso del algoritmo de cifrado AES [35] el cual es
uno de los métodos de cifrado más seguros y robustos utilizado en todo el mundo. Se ha
utilizado AES de 256 bits (AES256), con el modo CBC (cipher-block chaining).
56
Su instalación es muy sencilla, mediante npm, con el siguiente comando:
$ npm install aes256
Hemos creado una clase en el src de nuestro proyecto, la cual exportamos para que se haga uso
de las funciones encrypt, para el cifrado de los datos, y descrypt, para el descifrado de los datos.
Figura 69. Funciones de cifrado y descifrado con el protocolo AES.
57
9. APIS utilizadas
9.1. OAuth2 Google Las API de Google utiliza el protocolo OAuth 2.0 para la autenticación y autorización. OAuth 2.0
es la forma para lograr la autenticación de servicios de terceros. Proporciona un valor único,
denominado token de autenticación, que representa tanto la identidad del usuario como la
autorización de la aplicación para actuar en nombre de este.
Para autenticarnos con Google en nuestra aplicación, Firebase nos permite hacer uso de la API
de Oauth2 Google, con la que podemos iniciar sesión con nuestra cuenta de Google. Para ello,
habilitamos el proveedor Google desde nuestra consola en Firebase (Figura 70). Tras esto,
podremos acceder con nuestra cuenta de Google en nuestra aplicación.
Figura 70. Proveedores de acceso proporcionados por Firebase.
9.2. OAuth2 Facebook Podemos autenticarnos en nuestra aplicación mediante redes sociales, como por ejemplo con
nuestra cuenta de Facebook.
Para ello, Firebase nos proporciona la posibilidad de autenticarnos con el proveedor de acceso
de Facebook, habilitándolo desde los ajustes de autenticación, similar al anterior apartado con
el proveedor de acceso Google (Figura 71).
Es necesario tener una cuenta en Facebook y crearnos una cuenta para desarrolladores, con el
fin de obtener el identificador de nuestra aplicación y la clave secreta de dicha aplicación (Figura
65) para poder habilitar el proveedor de acceso Facebook en Firebase.
58
Figura 71. Configuración de la aplicación en Facebook for Developers.
También disponemos de una guía para autenticarnos en nuestra aplicación utilizando Facebook
con diversas plataformas, entre ellas iOS, Android y Web (Figura 72).
Figura 72. Guía para iniciar sesión con Facebook con diversas plataformas en nuestra aplicación.
10. Pruebas
Las pruebas en una aplicación son fundamentales para comprobar que todos los requisitos de
la aplicación se cumplen y se ha implementado dicha aplicación correctamente.
Este proceso de probar la aplicación consiste en escribir una serie de pruebas o test que ejecuten
nuestro código con unos datos de entrada con el fin de comprobar que nuestro código devuelve
el resultado esperado. Existen diversos tipos de pruebas, tales como pruebas unitarias, pruebas
de integración, pruebas de sistema, pruebas de aceptación, etc.
10.1. Pruebas unitarias. Las pruebas unitarias consisten en aislar pequeños fragmentos o componentes de código
desarrollados y comprobar que funcionan a la perfección de forma independiente a otros
componentes, con unos datos de entrada y resultado concretos.
59
En este proyecto se han implementado pruebas unitarias fundamentalmente, para validar los
componentes desarrollados, mediante la librería Jest.
10.1.1. Jest Jest [36] es una librería o marco de pruebas desarrollada por Facebook y usado por esta
compañía probar todas sus aplicaciones de React. Su uso está destinado principalmente para
pruebas unitarias en Javascript, integrándose también muy bien con Typescript.
Esta librería es bastante simple de instalar, mediante npm, y requiere una configuración mínima
para su uso y esto facilita su integración con otros tecnologías, como Travis CI.
Además, Jest destaca por su rapidez, pudiendo ahorrar tiempo en las ejecuciones de las pruebas
comparado con otros frameworks o librerías de pruebas. Esta rapidez en la ejecución de los test
se debe al uso de paralelización, y a la ejecución de las pruebas en un orden: primero las pruebas
más lentas, aprovechando el uso de todos los núcleos (CPU), y luego las pruebas más rápidas y
ligeras.
Para crear una test suite (conjunto de casos de prueba), que contendrá uno o varios casos de
prueba, crearemos una test suite con la palabra reservada describe, la cual se le pasa una
descripción y una función que contiene uno o más casos de prueba para cada componente o
funcionalidad que queramos testear. Para cada caso de prueba se identificará con la palabra
reservada “it”, la cual se le pasa una descripción del caso de prueba, y una función que ejecutará
ese caso de prueba concreto (Figura 73).
Para poder ejecutar los test creados en nuestro proyecto, primero debemos añadir en el
package.json de nuestro proyecto, en el apartado de scripts, la siguiente línea: “test”: “jest”. A
partir de ahora, cuando ejecutemos el comando “npm test”, se ejecutarán los test con la
herramienta Jest.
Para la ejecución de todos nuestros test existentes en nuestro proyecto utilizaremos el
comando:
$ npm test
Para la ejecución de un test en concreto utilizaremos el comando:
$ npm test -- -t “Nombre del caso de prueba o test suite”
60
Figura 73. Implementación de algunos casos de prueba y ejecución de un caso de prueba mediante Jest.
10.2. Pruebas de aceptación Las pruebas de aceptación hacen referencia a las pruebas del software o aplicación por parte
del usuario final para determinar si se cumplen los requisitos acordados inicialmente. Estas
pruebas se han llevado a cabo en nuestra aplicación mediante la herramienta Selenium IDE.
10.2.1. Selenium IDE Selenium IDE [37] es una extensión que se encuentra en navegadores como Firefox o Google
Chrome, entre otros, que podemos activar para elaborar y ejecutar tests rápidamente con las
interacciones del usuario y ejecutarlos directamente en el navegador. Permite crear scripts de
pruebas utilizando la aplicación web tal y como un usuario haría normalmente: a través del
navegador. Además, una de las grandes ventajas de Selenium IDE es que no hace falta tener
grandes conocimientos de programación para crear tests en Selenium.
61
Para nuestro caso, se han creado varios tests de Selenium para comprobar que nuestra
aplicación hace lo que se espera que debe hacer. En este caso los tests están relacionados con
las funcionalidades de la aplicación, como por ejemplo un test para comprobar el inicio y cierre
de sesión, test para la creación de un nuevo espacio, test para la eliminación de un espacio, test
para añadir un espacio a favoritos, etc.
Nuestro proyecto Selenium está formado por un conjunto de Test Cases (casos de prueba).
Podemos ejecutar los test individualmente, y observar cómo se ejecutan los comandos paso a
paso de nuestro script que contiene los comandos Selenese y al final de la ejecución Selenium
nos informará si el test ha pasado satisfactoriamente (Figura 74) o ha habido algún error en los
resultados esperados.
Figura 74. Ejecución de un test script con Selenium.
11. Ejemplo de funcionamiento
En este aparatado se realizará un ejemplo resumido del funcionamiento de la aplicación desarrollada. En el siguiente enlace, se dispone de un ejemplo más profundo e interactivo sobre la funcionalidad de la aplicación: https://www.youtube.com/watch?v=JDWigO2u2Lk.
A continuación, vamos a llevar a cabo un ejemplo del funcionamiento normal de la aplicación por un usuario registrado, en este caso, con rol de administrador, ya que cuenta con todos los permisos para ejecutar todas las funcionalidades implementadas en la aplicación.
Como primer paso, el usuario iniciará sesión con su correo y contraseña (Figura 75), y accederá a la página principal o dashboard (Figura 76), donde podrá ver varias tarjetas y podrá interaccionar con ellas. El usuario también podrá interaccionar con un menú interactivo situado a la izquierda de la interfaz, donde podrá acceder a algunas de las funcionalidades más usadas en la aplicación (Figura 77).
62
Figura 75. Inicio de sesión de la aplicación Figura 76. Home (dashboard) de la aplicación.
Figura 77. Menú de la aplicación.
63
A continuación, el usuario procederá clicar sobre la tarjeta “Mis espacios actuales”, donde se le
redirigirá a una interfaz donde podrá consultar un listado de todos los espacios de los que es
propietario y que está controlando en el momento actual, como se puede observar en la Figura
78. Además, podrá ver el número de espacios controlados, y podrá buscar un espacio en
concreto filtrando por el nombre del espacio. Al clicar sobre la tarjeta de un determinado
espacio de la lista, aparecerá un modal con una información más detallada sobre el espacio en
cuestión (Figura 79).
Figura 78. Lista de espacios controlados por un usuario Figura 79. Descripción y página principal del espacio.
El usuario podrá modificar el aforo actual haciendo clic en el botón “Modificar Aforo”, donde se
abrirá un modal con la funcionalidad para añadir y/o restar personas al espacio. En este caso, al
tratarse de un espacio de tipo Restaurante/Bar, el usuario dispondrá de dos pestañas, una de
ellas para controlar el aforo en el interior (Figura 80) y otra para la terraza (Figura 81).
64
Figura 80. Interfaz modificar el aforo del interior espacio. Figura 81. Interfaz modificar el aforo de la terraza.
También podemos consultar el aforo en tiempo real del espacio, clicando sobre el botón
“Consultar aforo” de la tarjeta del espacio (Figura 79). También podemos ver una gráfica del
aforo actual del espacio en cuestión (Figura 82 y Figura 83).
Figura 82. Consultar aforo actual en interior del espacio. Figura 83. Consultar aforo actual en terraza del espacio.
65
El usuario también podrá consultar los detalles del espacio que está controlando de una forma
resumida (Figura 84). Además, el usuario tiene la capacidad de crear todos los espacios que
desee. Para ello, en la figura 86 podemos ver que hay un botón para añadir un nuevo espacio
“Añadir nuevo espacio”. Pulsando esté botón, aparecerá un modal, donde el usuario podrá
introducir los datos que conciernen al nuevo espacio que va a crear (Figura 85). También, el
usuario podrá añadir determinados espacios a su lista de espacios favoritos, disponiendo de la
opción de eliminar estos espacios de su lista cuando desee, mediante el botón rojo en la tarjeta
del espacio, como podemos observar en la Figura 86.
Figura 84. Detalles del espacio.
Figura 85. Modal para añadir nuevo espacio. Figura 86. Lista de espacios favoritos.
66
Otra de las funcionalidades más interesantes de las que dispone el usuario es la de filtrar las
personas actuales que hay en un determinado espacio controlado, pudiendo filtrar por una
franja horaria (Figura 87) o sin ningún tipo de filtro (Figura 88). Además, el usuario podrá
contactar con las personas que hay en su espacio, pulsando sobre la opción “Contactar”, donde
se redirigirá al usuario al apartado de mensajes, en el cual podrá mandar un nuevo mensaje a
dicha persona. También dispone de la opción “Mas información”, en la cual pulsando sobre ella
se abre un modal con información más detallada sobre la persona en cuestión, como podemos
observar en la Figura 89.
Figura 87. Filtrado de usuarios por fecha de acceso Figura 88. Lista de usuarios en un espacio sin filtro.
Figura 89. Modal con detalles del usuario en el espacio.
67
Además el usuario podrá acceder a un espacio concreto, escaneando el código QR de dicho
espacio (Figura 87). También podrá salir de un determiando espacio con la misma funcionalidad
(Figura 88). Como se ha comentado en puntos anteriores, el código QR no se podrá escanear en
esta última release de la aplicación, ya que resulta incompatible el plugin QR de Cordova con
Capacitor. Por ello, se simula la entrada con el botón de “Entrar” y “Salir”, para entrar y salir del
espacio respectivamente.
Figura 90. Interfaz para entrada al espacio Figura 91. Interfaz para salida del espacio.
Por otra parte, el usuario dispondrá de un apartado de notificaciones, donde podrá consultar los últimos movimientos o acciones llevadas a cabo en los espacios, como por ejemplo, sobrepasar el aforo actual de un determiando espacio, la creación y eliminación de un nuevo espacio, añadir un nuevo espacio a la lista de favoritos, … Para cada acción de las detalladas anteriormente, el usuario recibirá una notificación, con la fecha de cuando se produjo la acción, y además pudiendo filtar por tipos de notificación. El usuario podrá eliminar la notificación individualmente, con el icono “x” en la parte superior de la notifiación, o eliminar todas las notificaciones con el botón “Eliminar todas las notificaciones” (Figura 92). También podemos filtrar por el tipo de notificaciones (Figura 93).
68
Figura 92. Lista de notificaciones sin filtro. Figura 93. Lista de notificaciones con filtro.
El usuario dispondrá de un apartado de Perfil de usuario, donde podrá ver (Figura 94) y/o
modificar (Figura 95) sus datos personales.
Figura 94. Perfil de usuario. Figura 95. Modal para cambiar datos perfil de usuario.
69
El usuario dispondrá de un apartado de mensajes, donde podrá visualizar los mensajes recibidos, y enviar nuevos mensajes a diferentes usuarios registrados en la aplicación (Figura 96). En primera instancia, aparecerá un listado de todos los usuarios que han contactado con él (Figura 97), y al clicar sobre el botón ubicado a la derecha del nombre del usuario, se abrirá un modal con los mensajes recibidos de ese usuario (Figura 98).
Figura 96. Lista de usuarios que han enviado mensajes. Figura 97. Detalle del mensaje recibido.
Figura 98. Envío de un nuevo mensaje a un usuario
70
12. Conclusiones, trabajos futuros y posibles mejoras
Como conclusión, quiero destacar que este trabajo me ha ayudado a adquirir nuevos
conocimientos sobre diferentes enfoques de programación, como es la programación reactiva,
además de ver nuevas tecnologías que me han apasionado y quiero seguir trabajando con ellas
en futuros proyectos. También, la realización de esta aplicación me ha ayudado a coger
confianza y verme capaz de desarrollar una aplicación desde cero por mí mismo, con ayuda de
mi tutora y otros terceros, siguiendo unos patrones y una metodología. Además, me ha ayudado
a adquirir nuevas competencias, como adaptar mejor la información encontrada en bibliografías
a mis necesidades.
Debido al poco tiempo del que se disponía y al ser una única persona que ha llevado el desarrollo y despliegue de la aplicación, no se ha tenido el tiempo suficiente deseado para desarrollar todas las funcionalidades que en un principio se tenía previsto implementar, pero la mayoría de ellas si se han podido llevar a cabo. Aunque no se hayan podido desarrollar estas funcionalidades, se desarrollaran en futuras versiones de la aplicación, para dotar a la aplicación de un gran valor y mejorar dicha aplicación de cara a la competencia.
Las siguientes funcionalidades no llevadas a cabo en este trabajo, y que serán desarrolladas en un futuro para mejorar la aplicación son las siguientes:
▪ Refinar el acceso automático de usuarios al espacio. ▪ Elaborar estadísticas de aforo en cada espacio o en determinadas franjas de tiempo. ▪ Añadir inteligencia artificial a la aplicación, para nuevas algoritmos de control de
usuarios y espacios. ▪ Internacionalización de la aplicación, para que pueda ser usada en varios idiomas, y
pueda ser exportada la aplicación a otros países. ▪ Integrar la aplicación con tecnologías hardware como sensores para controlar el aforo.
El desarrollo de este trabajo ha sido una gran experiencia que me ha servido para mejorar mis capacidades de síntesis, desarrollo y documentación, además de profundizar en enfoques de programación no vistos anteriormente, adquiriendo una perspectiva diferente en el desarrollo de aplicaciones.
71
13. Referencias
[1] Afority: https://afority.com/
[2] Clicker&Go: https://clickergo.com/es
[3] AppforoLimitado: https://www.appforolimitado.com/
[4] Apps multiplataforma vs nativas: https://tir-tech.com/app-nativa-vs-multiplataforma/
[5] Visual Studio Code: https://code.visualstudio.com/
[6] Google Chrome: https://www.google.com/intl/es_es/chrome/
[7] Android Studio: https://developer.android.com/studio
[8] Xcode: https://developer.apple.com/xcode/
[9] Github: https://github.com/
[10] Balsamiq: https://balsamiq.com/
[11] Lucidchart: https://www.lucidchart.com/pages/es
[12] NodeJS: https://nodejs.org/es/
[13] Npm: https://www.npmjs.com/
[14] React: https://es.reactjs.org/
[15] Typescript: https://www.typescriptlang.org/
[16] Ionic: https://ionicframework.com/
[17] Capacitor: https://capacitorjs.com/
[18] Definición de Scrum: https://proyectosagiles.org/que-es-scrum/
[19] Trello: https://trello.com/es
[20] Definición de Kanban: https://kanbanize.com/es/recursos-de-kanban/primeros-pasos/que-es-kanban
[21] Definición de releases: https://sites.google.com/site/practicadesarrollosoft/temario/scm/releases
[22] Definición Pull Request: https://aprendegit.com/que-es-un-pull-request/
[23] Travis CI: https://travis-ci.com/
[24] Configuración Travis CI: https://docs.travis-ci.com/
[25] Arquitectura Flux: https://es.survivejs.com/react/implementing-kanban/react-and-flux/
72
[26] DOM Virtual en React: https://es.reactjs.org/docs/faq-internals.html#:~:text=El%20DOM%20virtual%20(VDOM)%20es,proceso%20se%20conoce%20como%20reconciliaci%C3%B3n
[27] Descripción de los hooks: https://es.reactjs.org/docs/hooks-intro.html
[28] Hooks de estado en React: https://es.reactjs.org/docs/hooks-state.html
[29] Hooks de efecto en React: https://es.reactjs.org/docs/hooks-effect.html
[30] Capacitor: https://capacitorjs.com/docs/apis
[31] Lista plugins incompatibles Cordova: https://capacitorjs.com/docs/plugins/cordova
[32] Firebase: https://firebase.google.com/
[33] Cloud Messaging Firebase: https://firebase.google.com/products/cloud-messaging?hl=es-419
[34] Protocolo TLS: https://www.swhosting.com/blog/transport-layer-security-tls-que-es-y-como-funciona/
[35] Algoritmo AES: https://www.nist.gov/publications/advanced-encryption-standard-aes
[36] Jest: https://jestjs.io/es-ES/docs/getting-started
[37] SeleniumIDE: https://chrome.google.com/webstore/detail/selenium-ide/mooikfkahbdckldjjndioackbalphokd
Top Related