Diseño y desarrollo de la interfaz de usuario de una aplicación web para la mejora de la salud basada en un chatbot

Universidad de Valladolid Escuela Técnica Superior de Ingenieros de Telecomunicación Trabajo de Fin de Grado Grado en Ingeniería de Tecnologías de Telecomunicación Diseño y desarrollo de la interfaz de usuario de una aplicación web para la mejora de la salud basada en un chatbot Autor: Pablo Juan Fernández Cotrina Tutor: Juan Pablo de Castro Fernández Valladolid, 1 de julio de 2021 II TÍTULO: Diseño y desarrollo de la interfaz de usuario de una aplicación web para la mejora de la salud basada en un chatbot AUTOR: Pablo Juan Fernández Cotrina TUTOR: Juan Pablo de Castro Fernández DEPARTAMENTO: Teoría de la Señal y Comunicaciones e Ingeniería Telemática TRIBUNAL PRESIDENTE: Juan Pablo de Castro Fernández VOCAL: María Jesús Verdú Pérez SECRETARIO: Luisa María Regueras Santos SUPLENTE: Jaime Gómez Gil SUPLENTE: Ramón de la Rosa Steinz FECHA: 1 de julio de 2021 CALIFICACIÓN: III Resumen del TFG En este Trabajo de Fin de Grado, gracias a las tareas realizadas, ha sido posible la creación de la interfaz de usuario de una aplicación que ofrece un seguimiento personalizado a sus usuarios, con el que consiguen desarrollar su máximo potencial. Un proyecto que ha nacido de la detección de la necesidad de reducir el impacto económico consecuencia de la mala salud de los trabajadores. La empresa Ingage ha querido poner solución a este problema enfocándose en su sector de actuación, el sector de los seguros. Ante las diferentes posibilidades de desarrollo de la aplicación, se ha optado por una aplicación híbrida, que permitiera tanto una versión web como una versión nativa. A lo largo del proyecto se ha seguido un proceso de integración continua, en el que, a medida que se han ido creando nuevas funcionalidades, se han ido testeando, con el objetivo de conseguir una aplicación mucho más robusta. La aplicación, Full Power, ha sido diseñada para ser una aplicación atractiva, fácil de utilizar y adaptativa a cualquier tamaño de dispositivo. La aplicación en su conjunto está formada por la parte cliente y la parte del servidor, por lo que ha sido necesaria la creación de una API (Application Programming Interface) que habilitara la comunicación entre ambas. Además, gracias a haberse tratado de una aplicación híbrida, solo ha sido necesario un único desarrollo (en versión web) para obtener la versión final, finalizando con una conversión de web a nativo. El chatbot que contiene la aplicación permite obtener información de los usuarios mediante una encuesta de evaluación inicial, cuyo algoritmo es capaz de detectar posibles problemas de salud en dichos usuarios. Posteriormente, puede obtener nueva información a través de preguntas que realiza el chatbot lanzadas en las notificaciones locales del dispositivo (solo disponible en Android). Además, los usuarios pueden consultar los documentos de salud elaborados por el experto naturópata del equipo de trabajo. Palabras clave Salud, aplicación híbrida, Angular, IONIC Capacitor, Android, test, API, frontend, documento, fichero, integración continua. IV Abstract In this thesis, thanks to completed tasks, it has been possible to create an app user interface that offers customizable tracking to its users, who can reach their full potential. A project which was born because of the need to shrink the economic impact that is consequence of lack of health from workers. The Ingage company has chosen to solve this problem by focusing in their business field, Insurance field. Given the different possibilities for the app development, a hybrid app, that allows both web and native versions, has been chosen. Throughout the project, continuous integration process has been followed. In this process, by the time new functionalities have been created, they have been being tested, on purpose of getting such a robust application. The application, Full Power, has been designed to be an attractive, easy-to-use and responsive application. The application as a whole is composed of a client part and a server part, consequently there was a need to create an API (Application Programming Interface) that enabled communication between both sides. In addition, thanks to have been a hybrid app, a sole development has been needed (web version) to get final version, ending with a conversion from web to native. The chatbot that is inside the app enables get information from users by an initial evaluation survey, which algorithm can detect possible health problems on these users. The following times, it can get new information through the questions thrown on the local notifications of the device (only enabled in Android). Furthermore, users can check the health documents written by the team’s naturopath expert. Keywords Health, hybrid Application, Angular, IONIC Capacitor, Android, test, API, frontend, document, file, continuous integration. V Contenido Resumen del TFG .......................................................................................................................... III Palabras clave ............................................................................................................................... III Abstract ........................................................................................................................................ IV Keywords ...................................................................................................................................... IV Índice de figuras ......................................................................................................................... VIII 1. Introducción .......................................................................................................................... 1 1.1. Motivación .................................................................................................................... 1 1.2. Objetivos ....................................................................................................................... 2 1.3. Metodología .................................................................................................................. 2 1.4. Estructura de la memoria .............................................................................................. 3 2. Estado del arte ...................................................................................................................... 4 2.1. Tipos de aplicaciones móviles ....................................................................................... 4 2.1.1. Aplicaciones nativas .............................................................................................. 4 2.1.2. Aplicaciones web ................................................................................................... 4 2.1.3. Aplicaciones híbridas ............................................................................................. 5 2.2. Aplicaciones de salud .................................................................................................... 7 2.2.1. Aplicaciones de seguimiento deportivo ................................................................ 7 2.2.2. Aplicaciones de seguimiento general de la salud ................................................. 7 2.2.3. Aplicaciones para la mejora de la salud ................................................................ 8 3. Análisis del problema .......................................................................................................... 10 3.1. Especificaciones de los requisitos del sistema ............................................................ 10 3.1.1. Tipos de usurario ................................................................................................. 10 3.1.2. Características del usuario .................................................................................. 10 3.1.3. Hardware y Software ........................................................................................... 11 3.1.4. Requisitos ............................................................................................................ 11 3.2. Casos de uso ................................................................................................................ 13 3.3. Prototipado de la Interfaz de Usuario ......................................................................... 19 4. Desarrollo del proyecto ....................................................................................................... 23 4.1. Tecnologías utilizadas.................................................................................................. 23 4.1.1. Angular ................................................................................................................ 23 4.1.2. Apache Cordova e IONIC Capacitor ..................................................................... 24 4.1.3. Bootstrap ............................................................................................................. 24 4.1.4. CKEditor ............................................................................................................... 25 4.1.5. Jasmine ................................................................................................................ 25 4.1.6. GitHub y Git ......................................................................................................... 25 VI 4.1.7. Codecov ............................................................................................................... 25 4.1.8. Docker ................................................................................................................. 25 4.1.9. VSCode ................................................................................................................ 25 4.1.10. Android Studio..................................................................................................... 25 4.2. Arquitectura del sistema ............................................................................................. 25 4.2.1. Rutas .................................................................................................................... 27 4.2.2. Endpoints del backend ........................................................................................ 29 4.2.3. Servicios ............................................................................................................... 31 4.2.4. Componentes ...................................................................................................... 32 4.2.5. Módulos............................................................................................................... 34 4.3. Configuración del entorno de trabajo ......................................................................... 34 4.3.1. Fase de desarrollo ............................................................................................... 34 4.3.2. Testeo de la aplicación ........................................................................................ 38 4.3.3. Fase de despliegue .............................................................................................. 42 4.4. Estructura de ficheros ................................................................................................. 44 4.5. Implementación .......................................................................................................... 46 4.5.1. Comunicación con la API ..................................................................................... 46 4.5.2. Editor de texto ..................................................................................................... 46 4.5.3. Traducciones ....................................................................................................... 47 4.5.4. Notificaciones ...................................................................................................... 48 5. Manuales de uso ................................................................................................................. 50 5.1. Manual de usuario básico ........................................................................................... 50 5.1.1. Requisitos ............................................................................................................ 50 5.1.2. Primera vez en la aplicación ................................................................................ 50 5.1.3. Navegar por la aplicación .................................................................................... 54 5.1.4. Cierre de sesión ................................................................................................... 54 5.1.5. Consultar documentos ........................................................................................ 55 5.1.6. Contestar pregunta de notificación .................................................................... 56 5.1.7. Cambiar idioma ................................................................................................... 57 5.1.8. Hablar con el bot ................................................................................................. 58 5.2. Manual de administrador ............................................................................................ 58 5.2.1. Requisitos ............................................................................................................ 58 5.2.2. Gestionar documentos ........................................................................................ 59 6. Conclusiones y líneas futuras .............................................................................................. 64 6.1. Conclusiones................................................................................................................ 64 6.2. Líneas futuras .............................................................................................................. 65 VII 6.2.1. Creación de cuenta con una mayor cantidad de datos ....................................... 65 6.2.2. Eliminar cuenta de usuario .................................................................................. 65 6.2.3. Sección de estadísticas ........................................................................................ 65 6.2.4. Carácter socializador de la aplicación ................................................................. 66 Referencias .................................................................................................................................. 67 VIII Índice de figuras Figura 1.- Pérdidas económicas debidas a un sueño insuficiente en 5 países de la OCDE. .......... 1 Figura 2.- Uso de la caché cuando la conexión a internet no funciona [10]. ................................ 5 Figura 3.- Estructura de una aplicación híbrida. ........................................................................... 6 Figura 4.- Interfaz de la aplicación Runtastic. ............................................................................... 7 Figura 5.- Interfaz de la aplicación Strava. .................................................................................... 7 Figura 6.- Interfaz de la aplicación Zepp. ...................................................................................... 8 Figura 7.- Interfaz de la aplicación Salud. ...................................................................................... 8 Figura 8.- Interfaz de la aplicación Fabulous. ................................................................................ 9 Figura 9.- Prototipos del onboarding. ......................................................................................... 20 Figura 10.- Prototipos del inicio de sesión (izquierda), del menú principal (centro) y de la exención de responsabilidad (derecha). ..................................................................................... 20 Figura 11.- Prototipos de la encuesta principal. ......................................................................... 20 Figura 12.- Prototipos de la sección de salud.............................................................................. 21 Figura 13.- Prototipos de un documento de salud...................................................................... 21 Figura 14.- Prototipos de la sección de vitaminas y un documento de vitaminas. ..................... 21 Figura 15.- Prototipo de la sección de perfil. .............................................................................. 22 Figura 16.- Prototipos de notificaciones. .................................................................................... 22 Figura 17.- Prototipos de interacción con el chatbot tras notificación. ...................................... 22 Figura 18.- Arquitectura de la aplicación Full Power para la versión web. ................................. 26 Figura 19.- Arquitectura de la aplicación Full Power para la versión Android. ........................... 27 Figura 20.- Creación del icono de la aplicación Android. ............................................................ 37 Figura 21.- Configuración del icono de la aplicación Android. .................................................... 37 Figura 22.- Proceso para conseguir el fichero .apk empleando Android Studio. ..................... 38 Figura 23.- Ejemplo de salida de los test en el navegador. ......................................................... 40 Figura 24.- Ejemplo de salida de la cobertura del código en la consola. .................................... 40 Figura 25.- Cobertura vista con el fichero index.html generado en con los test. ................ 41 Figura 26.- Fragmento de la cobertura del fichero file.component.ts. ........................... 41 Figura 27.- Fragmento de la cobertura del fichero app.component.ts. ............................. 41 Figura 28.- Desplegable de la sección “Build” seleccionando “Generate Signed Bundle / APK…”. ..................................................................................................................................................... 43 Figura 29.- Selección del formato de salida del proyecto. .......................................................... 43 Figura 30.- Generación de la firma. A la izquierda para el APK y a la derecha para el Bundle. .. 43 Figura 31.- Selección entre producción y desarrollo. A la izquierda para el APK y a la derecha para el Bundle...................................................................................................................................... 44 Figura 32.- Proceso de obtención y uso del token de autenticación. ......................................... 46 Figura 33.- Presentación de la aplicación. ................................................................................... 50 Figura 34.- Pantalla de inicio de sesión. ...................................................................................... 51 Figura 35.- Página de registro. .................................................................................................... 51 Figura 36.- Iniciando sesión. ........................................................................................................ 52 Figura 37.- Aceptación de la exención de responsabilidad. ........................................................ 52 Figura 38.- Selección de sección de “Chat” y comienzo de primera encuesta. .......................... 53 Figura 39.- Respuesta de varias preguntas de la encuesta. ........................................................ 53 Figura 40.- Resultado de la encuesta. ......................................................................................... 54 Figura 41.- Barra de navegación. ................................................................................................. 54 Figura 42.- Icono para ir a la página principal desde el chat. ...................................................... 54 Figura 43.-Cierre de sesión. ......................................................................................................... 55 IX Figura 44.- Lista de documentos de salud (izquierda) y lista de documentos de vits&mins (derecha) ..................................................................................................................................... 55 Figura 45.- Documento de vitaminas. ......................................................................................... 56 Figura 46.- Documento de salud. ................................................................................................ 56 Figura 47.- Notificación con pregunta. ........................................................................................ 56 Figura 48.- Pregunta de la notificación. ...................................................................................... 57 Figura 49.- Respuesta del chatbot ante respuesta afirmativa de la pregunta. ........................... 57 Figura 50.- Cambiar idioma de la aplicación. .............................................................................. 58 Figura 51.- Posible conversación con el chatbot. ........................................................................ 58 Figura 52.- Lapicero para editar los documentos........................................................................ 59 Figura 53.- Guardar documento editado. ................................................................................... 59 Figura 54.- Sección de “Salud” para administradores. ................................................................ 60 Figura 55.- Documentos disponibles en la aplicación. ................................................................ 60 Figura 56.- Documentos disponibles por idiomas. ...................................................................... 61 Figura 57.- Botón de crear documento. ...................................................................................... 61 Figura 58.- Campos a rellenar al crear un documento. ............................................................... 61 Figura 59.- Creando un documento de salud. ............................................................................. 62 Figura 60.- Creando un documento de vitaminas. ...................................................................... 62 Figura 61.- Botón para eliminar documentos. ............................................................................ 63 Figura 62.- Eliminación de documentos. ..................................................................................... 63 7 capacidad de personalización máxima que ofrecen las aplicaciones nativas tanto a nivel software como hardware. 2.2. Aplicaciones de salud Actualmente, existen múltiples aplicaciones relacionadas con la salud en las tiendas de aplicaciones de Apple y de Google. Tras observar parte de ellas, he establecido varios grupos en función de las características principales que ofrecen: aplicaciones de seguimiento deportivo, de seguimiento general de la salud y para la mejora de la salud. 2.2.1. Aplicaciones de seguimiento deportivo Estas aplicaciones se basan en realizar un seguimiento de las actividades deportivas que realicemos, como puede ser correr, ciclismo o natación. Entre estas aplicaciones se encuentran Nike Run Club, Runtastic (Figura 4), Strava (Figura 5) o Sports Tracker. Figura 4.- Interfaz de la aplicación Runtastic. Figura 5.- Interfaz de la aplicación Strava. 2.2.2. Aplicaciones de seguimiento general de la salud Se puede considerar este tipo de aplicaciones un derivado del grupo anterior, ya que cuentan con seguimiento de las actividades deportivas. No obstante, no se centran en ello y, además, 8 permiten el seguimiento de otros aspectos, como la cantidad y calidad del sueño, la cantidad de agua ingerida, la alimentación, el nivel de estrés, el ritmo cardíaco, la respiración… Cuentan con los datos de gran cantidad de usuarios, con los que permiten mostrar ciertos estadísticos de utilidad para los usuarios. Algunos ejemplos de este tipo de aplicaciones son Zepp (Figura 6), Salud (Figura 7), Google Fit, Mi Fit, Huawei Health o Samsung Health. Figura 6.- Interfaz de la aplicación Zepp. Figura 7.- Interfaz de la aplicación Salud. 2.2.3. Aplicaciones para la mejora de la salud Aplicaciones que de manera proactiva (las anteriores son pasivas) ayudan a mejorar distintos aspectos de salud (como un entrenador personal dentro del teléfono), como mejorar el sueño o perder peso. Muestran información sobre cómo conseguir los objetivos deseados. Algunos ejemplos de este tipo de aplicaciones son Fabulous (Figura 8) o Healthy Habits. 9 Figura 8.- Interfaz de la aplicación Fabulous. La aplicación que se va a realizar pertenecerá a ese tercer grupo de aplicaciones. Son aplicaciones que ofrecen soluciones genéricas a todos los usuarios, la posibilidad de adecuación al usuario que ofrecen no es muy alta. La principal diferencia de la aplicación a desarrollar con las aplicaciones ya existentes será la presencia de un chatbot que permita comprender mejor las necesidades del usuario para ofrecer un servicio mucho más personalizado y ayudarle de una manera mucho más adaptada a alcanzar su máximo potencial. 10 3. Análisis del problema Este capítulo contiene la descripción del proceso de análisis realizado para el desarrollo de la aplicación. Este proceso comienza con la especificación de los requisitos del sistema, analizando: los tipos de usuario que van a utilizar la aplicación y sus características, las condiciones mínimas de hardware y software que permitan utilizar correctamente la aplicación y los requisitos funcionales y no funcionales de la aplicación. A continuación, se desarrollarán todos los casos de uso de la aplicación, incluyendo: su identificador, una breve descripción, actores que lo realizan, precondiciones, escenario principal de éxito, postcondiciones y posibles alternativas. Finalmente, se mostrará el prototipado de la interfaz de usuario, que no deja de ser un aspecto que definirá el desarrollo futuro de la aplicación y, es por ello una parte importante del análisis del problema. 3.1. Especificaciones de los requisitos del sistema El objetivo de esta sección es describir los diferentes requisitos que han sido recogidos en las reuniones del proyecto en la empresa INGAGE, en la que participaron Patrice Séjalon (tutor en la empresa) y Stéphane Tetart (experto naturópata). Estos requisitos estarán adecuados para la comprensión de todos los miembros del equipo. La aplicación Full Power está pensada para proporcionar al usuario una serie de consejos con el objetivo de alcanzar su máximo potencial, evitando problemas que en un futuro le provoquen la necesidad de acudir al médico, gracias a un seguimiento personalizado realizado por un chatbot que detecta qué aspectos de salud se pueden mejorar y unos documentos informativos con todo lo necesario para averiguar más sobre dichos ámbitos. De manera completa, la aplicación se configura con una arquitectura en la que se diferencia la parte del cliente (frontend) y la parte del servidor (backend). Esto se explicará de manera más detallada en la Sección 4.2. Debido a que el ámbito de este TFG comprende la parte correspondiente al frontend de la aplicación completa, en la presente sección se centrará el análisis de la parte del cliente. Utilizaré el término sistema o aplicación para referirme de manera más sencilla a la parte del cliente a partir de ahora. Estos requisitos estarán recogidos de acuerdo con las prácticas recomendadas de IEEE [13]. 3.1.1. Tipos de usurario Existirán dos tipos de usuario en este sistema: • Básicos: tras haberse registrado en la aplicación, usuarios que pueden utilizar las funciones básicas de la aplicación: el chatbot y consultar las diferentes secciones de documentos de salud. • Administradores: usuarios especiales que, además de poder realizar las funciones básicas, son los encargados de gestionar los documentos disponibles en la aplicación. 3.1.2. Características del usuario El sistema está pensado para ser utilizado por cualquier tipo de usuario, independientemente de sus conocimientos previos, lo que permitirá que la aplicación pueda ayudar a un mayor número de personas. 11 3.1.3. Hardware y Software Se pretende que la aplicación pueda ser utilizada tanto en dispositivos móviles o tabletas como en portátiles u ordenadores de sobremesa. Se podrá acceder a la aplicación mediante el navegador o bien, si contamos con un dispositivo con el sistema operativo de Android, a través del fichero .apk, que puede ser instalado. Será necesario que los dispositivos tengan una tarjeta de red con la que conectarse a internet para poder utilizarla correctamente. La aplicación funcionará correctamente en las últimas versiones de los navegadores Google Chrome, Microsoft Edge, Firefox y Safari. En el caso de Android, funcionará correctamente a partir de la versión de Android 5.0 Lollipop, que se corresponde con un nivel de API 21 y el 94.1% de los dispositivos Android a nivel global tienen esa versión o superior [14]. 3.1.4. Requisitos A la hora de enumerar los requisitos será importante diferenciar entre los Funcionales (Functional Requirement, FRQ) y los No Funcionales (Non Functional Requirement, NFRQ). Los requisitos funcionales son aquellos que expresan una funcionalidad del sistema, mientras que los requisitos no funcionales son características requeridas que señalan una restricción del sistema. Todos estos requisitos han sido redactados siguiendo la categorización FURPS+ [15], que se compone de las siguientes categorías: • Funcionalidad (Functionality): aquello que la aplicación debería realizar. Se corresponde con los requisitos funcionales. • El resto de las siglas se corresponden con los requisitos no funcionales: o Usabilidad (Usability): atributos relacionados con la interacción del usuario con la aplicación, la apariencia de la aplicación o la capacidad de respuesta. o Fiabilidad (Reliability): requisitos sobre la robustez o fiabilidad de la aplicación. o Rendimiento (Performance): para describir cómo de eficiente debería ser la aplicación en términos de velocidad y consumo de recursos. o Soporte (Supportability): requisitos instalación y configuración del sistema, también acerca de la sencillez para administrar la aplicación, testear el código y cómo de flexible es la aplicación. o El signo + se refiere a nuevas categorías de requisitos que, normalmente, serán restricciones. En estas categorías nos encontraremos: ▪ Restricciones de diseño. ▪ Requisitos de implementación. ▪ Requisitos de interfaz. ▪ Requisitos físicos. 3.1.4.1. Requisitos funcionales FRQ001. El sistema deberá comprobar si es la primera vez que se accede a la aplicación en el dispositivo de utilización, caso en que se mostrará una presentación sobre la misma. FRQ002. El sistema deberá permitir el registro de nuevos usuarios. La información necesaria para su registro será el nombre de usuario, la contraseña y la repetición de la contraseña. Esta información deberá ser enviada al backend para que pueda almacenarla. FRQ003. El sistema deberá impedir el registro de más de un usuario con el mismo nombre de usuario, realizando una indicación sobre este suceso. Además, deberá impedir la utilización de ciertos caracteres y comprobar que tenga una longitud determinada. FRQ004. El sistema deberá comprobar que la contraseña coincida con la repetición. 12 FRQ005. El sistema deberá permitir a los usuarios iniciar sesión, para lo que requerirá el nombre de usuario y la contraseña, que serán comprobados en el backend. También deberá permitir el cierre de sesión. FRQ006. El sistema deberá impedir a usuarios que no hayan iniciado sesión utilizar las funciones de la aplicación (excepto registrarse e iniciar sesión). FRQ007. El sistema deberá conseguir del backend si se ha aceptado la exención de responsabilidad y, en caso negativo, mostrar un aviso en el momento en el que el usuario inicie sesión. Sin su aceptación no se podrá utilizar la aplicación. Una vez aceptado, se comunicará al backend para que actualice la información del usuario. FRQ008. El sistema deberá recibir del backend si es la primera vez que un usuario accede a su cuenta. En caso afirmativo, se redirigirá al usuario automáticamente a la zona de chat para responder al cuestionario inicial. FRQ009. El sistema deberá permitir a los usuarios registrados consultar los diferentes documentos disponibles en la aplicación, que obtendrá desde el backend. FRQ010. El sistema deberá permitir a los usuarios registrados enviar mensajes al chatbot, que serán procesados en el backend y, finalmente, respondidos por este. FRQ011. El sistema deberá detectar el idioma del usuario y mostrar la aplicación en dicho idioma si está disponible. Además, permitirá el cambio de este si el usuario lo desea. 3.1.4.2. Requisitos no funcionales NFRQ001. El sistema deberá ser sencillo de utilizar e intuitivo, para que usuarios de cualquier nivel de conocimientos puedan dominar su uso sin necesidad de ayuda externa. Contendrá ciertas pistas que permitan aclarar sobre ciertas funcionalidades a los usuarios. NFRQ002. El sistema deberá funcionar correctamente en las últimas versiones de los navegadores Google Chrome, Microsoft Edge, Mozilla Firefox y Safari. Además, deberá funcionar tanto en versión web como en versión aplicación de Android. NFRQ003. Los colores seleccionados en la interfaz de usuario deberán ser afines a los colores de la empresa INGAGE. NFRQ004. La interfaz de usuario deberá adaptarse a cualquier tipo de pantalla (escritorio, móvil o tableta). NFRQ005. El sistema deberá ser capaz de avisar a los usuarios de que se ha producido un fallo al utilizar la API. NFRQ006. El sistema solo funcionará en dispositivos con conexión a internet. NFRQ007. El sistema permitirá una navegación fluida por toda la aplicación. 13 3.2. Casos de uso Identificador DarseDeAlta Descripción Un usuario crea una cuenta de usuario en la aplicación. Actor Usuario no registrado. Precondición Ninguna. Escenario principal de éxito Paso Acción 1 El usuario no registrado hace clic en la sección “¿No tienes una cuenta? Haga clic aquí para registrarse”. 2 El sistema solicita un nombre de usuario y la contraseña (con su confirmación). 3 El usuario introduce los datos solicitados siguiendo las reglas indicadas. 4 El sistema manda los datos al backend. 5 En el backend se comprueba que no existe ningún usuario registrado con el nombre de usuario a crear, caso en el que se creará la cuenta del usuario. 6 El sistema conduce al usuario a la página de inicio de sesión de la aplicación. Postcondición Un nuevo usuario se crea en la aplicación. Alternativas Paso Acción 3 El usuario no cumple con las reglas al introducir sus datos. Se informa de este hecho al usuario y se vuelve al paso 2. 5 El backend encuentra un nombre de usuario idéntico al que se desea crear. Se informa de este hecho al usuario y se vuelve al paso 2. Identificador IniciarSesion Descripción Un usuario puede iniciar sesión con su nombre de usuario y contraseña. Actor Usuario básico y administrador. Precondición Ninguna. Escenario principal de éxito Paso Acción 1 El sistema solicita al usuario su nombre de usuario y su contraseña. 2 El usuario introduce los datos solicitados. 3 El sistema envía los datos al backend. 4 El backend verifica que los datos introducidos son correctos. 5 El backend responde con la confirmación del acceso y el token de sesión. 6 El sistema conduce al usuario al menú principal de la aplicación. Postcondición El usuario ha iniciado sesión. Alternativas Paso Acción 4 El backend no verifica los datos introducidos porque no son correctos. Notificará de este hecho al usuario. Se vuelve al paso 1. 14 Identificador CerrarSesion Descripción Un usuario puede cerrar la sesión en la aplicación. Actor Usuario básico y administrador. Precondición El usuario ha iniciado sesión en el sistema. Escenario principal de éxito Paso Acción 1 El usuario accede a la sección “Perfil” de la aplicación. 2 El usuario selecciona “Cerrar Sesión”. 3 El sistema elimina el token, cerrando la sesión del usuario y navegando a la página de inicio de sesión. Postcondición El usuario ha cerrado la sesión. Identificador ConsultarDocumentos Descripción El usuario puede consultar los documentos disponibles tanto de la sección de salud como de la sección de vitaminas y minerales. Actor Usuario básico y administrador. Precondición El usuario ha iniciado sesión en el sistema. Escenario principal de éxito Paso Acción 1 El usuario accede a la sección “Salud” o “Vits&Mins” de la aplicación. 2 El sistema solicita al backend la lista de documentos disponibles sobre salud/vitaminas en el idioma actual de la aplicación. 3 El backend envía la lista de documentos disponibles. 4 El sistema muestra la lista de documentos disponibles. 5 El usuario selecciona cualquier elemento de la lista. 6 El sistema solicita al backend el documento seleccionado por el usuario. 7 El backend envía el documento seleccionado. 8 El sistema muestra al usuario el documento solicitado. Postcondición Ninguna. Identificador AceptarDisclaimer Descripción El usuario debe aceptar la exención de responsabilidad en el caso de que quiera utilizar la aplicación, en caso contrario no podrá utilizarla. Actor Usuario básico y administrador. Precondición El usuario ha iniciado sesión en el sistema. Escenario principal de éxito Paso Acción 1 El sistema muestra al usuario la exención de responsabilidad. 2 El usuario acepta la exención de responsabilidad. 3 El sistema envía al backend la aceptación de la exención. 4 El backend almacena esa información para el usuario que acepta. 5 El sistema permite la utilización de la aplicación al usuario. Postcondición El usuario ha aceptado la exención de responsabilidad. Alternativas Paso Acción 2 El usuario no acepta la exención de responsabilidad. En este caso no puede utilizar la aplicación. Se vuelve al paso 1. 15 Identificador CompletarPrimeraEncuesta Descripción El usuario puede completar la encuesta inicial tras iniciar sesión por primera vez. Actor Usuario básico y administrador. Precondición El usuario ha iniciado sesión por primera vez en el sistema. Escenario principal de éxito Paso Acción 1 El usuario accede a la sección “Chat” de la aplicación. 2 El sistema solicita al backend la primera pregunta del cuestionario. 3 El backend envía la primera pregunta del cuestionario. 4 El sistema muestra la primera pregunta del cuestionario y la zona donde debe responder el usuario. 5 El usuario introduce su respuesta a la primera pregunta. 6 El sistema envía la respuesta al backend. 7 El backend almacena la respuesta del usuario. 8 El backend envía la siguiente pregunta. 9 El sistema muestra la siguiente pregunta y la zona donde debe contestar el usuario. 10 El usuario introduce su respuesta. 11 Se repiten los pasos 6 a 10 hasta llegar a la última pregunta. 12 El sistema envía la respuesta a la última pregunta al backend. 13 El backend almacena la respuesta del usuario y marca como completada la primera encuesta. 14 El backend envía al sistema la indicación de finalización de la encuesta, así como de la información acerca de sus respuestas, indicando sus problemas y la gravedad de estos. 15 El sistema muestra al usuario la indicación de finalización de la encuesta, así como sus problemas, su gravedad y la posibilidad de navegar a la sección de la aplicación en la que se habla acerca de su problema. 16 El sistema programa una notificación en función de la gravedad del problema para recordar al usuario en el futuro ciertos consejos para mejorar su salud. Postcondición El usuario tiene un atributo que indica que ha completado la primera encuesta. Alternativas Paso Acción 2-10 El usuario abandona la sección de “Chat”. Las sucesivas veces que entre de nuevo en dicha sección, volverá al paso 1. 15 El usuario no está utilizando un dispositivo Android. Se ignora este paso. 16 Identificador ContestarPreguntaNotificacion Descripción El usuario recibe una notificación con una pregunta relacionada con sus problemas de salud. Al abrirla, podrá contestar a dicha pregunta y recibirá un consejo tras su respuesta. Actor Usuario básico y administrador. Precondición El usuario ha realizado la primera encuesta y tiene algún problema de salud y ha iniciado sesión en la aplicación. Escenario principal de éxito Paso Acción 1 El usuario abre la notificación. 2 El sistema programa una notificación en función de la gravedad del problema para recordar al usuario en el futuro ciertos consejos para mejorar su salud. 3 El sistema muestra al usuario la sección de “Chat” con la pregunta de la notificación y el campo para responder. 4 El usuario introduce su respuesta. 5 El sistema envía la respuesta al backend. 6 El backend envía al sistema el consejo adecuado en función de la respuesta del usuario. 7 El sistema muestra al usuario el consejo recibido. Postcondición Se ha programado una notificación. Alternativas Paso Acción 3-4 El usuario abandona la sección de “Chat”. Se finaliza el caso de uso. Identificador CambiarIdioma Descripción El usuario puede cambiar el idioma de la aplicación si el seleccionado por el sistema no es el adecuado. Actor Usuario básico y administrador. Precondición El usuario ha iniciado sesión en el sistema. Escenario principal de éxito Paso Acción 1 El usuario accede a la sección “Perfil” de la aplicación. 2 El usuario selecciona el idioma deseado entre las opciones disponibles. 3 El sistema cambia de idioma. Postcondición El sistema ha cambiado de idioma. 23 4. Desarrollo del proyecto Este capítulo contiene todo lo relacionado con el desarrollo del proyecto una vez hemos analizado de manera completa el problema que se va a abordar. Comenzando con un análisis de las diferentes tecnologías que se han utilizado a lo largo del proyecto, describiendo brevemente en qué consisten y destacando sus funcionalidades más importantes. A continuación, se realizará el análisis de la arquitectura del sistema desde el punto de vista de las conexiones entre la parte cliente y servidor hasta centrarse más concretamente en la arquitectura propia del frontend. Posteriormente, se describirá la configuración del entorno de trabajo en sus diferentes fases: desarrollo, testeo y despliegue. También, la estructura de ficheros del frontend, en la que se explicará de forma breve, la función de cada uno de ellos. Por último, explicaré los aspectos concretos relevantes de la implementación de la aplicación, como son las comunicaciones con la API, el editor de texto, las traducciones y las notificaciones. 4.1. Tecnologías utilizadas 4.1.1. Angular La parte de frontend está desarrollada en Angular, un framework desarrollado por Google que permite la creación de aplicaciones web de una sola página (SPA, Single Page Application), este tipo de aplicaciones permite cargar todos los recursos de la propia aplicación en la solicitud inicial, sin necesidad de recargas posteriores. Esto permite, además, evitar llamadas al backend para generar el propio contenido de la aplicación. En un inicio se barajaron varias opciones de tecnologías para realizar la aplicación, en una primera aproximación se eligió Python con Flask, no obstante, no permite una separación de frontend y backend, por lo que se descartó. Posteriormente de entre los distintos frameworks disponibles más enfocados a la parte de frontend, React, Vue y Angular, se optó por Angular por la posesión de mayor conocimiento de dicho framework por parte de la empresa. Angular se programa mediante TypeScript, un lenguaje de código abierto basado en JavaScript, con la diferencia de permitir la declaración de tipos. Este código al ser compilado es convertido a JavaScript para hacer posible su utilización [17]. Dentro de Angular nos encontramos varios conceptos fundamentales, que componen su arquitectura: • Módulos: permiten organizar las inyecciones de código y la compilación. Debe existir un módulo raíz que permita una organización global de todo el proyecto. Otro módulo importante en las aplicaciones de Angular es el que gestiona las rutas de la aplicación. • Componentes: parte elemental de Angular. Permite la creación de las diferentes vistas de la aplicación mediante la configuración de cuatro ficheros asociados al componente: o .ts: fichero TypeScript que define el componente como una clase, se definen las propiedades y métodos del componente. o .html: fichero HTML que permite definir la plantilla del componente. o .css: fichero CSS en el que se definen los estilos del componente definidos en la plantilla HTML. 24 o .spec.ts: fichero TypeScript que permite definir los test unitarios asociados al componente, no es indispensable para la creación de un proyecto, pero sí recomendable para permitir la integración continua. • Servicios: utilizados por los componentes para una funcionalidad específica. Al igual que los componentes se definen en un fichero TypeScript como clases, también cuentan con un fichero para los test unitarios. No se utilizan para las vistas, por lo que no requieren de plantilla y estilos. Se diferencian de los componentes en que pueden ser reutilizados por varios componentes de manera simultánea, por ejemplo, para realizar métodos comunes entre ellos, como pueden ser llamadas al servidor. También permiten comunicar información entre los componentes que, de otra manera, no podrían enviarse. • Tuberías: utilizados en las plantillas para transformar los datos antes de ser mostrados, como traducir el texto deseado o cambiar de minúsculas a mayúsculas. Se definen como clases en un fichero TypeScript, y cuentan con un segundo fichero para los test unitarios. • Interceptores: utilizados para interceptar mensajes HTTP antes de ser enviados y, por ejemplo, colocar una cabecera específica que indica que un usuario ha iniciado sesión. Se definen con un fichero TypeScript y un segundo fichero para los test unitarios. • Guardas: utilizados para proteger ciertas rutas y que solo puedan ser accedidas por ciertos usuarios (diferenciando registrados, no registrados y administradores). La utilización de Angular es mucho menos compleja mediante la utilización de Angular CLI (Command Line Interface, Interfaz de Línea de Comandos). Esta interfaz permite la utilización de comandos para diversas funciones como la creación de módulos componentes, servicios, tuberías, etc. O también la compilación del proyecto tanto para la versión de desarrollo, como la versión de producción, u otras utilidades como la ejecución de los test y comprobaciones de la calidad del código. 4.1.2. Apache Cordova e IONIC Capacitor Además de Angular, para tener la posibilidad de transformar la aplicación web en una aplicación para Android, se han utilizado las librerías Apache Cordova [18] e IONIC Capacitor [19]. Existen diferencias entre ambos: Cordova es mucho más sencillo de utilizar que Capacitor y, permite una conversión de la aplicación rápida y sencilla. Por el contrario, IONIC ofrece mucha mayor capacidad de personalización, ya que, mientras que Cordova compila la aplicación directamente al fichero .apk gracias a un único fichero de configuración, necesario para instalar aplicaciones en Android, IONIC convierte el proyecto de Angular en un proyecto de Android que puede ser trabajado desde el entorno de desarrollo de Android, Android Studio. El cambio de Cordova a Capacitor no es complicado, ya que las librerías son compatibles. Por ello, aunque se comenzó el proyecto utilizando Cordova, se terminó optando por Capacitor. 4.1.3. Bootstrap Bootstrap es un framework de CSS que permite dar estilos a una plantilla HTML mediante clases predefinidas [20]. El uso de este framework no limita la capacidad de introducir otros estilos personalizados. Se ha utilizado principalmente por su gran flexibilidad para posicionar los diferentes componentes de la plantilla en la interfaz que, además, son adaptables a cualquier tipo de pantalla de una manera rápida. 25 4.1.4. CKEditor CKEditor es un framework WYSIWYG (What you see is what you get, aquello que ves es lo que obtienes), es decir, es un editor de texto dentro de la aplicación [21]. Se ha utilizado por su gran facilidad de implementación en la aplicación y la gran capacidad de personalización que ofrece. Desde librerías con un editor por defecto hasta el proyecto completo para ser editado y, posteriormente, utilizado en el proyecto de Angular. 4.1.5. Jasmine Jasmine es el framework utilizado para testear el código. Es el proporcionado por defecto por el proyecto de Angular tras la creación de este. Permite la creación y ejecución de los test, que se utilizan para analizar el comportamiento adecuado del código desarrollado y su cobertura. 4.1.6. GitHub y Git GitHub es un servicio online de repositorios de código que permite el trabajo colaborativo en la elaboración de proyectos. Git es un sistema de control de versiones de proyectos que, en combinación con GitHub, es una herramienta muy potente para la gestión de proyectos. Es posible crear un repositorio en Git, que será almacenado en GitHub para que todos los miembros de un equipo o, incluso, todo el mundo, pueda colaborar en su desarrollo. 4.1.7. Codecov Codecov es un servicio de testeo de aplicaciones que permite la integración continua en el desarrollo. Mediante un fichero de configuración habilita la realización automática de todos los test cada vez que se hace una Merge Request en GitHub. Además, ofrece un informe similar al que ofrece Jasmine de manera local con los resultados de los propios test y la cobertura del código [22]. 4.1.8. Docker Docker es un framework que permite automatizar el despliegue de aplicaciones dentro de contenedores. Facilita el despliegue de las aplicaciones ya que no es necesario buscar un servidor que admita cada tecnología específica que utilizamos, sino que con permitir el lanzamiento de contenedores Docker es más que suficiente [23]. 4.1.9. VSCode Entorno de desarrollo creado por Microsoft. Ofrece gran versatilidad y permite el uso de un alto número de herramientas que ayudan a generar el código [24]. Estas herramientas abarcan desde sugerencias de autocompletado en el código hasta el control de versiones de Git. 4.1.10. Android Studio Entorno de desarrollo creado por Google para el desarrollo de aplicaciones de Android. Al convertir la web app en una app híbrida, ha sido necesario para la personalización de la aplicación para Android [25]. 4.2. Arquitectura del sistema La aplicación Full Power en su totalidad está compuesta por frontend (parte del cliente) y backend (parte del servidor). Estas dos partes se comunican entre sí mediante una API REST. 26 Esto permite reducir la carga de trabajo de la parte del servidor, siendo solo necesaria cuando se solicita un recurso desde la parte del cliente. Estas solicitudes que se realizan a la API son peticiones HTTP asíncronas y los datos que devuelve se encuentran en formato JSON (JavaScript Object Notation). Además, tanto el frontend (versión web), como la API y la base de datos (forman en conjunto la totalidad del backend) están envueltos, cada uno, en un contenedor Docker, que permite el despliegue de la aplicación de manera sencilla con la configuración de un único fichero, en el caso del frontend y, de varios ficheros en el caso del backend [5]. Todo el sistema está siendo ejecutado en una Raspberry Pi y, se requiere que exista un contenedor adicional que redirige las peticiones que llegan al frontend y al backend, también se encarga de redirigir las peticiones del frontend al backend. Un esquema de la arquitectura lo podemos ver en la Figura 18. No nos podemos olvidar que, en el caso de Android, el frontend está compilado en un fichero .apk cumpliendo con el esquema de la Figura 19. Figura 18.- Arquitectura de la aplicación Full Power para la versión web. 27 Figura 19.- Arquitectura de la aplicación Full Power para la versión Android. 4.2.1. Rutas En la aplicación de Angular nos encontramos con las rutas mostradas en la siguiente tabla, a las que un usuario puede navegar, tan solo el path, que se escribiría justo después de la URL del frontend, en la columna de guarda relacionado, hace referencia a si el acceso a la ruta está restringido de alguna forma. Existen 2 en esta aplicación, el fichero auth.guard.ts evita el acceso si un usuario no ha iniciado sesión y, el fichero admin.guard.ts evita el acceso si un usuario no es administrador. La configuración de todas las rutas ha sido realizada en el módulo dedicado a las rutas en Angular, en el fichero app-routing.module.ts. Ruta Descripción Componentes relacionados Guarda relacionado / Se redirige automáticamente a /login. AppComponent LoginComponent OnboardingComponent - /login Permite iniciar sesión a un usuario registrado. AppComponent LoginComponent OnboardingComponent - /register Permite crear una cuenta a un usuario no registrado. AppComponent RegisterComponent - /home Menú de inicio de la aplicación una vez el usuario ha iniciado sesión. Proporciona una pequeña descripción del resto de partes de la aplicación y AppComponent DisplayComponent DisclaimerComponent MenuComponent AuthGuard 28 permite la navegación a estas. /chat Permite comunicarse con el chatbot, realizar preguntas, realizar la encuesta inicial y responder a las preguntas de las notificaciones. AppComponent ChatbotComponent MenuComponent AuthGuard /health Permite la visualización de los ficheros disponibles en la sección de salud y buscar entre ellos. AppComponent HealthComponent MenuComponent AuthGuard /health/healt hFile Permite la visualización de un fichero de la sección de salud. healthFile hace referencia al fichero que se desea visualizar. AppComponent HealthFilesComponent MenuComponent AuthGuard /vits Permite la visualización de los ficheros disponibles en la sección de vitaminas y minerales y buscar entre ellos. AppComponent VitaminsComponent MenuComponent AuthGuard /vits/vitFile Permite la visualización de un fichero de la sección de vitaminas y minerales. vitFile hace referencia al fichero que se desea visualizar. AppComponent VitaminFilesComponent MenuComponent AuthGuard /settings Permite visualizar el nombre de usuario y cambiar el lenguaje de la aplicación. También se puede cerrar la sesión del usuario. AppComponent SettingsComponent LogoutComponent MenuComponent AuthGuard /files Disponible solo para administradores. Permite la visualización de un listado de todos los ficheros disponibles, así como de su creación, eliminación y edición (la creación y edición serán llevadas a cabo en /files/edit y en /health/healthFil e o /vits/vitFile, respectivamente). AppComponent FileComponent MenuComponent AdminGuard /files/edit Disponible solo para administradores. Permite la creación de ficheros. AppComponent FileEditComponent MenuComponent AdminGuard 29 4.2.2. Endpoints del backend El frontend necesita hacer llamadas al backend a través de la API REST para obtener la información deseada. A continuación, se muestra la lista de endpoints [5]: Endpoint Métodos Descripción /bot/process-msg POST Se envía un mensaje al bot y se recibe su respuesta. Se requiere enviar ‘msg’ o ‘question_response’, pero no ambos. En la encuesta inicial, la última respuesta del bot incluye dos cabeceras que permiten conocer los problemas del usuario y su gravedad, como resultado del algoritmo de salud. /conversations GET, POST El método GET devuelve una lista de todas las conversaciones con el bot. El método POST crea una nueva conversación asociada a un usuario. /conversations/{conversation_id} GET, DELETE El método GET devuelve la conversación con el id solicitado o devuelve 404 si no la encuentra. El método DELETE elimina la conversación del id proporcionado. /conversations/user/{user_id} GET Devuelve la lista de conversaciones asociadas al usuario solicitado. /files GET, POST El método GET devuelve la lista de los nombres de los documentos escritos en un idioma concreto. Returns a list of the names written in a specific language. El método POST crea un nuevo fichero. /files/all GET Lista todos los documentos de la base de datos, agrupados por nombre. /files/multi GET, POST El método GET devuelve los documentos solicitados en el idioma marcado en la solicitud o devuelve 404 si no los encuentra. El método POST crea nuevos ficheros. 30 /files/{name} GET, PUT, DELETE El método GET devuelve el documento solicitado por nombre e idioma o devuelve 404 si no lo encuentra. El método PUT actualiza el contenido de un documento dado su nombre e idioma. El método DELETE elimina un documento dado su nombre e idioma. /files/multiple DELETE Elimina el conjunto de documentos utilizando sus nombres y su idioma. /health-data GET, POST El método GET obtiene los resultados de los datos de salud de todos los usuarios. El método POST crea unos resultados de datos de salud. /health-data/user/{user_id} GET Obtiene los resultados de datos de salud de un usuario dado su id. /health-data/{health_data_id} GET, DELETE El método GET obtiene los resultados de datos de salud dado el id de estos datos. El método DELETE elimina los resultados de datos de salud dado su id. /images/{image_id} GET, DELETE El método GET devuelve la imagen del id solicitado o 404 si no la encuentra. El método DELETE elimina la imagen utilizando su id. /images GET, POST El método GET lista todos los id de las imágenes. El método POST crea una imagen. /images/multiple DELETE Elimina un conjunto de imágenes utilizando sus id’s. /notifications-content/secondsurvey/{problem} GET Devuelve una pregunta aleatoria de entre las preguntas categorizadas como segunda encuesta. /notifications-content/generic GET Devuelve una notificación genérica seleccionada aleatoriamente. /login POST Permite iniciar sesión al usuario. /register POST Permite registrar al usuario. /refresh POST Crea un nuevo token válido para el usuario. 31 /users GET, POST El método GET devuelve la lista de todos los usuarios. El método POST crea un nuevo usuario que, en este caso, puede ser administrador, no como en el endpoint /register. /users/{user_id} GET, DELETE El método GET devuelve un usuario por su id. El método POST elimina un usuario por su id. / GET Devuelve el estado del servidor. /version GET Devuelve la version del servidor. /settings GET Devuelve la configuración actual de la API. Requiere ser administrador. /me GET Devuelve el usuario actual. /accept-disclaimer POST Acepta la exención de responsabilidad. /survey-filled POST Indica que la encuesta principal ha sido completada. 4.2.3. Servicios La aplicación se compone de varios servicios, utilizados para realizar las llamadas al servidor o definir variables que son necesarias en varios componentes. Estos servicios son: • AuthService: servicio que gestiona todo lo concerniente a la autorización de los usuarios, como es el inicio de sesión, el registro de nuevos usuarios o el cierre de sesión. Al estar las sesiones gestionadas por un token, también se encarga del refresco de ese token y, en caso necesario, del autologin y del autologout. Este servicio es llamado desde un amplio número de componentes para conocer si hay un usuario loggeado y qué tipo de usuario es. También es utilizado por los guardas y por el interceptor de mensajes al servidor. • DisclaimerService: este servicio está asociado al componente de la exención de responsabilidad y, envía al backend, si el usuario ha aceptado dicha exención. • NotificationService: servicio que gestiona las notificaciones, los distintos tipos que hemos establecido y la gestión de estas cuando un usuario pincha en una notificación. Este servicio solo está disponible para usuarios de Android mediante el APK. • OnboardingService: se encarga de la presentación de la aplicación a un usuario que abre la aplicación por primera vez (tanto en su versión web como en versión móvil). Gestiona que una vez se haya saltado esa presentación, ya no se vuelva a mostrar. • ChatbotService: servicio que gestiona la comunicación con el chatbot, enviando los mensajes al servidor y recibiendo las respuestas. Se almacena el historial del chat mientras que la aplicación no sea cerrada o se cambie el idioma de la aplicación. • FileService: servicio que gestiona los documentos comunicándose con el servidor. Como los métodos son comunes tanto para la parte de salud como para la de vitaminas, 32 los métodos de esta sección son llamados por los servicios relacionados con dichas secciones. También cuenta con métodos específicos que solo puede utilizar el administrador. • HealthService: se encarga de gestionar los documentos de salud disponibles. Almacena la lista de documentos del idioma solicitado y, si se solicita un documento de entre los que se encuentran en la lista, almacena las dos partes de las que se compone el documento mientras no se cierre la aplicación o se cambie de idioma la aplicación. También permite la edición de los documentos, aunque es una función exclusiva de los administradores. • VitaminService: se encarga de gestionar los documentos de vitaminas y sales minerales disponibles y, si se solicita un documento de entre los que se encuentran en la lista, lo almacena mientras no se cierre la aplicación o se cambie de idioma la aplicación. También permite la edición de los documentos, aunque es una función exclusiva de los administradores. En la aplicación se emplean más servicios, son proporcionados por Angular e IONIC Capacitor a través de las diferentes librerías. Los más importantes para esta aplicación son: • Router: otorga funciones que permiten el ruteo en la aplicación. • HttpClient: contiene los métodos utilizadas para conectar con la API: GET, POST, PUT y DELETE. • LocalNotifications: permite controlar las notificaciones, crearlas, eliminarlas y definir el comportamiento de la aplicación cuando ocurre un evento relacionado con las notificaciones: clic, salida de la notificación y borrado de la notificación. • TranslateService: permite utilizar las traducciones dentro de los componentes. 4.2.4. Componentes Los componentes permiten configurar las diferentes vistas con las que se forma la aplicación y definir las variables y los métodos con los que interactuarán los usuarios al utilizarla. Como se mencionaba en la Sección 4.1.1, un componente está formado por un fichero TypeScript, un fichero HTML y un fichero CSS (el fichero dedicado a los test unitarios solo es necesario para la fase de testeo). Es importante entender cómo se comunican entre estos ficheros. El fichero TypeScript tiene un decorador @component en el que se definen tres parámetros: • selector: define al componente en la plantilla HTML. Se utiliza para introducir el componente en otros. Se introduce en las plantillas con la siguiente etiqueta: <selectorName></selectorName>. • templateUrl: indica el PATH al fichero que contiene la plantilla del componente. • styleUrls: indica el PATH de los ficheros de estilos del componente. Se han creado los siguientes componentes: • LoginComponent: componente inicial que se muestra en la aplicación. Asociado al inicio de sesión del usuario, permite comunicación con el componente de registro para usuarios no registrados. Además, si es la primera vez que se lanza la aplicación, se muestra el componente de Onboarding. • LogoutComponent: componente asociado al cierre de sesión de la aplicación. Este componente se introduce dentro del componente de Settings. 39 • coverageReporter: aquí se configura la parte correspondiente al reporte de cobertura de los test, el directorio donde se almacenarán los resultados y el tipo de ficheros que se crearán. Para el programador individual, el tipo de fichero más conveniente mientras va generando los test es html, ya que se puede ver de una manera visual cuál es la cobertura de cada fichero. De cara a la integración continua, el tipo de fichero necesario es lcovonly. • autoWatch: permite habilitar la ejecución de nuevo de los test cada vez que se guarda un fichero del proyecto cuando su valor es true, algo muy útil para comprobar rápidamente los cambios en el código durante la generación de los test unitarios. • browsers: navegadores donde se van a ejecutar los test, el valor que aparece por defecto es Chrome, se ha añadido ChromeHeadlessNoSandbox, que permite la ejecución de los test automáticos para una integración continua, debido a que se trata de un navegador que se ejecuta sin ventana. Para poder ejecutar los test se necesita utilizar el comando ng test, no obstante, si se desea obtener la cobertura de los test se debe añadir el flag --code-coverage. Además, al estar configurado para ejecutar los test automáticos en la integración continua, debemos indicar en que navegador deseamos ejecutar los test, puesto que, en caso contrario, se ejecutarán dos veces, una por cada navegador. Esto se consigue con el flag –browsers, en el caso de querer ejecutar los test y ver en la interfaz web los resultados de los test igualaremos ese flag a Chrome y, en el caso de que no (para la integración continua), lo igualaremos a ChromeHeadlessNoSandbox. De cara a evitar escribir todo el comando cada vez que se desee testear la aplicación, se puede simplificar gracias a la configuración del fichero package.json, en el que podemos configurar entre otros, comandos personalizados. En este proyecto, para ejecutar los test con cobertura en Chrome se ha utilizado el comando npm test. En el caso de la integración continua, se ha utilizado el comando npm run test:prod. En cuanto a la cobertura de los test, se proporcionan 4 parámetros principales que nos aportan información sobre la cobertura del código: • Lines: número de líneas que contiene el fichero. • Statements: similar al número de líneas, no obstante, en una misma línea pueden existir dos statements. • Branches: cada rama indica un posible flujo en la ejecución del fichero. Una declaración de un if abre dos posibles ramas, que se cumpla o que no la condición a estudiar. Será necesario pasar por las dos ramas para completar la cobertura. Hay ocasiones en las que no es necesario testear una rama si, por ejemplo, nunca se va a dar el caso o no se hace nada en caso de no cumplirse la condición. Jasmine permite saltarse esas ramas escribiendo antes de la declaración if: /* istanbul ignore else*/. • Functions: número de funciones del fichero. Además de poder saltar condiciones en la cobertura, de una manera más general se pueden saltar funciones completas o ficheros enteros con la línea: /* istanbul ignore next */. No obstante, no es una buena práctica porque puede dar la falsa sensación de tener el código bien cubierto, 100% de cobertura, cuando realmente no es así. En este proyecto se ha llegado a un 96% de cobertura, dejándose sin cubrir por completo dos ficheros: • app.component.ts: no se ha podido testear el método subscribeWithPriority, utilizada para escuchar el evento del backButton físico 40 y habilitar la posibilidad de ir hacia el menú desde cualquier parte de la aplicación y salir de la aplicación al encontrarnos en el menú. No se ha podido testear por no haber encontrado una forma de comprobar esa subscripción con prioridad. • upload-adapter.model.ts: no se ha podido testear ninguna de las funciones de este fichero, dedicado a la subida de imágenes con el editor de texto proporcionado por CKEditor, por no haber podido replicar una instancia de esta clase de cara a los test para poder comprobar sus métodos. En las siguientes figuras (Figura 23 y Figura 24) se muestra un ejemplo de la salida del comando npm test. Tanto de los propios test como de su cobertura. Figura 23.- Ejemplo de salida de los test en el navegador. Figura 24.- Ejemplo de salida de la cobertura del código en la consola. Además, podemos ver la cobertura fácilmente con el fichero HTML generado, en la Figura 25 podemos ver de manera general la cobertura de todos los directorios y, si vamos pinchando en cada uno, veremos los ficheros que contienen y su cobertura, llegando a observar fragmentos similares a los de la Figura 26, cuando se hace la cobertura (podemos observar en la parte izquierda el número de veces que se ha ejecutado cada línea) y, en la Figura 27, cuando esa parte de código no está cubierta (el callback de la función no se ha llegado a ejecutar). 41 Figura 25.- Cobertura vista con el fichero index.html generado en con los test. Figura 26.- Fragmento de la cobertura del fichero file.component.ts. Figura 27.- Fragmento de la cobertura del fichero app.component.ts. Para terminar la fase de testeo, es importante mencionar la integración continua. En este proyecto se ha configurado en el fichero ./github/workflows/test.yml. En este fichero se configura el momento en el que se realizan los test, en este caso cada vez que se realiza una Pull Request a la rama main. Posteriormente se definen las versiones del entorno en las que se van a ejecutar los test. En este caso se ha decidido realizarla en las tres últimas versiones major disponibles. Finalmente, se establecen todos los pasos a seguir para la ejecución de los test. Comenzando por la configuración del entorno y continuando por el lanzamiento de los test. Este proceso termina con la creación del fichero que muestra el reporte con los resultados y la cobertura de los test, que se realizan con Codecov. 42 4.3.3. Fase de despliegue Una vez la aplicación está terminada y se han superado todos los test. Se puede pasar a la fase de despliegue, en la que pasamos la aplicación al entorno de producción para que pueda ser utilizada por los usuarios finales. Para poder pasar la aplicación de Angular a producción, se va a utilizar el comando ya mencionado en la fase de desarrollo: npm run build-cap:prod. Este comando nos proporcionará los ficheros necesarios para poder desplegar la aplicación en cualquier servidor preparado para páginas web y, además, la actualización de los ficheros en el proyecto de Android. La aplicación se encuentra dentro de un contenedor Docker para ser desplegada. Esto se consigue con el fichero de configuración Dockerfile. Se configuran varias instrucciones con el objetivo de compilar la aplicación en versión de producción. Para construir la imagen de Docker que puede ser desplegada (ha sido desplegada en una Raspberry Pi 4): docker build -t <username>/frontend:<tag>. Esta imagen debe ser publicada en Docker Hub [26]: docker push -t <username>/frontend:<tag>. Como ha sido lanzada en una arquitectura ARM (la arquitectura de la Raspberry Pi), se ha modificado el comando anterior añadiendo los flags: --platform=linux/arm/v7 -- push. Para lanzar el contenedor hay que ejecutar: docker run -dp 80:80 <username>/frontend:<tag>. De cara a obtener la aplicación de Android en su versión de producción deberemos tener en cuenta dos posibilidades: • Compilar directamente a un fichero .apk. • Generar un fichero Android App Bundles (.aab): es un formato de publicación de la aplicación que delega la generación del APK a Google Play. La diferencia con la compilación directa es que Google Play optimiza directamente el APK para cada dispositivo, mejorando su compatibilidad y permitiendo a los usuarios descargas de menor tamaño. Requerirá entregar la firma del desarrollador por separado. En ambos casos hay que generar una firma de desarrollador, para evitar que las aplicaciones de la tienda de Google Play sean anónimas. Para generar esta firma habrá que seguir el siguiente procedimiento: 1. Dentro de Android Studio, en la parte superior, hay que hacer clic en la sección “Build” y dentro del desplegable, seleccionar “Generate Signed Bundle / APK…” (Figura 28). 43 Figura 28.- Desplegable de la sección “Build” seleccionando “Generate Signed Bundle / APK…”. 2. Se abrirá una ventana en la que tendremos que decidir entre las dos opciones de generar la salida del proyecto, seleccionamos la deseada (Figura 29). Figura 29.- Selección del formato de salida del proyecto. 3. Se nos solicitará el lugar donde se encuentra la firma, si no tenemos ninguna, crearemos una nueva haciendo clic en “Create new…”, en este caso completaríamos los campos solicitados para crear la firma. Si ya disponemos de una y, no aparece en el PATH por defecto, seleccionamos “Choose existing…” y buscamos en el sistema de ficheros el lugar donde se almacena la firma (Figura 30). • La única diferencia entre el APK y el Bundle es el campo de exportación de la firma encriptada, ya que en el caso del APK, se introduce en el momento de la compilación y, como ya mencionaba previamente, en el otro caso se hará al ser subida a Google Play. Seleccionaremos el directorio de almacenamiento de la firma. Figura 30.- Generación de la firma. A la izquierda para el APK y a la derecha para el Bundle. 4. Por último, al encontrarnos en producción debemos seleccionar la opción “Release” y, al aceptar, obtendremos nuestra aplicación lista para subir a Google Play (Figura 44 31). En el caso del APK tendremos que seleccionar el tipo de firma (compatible con diferentes versiones de Android). Figura 31.- Selección entre producción y desarrollo. A la izquierda para el APK y a la derecha para el Bundle. 4.4. Estructura de ficheros Se ha seguido la estructura de ficheros proporcionada inicialmente por Angular en la creación del proyecto con las variaciones necesarias para poder implementar todas las funcionalidades que permiten el correcto funcionamiento de la aplicación. La estructura es la siguiente (partiendo del directorio raíz del proyecto): • .github: en este directorio se encuentra la configuración que permite realizar los test automáticamente cuando se realiza un mergeado de una rama en Git. • .vscode: en este directorio se encuentra una configuración para VSCode. • android: en este directorio se encuentra toda la configuración para poder crear el fichero ejecutable en Android. Esta configuración es proporcionada por IONIC excepto algunos cambios mínimos de estilos, imágenes, etc. Necesarios para la personalización de la aplicación. Dentro de este directorio, los ficheros más relevantes se encuentran dentro del directorio app: o build: directorio donde se encuentra el fichero .apk obtenido tras la compilación del proyecto de Android durante la fase de desarrollo. o release: directorio donde se encuentra el fichero .apk obtenido tras la compilación del proyecto de Android durante la fase de producción. o src: directorio que contiene el proyecto de Angular compilado en el subdirectorio assets, el subdirectorio java, que contiene el fichero que controla la ejecución del proyecto de Android y el subdirectorio res, que contiene distintos formatos de colores, iconos y pantallas de lanzamiento de la aplicación para los diferentes tamaños de dispositivos móviles. Además, el directorio contiene el fichero AndroidManifest.xml, que contiene toda la configuración de la aplicación. • ckeditor5-build-classic: directorio que contiene el repositorio del editor de texto utilizado para la creación y edición de ficheros. Dentro del subdirectorio src se puede encontrar el código fuente para personalizar el editor de texto que, al ser compilado, puede ser obtenido el código resultante en el subdirectorio build, donde puede ser copiado para su utilización dentro del directorio src/assets, descrito posteriormente. • coverage: directorio que contiene un único subdirectorio con el nombre del proyecto, donde se almacenan los resultados de las coberturas de código tras las ejecuciones de 45 los test unitarios. El fichero para poder observar de manera sencilla la cobertura es index.html, se puede observar en cualquier navegador. • dist: directorio que contiene un único subdirectorio con el nombre del proyecto, donde se almacena el proyecto una vez ha sido compilado, independientemente de la fase del proyecto (desarrollo o producción). • e2e: directorio que contiene los resultados de la ejecución de los test end-to-end (test dedicados a comprobar la aplicación a nivel usuario y no a nivel de código). No se ha utilizado en este proyecto. • node_modules: directorio que contiene todas las dependencias del proyecto. • src: directorio en el que se realiza el desarrollo del proyecto. Contiene todos los ficheros que serán compilados posteriormente. Estos ficheros siguen la siguiente estructura: o app: directorio que contiene todos los módulos, servicios, clases, componentes, tuberías… del proyecto. o assets: directorio que contiene recursos necesarios para el correcto funcionamiento de la aplicación, entre ellos, el editor de texto de CKEditor, imágenes y traducciones en los idiomas disponibles. o environments: directorio que contiene las configuraciones de entorno de desarrollo y de producción. o .htcaccess: fichero que permite cargar la página con cualquier path o recargarla, debido a que el path en Angular no apunta a un fichero, sino a un componente. o favicon.ico: icono de la aplicación. Se puede observar en la pestaña del navegador. o index.html: fichero que contiene el encabezado del código HTML de la aplicación y lo configura. o main.ts: fichero que contiene la configuración global del proyecto en TypeScript. o polyfills.ts: fichero para hacer compatible la aplicación con los distintos navegadores. o styles.css: fichero CSS que contiene variables globales de estilos para todo el proyecto. o test.ts: fichero TypeScript requerido para la ejecución de todos los test. • .browserslistrc: fichero que contiene la lista de navegadores para los que debe funcionar. • .editorconfig: configuración para el entorno que se utilice, estableciendo, entre otros, el formato de los caracteres. • .eslintrc.json: fichero que configura las normas de estilo del código. • .gitignore: fichero utilizado para que los ficheros incluidos en este no sean incluidos en el repositorio. • .gitmodules: fichero que contiene el submódulo de Git utilizado para el editor de texto. • Dockerfile; fichero que configura el despliegue de la aplicación en un contenedor de Docker. • README.md: fichero escrito en Markdown en el que se explican los pasos a realizar para configurar el proyecto. • angular.json: fichero que contiene la configuración de Angular. 46 • capacitor.config.json: fichero que contiene la configuración de IONIC Capacitor. • karma.conf.js: fichero que contiene la configuración de los test. • package-lock.json: fichero que especifica las dependencias del fichero package.json. • package.json: fichero que contiene todas las dependencias que son requeridas para la configuración del proyecto. • tsconfig.app.json, tsconfig.json y tsconfig.spec.json: ficheros de configuración de TypeScript. 4.5. Implementación 4.5.1. Comunicación con la API Angular, a través de la librería http, permite utilizar el servicio HttpClient [17] para lanzar llamadas al backend. Se ha empleado el patrón CRUD (Create, Read, Update, Delete), para lo cual, se han utilizado los métodos que permiten hacer las llamadas GET, POST, PUT y DELETE, cuyo nombre es homónimo con la función que realizan. En función del tipo de endpoint al que se dirija la llamada, el backend requiere o no la autenticación por parte del cliente. Esta autenticación se realiza mediante un token generado en el backend utilizando JWT (JSON Web Tokens) [27] y que es enviado como respuesta al iniciar sesión junto con el tiempo de validez del token [5]. El frontend almacena el token mientras que el token sea válido, esto permite controlar la duración de la sesión también en el frontend y, cerrar la sesión automáticamente si el tiempo de validez se ha agotado. Para evitar que a un usuario se le cierre la sesión mientras utiliza la aplicación, se solicita un nuevo token con un nuevo tiempo de validez. Además, se utiliza el interceptor con el objetivo de capturar la petición HTTP antes de ser emitida e introducir una cabecera con el token y que dicha petición permita autenticar al usuario en el backend. Este interceptor se utiliza siempre que haya un usuario con sesión iniciada, en caso contrario, no se envía la cabecera. Esto ocurrirá, por ejemplo, al crearse una cuenta de usuario o al iniciar sesión. En la Figura 32 podemos ver un esquema explicativo de este suceso. Figura 32.- Proceso de obtención y uso del token de autenticación. 4.5.2. Editor de texto El editor de texto se ha empleado para que el administrador pueda crear los documentos de salud que se encuentran en la aplicación. Este editor se ha generado a partir de una base proporcionada por CKEditor, añadiendo los plugins deseados para obtener el editor ideal. 47 Los plugins que se han añadido han sido: • Negrita. • Cursiva. • Adición y modificación de imágenes. • Añadir títulos. • Variación del tamaño de letra. • Subrayado. • Justificación del texto. • Centrado del texto. • Links. • Listas. • Listas numéricas. • Youtube. Este editor es compilado y añadido como un recurso en el directorio src/assets/ckeditor. De manera específica, para la subida de imágenes ha sido necesario añadir el fichero uploadadapter.model.ts, con un código proporcionado por CKEditor, que ha sido modificado para adecuarlo a la aplicación. Permitiendo así que al añadir las imágenes al editor se guarden también en el backend. 4.5.3. Traducciones Angular ofrece muchas facilidades para implementar las traducciones. Es suficiente con añadir en el fichero app.module.ts dentro de imports en el decorador @NgModule las siguientes líneas: TranslateModule.forRoot({ loader: { provide: TranslateLoader, useFactory: httpTranslateLoader, deps: [HttpClient] } }) Dentro del mismo fichero hay que añadir el siguiente método: export function httpTranslateLoader(http: HttpClient) { return new TranslateHttpLoader(http, './assets/i18n/', '.json'); } En esas líneas se ha definido el PATH del directorio donde se van a encontrar los ficheros con las traducciones. En ese directorio hay que crear un fichero en formato JSON por cada idioma del que se desea traducción, tres para esta aplicación: español, inglés y francés. Para poder asignar las traducciones en los lugares deseados hay que crear los identificadores de las traducciones. Por cada frase diferente a traducir habrá un identificador. Lo habitual es incluir estos identificadores en las plantillas HTML y aplicar la tubería translate para que aparezca traducida en cada idioma. Voy a mostrar un ejemplo de traducción. 48 • En la plantilla HTML: {{'Logout'|translate}}. • En el fichero es.json: "Logout": "Cerrar sesión". • En el fichero en.json: "Logout": "Log out". • En el fichero fr.json: "Logout": "Se déconnecter". Al arrancar la aplicación se selecciona el idioma del navegador/dispositivo en el que se utiliza la aplicación, en caso de no ser ninguno de los disponibles se selecciona el inglés. 4.5.4. Notificaciones En esta aplicación se utilizan las notificaciones locales por dos motivos: • Invitar al usuario a volver a la aplicación. • Recordar al usuario a seguir los consejos de la aplicación para conseguir alcanzar el máximo potencial. Como consecuencia, existen dos tipos de implementaciones de estas notificaciones. Por un lado, las notificaciones que invitan al usuario a volver a la aplicación las denominaré “Notificaciones genéricas” o solo “genéricas” y, las otras notificaciones las llamaré “Notificaciones de salud” para referirme en sucesivas ocasiones. Todas las notificaciones están gestionadas desde el servicio NotificationService [19], tal y como se mencionaba en el apartado 4.2.3 y, en última instancia se utiliza el servicio proporcionado por IONIC para la utilización de las notificaciones: LocalNotifications. La diferencia se encuentra en que las notificaciones genéricas son programadas desde DisplayComponent y, las notificaciones de salud desde ChatComponent. Al tratarse de notificaciones a nivel local, estas solo pueden ser programadas cuando la aplicación está siendo utilizada, es por ello, que todas las notificaciones se programan con repetición, es decir, la notificación aparecerá periódicamente (con el periodo marcado inicialmente) hasta que se pinche en la notificación y se entre de nuevo en la aplicación. En el caso de las notificaciones generales, una vez se entra a la aplicación, en la página /home, se programa una notificación llamando al backend al endpoint /notificationscontent/generic, que permite obtener un mensaje de entre los disponibles para ese tipo de notificación. Cada vez que se hace clic en una notificación de este tipo, se vuelve a programar una nueva y se navega de vuelta al /home. Por otro lado, las notificaciones de salud son programadas por primera vez cuando se completa la encuesta principal si tenemos algún problema. En este caso, se hace una llamada al backend al endpoint /notifications-content/second-survey/{problem}, que permite obtener un mensaje con una de las preguntas relacionadas con el problema de salud {problem}. Finalmente, se programa la notificación con una frecuencia mayor o menor en función de la gravedad del problema (relación directa entre gravedad del problema y frecuencia de notificación). Una vez el usuario hace clic en la notificación de salud, se programa de nuevo otra notificación del mismo tipo con una pregunta nueva, con la misma frecuencia que la anterior. A continuación, se redirige al usuario a la zona de chat y se le hace la pregunta que aparecía en el mensaje de la notificación. Se produce una interacción con el backend en la que se intercambian la respuesta a la pregunta y el consejo relacionado con la pregunta. 55 Figura 43.-Cierre de sesión. 5.1.5. Consultar documentos Para poder consultar documentos deberemos ir a las secciones habilitadas para esta labor, “Salud” y “Vits&Mins”, al acceder a una de estas secciones, veremos los documentos disponibles en dicha sección, pudiendo seleccionar cualquiera de ellos (Figura 44). Figura 44.- Lista de documentos de salud (izquierda) y lista de documentos de vits&mins (derecha) Al seleccionar, podremos ver el documento, en el caso de “Vits&Mins”, veremos el documento directamente (Figura 45). En el caso de “Salud”, deberemos pinchar en uno de los botones: “Entender” o “Actuar”, para elegir cuál de las secciones del documento queremos leer (Figura 46). 56 Figura 45.- Documento de vitaminas. Figura 46.- Documento de salud. 5.1.6. Contestar pregunta de notificación Una vez recibimos una notificación (Figura 47) que contiene una pregunta de salud, al pinchar en ella, se abrirá la aplicación, iniciaremos sesión en el caso que sea necesario y podremos responder a dicha pregunta en la sección del chatbot (Figura 48). Figura 47.- Notificación con pregunta. 57 Figura 48.- Pregunta de la notificación. Obtendremos un consejo del bot en función de nuestra respuesta (Figura 49). Figura 49.- Respuesta del chatbot ante respuesta afirmativa de la pregunta. 5.1.7. Cambiar idioma Para cerrar sesión, deberemos ir a la sección de “Perfil”, una vez allí, hacemos clic en el idioma deseado entre los disponibles (Figura 50). 58 Figura 50.- Cambiar idioma de la aplicación. 5.1.8. Hablar con el bot Para hablar con el bot, tan solo deberemos acceder a la sección de “Chat” y escribir en el espacio habilitado para ello (Figura 51). Figura 51.- Posible conversación con el chatbot. 5.2. Manual de administrador 5.2.1. Requisitos Los requisitos son idénticos a los del usuario básico, con la excepción de que es necesaria una cuenta de administrador para poder acceder a las funcionalidades específicas de gestión de documentos. Un administrador puede realizar todas las operaciones descritas en el manual de usuario básico, excepto el registro, ya que un administrador no puede registrarse como administrador desde la aplicación. 59 5.2.2. Gestionar documentos 5.2.2.1. Modificar documentos Para modificar documentos hay que repetir los pasos descritos en la sección 5.1.5 para acceder al documento que se desea modificar. Una vez en el documento, solo hay que pinchar en el lapicero que aparece para editar el documento (Figura 52). Figura 52.- Lapicero para editar los documentos. Una vez editado, si pulsamos en “Guardar”, se guardará la modificación (Figura 53). Figura 53.- Guardar documento editado. También se puede acceder a los documentos desde la sección de gestionar documentos, en la que aparece el listado de todos los documentos disponibles sea cual sea el idioma en el que se encuentren. Para acceder a esta sección, tan solo hay que pulsar el botón que aparece en las secciones de “Salud” y “Vits&Mins”, que dice “Gestionar Documentos” (Figura 54). 60 Figura 54.- Sección de “Salud” para administradores. Una vez dentro, aparecerán todos los documentos disponibles (Figura 55). Figura 55.- Documentos disponibles en la aplicación. Pinchando en uno de ellos, podremos ver los idiomas en los que se encuentra disponible, pinchando en el idioma del respectivo documento, navegaremos a ver el documento y podremos modificarlo de la misma manera que se explica anteriormente (Figura 56). 61 Figura 56.- Documentos disponibles por idiomas. 5.2.2.2. Crear documentos Para crear documentos hay que ir a la sección de gestionar documentos siguiendo el mismo proceso que se menciona en la sección anterior. Una vez allí, seleccionamos el botón que dice “Crear Fichero” (Figura 57). Figura 57.- Botón de crear documento. Ahora tenemos que rellenar los campos que van a definir el documento (Figura 58): • Nombre: identificador para agrupar aquellos documentos en distintos idiomas que hacen referencia a la misma información. • Título: nombre que aparecerá encabezando el documento en la aplicación, en el idioma para el que se prepara el documento. • Idioma: elegir entre los disponibles. Figura 58.- Campos a rellenar al crear un documento. 62 No se pueden crear dos documentos con el mismo nombre e idioma. Si hemos seleccionado que se trata de un documento de salud (Figura 59), tendremos que rellenar dos secciones (Entender y Actuar), pasando de una sección a otra haciendo clic en “Siguiente”, en caso contrario, para las vitaminas solo deberemos completar una única sección (Figura 60). Para guardar el documento en el servidor, pulsaremos en “Crear”. Figura 59.- Creando un documento de salud. Figura 60.- Creando un documento de vitaminas. 5.2.2.3. Eliminar documentos Por último, el proceso de eliminación de documentos. Como ya hemos realizado anteriormente, accederemos a la sección de gestión de documentos. Una vez allí, pincharemos en el botón que dice “Eliminar Documentos” (Figura 61). 63 Figura 61.- Botón para eliminar documentos. Aparecerán unos cuadrados para chequear los documentos que se desean eliminar. Se pueden elegir tanto documentos individuales como todos los documentos de un mismo nombre, el único límite es el número de documentos disponibles en ese momento. Para confirmar la eliminación pulsaremos el botón que dice “Confirmar Eliminación” (Figura 62). Figura 62.- Eliminación de documentos. 64 6. Conclusiones y líneas futuras 6.1. Conclusiones El impacto económico consecuencia de la falta de salud de los trabajadores requiere de la toma de medidas para revertir la situación, tanto por los propios trabajadores, que se encontrarán más felices por tener una mejor salud, como por la economía, ya que un trabajador más sano será más probable que alcance su máximo potencial y obtendrá un mayor rendimiento. Esto supondrá una mayor rentabilidad y una mejora económica. Se ha observado que optar por el desarrollo aplicaciones híbridas permite obtener las ventajas de las aplicaciones web, como son la sencillez de su programación y la capacidad multiplataforma. Siendo en este último aspecto incluso mejor las híbridas, ya que evitan posibles incompatibilidades con ciertos navegadores. Además, se suman las ventajas de las aplicaciones nativas, como son la gran personalización de la interfaz de usuario completa y la capacidad de control sobre todas las características del dispositivo. Añadiendo que las desventajas de las aplicaciones web y de las aplicaciones nativas son eliminadas en las aplicaciones híbridas, hacen de estas la alternativa perfecta para el desarrollo de aplicaciones móviles. Con el objetivo de ayudar a los trabajadores a alcanzar su máximo potencial nació, en la empresa Ingage, la idea diseñar una aplicación atractiva, fácil de usar y que, mediante el uso de un chatbot, ofrecer un servicio completamente personalizado y adaptado a las necesidades de los trabajadores. En este Trabajo de Fin de Grado se ha abordado la parte de la aplicación correspondiente con el diseño y desarrollo de la parte del frontend. Se han elaborado todos los requisitos en conjunto con el equipo en las reuniones iniciales y, el posterior desarrollo, de manera concurrente con Diego Alloza González, quien ha sido el encargado de elaborar el backend [5]. La aplicación fue pensada para diferenciar claramente la parte del cliente de la parte del servidor y, como consecuencia, ha sido necesaria la elaboración de una API robusta que permitiera la transmisión de información entre las dos partes. Para el desarrollo de la aplicación se utilizó el framework de Angular, que ha permitido crear una SPA. Con esta SPA se han evitado llamadas innecesarias al backend, por estar todos los recursos de la aplicación ya cargados en la solicitud inicial. El uso de Angular junto con IONIC Capacitor ha habilitado la posibilidad de obtención de una aplicación híbrida fácilmente personalizable. Además, gracias a haber realizado este trabajo junto con las prácticas de empresa, han sido tenidas en cuenta prácticas habituales de las empresas de desarrollo software. Como ejemplo, la elaboración de los test unitarios que han permitido comprobar si el código tenía el comportamiento esperado. En conjunto con la integración continua (otra práctica habitual en las empresas), la elaboración iterativa e incremental seguida al utilizar Scrum ha resultado más sencilla porque cada vez que se ha añadido una nueva funcionalidad se ha podido testear toda la aplicación y comprobar que tanto las nuevas funcionalidades como las antiguas funcionaran y obtener el correspondiente reporte. Como último ejemplo de práctica habitual en las empresas, el despliegue de la aplicación en contenedores que envuelvan las diferentes partes de la aplicación, facilitándolo en gran medida. El empleo de notificaciones también ha sido una parte importante de la aplicación, porque es la que invita al usuario a volver a la aplicación cuando este no la está utilizando. La conexión de un evento externo a la aplicación (notificación) con el resto de la aplicación ha sido complicado por la falta de documentación disponible y, por la dificultad del testeo de las propias notificaciones,