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