Sistema de tele-rehabilitación a domicilio con chatbot y microordenador de bajo coste

1 UNIVERSIDAD DE VALLADOLID E.T.S.I. TELECOMUNICACIÓN TRABAJO FIN DE GRADO GRADO EN INGENIERÍA DE TECNOLOGÍAS ESPECÍFICAS DE TELECOMUNICACIÓN. MENCIÓN EN TELEMÁTICA Sistema de tele-rehabilitación a domicilio con chatbot y microordenador de bajo coste Autor: D. Javier Delgado Rodríguez Tutor: D. Mario Martínez Zarzuela y Dña. Cristina Simón Martínez Valladolid, 23 de agosto de 2021 2 Agradecimientos En primer lugar, a Mario y a Cristina, agradecer el esfuerzo empleado y la oportunidad que me habéis dado de participar en este bonito proyecto. Espero haberos devuelto esa confianza con el esfuerzo empleado en desarrollar la aplicación. Sin olvidarme de Beatriz, que gracias a ella he obtenido el punto de vista clínico necesario para el desarrollo del proyecto. Como punto y final a esta etapa, agradecer a mis padres y a mi hermana el esfuerzo y confianza puesta en mí desde que comencé este viaje hace cinco años, sin vosotros no hubiera llegado a donde estoy. Y a Estela. Por tu apoyo incondicional durante estos años. Lo mereces todo y más. 3 TÍTULO: Sistema de tele-rehabilitación a domicilio con chatbot y microordenador de bajo coste AUTOR: D. Javier Delgado Rodríguez TUTOR: D. Mario Martínez Zarzuela Dña. Cristina Simón Martínez DEPARTAMENTO: Departamento de Teoría de la Señal y Comunicaciones e Ingeniería Telemática TRIBUNAL PRESIDENTE: MÍRIAM ANTÓN RODRÍGUEZ VOCAL: DAVID GONZÁLEZ ORTEGA SECRETARIO MARIO MARTÍNEZ ZARZUELA SUPLENTE FRANCISCO JAVIER DÍEZ PERNAS SUPLENTE CARLOS GÓMEZ PEÑA FECHA: CALIFICACIÓN: 4 Resumen El trabajo desarrollado ha tenido como objetivo encontrar un sistema simple, de bajo coste y organizado que permita a los pacientes rehabilitarse desde casa manteniendo el sentimiento de cercanía por parte de los terapeutas en las rehabilitaciones presenciales. Para cumplir con el objetivo se ha desarrollado un sistema que hace uso de tecnologías de bajo coste, como la Raspberry Pi, para el desarrollo de un bot en Telegram haciendo uso de la Application Programming Interfaces (API) de Telegram y el desarrollo de una aplicación web, con la que se consigue crear un canal de comunicación entre terapeuta-paciente. Se busca mantener los mismos aspectos sociales y la misma motivación que a través de las rehabilitaciones presenciales. Durante los próximos apartados de este documento, se podrán ver detallados cada uno de los pasos que se han seguido durante el desarrollo de este sistema hasta que se ha conseguido el resultado final. Finalmente, se incluyen unas breves conclusiones y las diferentes líneas de trabajo futuro. Palabras clave: tele-rehabilitación, framework, computación en la nube, aplicación web, bot. Abstract The project carried out has aimed to find a simple, low-cost and organized system that allows patients to rehabilitate from home while maintaining the feeling of closeness on the part of therapists in face-to-face rehabilitation. To reach the objective, a system has been developed that makes use of low-cost technologies, such as the Raspberry Pi, for the development of a bot in Telegram using the Telegram API and the development of a web application, with which it is possible to create a communication channel between therapist-patient. It seeks to keep the same social aspects and the same motivation as through face-to-face rehabilitation. During the next sections of this document, each of the steps that have been followed during the development of this system will be detailed until the final result has been achieved. Finally, some brief conclusions and the different lines of future work are included. Keywords: tele-rehabilitation, framework, cloud computing, web application, bot. 5 Abreviaturas AWS: Amazon Web Services API: Application Programming Interfaces BBDD: Bases de datos MTV: Model Template View 6 Índice de contenido 1. Introducción .................................................................................................................................................. 10 1.1. Contexto y motivación .............................................................................................................................................. 10 1.2. Objetivos ........................................................................................................................................................................ 11 1.3. Fases y métodos .......................................................................................................................................................... 12 1.4. Recursos hardware y software ............................................................................................................................. 15 2. Estado del arte .............................................................................................................................................. 16 2.1. Trabajos previos ......................................................................................................................................................... 16 2.2. Revisión de tecnologías............................................................................................................................................ 17 2.2.1. Desarrollo web - Frameworks .................................................................................................................................... 17 2.2.2. Sistemas de chatbot ......................................................................................................................................................... 20 2.2.3. Computación en la nube ................................................................................................................................................ 25 2.2.4. Microordenadores ............................................................................................................................................................ 33 2.2.5. Sistemas de gestión de bases de datos .................................................................................................................... 34 2.2.6. Servidores Web .................................................................................................................................................................. 37 3. Requisitos y sistema desarrollado ........................................................................................................ 42 3.1. Requisitos Funcionales .......................................................................................................................................... 42 3.2. Requisitos No funcionales .................................................................................................................................... 42 3.3. Sistema desarrollado - diseño .............................................................................................................................. 43 3.3.1. Estructura del sistema ................................................................................................................................................... 43 4. Despliegue ..................................................................................................................................................... 63 4.1. Amazon EC2 ................................................................................................................................................................ 64 4.2. Bucket S3 ..................................................................................................................................................................... 68 4.3. Raspberry Pi 4 ........................................................................................................................................................... 69 4.4. Pruebas de funcionamiento ................................................................................................................................. 70 5. Conclusiones y líneas futuras ................................................................................................................. 72 6. Referencias bibliográficas ........................................................................................................................ 75 Anexo 1 - Configuración de Telegram para el uso del bot .................................................................................. 77 Anexo 2 – Manual uso de aplicación web .................................................................................................................. 81 Anexo 3 – Presupuesto total del proyecto ................................................................................................................. 91 7 Í ndice de ima genes Imagen 1 . Estructura del Modelo en Cascada en la versión de Winston W. Royce. ............ 12 Imagen 2. Diferencias entre el modelo iterativo y el modelo iterativo e incremental. ....... 13 Imagen 3. Estructura del modelo en espiral. .......................................................................... 14 Imagen 4. Comparativa Django y Laravel (9). ........................................................................ 18 Imagen 5. Esquema de la arquitectura MTV. .......................................................................... 19 Imagen 6. Opciones disponibles en el BotFather (12). .......................................................... 21 Imagen 7. Funcionamiento básico de un bot de Telegram. ................................................... 22 Imagen 8. Interfaz de Chatfuel (13). ........................................................................................ 22 Imagen 9. Tarjeta que conforma el flujo de un chatbot en Chatfuel (13). ............................ 23 Imagen 10. Comparativa entre una empresa tradicional y una empresa que hace uso del cloud computing (15). ............................................................................................................... 26 Imagen 11. Modelos de funcionamiento de la computación en la nube (15). ..................... 29 Imagen 12. Gartner: Evaluación de los proveedores de servicios según su infraestructura y los servicios que ofrecen, en 2020 (18). .................................................................................. 31 Imagen 13. Regiones en las que se sitúan los centros de datos de Amazon Web (17). ...... 31 Imagen 15. Modelo de base de datos orientado a objetos (23). ............................................ 34 Imagen 17. Modelo de base de datos de forma jerarquizada (23). ....................................... 35 Imagen 19. Ejemplo de estructura básica del paradigma cliente-servidor en aplicaciones web (26). ..................................................................................................................................... 38 Imagen 20. Comparativa entre Apache y Nginx en cuanto a la capacidad del servidor frente a grandes niveles de concurrencia (29). .................................................................................. 40 Imagen 21. Comparativa de los servidores web más populares entre 2009 y 2018 (Netcraft) (30). ............................................................................................................................................. 40 Imagen 24. Arquitectura de Django. ........................................................................................ 44 Imagen 25. Página principal de aplicación web. ..................................................................... 45 Imagen 26. Página de pacientes de la aplicación web. ........................................................... 46 Imagen 27. Página de información detallada de los pacientes en la aplicación web. ......... 46 Imagen 28. Página de ejercicios de la aplicación web. ........................................................... 47 Imagen 29. Página de sesiones de la aplicación web. ............................................................ 47 Imagen 30. Panel de administración de la aplicación web. ................................................... 48 Imagen 31. Esquema completo de la base de datos. .............................................................. 58 Imagen 32. Diagrama de flujo cuando el paciente comienza los ejercicios. ......................... 60 Imagen 33. Diagrama de flujo cuando el paciente actualiza el formulario. ......................... 61 Imagen 34. Mensaje de respuesta del bot cuando el paciente solicita instrucciones de la sesión. ......................................................................................................................................... 62 Imagen 35. Mensaje de respuesta del bot cuando el paciente solicita instrucciones de uso del bot.......................................................................................................................................... 62 Imagen 36. Arquitectura del sistema desplegado. ................................................................. 63 Imagen 37. Ejemplo de descarga de Telegram en sistema operativo iOS. ........................... 77 Imagen 38. Configuración de teléfono en Telegram. .............................................................. 77 Imagen 39. Confirmación del teléfono a través de un SMS. ................................................... 77 Imagen 40. Configuración de privacidad de número de teléfono en Telegram. .................. 78 Imagen 41. Configuración de usuario para hacer uso del bot. .............................................. 79 Imagen 42. Búsqueda por nombre del bot en iOS. ................................................................. 79 Imagen 43. Búsqueda por nombre del bot en Android. ......................................................... 79 8 Imagen 44. Apariencia del bot con el que se comunican los pacientes. ............................... 80 Imagen 45. Página principal de la aplicación web. ................................................................. 81 Imagen 46. Botón que nos permite añadir un nuevo paciente. ............................................. 82 Imagen 47. Panel de administración en el que damos de alta al paciente. .......................... 82 Imagen 48. Dos formas de acceder al panel de administración. ........................................... 83 Imagen 49. Ventana de inicio de sesión en el panel de administración. .............................. 83 Imagen 50. Acceso a las secciones de Ejercicios, Pacientes y Sesiones desde el panel de administración. .......................................................................................................................... 84 Imagen 51. Botón que nos permite editar los datos de un paciente. .................................... 85 Imagen 52. Segunda opción de editar los datos de un paciente. ........................................... 85 Imagen 53. Acceso a los datos de un paciente para cambiar su estado de visible a oculto. 86 Imagen 54. Casilla que se debe desmarcar para ocultar a un paciente. ............................... 87 Imagen 55. Botón desde el que podemos ver los pacientes ocultos que tenemos. ............. 87 Imagen 56. Página que muestra un listado de los pacientes ocultos. ................................... 88 Imagen 57. Información detallada que se muestra de cada uno de los pacientes. .............. 88 Imagen 58. Información de las sesiones dividas en tres secciones: resumen, detallado e informe. ....................................................................................................................................... 89 Imagen 59. Información de los ejercicios dividos en dos secciones: resumen y detallado. 90 9 Í ndice de tablas Tabla 1. Amenazas y riesgos de la computación en la nube (15). ..................................................... 30 Tabla 2. Clasificación de proveedores de cómputo en la nube (21). .................................................. 33 Tabla 3. Diagnósticos .............................................................................................................................. 48 Tabla 4. Objetivo terapéutico ................................................................................................................. 49 Tabla 5. MACS .......................................................................................................................................... 49 Tabla 6. GMFCS ....................................................................................................................................... 49 Tabla 7. Calificaciones ............................................................................................................................ 49 Tabla 8. Edad ........................................................................................................................................... 50 Tabla 9. Extremidades ............................................................................................................................ 50 Tabla 10. Lateralidad .............................................................................................................................. 50 Tabla 11. Posición ................................................................................................................................... 51 Tabla 12. PCI............................................................................................................................................ 51 Tabla 13. Ejercicios ................................................................................................................................. 52 Tabla 14. Terapeutas .............................................................................................................................. 52 Tabla 15. Pacientes ................................................................................................................................. 53 Tabla 16. Sesiones ................................................................................................................................... 54 Tabla 17. Sesiones Ejercicios ................................................................................................................. 54 Tabla 18. Ejercicios realizados .............................................................................................................. 55 Tabla 19. Registro de las sesiones ......................................................................................................... 56 Tabla 20. Formulario de pacientes ........................................................................................................ 56 Tabla 21. Valoración de los pacientes ................................................................................................... 57 16 2. Estado del arte 2.1. Trabajos previos Antes de centrarnos en nuestro proyecto es interesante hacer un breve repaso de tecnologías ya existentes que se aplican o se han aplicado para la tele-rehabilitación y cuáles han sido sus resultados. Para ello vamos a revisar varios estudios que se centran en la rehabilitación domiciliaria a través del uso de diferentes tecnologías y metodologías. En uno de los estudios revisados, detallan los beneficios de la realidad virtual aplicada a la tele-rehabilitación, con el fin de mejorar la movilidad y el equilibrio de pacientes que han sufrido un accidente cerebrovascular. En este estudio participaron seis pacientes durante 3 semanas, dos en la clínica y una en casa. El proyecto consistía en un bastidor de bipedestación para el entrenamiento del equilibrio. Se configuraban diferentes escenarios en el que el paciente iba equilibrando su cuerpo en función de los obstáculos que iban apareciendo en las diferentes escenas que se le iban presentando en la pantalla. Los resultados obtenidos en este estudio reflejaban que el uso de la realidad virtual en la telerehabilitación mejoraba el equilibrio y la postura en estos pacientes. Se concluyó que el entrenamiento en el hogar tenía un resultado similar al que se obtenía en la clínica, pero este nuevo enfoque permite reducir las visitas a la clínica, aporta mayor autonomía al paciente, reduce costes y permite tratar a más pacientes simultáneamente (6). Una prueba de otro sistema de tele-rehabilitación es lo que podemos observar en el siguiente estudio. En el estudio participaron 12 pacientes que habían sufrido un accidente cerebrovascular. Cada uno de ellos recibió durante 28 días un programa de telerehabilitación en su hogar basado en diferentes juegos y ejercicios. Todos ellos se basaban en actividades dinámicas y enfocadas en los principios de plasticidad y el aprendizaje. El programa de rehabilitación consistía en la realización de los ejercicios que previamente el terapeuta había seleccionado de forma personalizada. Dentro de la hora programada para el entrenamiento además de realizar las actividades, cada tres veces por semana se hacían videoconferencias con los terapeutas en las que se realizaba un seguimiento con el paciente de cada una de las actividades realizadas. El sistema se componía de una mesa, una silla, un ordenador, una cámara web interna, un módem USB inalámbrico, un brazalete de presión arterial y una alfombrilla USB con interruptores. Este estudio evidencia los beneficios de mantener los programas de rehabilitación también desde el hogar de los pacientes (1). En este siguiente estudio se describe la inclusión de una Nintendo Wii en el programa de rehabilitación en casa en el que participaron niños entre 7 y 12 años con parálisis cerebral hemipléjica espástica. El uso de la Wii aportaba a este tipo de pacientes la motivación necesaria para completar el entrenamiento, aprovechando este hecho para, a su vez, aumentar la función motora de los pacientes. El entrenamiento con la Wii ha resultado ser eficaz para mejorar las capacidades motoras en estos pacientes y podría ser un punto de partida para la inclusión de videojuegos como terapia. Sin embargo se requieren más investigaciones para reafirmar y completar la aplicación de este tipo de rehabilitación (7). 17 De estos estudios se puede observar la necesidad de implementar programas de rehabilitación adaptados a cada situación y a las necesidades de los pacientes. Además, resulta necesario adaptarse a los cambios sociales y evolucionar con los avances tecnológicos y los beneficios que nos pueden aportar. Sin embargo, son muchos los estudios que se tienen que realizar para determinar que patologías clínicas se pueden beneficiar de ello. 2.2. Revisión de tecnologías En este apartado haremos una revisión de la evolución de las tecnologías usadas para el desarrollo de este sistema a lo largo de los años. Nos centraremos en las herramientas que hemos usado en este proyecto haciendo hincapié en las características principales que las diferencian de las demás. 2.2.1. Desarrollo web - Frameworks A lo largo de los últimos 30 años el desarrollo web ha experimentado una gran revolución en todos los aspectos. Las primeras páginas web de las que tenemos conocimiento nacieron en la década de los años 90. Por aquel entonces, las páginas tenían una pantalla negra con colores monocromáticos. En realidad, fue en el año 1991 cuando se publicó la primera página web (WWW) de la mano de uno de los considerados padres de la Web, Tim Berners- Lee. En la actualidad el diseño web se encuentra en auge, ya no es necesario tener conocimientos avanzados en diseño web, sino que disponemos de herramientas que nos permiten crear sitios web de una forma increíblemente sencilla. Si es verdad que con el paso del tiempo los requerimientos de las páginas web van creciendo y con ello las herramientas que tenemos a nuestra disposición. Cuando hablamos de páginas web podemos dividirlas en dos partes, el front-end y el backend. Cuando hablamos de front-end nos referimos a la parte con las que los usuarios interactuamos. La estética y la disposición de los elementos en una página web es muy importante, ya que debe de ser atractiva para los usuarios. Y no solo eso, además debe de tener algunos requisitos esenciales como la responsividad, usabilidad y accesibilidad. En muchos casos no es necesario nada más en una página web, pero en muchos otros necesitamos dotar a la página de “inteligencia”. Es en esta parte donde entra en juego el back-end. El back-end es una parte del desarrollo web que actúa de forma transparente a los usuarios. Gracias a ello podemos crear aplicaciones web que van más allá de mostrar la información organizada. La existencia de muchos frameworks como Django, Laravel o Flask posibilita crear aplicaciones web de cualquier tipo como, por ejemplo, aplicaciones web médicas, aplicaciones web de compraventa, etc. En nuestro proyecto ha sido necesario el uso de uno de estos frameworks, es el caso de Django. El proyecto se divide en varias partes, una de ellas es la parte de la aplicación web. Para esta parte se ha creado una aplicación web que por un lado tiene la parte informativa en la que se quiere exponer el trabajo que estamos desarrollando y por el otro lado se encuentra la parte de aplicación como tal, que está configurada únicamente para usuarios con acceso a ella. 18 Elección del framework para el desarrollo de la aplicación web La necesidad de crear una página web con inteligencia, ha provocado el estudio de las diferentes herramientas que permiten crear sitios web dinámicos, escalables y potenciales. He llevado a cabo una breve comparación entre las herramientas más usadas actualmente para el desarrollo web. Realmente muchas de ellas son muy similares, arquitecturas que varían levemente unas de otras, pero con un objetivo final conjunto que se trata de crear sitios web seguros y de una forma rápida (8). Por comentar los aspectos más relevantes de los frameworks más usados he querido listar los beneficios que nos ofrecen estas herramientas (8): • Creación rápida de una página web • Seguridad y fiabilidad • Escalabilidad • Rendimiento Si bien es cierto, no todas usan el mismo lenguaje y eso afecta en muchas ocasiones al rendimiento, rapidez o a la fiabilidad. Por ello antes de elegir una u otra es importante determinar la funcionalidad del sitio web y sus necesidades. Por ejemplo, Django se suele destinar a aplicaciones que requieran un cierto grado de seguridad, ya que el sistema de autenticación de usuarios del que dispone es más potente que otras (8). Por otro lado, Laravel funciona muy bien cuando se quiere crear un sitio web para la transmisión de video en directo o comunidades en línea. La comparación entre Django y Lavarel, se puede observar en la imagen 4. Aunque Laravel lidera el número de sitios web en los que se hace uso de ella, su tendencia está decreciendo en comparación con Django. Se debe en gran parte a que Django usa un lenguaje de alto nivel como es Python, haciendo hincapié en la búsqueda del desarrollo rápido y el diseño limpio. Además, con Python obtenemos una mayor flexibilidad, escalabilidad y versatilidad que con PHP que es el marco de trabajo que usa Laravel (9). Como podemos imaginarnos el catálogo de herramientas es inmenso y no para de crecer según las necesidades del mercado que van surgiendo. Imagen 4. Comparativa Django y Laravel (9). 19 La elección de usar Django en este proyecto no se ha basado en un comparativa como la que nos muestra la imagen 4. La finalidad de este proyecto, las facilidades que ofrece Django (como el panel de administración por defecto o la compatibilidad con gran variedad de gestores de bases de datos), el uso de Python como lenguaje de programación, el sistema de autenticación, el rápido despliegue y el número de plugins que ofrecen, decantaron la balanza en un mercado lleno de posibilidades. Arquitectura de Django El primer paso para entender el funcionamiento de Django es comprender su arquitectura, puesto que rompe con las arquitecturas convencionales conocidas. Por una parte, tenemos el modelo (M), que sería la parte que mantiene unida la aplicación con la base de datos (acceso, validación, relaciones entre los dat os…). Después tendríamos las plantillas (T), donde se diseña y configura la presentación de cada una de las páginas web, es decir, lo que el usuario final va a percibir. Finalmente, tenemos la vista (V) que contiene toda la lógica de negocio de la aplicación web y hace de puente entre las vistas y las plantillas. Todo unido da lugar a la arquitectura Model Template View (MTV) (10). En la imagen 5, se puede observar que existen tres capas que son independientes pero que se unen en una solo, la aplicación web final. Además, el usuario sólo percibe la vista, es decir, lo que el programador ha diseñado para mostrar a los usuarios en cada una de las secciones de la página web, haciendo uso de las plantillas para mostrar la información. Para el usuario es irrelevante lo que existe por debajo de la vista, ya que sólo percibe el funcionamiento de la página. Las comunicaciones entre las distintas capas son de la siguiente forma, un usuario accede a la página y se encuentra con lo que el programador ha definido en la vista y lo que finalmente se muestra en la plantilla (Template). Cuando una de las vistas requiere hacer una consulta a una base de datos (BBDD) lo que sucede es que se hace la petición a una o varias tablas definidas en el modelo. La base de datos devolverá una serie de objeto dependiendo de la Imagen 5. Esquema de la arquitectura MTV. 20 consulta realizada, la vista lo procesará y, por último, se mostrará a través de la plantilla definida para esa sección (10). Características principales Una vez descrita la arquitectura de Django, podemos definir los aspectos más relevantes que le convierten en una herramienta para el desarrollo web (11). 1. Escalabilidad, permite crear sitios web dinámicos que se adaptan rápidamente a las necesidades de la aplicación. 2. Seguridad, incluye un sistema de autenticación de usuarios muy seguro, evita errores en las BBDD y falsificación de solicitudes, etc. 3. Documentación extensa, el proyecto de Django incluye diferentes versiones, con su respectiva API, widgets y continuas actualizaciones. 4. El uso de la arquitectura MTV permite un desarrollo ágil y reutilizable. 5. Cuenta, por defecto, con un panel de administración que permite el control simplificado de las bases de datos y permite añadir diferentes plugings que mejoran la experiencia de usuario. 6. Uso de Python del que hereda todas las facilidades que nos ofrece este lenguaje, incluyendo la simplicidad de generar aplicaciones fáciles de entender. 2.2.2. Sistemas de chatbot En la actualidad el número de aplicaciones que permiten la creación de bot aumentan día a día. Podemos destacar aplicaciones como Telegram, Facebook, PandoraBots, Signal, Whatsapp, etc. Para estudiar el funcionamiento de estas herramientas vamos a centrarnos en algunas de las más importantes, es el caso de: Telegram, Chatfuel y Signal. Antes de comenzar la descripción de cada una de ellas y su funcionamiento, me gustaría explicar el significado de bot. Cuando oímos la palabra bot lo primero que le asociamos es una máquina o robot que nos habla. Pero el concepto va mucho más allá de todo eso. En realidad, un bot es un programa informático que se encarga de realizar tareas de forma similar a un humano. Es decir, los bot poseen cierta inteligencia que les permite realizar infinidad de tareas, y en muchos de los casos esas tareas son una respuesta a un estímulo, reconocimiento de voz o texto de una o varias personas. Como ya nos podemos imaginar un bot puede hacer todo lo que sea posible programar, es decir, podemos hacer lo que queramos con ellos, desde cosas buenas como cosas no tan buenas. Y en este apartado quiero destacar esta clasificación que le damos a los bot, ya que todo lo bueno que pueden ser los bots lo pueden ser de malos, dependiendo la finalidad que tengan los creadores. Podemos tener un bot monitorizando nuestra web, enviándonos informes de rendimiento o visitas de nuestra página. Pero pueden también existir bots que se encarguen de realizar ataques a un sistema, uno de los más frecuentes es el ataque por denegación de servicio (DDoS) o envío de SPAM. En resumen, el uso de bot o la creación de estos, busca facilitarnos la vida, estando las 24 horas a nuestra disposición y realizando tareas por nosotros. Sencillamente, nosotros somos los que vamos a definir las funciones que queremos que efectúe nuestro bot, tanto las buenas como las malas, ya que los bots, por sí solos, no son ni buenos ni malos. 21 Una vez descrito el termino de bot, es importante conocer algunas de las herramientas que existen y comparar las características de cada una de ellas. Telegram Bot API En 2015, Telegram desarrolló una interfaz de programación para el uso de bot en su aplicación de mensajería. Para crear un bot es tan sencillo que basta con “hablar” por Telegram al usuario @BotFather. Este bot nos permite hacer diferentes cosas, algunas de ellas son las que se pueden ver en la imagen 6 (12). En el caso de querer crear un nuevo bot, le debemos de mandar el siguiente mensaje: /newbot. Con ese simple mensaje el bot padre nos envía un token con el que se identifica ese bot en Telegram. Además, se debe de añadir un nombre de usuario al bot para que se pueda encontrar en Telegram. Es importante destacar que el token es como la llave a nuestro bot y si alguien accede a esa llave puede hacer que nuestro bot envie mensajes o cualquier otra cosa. Por ello, es muy importante mantenerlo en secreto si no queremos tener problemas. En cuanto tenemos nuestra llave, el bot está activo, pero sin ningún tipo de funcionalidad. Debemos de programar nuestro bot y para ello necesitamos hacer uso de la API de Telegram. Gracias a la excelente interfaz HTTPS de desarrollo de la que dispone Telegram, programar un Bot resulta muy sencillo. Tenemos dos formas de representar el funcionamiento de un bot según si está destinado a un grupo o a usuarios individuales, pero el funcionamiento final es igual. Como podemos ver en la imagen 7, el funcionamiento es muy sencillo. Un usuario o grupo de usuarios pregunta o no, según el propósito del bot y esta contesta a lo que se le pregunta, o cumple con las funciones para las que ha sido programado. Imagen 6. Opciones disponibles en el BotFather (12). 22 Chatfuel Para comparar las herramientas del mercado, destacamos Chatfuel como una de ellas ya que su uso es muy diferente al de Telegram. Si en Telegram el uso de la aplicación es gratuita y posee una API para crear bots para lo que necesitemos, Chatfuel, es una empresa encargada de crear bots. En primer lugar, las diferencias principales son que es de pago (pero ofrece un servicio mínimo gratis en el que permite funcionalidades limitadas) y que está orientada a empresas que quieran sacar rendimiento a los redes sociales o canales de comunicación (13). Lo que nos ofrece esta herramienta es una aplicación capaz de crear Bot de forma simplificada, sin usar líneas de código, donde todo lo que queremos automatizar se consigue haciendo clic en una pantalla. En la imagen 8 se puede observar cómo es la interfaz que nos ofrece Chatfuel, en este caso estamos viendo la pestaña de flujos, en ella se van creando los flujos de funcionamiento del chatbot (13). Imagen 8. Interfaz de Chatfuel (13). Imagen 7. Funcionamiento básico de un bot de Telegram. 23 Si nos adentramos un poco más dentro de la anatomía de la aplicación, veremos que el flujo del chat está formado por tarjetas que van definiendo el funcionamiento del chatbot, también permiten ejecutar alguna acción o exportar datos, entre muchas otras cosas. En la imagen 9 podemos ver cómo es una de esas tarjetas (13). En resumen, las tarjetas contienen la información que el bot va a compartir con los demás usuarios y las respuestas rápidas son el conjunto de opciones que se le presentan a los usuarios para contestar a esa pregunta. Además del flujo desde Chatfuel nos permiten acceder a un panel de administración de nuestros bot donde podemos (13): 1. Crecimiento, herramientas que permiten aumentar las subscripciones de usuarios al bot de tu compañía. 2. Flujos, configuración del flujo de mensajes de los bot. 3. Automatizar. 4. Chat en directo. 5. Configurar inteligencia artificial, permite identificar las preguntas más frecuentes al bot y configurar las respuestas a ellos. 6. Personas, permite visualizar los usuarios, agrupar usuarios o generar ficheros csv para impulsar las ventas. 7. Reconectar, captar de nuevo los usuarios que alguna vez ya se han conectado. 8. Configurar. 9. Analizar. 10. Mejorar. Como hemos podido comprobar esta herramienta y Telegram son muy diferentes, pero ambas usan la tecnología de los Bot para automatizar acciones. Si bien es cierto Telegram ofrece una API en la que puedes gestionar tus bot, programarlos y todo gratuitamente. Por Imagen 9. Tarjeta que conforma el flujo de un chatbot en Chatfuel (13). 24 otro lado, Chatfuel ofrece a todas las personas con acceso a un teléfono o a un ordenador la manera de crear un bot sin necesidad de saber programar o incluso de lo que es un bot. Además, su mercado está expresamente dirigido a mejorar el rendimiento de las empresas, algunas de ellas son empresas de gran nombre como LEGO, Nivea, National Geographic, Adidas, Netflix, etc. Muchas de ellas en las que los bot que se han implementado se destinan a hacer recomendaciones a los usuarios, generar descuentos, ofertas y muchas aplicaciones más (13). Signal Signal es otra de esas aplicaciones de las que no se oye hablar mucho, pero sus funcionalidades permiten que se adapte perfectamente a las expectativas de muchos nichos de mercado. Por un lado, ofrece seguridad gracias al cifrado extremo a extremo en donde ni siquiera la propia empresa conoce el contenido de esos mensajes de texto, audios, fotos o videos que se envían a través de la aplicación. No envía publicidad a los usuarios, es decir, queda libre de spam y de seguimiento a los usuarios. Con todo eso y mucho más Signal es una aplicación gratuita que está disponible para Android, iOS, Windows o Linux (14). En comparación con Telegram, Signal utiliza un cifrado extremo a extremo sin necesidad de servidor intermedio. En cambio, en Telegram aunque existan conversaciones privadas (no en el caso de que se use un Bot) los mensajes pasan por los servidores de Telegram. Además, Signal se distingue de sus competidores guardando únicamente los datos necesarios para la comunicación: móvil, fecha de creación y última fecha de conexión. Para acceder a la aplicación de Signal es necesario introducir un pin, de esta forma impedimos accesos no autorizados. Por último, pero no menos importante, nos ofrece crear mensajes que se autodestruyen, es decir, podemos enviar mensajes que al cabo de un rato (según el tiempo que definamos) se borran. Telegram también lo permite, pero solo en los chats privados. Como se puede comprobar son muchas las ventajas de Signal sobre los dos competidores que hemos comentado con anterioridad, pero uno de los problemas que tiene se centra en una de las necesidades de nuestro proyecto, la creación de bots. Desafortunadamente, Signal no dispone de una API que permita crear bots con facilidad. Actualmente se encuentra en proceso de desarrollo, pero pronto veremos los primero bots con Signal. Comparación de sistemas de chatbots Una vez repasadas algunas de las aplicaciones más destacadas en las que se pueden crear chatbots es importante nombrar algunas de las características principales que debemos de tener en cuenta a la hora de decidirnos entre una u otra: • Privacidad: el tratamiento de nuestros datos por parte de las empresas que nos ofrecen la herramienta es importante a la hora de escoger una u otra. Dentro de las anteriormente comentadas, la más destacada por su privacidad y por los métodos de seguridad que ofrece a sus usuarios es Signal. Por su parte Chatfuel y Telegram también nos ofrece privacidad y protegen nuestros datos, pero a un nivel inferior que Signal. • Documentación: cuando las aplicaciones nos permiten crear con ellas otras aplicaciones específicas para cumplir los requerimientos de los usuarios, uno de los aspectos más valorables y a tener en cuenta es tener acceso a una amplia documentación, actualizada y realimentada en la que se pueda tener acceso a métodos y funciones disponibles para programar dichas aplicaciones. En este caso Telegram 25 Bot API nos lo cumple a la perfección, se encuentra actualizada, con soporte y con una gran comunidad que ofrece proyectos y ayuda con todo lo relativo a la creación de los bots. • Funcionalidad: este aspecto está muy ligado al conjunto de librerías de las que dispone la aplicación. Los límites vienen marcados por los desarrolladores por ello es importante elegir una aplicación que este en continua renovación y que se actualice periódicamente. Esta característica la cumplen la mayoría de las aplicaciones que apuestan fuerte por el desarrollo de bots. • Requisitos de la aplicación: el último aspecto y el más importante es definir la aplicación a la que queremos destinar nuestro bot. Un bot que envíe mensajes sencillos sin ninguna necesidad de conversación previa, un bot meramente informativo, en este caso, cualquier aplicación lo puede solventar con facilidad. Pero una vez que se va haciendo más compleja la aplicación, los requisitos cambian y es necesario buscar la herramienta que mejor se adapte a nuestras necesidades. En este caso, Telegram Bot API nos resuelve todas nuestras necesidades a la perfección 2.2.3. Computación en la nube En los últimos años, la descentralización ha sido la tónica seguida por muchas empresas que ven como los hábitos los usuarios están cambiando, obligando a las empresas a modernizarse. En la actualidad esto se conoce como transformación digital, y más aún en estos meses, en los que la pandemia mundial provocada por la COVID ha acelerado este proceso mucho más. Esta transformación del modelo de negocio influye en la digitalización tanto de las PYMES como de las grandes empresas, y es en este momento donde aparece el concepto de nube. La nube es una de las revoluciones más importantes de los últimos años que permiten a las empresas ir adaptándose a las nuevas tecnologías de una forma sencilla y con un coste reducido. La idea de la nube nace de la necesidad de una reducción de costes en hardware y en software por parte de las empresas y es de esta manera, como las empresas pasan de tener su propio hardware, muchas veces sobredimensionado y muy costoso, a tener contratados solos los servicios necesarios para realizar su actividad empresarial (15). Una de las ventajas más importantes que ofrecen estos servicios es la escalabilidad, flexibilidad el bajo coste y el acceso desde cualquier lugar. Aunque aún existe un gran desconocimiento de este concepto en la sociedad empresarial y en ocasiones genera reticencia entre muchos de ellos por temor a la garantía de seguridad que nos ofrece la nube (15). Cuando hablamos de la nube o cloud estamos hablando de la computación en la nube o cloud computing. El cloud computing permite a un proveedor de servicios ofrecer servicios informáticos a través de internet. Entre los cuales están los servicios de almacenamiento, de redes, de servidores, de aplicaciones, etc. Un amplio abanico que permite cumplir con los requerimientos de las empresas. Para entender cómo funciona la computación en la nube tenemos que ver primero como funcionan las empresas tradicionalmente. En la imagen 10 se puede observar la comparación entre una empresa tradicional y una empresa que utiliza cloud computing (15). 32 Como dato de interés general hay que destacar la próxima apertura de zonas de disponibilidad dentro de España, puesto que en la actualidad la región más próxima que nos ofrecen Amazon es la de París, Francia. Google Cloud Platform Google Cloud es otra de las aplicaciones que se encuentran en la cúspide del sector. Ofrece aproximadamente 90 servicios de tecnología de todo tipo. Al igual que AWS, Google Cloud posee una interfaz que permite el fácil acceso a los usuarios. Los servicios que se ofrecen se adaptan de forma sencilla a las necesidades de cada usuario (19). Qué tipo de soluciones nos ofrece Google, en este caso estaríamos hablando de tres: IaaS, PaaS y SaaS. Como ya hemos visto anteriormente cada una de ellas va aumentando los recursos que se ofrecen a los usuarios. Las principales categorías de servicios que nos ofrece Google Cloud son los siguientes (19): 1. Cálculo 2. Redes 3. Almacenamiento y bases de datos 4. Inteligencia Artificial y Machine Learning 5. Big Data 6. Identidad y seguridad 7. Aplicaciones de gestión Microsoft Azure Microsoft Azure es una plataforma que ofrece más de 200 productos y servicios en la nube con la idea de ofrecer soluciones a problemas del presente y de futuro. Los servicios que ofrecen son muy similares a las de las empresas que ya hemos comentado, pero se destacan por ser 5 veces más barato que AWS. Se puede pensar que al ser una compañía de Microsoft solo ofrece servicios para Windows, pero no es así, también son compatibles con las tecnologías de código abierto. Evitando así cerrarse a un gran nicho de mercado que hace uso de tecnologías de código abierto (20). Aúnan muchos esfuerzos en la seguridad de los datos de sus clientes, invirtiendo 1 billón de dólares al año para mantener la privacidad de ellos y protegerlos frente a los ciberataques. Una característica destacable de Microsoft Azure es que los clientes tienen la posibilidad de hacer copias de seguridad automáticas de los datos, para de esta forma mantener a salvo los datos de los clientes en caso de pérdida o sustracción, volviendo a hacer hincapié en la importancia de la seguridad de los datos. Como hemos visto los proveedores de servicios nos ofrecen servicios similares y los precios en muchos de ellos se asemejan bastante. Por ello en la tabla 2 vamos a recoger tres aspectos importantes a la hora determinar cuál es la que mejor se adapta a nuestras necesidades (20). 33 Tabla 2. Clasificación de proveedores de cómputo en la nube (21). 2.2.4. Microordenadores La Raspberry Pi es la placa más popular que se encuentra en el mercado, pero no es la única y sus competidores son muchos. La primera Raspberry Pi que salió al mercado lo hizo en 2012, fue el modelo Raspberry 1 Model A y se caracterizaba por sus 256 MB de RAM, por tener WiF i y por su coste reducido, 40 €. Los modelos se han ido sucediendo durante estos 9 años hasta la aparición de la Raspberry Pi 4 Model B+, que es la placa más potente hasta el momento que ha desarrollado la marca. Capaz de soportar Gigabit Ethernet, WiFi en doble banda de frecuencia, 4 puertos usb, etc. La popularidad de la Raspberry Pi le ha convertido en una de las placas que más se usa para aprender o desarrollar programas y aplicaciones en entornos educativos. Pero sus competidores no se han quedado atrás y han ido desarrollando sus propias placas muchas de ellas destinada a funciones muy específicas (22). Una de ellas sería la NVIDIA Jetson Nano, que está orientado a la Inteligencia Artificial y es capaz de proporcionarnos 472 GFLOPs de potencia. Al igual que su potencia su precio también es elevado llegando a costar hasta 150 €. Por otro lado, tenemos placas como Arduino que se centran en la robótica o en las impresoras 3D. Se diferencia de Raspberry en que no tiene procesador, sino que hace la función de un microcontrolador. Finalmente, la placa Rock64 Media Board es una de las que más se asemeja en cuanto a precio a la Raspberry, pero ofreciéndonos un procesador más rápido y el doble de memoria (22). La aceptación de estas placas se debe a su bajo coste (exceptuando algunos casos), su tamaño reducido, la completa funcionalidad que ofrecen como un ordenador convencional, la adaptación a todo tipo de lenguajes de programación y los variados periféricos que permiten integrar. Pero todo sistema tiene sus inconvenientes, y los microordenadores también tienen los suyos. Hay que tener en cuenta que estas placas tienen sus limitaciones en cuanto a computación, memoria o configuración en contraposición con los ordenadores tradiciones. Una vez seamos conscientes de ello, podemos disfrutar de una tecnología que Tipo de Cliente Coste Servicios Amazon Web Services Cualquiera Gartner recomienda el uso de una herramienta de terceros para estimar el precio Ofrece muchas opciones, pero se centra en soluciones de nube pública Google Cloud Platform Pequeñas y medianas empresas Gartner destaca los precios centrados en sus clientes con ofertas y descuentos Menos servicios, pero con capacidades de IA y ML por delante de la competencia Microsoft Azure Empresas Los descuentos se basan en condiciones particulares Infraestructura robusta haciendo uso de la nube híbrida 34 permite aprender a desarrollar de una forma sencilla y a un coste bastante más bajo en comparación con los ordenadores convencionales. 2.2.5. Sistemas de gestión de bases de datos Cuando hablamos de una base de datos lo relacionamos directamente con una información almacenada en un lugar. Pero el término va muchos más allá y hay que distinguir el uso que hace de ello. Efectivamente, una base de datos almacena gran cantidad de información para su posterior procesamiento. Estos sistemas son capaces de gestionar muchos de datos con relativa sencillez, pero es importante que diferenciemos entre la base de datos contenedora de información y el programa que gestiona la BBDD. No todos los programas pueden saber leer este tipo de datos ni los programas que las gestionan se pueden autodenominar como base de datos. Tampoco es cierto que son un grupo de ficheros, puesto que, los archivos de un ordenador no conforman una base de datos (23). Fue en la década de los años 60 donde el término de base de datos empezó a coger forma, proporcionándonos de esta forma una abstracción entre el software y el programa de aplicación. Los primeros modelos consistían en modelos en red y jerarquizados, algo demasiado simple y limitado, esto dio paso a las bases de datos relacionales, un sistema mucho más potente que rápidamente se abrió camino en el mercado. Hoy en día la gran mayoría de sistemas de bases de datos hacen uso de modelos relacionales, pero no todos hacen uso de ese modelo, por lo que describiremos por encima algunos de los tipos de modelos que existen (23): • Relacional: es el caso más común en bases de datos. Hace uso de filas para colocar los datos y permite crear relaciones con las demás filas, presentándolo en bloques o columnas. Por ejemplo: MySQL, MariaDB, Oracle DB, etc. • Jerárquica: los datos se almacenan en forma de árbol, con un relación padre-hijo. Por ejemplo: IMS de IBM. • De red: los datos se enlazan entre sí formando una gran red. • Orientada a objetos: extiende el concepto de modelo relacional añadiéndole el sentido de la herencia (algunos objetos heredan parámetros de otros objetos). Por ejemplo: PostgreSQL (combina los modelos relacional y orientado a objetos) • Orientada a documentos: ofrece la oportunidad de almacenar información en diferentes documentos. Por ejemplo: OrientDB o CouchDB. Imagen 14. Modelo de base de datos relacional (23). Imagen 14. Modelo de base de datos orientado a objetos (23). 35 Cuando tenemos los datos en una base de datos debemos de tener en cuenta cómo de protegidos los tenemos y esto cada vez es más importante para las empresas. Toda base de datos debe ser segura y conseguir proteger la disponibilidad, la confidencialidad y la integridad de la base de datos (23): • Disponibilidad: necesidad de mantener los datos siempre a disposición de los clientes. • Confidencialidad: es el aspecto más importante de seguridad dentro de una base de datos y la mejor manera para conseguirlo es tener cifrados los datos. • Integridad: garantizar el acceso a los datos únicamente a las personas autorizadas para ello. Antes hemos hablado de la importancia de distinguir entre base de datos y el programa que lo gestiona, una vez descritas las características principales de una base de datos, toca describir las funciones principales de un programa de gestión de base de datos y por qué son tan necesarios. Por un lado, el gestor de una base de datos tiene que ser capaz de almacenar, borrar y modificar los datos. Además, tiene que poder gestionar los metadatos que son los que mantienen el orden dentro de la base de datos y contienen la información más relevante. El tratamiento de los datos tiene como base el CRUD (Create, Read, Update y Delete). Por otra parte, los datos deben de estar seguros dentro de la base de datos, las consultas deben estar optimizadas, se debe permitir el acceso por varios usuarios simultáneamente y el sistema debe de ser transparente con el usuario (23). Imagen 15. Modelo de base de datos de forma jerarquizada (23). Imagen 16. Modelo de base de datos en red (23). Imagen 18. Modelo de base de datos orientado a documentos (23). 36 Como hemos comentado antes, existen en el mercado diferentes gestores de bases de datos, por ello vamos a centrarnos en dos de ellas para comentar las características y diferencias que nos podemos encontrar en el mercado. MariaDB Aunque MySQL es el gestor de bases de datos por excelencia, el mercado se ha ido expandiendo y han surgido alternativas como MariaDB que estás basadas en software libre y con una gran flexibilidad. Es tan cercana a MySQL debido a que su desarrollador fue uno de los que desarrolladores de MySQL, con la idea de mantener las características de MySQL pero en formato de software libre. Todo lo bueno de MySQL está integrado en MariaDB pero además incluye mejoras en las consultas, permitiendo crear consultas más complejas y con la opción de mantenerlas en una caché. Permite acceder a clúster de datos lo que provoca que se pueda trabajar muy bien desde la nube. Gracias a la comunidad que se encuentra en continua investigación y desarrollo, MariaDB sigue mejorando y ampliando sus funcionalidades y la seguridad. MariaDB no se ha convertido en una de las mejores herramientas para gestionar las bases de datos por casualidad, sus características lo avalan (24): • Velocidad: la rapidez en sus consultas se debe al uso del motor aria, que, en vez de escribir en disco, lo que hace es almacenar las filas en caché. Además, la eliminación de las conversiones en caracteres innecesarios provocó aumentar la velocidad entre un 1-5%. • Extensiones que ofrece: entre muchas de las que posee, podemos destacar la inclusión de un sistema de autenticación, la posibilidad de elegir un motor de almacenamiento de una tabla, uso de columnas virtuales, etc. • Errores y feedback: en este sentido los errores se van corrigiendo a medida que aparecen y continuamente están implementando mejoras. El feedback o las alertas han ido desapareciendo hasta mostrar únicamente las necesarias para solventar una incidencia. • Ayuda y documentación: gracias a la comunidad que da soporte a MariaDB, tenemos a nuestra disposición una completa documentación que nos permite hacer frente a las dudas que nos puedan surgir. • GPL: La licencia GPL es la clave para que MariaDB sea de código abierto. Garantiza a los usuarios la disponibilidad de usar, modificar y compartir de manera libre. Es de gran importancia saber que todos los programas de MySQL van a ser compatibles con MariaDB. Según el tipo de servidor puede ser interesante estudiar la posibilidad de implementar MariaDB puesto que nos ofrece un gran rendimiento, acceso a funciones específicas y adaptarse rápidamente a soluciones específicas como el uso de aplicaciones en la nube. PostgreSQL MariaDB es un tipo de modelo relacional, sin embargo, en el caso de PostgreSQL se combina el modelo relacional y el orientado a objetos. Sigue siendo, al igual que MariaDB, con licencia de código abierto y gracias a los colaboradores que actúan de forma desinteresada se mantiene el proyecto actualizado, esta comunidad se autodenomina PDGD (PostgreSQL Global Development Group). La denominación de este proyecto ha ido evolucionando desde 37 la década de los 80 en el que se conocía como “ Postgres” . En 1996, el nombre cambió de forma oficial a “PostgreSQL” y es el que se mantiene hasta la actualidad. Este gestor de base de datos se caracteriza por ser uno de los motores más usados en la actualidad y en parte gracias a las siguientes especificaciones que lo avalan (25): • Alta concurrencia: cada acceso a la base de datos se ve como un acceso único sin importar que otros estén accediendo a la misma tabla de la base de datos. Se denomina como un sistema Multiversion Concurrency Control (MVCC), es un método para controlar y proporcionar un acceso concurrente a los datos. • Sistema hot standby: este proceso permite que se puedan ejecutar búsquedas mientras la base de datos se encuentra en modo standby. • Soporte nativo a diferentes tipos de datos (texto largo, números de precisión, direcciones MAC, arrays, etc.) • Uso de formato JSON: muchas bases de datos encuentran dificultades en los sistemas de bases de datos relacionales. Pero en el caso de PostgreSQL, tenemos un sistema capaz de indexar elementos y realizar búsquedas en dicho formato. • Notificaciones: es un sistema capaz de mantenerse sincronizado con varios dispositivos gracias a las funciones de LISTEN, UNLISTEN Y NOTIFY. • Registro: PostgreSQL hace un registro de cada transacción que se realiza permitiendo restaurar la base de datos desde cualquier punto de restauración. • Disparadores: son procedimientos que se crean con una acción determinada y se ejecutan según unos parámetros. Al igual que MariaDB, PostgreSQL tiene muchas ventajas. Se pueden clasificar en (25): 1. Uso gratuito 2. Multiplataforma 3. Estable y escalable 4. Incorpora una herramienta gráfica 5. Robusto y fiable 6. Soporte En contraposición sí que debemos comentar ciertas desventajas de este sistema, por un lado, se destina para bases de datos grandes, en las que se desenvuelve mejor. Finalmente, he de destacar que el lenguaje que emplea presenta dificultades por lo que se recomienda un alto conocimiento del lenguaje SQL (25). 2.2.6. Servidores Web El paradigma cliente-servidor en aplicaciones web tiene dos partes bien diferenciadas por un lado el cliente y por el otro el servidor. La comunicación entre ambas partes se rige por el protocolo de comunicación HTTP, desde el cliente se envían las peticiones y desde el servidor se procesan las peticiones y se responde en consecuencia (26). 38 En la imagen 19 podemos observar un claro ejemplo de funcionamiento de la comunicación entre cliente y servidor. Como vemos ambas partes se encuentran, por lo general, en máquinas separadas, cada una de ellas con su propio hardware y software. En el caso del cliente tenemos el front-end, que es lo que sería el navegador web, en el que el usuario únicamente hace uso de una aplicación sin saber quién lo está gestionando por debajo. En este caso, es el servidor, nuestro back-end, el que está gestionando esas peticiones de la aplicación y mostrando al cliente lo que está solicitando en ese momento según la programación que lleva implementada el servidor en cada caso (26). Al hacer uso de esta tecnología debemos de ser conscientes de las ventajas y desventajas que acarrea este sistema. Primero veamos las ventajas (27): • Centralizado: gracias a tener un sistema central somos capaces de controlar de mejor manera los accesos, los recursos y la integridad de estos. Somos capaces de mantener los recursos actualizados y añadir más de forma sencilla, que por ejemplo en una red P2P. • Escalabilidad: podemos ir creciendo a la vez que lo hacen los clientes adaptando los servidores para que cumplan mejor las exigencias de los usuarios. • Mantenimiento: al tener la posibilidad de crear redundancias entre los servidores, somas capaces también de mantener y aislar de forma sencilla cada uno de ellos en el momento que haya que actualizar o reparar alguno de ellos. • Tecnologías: en el mercado existen muchas soluciones al paradigma clienteservidor que ofrecen interfaces amigables, fácil implementación y gran cantidad de documentación para llevar a cabo las acciones que el usuario desea realizar. Por el otro lado hay que ser consciente de las desventajas que pueden tener (27): • Gestión del tráfico: las altas cantidades de tráfico que se pueden dar en los servidores es un problema del paradigma. Cuantos más clientes, más peticiones al servidor y puede que ello cause problemas, en contraposición, existen las rede P2P en el que cada nodo hace el papel de servidor • Robustez: cuando el sistema se cae, las peticiones no pueden ser resueltas. Podemos conseguirlo a través de la redundancia en más de un servidor, que es como funciona las redes P2P, con los recursos distribuidos por sus nodos. Imagen 16. Ejemplo de estructura básica del paradigma cliente-servidor en aplicaciones web (26). 39 • Hardware y software: es muy importante el equipamiento de los servidores y la capacidad de gestionar los recursos. Cuantas más peticiones, más capacidad de gestión por parte de los servidores, lo que incurre directamente en un mayor coste de los dispositivos. Apache Uno de los servidores web más populares del mercado es Apache. Se puso en funcionamiento en 1995 y es una herramienta de código abierto, multiplataforma y gratuito. Con él se ejecutan el 46% de aplicaciones web de todo el planeta. Apache no es un dispositivo, sino que es un software que se ejecuta en un dispositivo, en un servidor. Su función principal es la de conectar los servidores y navegadores, mientras existe una comunicación entre ellos (28). Cuando accedemos a una página web lo que estamos haciendo es una petición a un servidor web para que nos muestre la información del sitio web. Apache tiene la función de devolvernos el contenido solicitado, ya sea texto, imágenes, videos, etc. Además, es responsable de que la comunicación sea fluida y segura entre dos máquinas (28). En cuanto a las funcionalidades de Apache, disponemos de muchos módulos extras que nos permiten, entre muchas otras cosas, configurar la seguridad, almacenar en caché, redirecciones, configurar certificados SSL, crear autenticación, etc. Una vez visto las capacidades de este sistema tenemos que ver los pros y contras que nos ofrece. Por un lado, las ventajas son las siguientes (28): 1. Es código abierto y no supone ningún coste 2. Robusto 3. Mantienen el sistema actualizado 4. Fácil configuración para los principiantes 5. Multiplataforma, disponible en Unix y en Windows 6. Compatibilidad por defecto con WordPress 7. Soporte de ayuda Por el otro, las desventajas de este servidor web son: 1. Reducción de rendimiento con webs con mucho tráfico 2. Su amplia configuración puede generar brechas de seguridad NGINX En la actualidad existen muchos servidores web que están en alza y compiten de tu a tu con Apache, uno de ellos es caso de NGINX. Se lanzó en 2004 y desde entonces ha ido ganando adeptos dentro de los propietarios de aplicaciones web. Fue creado como la solución al problema que se genera en otros servidores cuando el número de solicitudes aumenta hasta las 10.000 simultáneamente (29). En la imagen 18, se puede observar el comportamiento de ambos servidores frente a grandes cantidades de tráfico. Donde constatamos que Nginx atiende a muchas más peticiones que Apache cuando aumenta la cantidad de conexiones. En cambio, Apache se mantiene estable en todo momento (29). 40 Nginx está diseñado para usar muy poca memoria y aceptar altos niveles de tráfico. Su funcionamiento hace que no se genere u proceso por cada petición que se recibe, sino que actúa de forma asíncrona, en donde cada petición es un evento dentro de un solo hilo. Se caracteriza por incluir IPv6, balanceo de carga, websockets, proxy inverso con caché, etc (29). En la imagen 21 se puede observar la comparativa de Nginx con los servidores más populares, en ella vemos cuáles son los más utilizados por la comunidad de desarrolladores de aplicaciones web (30). Apache sigue siendo el más popular de entre todos, pero Nginx sigue expandiéndose por el mercado de las páginas web con mucho tráfico. Un ejemplo de ello es que empresas con Netflix o la NASA hace uso de Nginx en sus servidores (30). Imagen 17. Comparativa entre Apache y Nginx en cuanto a la capacidad del servidor frente a grandes niveles de concurrencia (29). Imagen 18. Comparativa de los servidores web más populares entre 2009 y 2018 (Netcraft) (30). 41 Como se puede observar en las imágenes 22 y 23, la popularidad de Apache y Nginx se está igualando. Apache por su parte está teniendo una tendencia a la baja. Sin embargo, Nginx está encontrando la manera de abrirse un hueco (31,32). Imagen 22. Comparativa entre Apache y Nginx según el número de páginas web que usan su tecnología en sus servidores (31). Imagen 23. Comparativa entre Apache y Nginx según su popularidad (32). 48 Base de datos En este subapartado se va a tratar de explicar cada una de las tablas que da lugar a la base de datos del sistema. Más allá de detallar las relaciones entre tablas vamos a tratar de analizar cada uno de los datos que son almacenados en las tablas y explicar la función que cumplen cada uno de los datos. Gracias a este apartado podremos entender mejor el sistema que se ha diseñado. Diagnósticos Esta tabla es la encargada de almacenar los diagnósticos que van a estar disponibles dentro de la aplicación web cuando demos de alta a un paciente o un ejercicio. Indicando por un lado el diagnóstico de un paciente y en el caso de los ejercicios, el diagnóstico al que está sujeto la realización del ejercicio. Un ejemplo de diagnóstico sería: triparesia. Tabla 3. Diagnósticos Campo Tipo de dato Descripción ¿Es obligatorio? nombre CharField(40) Nombre del diagnóstico Sí creado DateTimeField Momento de creación Auto-rellenado actualizado DateTimeField Momento de actualización Auto-rellenado Objetivo terapéutico Los objetivos terapéuticos definen los diferentes grupos de finalidades para las que se lleva a cabo cada uno de los ejercicios, de esta manera podemos definir como objetivo terapéutico el siguiente ejemplo: alimentación. Permitiendo agrupar los ejercicios en grandes grupos destinados a diferentes objetivos definidos en esta tabla. Imagen 25. Panel de administración de la aplicación web. 49 Tabla 4. Objetivo terapéutico Campo Tipo de dato Descripción ¿Es obligatorio? nombre CharField(40) Nombre del objetivo terapéutico Sí creado DateTimeField Momento de creación Auto-rellenado actualizado DateTimeField Momento de actualización Auto-rellenado MACS Esta tabla se corresponde con los diferentes niveles de habilidad manual (de 1 a 5) que se van a definir. La escala MACS permite al terapeuta asociar el nivel de habilidad manual que tiene cada paciente en su historial clínico dentro de la aplicación web. Tabla 5. MACS Campo Tipo de dato Descripción ¿Es obligatorio? nombre CharField(40) Nivel de habilidad manual Sí creado DateTimeField Momento de creación Auto-rellenado actualizado DateTimeField Momento de actualización Auto-rellenado GMFCS La GMFCS, al igual que la MACS, es un valor que el terapeuta rellena al dar de alta al paciente en el sistema. Con él indica la habilidad motora gruesa que posee el paciente en concreto. Lo posibles valores van del 1 al 5. Tabla 6. GMFCS Campo Tipo de dato Descripción ¿Es obligatorio? nombre CharField(40) Nivel de función motora gruesa Sí creado DateTimeField Momento de creación Auto-rellenado actualizado DateTimeField Momento de actualización Auto-rellenado Otras calificaciones Las calificaciones están directamente relacionadas con el campo FMS que se encuentra en la tabla de Pacientes. Su función es definir los niveles de calificación que se dan dentro del Functional Movement Screen (FMS). Los niveles están muy definidos y son los siguientes, del 1 al 6 y las letras C y N. Tabla 7. Calificaciones Campo Tipo de dato Descripción ¿Es obligatorio? nombre CharField (40) Nivel de clasificación de la movilidad funcional Sí creado DateTimeField Momento de creación Auto-rellenado actualizado DateTimeField Momento de actualización Auto-rellenado 50 Edad Esta tabla refleja los rangos de edades disponibles en la aplicación web para dar de alta un nuevo ejercicio. Sirven para agrupar los ejercicios por grupos de edades. Un ejemplo de rango de edad es el siguiente de 2-4 años. Tabla 8. Edad Campo Tipo de dato Descripción ¿Es obligatorio? nombre CharField (40) Rango de edad Sí creado DateTimeField Momento de creación Auto-rellenado actualizado DateTimeField Momento de actualización Auto-rellenado Extremidades Las extremidades son valores que forman parte de los parámetros de un ejercicio. De esta forma indicamos las extremidades que están involucradas en la realización del ejercicio. Como, por ejemplo: superior o inferior Tabla 9. Extremidades Campo Tipo de dato Descripción ¿Es obligatorio? nombre CharField (40) Nombre del tipo de extremidad Sí creado DateTimeField Momento de creación Auto-rellenado actualizado DateTimeField Momento de actualización Auto-rellenado Lateralidad Al igual que en la anterior tabla, la lateralidad forma parte de la parametrización de cada uno de los ejercicios. Los ejercicios van a poder ser unilaterales, bilaterales o ninguna de las dos. Tabla 10. Lateralidad Campo Tipo de dato Descripción ¿Es obligatorio? nombre CharField (40) Nombre del tipo de lateralidad Sí creado DateTimeField Momento de creación Auto-rellenado actualizado DateTimeField Momento de actualización Auto-rellenado Posición Respecto a esta tabla podemos definir en ella la posición del cuerpo que implica la realización del ejercicio. Es un detalle más dentro de la creación de los ejercicios y añade indicaciones para la realización del mismo. Un ejemplo de posición sería “De pie”. 51 Tabla 11. Posición Campo Tipo de dato Descripción ¿Es obligatorio? nombre CharField(40) Nombre del tipo de posición Sí creado DateTimeField Momento de creación Auto-rellenado actualizado DateTimeField Momento de actualización Auto-rellenado PCI PCI se define como el trastorno del tono postural y del movimiento, de carácter, secundario a una agresión no progresiva a un cerebro inmaduro (34). En esta tabla se recoge los tipos de PCI que existen, por ejemplo, espástica, atetoide, atáxica, etc. Tabla 12. PCI Campo Tipo de dato Descripción ¿Es obligatorio? nombre CharField(40) Nombre del PCI Sí creado DateTimeField Momento de creación Auto-rellenado actualizado DateTimeField Momento de actualización Auto-rellenado Antes de continuar con las siguientes tablas hay que comentar ciertos aspectos que caracterizan a todas las tablas que acabamos de ver. En primer lugar, todas poseen tres campos en lo que lo único que varía entre ellas es el significado del campo “nombre”. Puede parecer que son innecesarias algunas de ellas, pero están diseñadas para que puedan crecer a la vez que lo hace el proyecto. Por ello, este diseño se ha hecho pensando en crear una buena base de crecimiento de la aplicación en el que añadir más campos en alguna de las tablas sea sencillo, es decir, buscado un diseño perfectamente escalable. A partir de la siguiente tabla nos encontraremos con 5 tablas que comienzan a crear relaciones uno a uno y varios a varios con las diferentes tablas que hemos creado con anterioridad. Podemos considerarlas el núcleo de nuestra aplicación y son las siguientes: Ejercicios Cada uno de los ejercicios que se dan de alta en la aplicación necesitan antes ser parametrizados con los campos que podemos ver en la tabla posterior. De gran importancia es el campo “código” puesto que es necesario que exista una relación entre el código y el nombre del fichero que se asocia a este ejercicio y se adjunta al campo “vid eo”. Ambos deben coincidir para el correcto funcionamiento de la aplicación. El resto de los campos, exceptuando el campo “nombre” y descripción, se eligen de listas desplegables que facilitan la creación de nuevos ejercicios. Algunos permiten elegir solamente un valor y otros varios valores, es decir, algunos campos son ForeignKey y otros son relaciones ManyToMany. Todos los campos son obligatorios excepto el campo descripción ya que en algunos casos el nombre del ejercicio se puede considerar suficientemente explicativo. 52 Tabla 13. Ejercicios Campo Tipo de dato Descripción ¿Es obligatorio? código CharField (8) Código con el que se identifica el ejercicio Sí nombre CharField (60) Nombre del ejercicio Sí descripción TextField (500) Descripción del ejercicio No edad CharField (40) Selección del rango de edad Sí extremidades CharField (40) Selección de las extremidades Sí lateralidad CharField (40) Selección de la lateralidad Sí posición CharField (40) Selección de la posición Sí objetivo terapéutico CharField (40) Selección del objetivo terapéutico Sí diagnostico CharField (40) Selección del diagnóstico Sí pci CharField (40) Selección del PCI Sí video FileField Subida del video (formato .mp4, .mkv, .avi, etc) Sí visible BooleanField(Por defecto: True) Permite hacer no visible un ejercicio en una situación determinada Sí creado DateTimeField Momento de creación Auto-rellenado actualizado DateTimeField Momento de actualización Auto-rellenado Terapeutas La tabla de terapeutas contiene a todos los terapeutas que poseen credenciales para acceder a la aplicación web. Previamente debe de haberse creado un perfil para cada uno de ellos gracias las facilidades que ofrece Django y a sus tablas en las que almacena a los usuarios y grupos de usuarios. Es una forma de unificar a todos los terapeutas en una tabla ya que en un futuro pueden existir más usuarios que no tienen por qué ser terapeutas y de esta manera lo mantenemos separado. Tabla 14. Terapeutas Campo Tipo de dato Descripción ¿Es obligatorio? nombreUsuario CharField (30) Nombre de usuario del terapeuta para el acceso a la app Sí nombre CharField (20) Nombre del terapeuta Sí apellidos CharField (40) Apellidos del terapeuta Sí creado DateTimeField Momento de creación Auto-rellenado actualizado DateTimeField Momento de actualización Auto-rellenado 53 Pacientes Los pacientes son dados de alta en el sistema rellenando los siguientes campos que aparecen en la tabla. Muchos de ellos han sido definidos con anterioridad en las diferentes tablas lo que permite que rellenar los campos dependa de desplegar listas con posibles valores. Además, nos encontramos con campos que no he visto antes en ninguna otra tabla y que son específicos de los pacientes, que son el usuario y la contraseña con las que se van a identificar frente al bot. Si los datos son erróneos, el control de acceso integrado en el bot nos va a denegar el acceso a nuestra tele-rehabilitación. Por último, cada paciente está asociado a un terapeuta. Como ya hemos explicado anteriormente, solo el terapeuta que este asociado a un paciente puede ver sus sesiones, su perfil, etc. Por eso es necesario crear esta unión de campos en esta tabla. Tabla 15. Pacientes Campo Tipo de dato Descripción ¿Es obligatorio? nombre CharField(20) Nombre de usuario del terapeuta para el acceso a la app Sí apellidos CharField(40) Apellidos del terapeuta Sí fechaNacimiento DateField Fecha de nacimiento del paciente Sí diagnostico CharField(40) Selección del diagnostico Sí macs CharField(40) Selección de las MACS Sí gmfcs CharField(40) Selección de la GMFCS Sí calificacion5 CharField(40) Selección de la calificación FMS para 5 metros Sí calificacion50 CharField(40) Selección de la calificación FMS para 50 metros Sí calificacion500 CharField(40) Selección de la calificación FMS para 500 metros Sí usuario CharField(30) Usuario para el uso del bot Sí contraseña CharField(10) Contraseña para el uso del bot Sí terapeuta CharField(30) Terapeuta asignado al paciente Sí visible BooleanField(Por defecto: True) Permite hacer no visible un ejercicio en una situación determinada Sí creado DateTimeField Momento de creación Auto-rellenado actualizado DateTimeField Momento de actualización Auto-rellenado Sesiones En la tabla sesiones somos capaces de generar una nueva sesión con ejercicios para un paciente. En ella indicamos el paciente al que va dirigida, para cuando está programado su inicio y su fin y los ejercicios con las respectivas repeticiones que debe de realizar. En esta tabla solo se encuentra el campo ejercicios puesto que está diseñado de tal manera que se ha creado una relación ManyToMany en la que se ha introducido el campo de repeticiones 54 (lo podemos ver en la Tabla 17) Además el terapeuta va a poder generar y enviar sesiones cuando crea conveniente gracias al campo “enviado”, con el que podrá ver si la sesión se ha enviado al paciente o aún no. Y aunque no aparezca en la tabla, el sistema muestra un mensaje de Activo si la sesión se encuentra aun dentro de las fechas indicadas en la tabla. La forma de mostrarlo es a través de la interfaz de la aplicación web. Tabla 16. Sesiones Campo Tipo de dato Descripción ¿Es obligatorio? paciente CharField (20) Nombre de paciente al que le asignamos la sesión Sí ejercicios CharField (60) Ejercicios que tendrá la sesión Sí periodicidad IntegerField Número de repeticiones de la sesión Sí fechaInicial DateField Fecha de inicio de la sesión Sí fechaFinal DateField Fecha de finalización de la sesión Sí terapeuta CharField (30) Terapeuta asignado al paciente Sí visible BooleanField (Por defecto: True) Permite hacer no visible una sesion en una situación determinada Sí enviado BooleanField (Por defecto: False) Indica si la sesión ya ha sido enviada al paciente Sí creado DateTimeField Momento de creación Auto-rellenado actualizado DateTimeField Momento de actualización Auto-rellenado Sesiones Ejercicios Como ya hemos comentado, esta tabla se encuentra ligada al campo “ejercicios” de la tabla “sesiones”, como consecuenci a de la relación ManyToMany que existe entre ellas. Se compone de tres campos que relacionan los ejercicios con la sesión y se añade como extra el campo de “repeticiones” que nos permite definir el número de r epeticiones que debe hacer el usuario por cada ejercicio. Tabla 17. Sesiones Ejercicios Campo Tipo de dato Descripción ¿Es obligatorio? ejercicios IntegerField Nombre de los ejercicios que se asocian a la sesión Sí sesiones IntegerField Indica la sesión a la que se asocian los ejercicios Sí repeticiones SmallIntegerField Número de repeticiones de cada ejercicio dentro de la sesión Sí 55 Hasta aquí habríamos visto una comunicación terapeuta → paciente, en ese sentido, ya que los datos que aparecen en las tablas los han generado los terapeutas para los pacientes. De los cuales no todos los datos son mostrados/enviados a los pacientes, pero si se usan para crear perfiles de ellos en el sistema y definir tipo de sesiones y ejercicios que van a realizar. Ahora tenemos que hablar de las ultimas tablas que forman parte de la base de datos en el punto en el que se produce la comunicación desde el paciente al terapeuta. Estamos hablando del envío del feedback por parte del paciente. Parte del contenido se autogenera gracias a la programación del bot y por lo tanto muchos datos son recogidos y enviados a los terapeutas de forma transparente al paciente. Un ejemplo de ello son las horas en las que el paciente inicia la sesión, empieza un ejercicio o cuántas veces repite el ejercicio. El contenido de las tablas se introduce en el sistema de forma automática según la programación horaria que este configurada, y por lo tanto, no necesita intervención por ninguna de las partes. Ejercicios realizados Los ejercicios que el paciente realiza durante la sesión se registran en la siguiente tabla. Gracias a ello el terapeuta sabe en todo momento si el usuario ha realizado los ejercicios que ha programado para cada sesión. Los datos que ofrece esta tabla son el ejercicio programado, la fecha completa en la que ha realizado el ejercicio y la sesión a la que pertenece ese ejercicio. Este último campo es muy importante ya que asocia el ejercicio con la sesión a la que pertenece. Tabla 18. Ejercicios realizados Campo Tipo de dato Descripción ¿Es obligatorio? ejercicio CharField (80) Nombre del ejercicio que ha realizado el usuario Sí fecha CharField (30) Fecha y hora en la que se realiza el ejercicio Sí sesion IntegerField ID de la sesión Sí Registro de las sesiones Las sesiones al igual que los ejercicios llevan asociado un registro, en él los terapeutas pueden ver el tiempo transcurrido desde que empezó la sesión hasta que la finaliza. Además de ello, en esta tabla se recogen los comentarios generales que el paciente puede incluir al final de la sesión, como por ejemplo quejas o problemas que le hayan surgido durante la sesión. 56 Tabla 19. Registro de las sesiones Campo Tipo de dato Descripción ¿Es obligatorio? fechaI CharField (30) Fecha y hora de inicio de la sesión Sí fechaF CharField (30) Fecha y hora de finalización de la sesión Sí sesion IntegerField ID de la sesión Sí comentario CharField (100) Comentarios sobre la sesión para el terapeuta Sí Formulario de pacientes En esta tabla se recoge un formulario con las preferencias para la realización de las sesiones. Por defecto, se completa la primera vez que el paciente inicia el bot. Más adelante siempre tiene la posibilidad de actualizar los datos. Con ello el terapeuta va a saber el día o días preferidos, las horas en las que se va a poder realizar la sesión y el momento del día que prefiere, mañana o tarde. Tabla 20. Formulario de pacientes Campo Tipo de dato Descripción ¿Es obligatorio? dia CharField (100) Días preferidos por el usuario para hacer la rehabilitación desde casa Sí momento CharField (30) Momento del día para realizar la sesión: mañana o tarde Sí horas CharField (30) Horas preferidas para realizar la sesión Sí usuario CharField (30) Nombre del usuario Sí idUser IntegerField ID del usuario Sí Valoración de los pacientes Las valoraciones individuales de cada ejercicio son recogidas y almacenadas en esta tabla. Esta información es utilizada por el terapeuta para conocer de primera mano las sensaciones del paciente. Se recogen al final de cada ejercicio, exceptuando si el ejercicio ya ha sido valorado en esa misma sesión. Estos datos permiten visualizar la evolución del paciente en cuanto a realización de ejercicios se refiere, ya que se pueden comparar las valoraciones de los ejercicios en tiempos diferentes. Se puede hacer puesto que las valoraciones están sujetas a un ejercicio y a una sesión en concreto, y a su vez existe un registro de fecha en la que se ha producido la valoración. 57 Tabla 21. Valoración de los pacientes Campo Tipo de dato Descripción ¿Es obligatorio? usuario CharField (100) Paciente que realiza la valoración Sí ejercicio CharField (30) Ejercicio que se valora Sí valoracion1 IntegerField Valoración de la primera pregunta Sí valoracion2 IntegerField Valoración de la segunda pregunta Sí valoracion3 IntegerField Valoración de la tercera pregunta Sí valoracion4 IntegerField Valoración de la cuarta pregunta Sí valoracion5 IntegerField Valoración de la quinta pregunta Sí fecha CharField(30) Fecha y hora de la valoración Sí sesion IntegerField ID de la sesión Sí Una vez se han presentado las tablas que forman la base de datos debemos conocer cómo se relacionan entre sí y para ello disponemos de la imagen 31 en la que podemos ver la relación que existe entre cada una de ellas, los tipos de datos que almacenan, etc. 64 Además de todo ello, el sistema incluye sistemas de seguridad para mantener la integridad de la base de datos, gracias en parte al sistema de copias de seguridad y a la monitorización de cambios en los modelos por parte de Django. En las siguientes secciones se desarrollan cada uno de los servicios que acabamos de nombrar y se detallan más a fondo las características de cada uno de ellos. 4.1. Amazon EC2 La instancia Una vez tenemos diseñado el sistema lo que hay que hacer es crear una instancia. Para ello desde la consola de AWS seguiremos los pasos que nos da el asistente. Primero debemos de seleccionar una imagen para cargar el sistema operativo o lo que en Amazon se denomina una AMI (Amazon Machine Image). Disponemos de gran cantidad de imágenes, muchas de ellas son específicas para ciertas aplicaciones y otras son más comunes para cualquier aplicación. En nuestro caso hemos seleccionado “Debian 10 Buster”. Después debemos de elegir entre los diversos tipos de instancia que tenemos a nuestra disposición. Las características a tener en cuenta a la hora de elegir un tipo u otro están relacionadas directamente con la funcionalidad que vaya a tener nuestra aplicación. Podemos escoger más memoria menos memoria, más CPU menos CPU… dependiendo de lo que necesitemos. En el proyecto se ha escogido una instancia básica, una t3.small, que nos ofrece muy buenas prestaciones para lo que nuestra aplicación va a requerir. Las características son las siguientes: • 2 CPU virtuales con 2Gib RAM • 30 GiB de memoria • Hasta 5 gigabits de velocidad de transferencia de datos Además, AWS siempre nos ofrece escalabilidad en sus instancias, por lo que cambiar de una instancia a otra no supone ningún esfuerzo si nuestro sistema lo requiere. Una vez seleccionada la instancia debemos de añadir seguridad a nuestro sistema, esto se hace creando grupos de seguridad dentro de la instancia que actúan como un firewall, creándole reglas. Por lo que disponemos de reglas de entrada y reglas de salida que podemos configurar. En nuestra instancia se han configurado las siguientes reglas: ENTRADA • Acceso por el protocolo HTTP desde cualquier dirección IP • Acceso por el protocolo HTTPS desde cualquier dirección IP • Acceso por el protocolo SSH desde cualquier dirección IP, para poder acceder a la instancia, configurarla, etc SALIDA • Se permite todo el tráfico. Como acabo de detallar el acceso a la instancia se realiza por SSH, todo ello para poder configurarla, acceder a los servicios y en definitiva controlar a nuestro antojo la instancia. 65 Cuando acabamos de configurar la instancia es obligatorio obtener un par de claves públicoprivada para acceder por SSH a nuestra instancia. Y es que es necesario que la comunicación este cifrada para poder acceder a ella. Para ello se define el Rol IAM (Identity and Access Management) en el que podemos configurar el acceso que damos a cada uno de los usuarios que vayan a acceder a la instancia y los permisos que les damos a cada uno de ellos, gracias a las políticas de acceso. En este caso, soy el único usuario con credenciales y mi rol tiene activada la política de acceso total a la instancia. En cuanto hayamos configurado todo correctamente podemos acceder a nuestra instancia y comprobar que podemos acceder a todos los servicios. La aplicación Para acceder a nuestra aplicación web disponemos de un servidor web que se encuentra alojado dentro de nuestra instancia. El servidor web que está funcionando en este sistema es Apache y es el encargado de recibir todas las peticiones del exterior y servir la información a los usuarios. Para ello lo que debemos de hacer es instalar en nuestra instancia el servidor Apache. Una vez lo tengamos configurado, lo que debemos de hacer es servir los datos de la aplicación web y para ello debemos de conectar Apache con el framework Django. Para realizar esa conexión entre ambas tecnologías lo que debemos de configurar es el archivo settings.py de Django y Apache haciendo uso del mod_wsgi. Desde la documentación de Django nos ofrecen ya las líneas de configuración que deben de ir ubicadas en la configuración del host virtual dentro de Apache y que son las siguientes: WSGIScriptAlias / /path/to/mysite.com/mysite/wsgi.py WSGIPythonHome /path/to/venv WSGIPythonPath /path/to/mysite.com <Directory /path/to/mysite.com/mysite> <Files wsgi.py> Require all granted </Files> </Directory> Finalmente, el host virtual configurado para nuestra aplicación web en Apache es el siguiente: <IfModule mod_ssl.c> <VirtualHost *:443> ServerName www.rehabot.twyncare.com:443 ServerAdmin [email protected] ServerAlias rehabot.twyncare.com DocumentRoot /home/admin/rehabilitacion <Directory /home/admin/rehabilitacion> Require all granted </Directory> #Cabe destacar que usamos el path a python de nuestro virtualenv WSGIDaemonProcess rehabilitacion python-home=/home/admin/developer pythonpath=/home/admin/rehabilitacion 66 WSGIProcessGroup rehabilitacion WSGIScriptAlias / /home/admin/rehabilitacion/rehabilitacion/wsgi.py Alias /static/ /home/admin/rehabilitacion/rehabilitacion_app/static/ Alias /media/ /home/admin/rehabilitacion/media/ <Directory /home/admin/rehabilitacion/rehabilitacion_app/static/> Require all granted </Directory> <Directory /home/admin/rehabilitacion/media/> Require all granted </Directory> <Directory /home/admin/rehabilitacion/rehabilitacion> <Files wsgi.py> Require all granted </Files> </Directory> ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined Include /etc/letsencrypt/options-ssl-apache.conf ServerAlias www.rehabot.twyncare.com SSLCertificateFile /etc/letsencrypt/live/rehabot.twyncare.com/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/rehabot.twyncare.com/privkey.pem </VirtualHost> </IfModule> Además de la configuración de Apache, para que la comunicación entre Django y Apache se pueda realizar debemos de indicar dentro de Django en el fichero wsgi.py las siguientes líneas de código que indican los path donde debe buscar Apache los contenidos que la aplicación debe servir: import os import sys from django.core.wsgi import get_wsgi_application # path a donde está el manage.py de nuestro proyecto Django sys.path.append('/home/admin/rehabilitacion/') # referencia (en python) desde el path anterior al fichero settings.py # Importante hacerlo asi, si hay varias instancias coriendo (en lugar de setdefault) os.environ['DJANGO_SETTINGS_MODULE'] = "rehabilitacion.settings" # prevenimos UnicodeEncodeError os.environ.setdefault("LANG", "en_US.UTF-8") os.environ.setdefault("LC_ALL", "en_US.UTF-8") application = get_wsgi_application() Con estos cambios no estaría todo resuelto, sino que Django nos obliga a realizar ciertas variaciones de seguridad en el fichero settings.py las cuales se corresponde con: 67 • Debug a FALSE • Conexiones SSL activadas • Indicación de los hosts desde los que se tiene acceso • Parámetros relacionados con las Cookies • Indicar la URL de nuestra aplicación Una vez tengamos todo ello configurado, podemos poner en funcionamiento el servidor y deberíamos ser capaces de acceder a ella desde cualquier dispositivo. La Base de Datos Respecto a la base de datos de la aplicación también se encuentra disponible dentro de la propia instancia. Como expuse en capítulos anteriores el número de sistemas de gestión de bases de datos es inmenso. En el caso de este sistema se usa MariaDB, ya que nos ofrece una gestión sencilla, consultas muy agiles y seguridad. Para ello lo primero que debemos de hacer es instalar MariaDB en nuestra instancia. Una vez lo tengamos instalado, debemos de proceder a su configuración. Antes de configurar el acceso debemos de haber creado ya nuestra base de datos como en el siguiente ejemplo: MariaDB [(none)]> CREATE DATABASE <nombre_base_datos>; Después creamos un usuario y contraseña para acceder a todas las funciones de la base de datos, para ello se usa el siguiente comando: GRANT ALL ON <nombre_base_datos>.* TO ‘usuario’@’localhost’ IDENTIFIED BY ‘contraseña’ WITH GRANT OPTION; Con el anterior comando conseguimos el acceso total a la base de datos que hemos indicado y para acceder a ella necesitaremos usar las credenciales que se han configurado en el comando. Finalmente, para entrar usaremos: mysql -u <nombre_usuario> -p Y el sistema nos solicitará la contraseña. Una vez tengamos configurado un perfil de acceso a la base de datos debemos integrar en Django las credenciales de acceso. Antes de continuar, quiero destacar que en este sistema vamos a tener 2 gestores de la base de datos. Por un lado, tenemos el sistema nativo de MariaDB, que nos permite realizar cualquier acción sobre la base de datos que nosotros necesitemos, teniendo en cuenta que se trabaja con comandos. Pero por otro lado vamos a tener un acceso a alto nivel gracias a Django. Lo que hacemos es integrar la base de datos (credenciales) en Django y gracias a la arquitectura de Django automáticamente cuando creemos un modelo (tabla dentro de la base de datos) lo que en realidad estamos haciendo es evitar usar un comando para crear esa tabla y usar las opciones que Django incluye para crear tablas y las respetivas relaciones entre ellas. Todo ello se consigue a través de líneas de código Python muy sencillas que después se integran en un sitio de administración de Django en el que consultar los datos de una de las tablas se consigue haciendo un ‘clic’. Una vez comprendido la estructura de funcionamiento de la base de datos, lo único que hay que hacer es en el archivo de configuración de Django introducir los datos de acceso a la 68 base de datos que queramos usar. Los datos que se solicitan por parte de Django son los siguientes: • ENGINE, hay que indicar el tipo de gestor de base de datos que usamos (PostgreSQL por defecto). • NAME, nombre la base de datos a la que nos vamos a conectar. • USER, usuario de acceso previamente configurado. • PASSWORD, contraseña de acceso previamente configurado. • HOST, por lo general desde ‘localhost’. • PORT, puerto que usemos para acceder a ella. Después, gracias a los modelos que usa Django, podemos crear las tablas que la aplicación requiera de forma sencilla. Como medida de seguridad ante el tratamiento de datos clínicos que son de gran sensibilidad, se han programado copias de seguridad de la base de datos en un almacenamiento de AWS, dentro de un bucket S3, del cual hablaremos en el siguiente apartado. 4.2. Bucket S3 En los anteriores capítulos hemos hablado de usar bucket S3 para el almacenamiento de los videos, los ficheros con los datos de la aplicación y las copias de seguridad de la base de datos. De esta forma liberamos al servidor web de tener que almacenar esos datos con lo que ello conlleva. Lo primero que debemos hacer es acceder a la consola de AWS y entrar al apartado de S3. Una vez dentro seleccionamos la opción de crear un bucket S3, nos solicitará un nombre y este debe de cumplir con los siguientes requisitos: ▪ Ser único en todo Amazon S3 ▪ Tener entre 3 y 63 caracteres ▪ Sin usar mayúsculas ▪ Comenzar por una letra minúscula o un número Después deberemos elegir una región disponible de AWS en la que almacenar el bucket. Hay que tener en cuenta que cuanto menor sea la distancia mejor será la experiencia de usuario en cuanto a latencia y coste. En cualquier caso, se podrán transferir de una región a otra según lo necesitemos. A partir de este momento tendremos la posibilidad de añadir objetos a él. Los tipos de objetos que pueden almacenarse van desde ficheros de texto hasta contenido multimedia. Tendremos también la posibilidad de regular el acceso a los datos gracias al uso de políticas de acceso. En el siguiente apartado hablaremos de cómo se accede a los datos que están almacenados en el bucket de S3 desde la Raspberry Pi, que en realidad se hace de la misma forma que cuando se suben a él desde la aplicación web. 69 4.3. Raspberry Pi 4 Por último, hablaremos del componente que se sitúa en el lado del paciente, la Raspberry Pi. Este pequeño ordenador es el encargo de interactuar con el paciente y ser su acompañante durante la realización de los ejercicios. Como sabemos este microordenador se caracteriza por ser muy polivalente a la hora de desarrollar sistemas con cualquier finalidad. Además, su bajo coste lo convierte en una verdadera opción a tener en cuenta cuando queremos desarrollar ciertos proyectos. En este caso, se adapta perfectamente a las necesidades que debe de tener el sistema, pero siempre siendo conocedores de sus limitaciones. Por otro lado, la elección de esta tecnología se vio condicionada a que nos permite integrar la API de Telegram en el sistema y de esta manera poder desarrollar uno de los puntos clave de nuestro sistema como es el bot de Telegram. Una vez hemos descrito los requisitos que cumple, veremos cómo es el proceso de despliegue de la aplicación en la Raspberry Pi. Primero, como en cualquier ordenador necesitamos un sistema operativo, en este caso se ha instalado Raspberry Pi OS with desktop. Una vez se configura los parámetros principales del sistema operativo ya podemos acceder a nuestra Raspberry. Los diferentes paquetes que se han instalado en la Raspberry Pi son los siguientes: ▪ git clone --branch master https://github.com/javieru14/BotRehabilitacion ▪ sudo apt install python3 python3-pip python3-setuptools ▪ pip3 install awscli --upgrade --user ▪ Visual Studio Code ▪ pip3 install Schedule Para entender mejor cada uno de ellos vamos a ir detallando la función que realizan en nuestra aplicación. El primero de ellos no es más que una clonación de un repositorio en github que contiene la API de Telegram con la que funciona el bot. En el segundo comando, lo que se observa es la instalación de Python que es el lenguaje en el que está desarrollada la aplicación casi por completo, en este caso estamos hablando de versión 3 de Python. Además, se lleva a cabo la instalación de paquetes complementarios para el correcto funcionamiento de Python. En el siguiente comando lo que se instala, como comentamos en el apartado 5.2, la descarga y subida de objetos al bucket S3 se hace a través de un CLI(Command Line Interface) de AWS en el que existen una serie de comandos que nos permiten interactuar con el bucket. Los comandos utilizados son los siguientes: Para la subida: aws s3 sync <source> <target> [--options] Para la descarga: aws s3 sync <target> <source> [--options] Como podemos observar lo único que cambia es el objetivo que tenemos en el comando. Realmente no se suben o se bajan, sino que se define como una sincronización de los objetos 70 en los que podemos detallar que se sobrescriban o se borren si no existen gracias al apartado de options. En cuanto a la finalidad que le damos a estos comandos es de gran importancia debido a que se encargan de actualizar los ficheros que se “envían” los pacientes y los terapeutas entre ellos. La forma que tienen de ejecutarse es de manera automática por medio de scripts programados a ciertas horas en las que actúan. Continuando por el cuarto paquete que debemos instalar, nos encontramos con Visual Studio Code. Su instalación no es necesaria, pero es conveniente para hacer comprobaciones de funcionamiento del código del bot en caso de error. Para finalizar, existe una segunda aplicación que está directamente relacionada con el uso del bot. Se encarga de recordar a los usuarios, en los días preferidos de rehabilitación, que que tienen programada una sesión por parte de su terapeuta. Esta funcionalidad incluye un valor añadido a la aplicación principal ya que mantiene activa la participación de los pacientes en la realización de la tele-rehabilitación. Por ello el paquete schedule es tan importante, porque nos permite crear recordatorios basándose en la fecha de finalización de cada una de las sesiones de un paciente y la fecha actual en la que nos encontremos. Una vez instalados los paquetes que acabamos de describir, el sistema de ficheros de nuestra Raspberry debe de estructurarse según se ha establecido. El sistema está estructurado de tal forma que permite el despliegue en un Raspberry en varios minutos. Para ello se debe de clonar el siguiente repositorio en la raíz del usuario: git clone --branch master https://github.com/javieru14/ScriptsRehabilitacion.git Con ello conseguimos estructurar de manera adecuada todos los scripts que permiten que la aplicación funcione correctamente. Esos scripts son los que sincronizan los datos del paciente y terapeuta a través del CLI de S3 en nuestro bucket. Como sabemos el sistema que se ha desarrollado funciona automáticamente, por ello antes de finalizar el despliegue debemos de programar el funcionamiento de estos scripts que hacen funcionar la aplicación. Hay que tener en cuenta lo critico que es que estos scripts estén en funcionamiento ya que de lo contrario la aplicación podría sufrir fallos. Para ello se han programado una línea de comando por cada script que se debe ejecutar dentro de crontab, que no es más que un fichero de texto que contiene tareas programadas. Una vez está todo configurado, el funcionamiento de la aplicación es correcto y el sistema está completo. 4.4. Pruebas de funcionamiento Una vez tengamos los diferentes componentes del sistema configurados, la aplicación estará lista para usarse. Durante el periodo de pruebas de la aplicación se ha comprobado que la aplicación es robusta pero en ocasiones podremos encontramos con errores o fallos en el funcionamiento. Estos fallos se suelen deber en su gran mayoría a que alguna configuración esta deshabilitada y por ello el flujo de la aplicación da error. Un fallo muy común durante la fase de pruebas ha sido que el sistema no era capaz de reproducir el video, tras depurar el fallo a través de los logs configurados en el bot, el error se debía a una errata en el nombre del fichero que se quería abrir o en cuyo caso una mala sincronización con el servidor. Los fallos similares al que acabamos de nombrar no necesitan una depuración de muchas horas 71 puesto que si todos los componentes del sistema están funcionando no se va a dar ese problema. Cuando me refiero a este tipo de fallos, recojo los que han surgido a lo largo de las pruebas y mejoras del bot. Un largo proceso en el que se ha ido perfeccionando el funcionamiento del bot hasta el punto de robustez en el cual se encuentra ahora la aplicación. Por ello es de vital importancia que la configuración se realice de igual forma y en el mismo orden en el que se indica en el capítulo de despliegue. En cuanto a fallos diferentes a errores de nombres de ficheros o descargas incompletas de ficheros, el usuario puede que se encuentre con situaciones en la que el bot le envié un mensaje indicando: “ERROR: Bot en mantenimiento”. En ese caso existen varias formas de solucionar el problema. Teniendo en cuenta que el usuario no tiene por qué saber lo que ha pasado, para recuperar el funcionamiento normal de la aplicación el usuario debe de seguir los siguientes pasos: 1. Apagar la Raspberry Pi 2. Esperar unos segundos hasta que la pantalla este en negro completamente. 3. Encender la Raspberry Pi y esperar unos minutos a que se reinicien todos los servicios necesarios para el funcionamiento del bot. 4. Enviar de nuevo “/start” al bot desde Telegram y comenzar de nuevo la sesión. Si el error sigue saliendo en el mismo punto, debe comunicárselo a su terapeuta para que se ponga en contacto con el desarrollador, en este caso, conmigo. Gracias al sistema de logs que se ha desarrollado para el bot, sabemos en qué momento se ha producido el error, depurar con mayor facilidad el flujo de la conversación y acometer las acciones necesarias para solucionarlo. La experiencia en la depuración de fallos de la aplicación hace que la gran mayoría de ellos estén relacionados con nombres de ficheros mal escritos, caracteres especiales en los ficheros de las sesiones, videos con nombres repetidos que hacen que el sistema les añada caracteres para diferenciarlos, etc. Existen otro tipo de fallos que son cometidos por los humanos y que tienen fácil solución. Me refiero a errores, por ejemplo, como los de introducir mal las credenciales de acceso al bot de un paciente. En el caso de que se dé de alta un paciente y este introduzca o reciba unas credenciales que no se correspondan con las suyas, el sistema al tercer intento va a bloquear esa cuenta. Otro fallo similar a este podría ser en el que el usuario no configura adecuadamente su perfil de Telegram, en ese caso, cuando quiera entablar una conversación con el bot, este no le va a responder. Como podemos comprobar son errores que pueden darse, pero su solución implica poco tiempo y esfuerzo. Para evitar este tipo de fallos, se recomienda que tanto la configuración del perfil de Telegram como una prueba de conversación con el bot realice en la propia visita presencial al terapeuta. De esta forma, podemos evitar que se cometan este tipo de errores y conseguir un uso de la aplicación lo más ideal posible. 72 5. Conclusiones y líneas futuras En este capítulo detallaremos las conclusiones que se sacan tras diseñar, desarrollar, implementar y desplegar el sistema. Además, hablaremos del futuro que le depara al sistema en las siguientes actualizaciones de la aplicación. Conclusiones Desde el comienzo, el proyecto apuntaba hacia un horizonte con muchas posibilidades en el que necesitábamos desarrollar un sistema desde cero que cumpliera con los requisitos nombrados anteriormente. Tras completar la primera versión del sistema los resultados avalan una buena base para seguir avanzando y trabajando sobre ella. La aplicación se ha desarrollado haciendo uso de tecnologías de bajo coste como la Raspberry Pi y usando como plataforma de implementación la nube de Amazon, AWS; siempre pensando en ser un complemento más para las terapias convencionales. Tras lograr desarrollar esta primera versión del sistema de lo que estamos seguros es de que tiene muchos puntos fuertes que se pueden explotar. La elección de las tecnologías que han sido aplicadas en el desarrollo de la aplicación han sido clave para obtener un prototipo con la rapidez que se ha conseguido. Además, puedo asegurar que la escalabilidad de este proyecto es enorme, lo que le permitirá tener una vida útil más larga para poder seguir siendo desarrollada. En la actualidad, las aplicaciones que se ejecutan en la nube están a la orden del día y el proceso de digitalización que estamos viviendo permite que podamos estar conectados en cualquier momento a Internet. En el caso de la medicina, los avances son evidentes y nuestro sistema demuestra que es necesario adaptarnos a los nuevos cambios que estamos viviendo. Por ello, es importante que sepamos hacer uso de las herramientas que existen para que la vida de todos sea mucho más fácil. En este proyecto, lo que buscamos es optimizar los recursos que tenemos. En este caso, basta con tener acceso a internet para que los pacientes puedan rehabilitarse desde casa con el mismo o muy parecido seguimiento que desde las rehabilitaciones presenciales. De esta forma, los pacientes pueden realizar la rehabilitación junto con su terapeuta los días que tengan cita presencial y los días que no tengan cita lo podrán hacer desde su casa, optimizando así los recursos disponibles y progresando a mayor velocidad. De esta manera, el conjunto de tecnologías usadas para crear este sistema permite a los usuarios recibir las sesiones con los ejercicios de rehabilitación para realizarlos desde casa, obtener recordatorios para no olvidarse de las sesiones y enviar comentarios al terapeuta sobre los ejercicios o sesiones programadas. Por otro lado, esta herramienta ayuda a los terapeutas a continuar el seguimiento no presencial de las rehabilitaciones de sus pacientes, pudiendo crear, modificar o consultar la evolución o comentarios de los pacientes. Este proyecto ha supuesto un reto para mí y me ha servido como crecimiento profesional y personal. He asentado conocimientos en el desarrollo de aplicaciones, he aprendido a encontrar soluciones tecnológicas para las necesidades que acarreaba el sistema y además he sabido indagar en tecnologías que para mí resultaban desconocidas hasta el momento y de las que he adquirido nuevos conocimientos. Líneas Futuras Ante un proyecto de este calibre lo que más se espera es conseguir que evolucione a lo largo del tiempo, que incluya mayores servicios, mayor recogida de datos, más funcionalidades 73 que ayuden a los terapeutas y a los pacientes a continuar con su rehabilitación en cualquier circunstancia y de la mejor manera posible. Por ello desde esta primera versión podemos imaginarnos las líneas por las que el sistema puede crecer: Pantalla La pantalla es un accesorio del que se puede sacar mayor rendimiento y mayor usabilidad: • Interactividad: actualmente el uso la pantalla está limitado a los videos. En un futuro deberá convertirse en el accesorio principal que mantenga a los pacientes activos durante las sesiones. • Mayores funcionalidades: es posible que sea interesante convertir la pantalla en una “consola” desde la que funcione el sistema por completo, en la que podamos incluir juegos en los que los ejercicios de la sesión se realicen de igual forma, pero “jugando”. • Feedback: es importante mantener al paciente activo y sería muy buena forma de hacerlo si le vamos ofreciendo feedback o puntos al paciente, con la idea de crear recompensas por el esfuerzo que realiza. En líneas generales aprovecharnos de la interactividad que nos puede ofrecer el uso de cualquier pantalla táctil. Aplicación Web En general, el sistema permite una gran escalabilidad y la aplicación web permite abrirse por muchas vías de desarrollo: • Visualización: los terapeutas deben de poder visualizar de forma más sencilla los datos recogidos en la Raspberry Pi, como, por ejemplo, a través de gráficas en el que se recojan las medias de valoraciones de los ejercicios o la evolución de un paciente respecto a la dificultad que encuentra en un ejercicio. De esta forma, los terapeutas son capaces de actuar en consecuencia más rápidamente sobre las necesidades de cada paciente. • Funcionalidades: el sistema va a soportar las necesidades que vayan surgiendo, la implementación de estas será únicamente cuestión de tiempo de programación. Como, por ejemplo, crear un sistema de notificaciones que permita crear alertas según parámetros de satisfacción de sesiones o avisos de finalización de sesiones. Sensores Una de las vías próximas de desarrollo se encuentra en la adicción de sensores al sistema. Estos sensores se sitúan en el cuerpo del paciente para recoger los datos de los movimientos durante la realización de las sesiones. El envío de los datos de movimiento recogidos por los sensores mejoraría aun mas la comunicación entre en paciente y el terapeuta, ya que permitiría al terapeuta tener una mejor noción de lo sucedido durante la realización de los ejercicios y la evolución del paciente. El sistema actual es capaz de evolucionar para conseguir incluir una tecnología más dentro del sistema como son los sensores. Deberán recoger los datos al igual que en la actualidad se recoge el feedback de los usuarios, pero además en el servidor deberán de ser analizados 80 Imagen 39. Apariencia del bot con el que se comunican los pacientes. 2. Una vez hayamos encontrado el bot que nos corresponde, lo que debemos hacer para iniciar la conversación es escribir /start o pulsar en “Iniciar”. 3. En nuestra primera sesión nos pedirá la contraseña. Si es correcta, tendremos acceso a nuestras sesiones y el bot nos tendrá recordados para las siguientes sesiones. Si se produce algún error durante la configuración, por favor, comuníqueselo a su terapeuta. 81 Anexo 2 – Manual uso de aplicación web En este manual vamos a explicar que pasos deben seguir los terapeutas para los diferentes casos de uso de la aplicación web: 1. Crear pacientes, ejercicios o sesiones 2. Editar pacientes, ejercicios o sesiones 3. Ocultar pacientes, ejercicios o sesiones 4. Consultar pacientes 5. Consultar sesiones 6. Consultar lista de ejercicios 7. Consultar credenciales para el bot del paciente Caso de uso 1 - Crear pacientes, ejercicios o sesiones Para los tres casos la metodología es la misma y en cada uno de ellos tenemos dos caminos posibles para hacerlo. 1. Acceder a la aplicación web > En el caso de querer dar de alta un nuevo usuario pinchamos en el 1, si lo que queremos es crear un nuevo ejercicio seleccionamos el 2 y si en realidad lo que necesitamos es crear una sesión, pulsamos en 3. 2. Dentro de “Pacientes”, tendremos la opción en la esquina superior derecha de dar de alta a un paciente nuevo. Imagen 40. Página principal de la aplicación web. 82 3. Este enlace nos redirigirá al panel de administración de la aplicación al apartado de dar de alta a nuevos pacientes. Solo deberemos de rellenar todos los campos que sean necesarios y para finalizar pulsaremos en “Guardar”. Estos mismos pasos tendremos que hacer si queremos crear ejercicios o sesiones. De tal manera que todo ello lo podríamos hacer directamente accediendo al panel de administración de la aplicación. Imagen 41. Botón que nos permite añadir un nuevo paciente. Imagen 42. Panel de administración en el que damos de alta al paciente. 83 Para acceder al panel de administración se puede hacer a través de la siguiente url https://www.rehabot.twyncare.com/admin o también desde el menú principal de la aplicación. En el caso de no estar loggeados en la aplicación nos aparecerá en pantalla la siguiente ventana. Deberemos introducir las mismas credenciales que para acceder desde la aplicación web. Imagen 43. Dos formas de acceder al panel de administración. Imagen 44. Ventana de inicio de sesión en el panel de administración. 84 Una vez hayamos iniciado sesión accederemos a la página principal del panel de administración en la que se nos mostrarán las opciones a las que podemos acceder, pero en este caso nos vamos a centrar en nuestro caso de uso. Y como lo que queremos es añadir, deberemos pulsar en añadir. Como resultado de ello accederemos a la misma pantalla que hemos mostrado anteriormente. Caso de uso 2 - Editar pacientes, ejercicios o sesiones Al igual que en caso de uso número 1, lo primero que debemos hacer es acceder a la ventana en la que queremos modificar algo, es decir, un paciente, una sesión o un ejercicio. Y podemos hacerlo por dos vías, por la aplicación web o a través del panel de administración. El concepto es el mismo ya que para editar antes debe existir, por lo tanto, debemos de encontrar lo que queremos modificar. Siguiendo esa filosofía, lo primero que haremos es buscar. En este ejemplo buscaremos un paciente en concreto. 1. En primer lugar, en el caso de que la lista sea muy larga, tenemos la opción de buscar y filtrar la búsqueda. Cuando hayamos encontrado lo que nos gustaría editar debemos de pulsar en “Editar Paciente”. Podemos crear tantos usuarios, ejercicios o sesiones como queramos, pero en el caso de las sesiones solo podremos enviar de una en una. Es decir, si quiero enviar dos sesiones a la vez el sistema me va a dejar, pero el usuario va a recibir la última puesto que el sistema nos sobrescribe los datos en el servidor y se queda con la última sesión. Como solución tenemos la opción de crear muchas sesiones pensando a largo plazo, pero ir enviando las sesiones de una en una. Imagen 45. Acceso a las secciones de Ejercicios, Pacientes y Sesiones desde el panel de administración. 85 Imagen 46. Botón que nos permite editar los datos de un paciente. 2. Como ya hemos visto antes este enlace nos lleva directamente al panel de administración donde podremos editar los datos del paciente. 3. Existe otra posibilidad de hacerlo y es que, si en vez de estar en esa ventana decidimos primero ver más detalles sobre el paciente, accederemos a la siguiente pantalla, a través del botón “Ver más”, donde también es posible editar el paciente. La diferencia entre crear y editar es que en la edición veremos los campos rellenos con los datos actuales y en la creación están vacíos esperando a ser rellenados. Una vez realizados los cambios se pulsa en “Guardar” y los cambios se habrán efectuado. Al igual que en la creación podemos acceder directamente al panel de administración y desde allí seleccionar el paciente, ejercicio o sesión que queramos modificar. Imagen 47. Segunda opción de editar los datos de un paciente. 86 Es muy importante tener en cuenta que, si queremos modificar una sesión, primero debemos comprobar que no haya sido ya enviada al paciente, porque si está enviada el paciente va a recibir la primera sesión. Hay dos maneras de solucionarlo: 1. Si la sesión se ha enviado por error, tenemos hasta las 23:59 de ese mismo día para modificarla y enviar la sesión rectificada. Tendríamos que acceder a la sesión, realizar los cambios y desmarcar la casilla de “Enviado”. Después dentro de Sesiones > Enviar Sesión (La que hemos modificado). 2. Si la sesión se quiere modificar y han pasado de las 00:00. Lo que tenemos que hacer es crear una nueva sesión y a las 00:00 de ese mismo día se actualizará en el servidor y el usuario recibirá la nueva sesión al día siguiente. Caso de uso 3 - Ocultar pacientes, ejercicios o sesiones Dentro de la aplicación web existe una opción que nos permite ocultar elementos de la ventana principal de pacientes, ejercicios y sesiones. Lo que conseguimos es ocultar esos datos en la ventana principal si se da un caso excepcional, como, por ejemplo, un paciente que abandona el sistema tele-rehabilitación. Si después quisiera retomar este camino, no tendríamos que volver a dar de alta el usuario bastaría con desactivar la ocultación. 1. Accedemos a la ventana en la queremos ocultar elementos. 2. Seleccionamos el elemento que queremos ocultar. Imagen 48. Acceso a los datos de un paciente para cambiar su estado de visible a oculto. 87 3. Ocultamos el elemento, en este caso, un paciente. Para ello desmarcamos la casilla “Sin ocultar”. 4. Después podremos consultar los pacientes ocultos desde el siguiente enlace. Imagen 49. Casilla que se debe desmarcar para ocultar a un paciente. Imagen 50. Botón desde el que podemos ver los pacientes ocultos que tenemos. 88 Observaremos algo similar a lo siguiente. 5. En el caso de querer volver a mostrarlo simplemente repetiremos los pasos, pero en este caso marcaremos la casilla “Sin ocultar”. Caso de uso 4 - Consultar pacientes Desde el menú principal de pacientes tendremos acceso para consultar la información resumida de nuestros pacientes. En el caso de querer obtener información más detallada tendremos que seleccionar el enlace “Ver más” del paciente que queramos. Una vez dentro de la información detallada del paciente podremos consultar la siguiente información. Imagen 52. Información detallada que se muestra de cada uno de los pacientes. 1 – Información detallada del paciente 2 – Momento preferido para realizar la tele-rehabilitación 3 – Sesiones asociadas al paciente, tanto las activas como las no activas en ese momento Imagen 51. Página que muestra un listado de los pacientes ocultos. 89 4 – Historia clínica (En esta versión del sistema no está desarrollada) 5 – Usuario y contraseña asociados al paciente para usar en Telegram – Bot Caso de uso 5 - Consultar sesiones En el caso de que queramos consultar las sesiones que hemos programado a nuestros pacientes, podemos hacerlo desde el Menú principal > Sesiones > Consultar. Una vez dentro nos encontraremos con los siguientes datos. Imagen 53. Información de las sesiones dividas en tres secciones: resumen, detallado e informe. Resumen – disponemos de la información resumida de la sesión: paciente al que se le asigna la sesión y fecha de inicio y final de la sesión. Detallado – contiene la información resumida más los detalles de los ejercicios y repeticiones que se han seleccionado para ese paciente. Informe – una vez la sesión ha sido completada, los datos recogidos por el bot se muestran en el siguiente orden: comienzo y final de la sesión, fecha y hora de cuando han sido realizados los ejercicios y las valoraciones de cada ejercicio. Además, podemos consultar que sesión esta activa y cual no. Una sesión se encuentra activa si la fecha actual es superior a la fecha final de la sesión, es decir, si estamos dentro del plazo de tiempo para el que se ha programado esa sesión. Caso de uso 6 - Consultar lista de ejercicios El último tipo de consultas que podemos realizar es el de los ejercicios. Una vez dentro de la ventana de ejercicios podemos ver información resumida o información detallada de ellos.