Implementação de serviços Confort@Home

Universidade do Minho Escola de Engenharia Carlos Miguel Azevedo Magalhães Implementação de serviços Confort@Home Outubro de 2022 Universidade do Minho Escola de Engenharia Carlos Miguel Azevedo Magalhães Implementação de serviços Confort@Home Dissertação de Mestrado Mestrado em Engenharia Informática Trabalho efetuado sob a orientação de: José Manuel Ferreira Machado Outubro de 2022 DIREITOS DE AUTOR E CONDIÇÕES DE UTILIZAÇÃO DO TRABALHO POR TERCEIROS Este é um trabalho académico que pode ser utilizado por terceiros desde que respeitadas as regras e boas práticas internacionalmente aceites, no que concerne aos direitos de autor e direitos conexos. Assim, o presente trabalho pode ser utilizado nos termos previstos na licença abaixo indicada. Caso o utilizador necessite de permissão para poder fazer um uso do trabalho em condições não previstas no licenciamento indicado, deverá contactar o autor, através do RepositoriUM da Universidade do Minho. Licença concedida aos utilizadores deste trabalho Creative Commons Atribuição-NãoComercial-CompartilhaIgual 4.0 Internacional CC BY-NC-SA 4.0 https://creativecommons.org/licenses/by-nc-sa/4.0/deed.pt iii Agradecimentos Em primeiro lugar quero deixar um agradecimento à minha família, em especial aos meus pais, por todo o apoio e sacrifício que fizeram ao longo destes anos, por me proporcionarem todas as condições para a conclusão deste percurso e pelo apoio moral, amor e dedicação. À minha namorada e amigos por toda a compreensão e motivação, por me acompanharem ao longo destes anos, tornando o meu percurso académico inesquecível. Quero agradecer ao Professor José Machado pela orientação e sugestões que melhoraram esta dissertação. Por fim, quero agradecer à empresa Altice Labs , em especial à Telma Mota e à equipa do SmartAL , pela sugestão deste tema de dissertação, pela confiança depositada e por todo o apoio e conhecimento transmitido durante a realização deste trabalho. v DECLARAÇÃO DE INTEGRIDADE Declaro ter atuado com integridade na elaboração do presente trabalho académico e confirmo que não recorri à prática de plágio nem a qualquer forma de utilização indevida ou falsificação de informações ou resultados em nenhuma das etapas conducente à sua elaboração. Mais declaro que conheço e que respeitei o Código de Conduta Ética da Universidade do Minho. , (Local) (Data) (Carlos Miguel Azevedo Magalhães) vii 3.5.2 CriarDependente ............................ 30 3.5.3 CriarDispositivo ............................. 31 3.5.4 Visualizar Localização dos Dependentes . . . . . . . . . . . . . . . . . . 31 3.5.5 Criar Cerca Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.5.6 Verificar Localização dos Dependentes . . . . . . . . . . . . . . . . . . 33 3.6 ModelodeDados................................. 34 3.6.1 Entities ................................. 34 3.6.2 Outdoor ................................. 36 3.6.3 Geofences................................ 37 3.6.4 Notifications............................... 38 4 Implementação da Aplicação 39 4.1 Arquitetura Tecnológica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.1.1 React .................................. 40 4.1.2 Node.js ................................. 41 4.1.3 Prisma.................................. 42 4.1.4 PostgreSQL ............................... 43 4.1.5 RabbitMQ ................................ 43 4.1.6 Docker.................................. 43 4.1.7 Github.................................. 44 4.1.8 Postman................................. 44 4.1.9 GoogleCloud............................... 44 4.2 Implementação de Microsserviços . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.2.1 Notifications............................... 45 4.2.2 Outdoor ................................. 48 4.2.3 Geofences................................ 57 4.3 InterfacedoUtilizador............................... 65 4.4 Deployment.................................... 76 5 Conclusões e Trabalho Futuro 79 5.1 Conclusões.................................... 79 5.2 TrabalhoFuturo.................................. 80 Bibliografia 81 xiv Índice de Figuras 1 Design Science Research Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 ArquiteturaFuncional................................. 28 3 Diagrama de Sequência: Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4 Diagrama de Sequência: Criar Dependente . . . . . . . . . . . . . . . . . . . . . . 30 5 Diagrama de Sequência: Criar Dispositivo . . . . . . . . . . . . . . . . . . . . . . . 31 6 Diagrama de Sequência: Visualizar Localização dos Dependentes . . . . . . . . . . . 32 7 Diagrama de Sequência: Criar Cerca Virtual . . . . . . . . . . . . . . . . . . . . . . 32 8 Diagrama de Sequência: Verificar Localização dos Dependentes . . . . . . . . . . . . 33 9 ModelodeDados:Entities .............................. 35 10 ModelodeDados:Outdoor .............................. 36 11 Modelo de Dados: Geofences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 12 Modelo de Dados: Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 13 ArquiteturaTecnológica................................ 40 14 Estrutura do serviço Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 15 Estrutura de uma notificação de geofences ...................... 47 16 Estrutura do serviço Outdoor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 17 DeviceValidator.ts................................... 49 18 LocationValidator.ts.................................. 50 19 ExpressAuthTokenValidator.ts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 20 Classe Device em TypeScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 21 RotaPOST/createDevice............................... 53 22 Função do Controller createDevice . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 23 Verificação das Geofences na função newLiveEvent . . . . . . . . . . . . . . . . . . 55 24 Envio de alerta sobre cercas-virtuais para o RabbitMQ . . . . . . . . . . . . . . . . . 55 25 Envio de alerta sobre queda para o RabbitMQ . . . . . . . . . . . . . . . . . . . . . 56 26 Função do Service createDevice . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 xv 27 Estrutura do serviço Geofences . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 28 Classe Geofence em TypeScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 29 Rota POST /createGeofence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 30 Função do Controller createGeofence . . . . . . . . . . . . . . . . . . . . . . . . . 60 31 Verificação da Posição numa Cerca circular . . . . . . . . . . . . . . . . . . . . . . 62 32 Verificação da Posição numa Cerca poligonal . . . . . . . . . . . . . . . . . . . . . 63 33 Loop de verificação de posição . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 34 Resposta de alerta de saída de uma cerca . . . . . . . . . . . . . . . . . . . . . . . 64 35 Função do Service createGeofence . . . . . . . . . . . . . . . . . . . . . . . . . . 65 36 Aplicação - Página de Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 37 Aplicação - Página de Registo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 38 Aplicação - Primeiro Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 39 Aplicação - Dados Pessoais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 40 Aplicação - Página Principal sem Dependentes . . . . . . . . . . . . . . . . . . . . . 68 41 Aplicação - Adicionar Dependente . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 42 Aplicação - Adicionar Dispositivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 43 Aplicação - Página Principal com Dependentes . . . . . . . . . . . . . . . . . . . . . 70 44 Aplicação - Página Conta Cuidador . . . . . . . . . . . . . . . . . . . . . . . . . . 70 45 Aplicação - Página Alterar password . . . . . . . . . . . . . . . . . . . . . . . . . . 71 46 Aplicação - Página de Dispositivos do Cuidador . . . . . . . . . . . . . . . . . . . . 71 47 Aplicação - Página de Dados de um Dependente . . . . . . . . . . . . . . . . . . . . 72 48 Aplicação - Página de Dispositivos de um Dependente . . . . . . . . . . . . . . . . . 72 49 Aplicação - Página de Histórico de Notificações de um Dependente . . . . . . . . . . . 73 50 Aplicação - Página de Histórico de Localizações de um Dependente . . . . . . . . . . 73 51 Aplicação - Página de Mapa sem Cercas/Lugares seguros . . . . . . . . . . . . . . . 74 52 Aplicação - Página de Mapa com Cercas/Lugares seguros . . . . . . . . . . . . . . . 74 53 Aplicação - Caixa de Diálogo para criação de uma cerca . . . . . . . . . . . . . . . . 75 54 Aplicação - Caixa de Diálogo para editar um Lugar Habitual . . . . . . . . . . . . . . 75 55 Aplicação - Pop-up para notificações . . . . . . . . . . . . . . . . . . . . . . . . . . 76 xvi Índice de Tabelas 1 Teleloc........................................ 21 2 Criação de conta e Plano de Subscrição . . . . . . . . . . . . . . . . . . . . . . . . 22 3 Adicionarumdependente............................... 22 4 Atribuir um dispositivo a um dependente . . . . . . . . . . . . . . . . . . . . . . . 22 5 Monitorização da Localização em Ambiente Exterior . . . . . . . . . . . . . . . . . . 23 6 Criar e/ou editar Cercas Virtuais . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7 Criar e/ou editar Lugares Seguros . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 8 DeteçãodeQueda/SOS................................ 24 9 Notificações ..................................... 25 xvii xix Siglas AMQP Advanced Message Queuing Protocol 43 B2B Business to Businnes 16 B2B2C Business to Business to Consumer 16 BPM Batidas por Minuto 13 CET Centro de Estudos de Telecomunicações 2 CHUCB Centro Hospitalar Universitário Cova da Beira 14 CHULC Centro Hospitalar Universitário Lisboa Central 14 CNTS Centro Nacional do TekSaúde 14, 15 DECO Defesa do Consumidor 6 DPOC Doença Pumonar Obstrutiva Crónica 14 DSR Design Science Research 2, 79 ER Entidade-Relacionamento 34 GPS Global Positioning System 4, 10, 16, 17, 19, 20, 23, 31, 33, 36 HDS Hospital Distrital de Santarém 14 IA Inteligência Artificial 2 ID Investigação e Desenvolvimento 2 IoT Internet of Things 15 ML Machine Learning 2 xxi NPM Node Package Manager 42 ONU Organização das Nações Unidas 5 ORM Object-relational mapping 42 SGBD Sistema de Gestão de Base de Dados 43 SmartAL Smart Assisted Living 1 SNS Serviço Nacional de Saúde 6, 14 SPMS Serviços Partilhados do Ministério da Saúde 14, 15 SQL Structured Query Language 43 TERI Telemonitorização de Doentes em Risco 14 TIC Tecnologias da Informação e Comunicação 2 UE União Europeia 5 xxii 1 Introdução Neste capítulo introdutório, será contextualizado o tema da dissertação, assim como a metodologia utilizada para a sua realização, e será feita uma breve apresentação da empresa que lançou o desafio. De seguida, serão apresentados os objetivos e resultados esperados e, por fim, um pequeno resumo da restante estrutura do documento. 1.1 Contexto e Motivação A área de eHealth/Assisted Living tem vindo a crescer com a necessidade de melhorar a qualidade de vida de pessoas. A pandemia catapultou a necessidade de exercer telemedicina e prestar cuidados de saúde à distância. No entanto, para o fazer é necessário recorrer à tecnologia e as pessoas mais idosas apresentam ainda dificuldades em lidar com novos terminais e aplicações devido à sua natural falta de literacia digital. Esta realidade realça o papel do cuidador informal, do vizinho ou do familiar que, dada a proximidade física e/ou emocional, possa ajudar e acompanhar mais de perto estas pessoas. É certo que a maioria dos idosos, a partir de determinada altura, passa a viver em instituições, mas pretende-se cada vez mais prolongar a sua estadia em casa, assegurando a segurança e conforto necessários, pois está provado que é essa a preferência da maior parte da população sénior [17]. No entanto, persiste a preocupação do isolamento e da falta de acesso a bons cuidados de saúde. Neste sentido, é necessário assegurar o mais possível a autonomia dos idosos e garantir o seu bem-estar, implementando ferramentas que permitam acompanhar à distância esta população. O conceito “envelhecer em casa” ganha cada vez mais tração, mas é necessário reforçar a telemonitorização para melhorar a qualidade dos serviços de saúde. Usufruindo do ambiente ”casa e área circundante”, pode-se cruzar informação proveniente da telemonitorização clínica (já recolhida pela aplicação da Altice Labs SmartAL [18]), com informação adicional ligada à telemonitorização não clínica (e.g., localização) e à domótica (e.g., sensores de deteção de quedas, de abertura de portas, de movimento, de qualidade do ar e câmaras), criando cenários interessantes de ”casa inteligente”aplicados especificamente à área da saúde e do bem-estar. Em particular, para os idosos (ou para outras pessoas em situações de risco ou que sofram de patologias leves - e.g., demência ligeira, é importante continuar a garantir a sua autonomia conforme vão perdendo capacidades, 1 CAPÍTULO 2. ESTADO DA ARTE sociedade à telessaúde, permitindo a redução da saturação dos serviços de saúde primários em hospitais, lares e outras instituições e, por conseguinte, concedendo aos profissionais de saúde mais tempo de qualidade para poderem prestar mais apoio aos casos efetivamente críticos. Manter os utentes em casa, com acompanhamento remoto, beneficiará todas as partes envolvidas, estado, instituições, profissionais de saúde e familiares, mas sobretudo os próprios, pois a manutenção num ambiente que lhes é à partida mais favorável, psicológica e emocionalmente, estimulará a sua mais rápida recuperação, ao invés de agravar o seu quadro clínico, para condições eventualmente sem retorno nos casos mais sensíveis. No entanto, atualmente a implementação no terreno de um serviço de telemonitorização pode não ser linear, devido à natural resistência à novidade e à baixa literacia digital, por parte dos utentes (sobretudo dos mais idosos), mas também de familiares e de alguns profissionais de saúde, pelo que é necessário formar e familiarizar utentes e profissionais com este tipo de acompanhamento e, sobretudo, com as ferramentas e aplicações de suporte, para que a sua utilização passe a ser uma commodity e a constar das rotinas diárias de ambos. A título de exemplo, espera-se que a medição de sinais vitais decorrentes da telemonitorização ocorra com frequência e dentro da máxima normalidade, pois a partir dela espera-se poder ajudar o doente a prevenir situações mais complicadas e a ganhar mais consciência e autonomia para participar mais ativamente na manutenção da sua saúde e nos próprios processos de tratamento. No entanto, como a telemonitorização não se aplica apenas a quadros clínicos que necessitam de acompanhamento profissional, pelo menos de forma permanente, pode ser apenas usada como forma de acompanhamento preventivo, e nestes casos, os cuidadores informais (sobretudo os mais novos) podem ser os principais agentes de mudança; acredita-se que mais facilmente poderão incentivar os idosos a usar a tecnologia e a mostrar as mais-valias do acompanhamento remoto para lhes garantir mais conforto, segurança e salvaguardar ocorrências que resultem em problemas mais graves. De acordo com um artigo publicado no Journal of Medical Internet Research por Norman e Skinner, literacia pode definir-se, de forma genérica, pela “capacidade de obter, processar e entender a informação e os serviços necessários para tomar as decisões mais adequadas”. No caso da saúde digital, ou eHealth , esta literacia traduz-se na capacidade de uma pessoa obter, processar e entender informação básica sobre saúde, através da tecnologia [21]. Um estudo realizado por Cruz Miranda Dídia em 2013 [3], onde foram inquiridas 408 pessoas, verificou-se que pessoas com doenças crónicas, com idade avançada e/ou baixa escolaridade, possuem naturalmente menor literacia digital em saúde. Associa-se a este facto o nível de analfabetismo que, segundo os dados dos Censos 2011, ainda abrange cerca de 5,22% da população portuguesa, o que se traduz em cerca de 551 mil portugueses [16]. Segundo o mesmo estudo, a maioria destas pessoas são idosas e vivem no interior, consequentemente mais isoladas. Assim, assumindo que um dos principais objetivos das sociedades evoluídas é garantir apoio e qualidade de saúde a todos, mas sobretudo a estas pessoas mais frágeis, enfrenta-se um grande desafio, pois são as mesmas que apresentam maior grau de analfabetismo, e consequentemente baixa ou nenhuma literacia tecnológica. É, portanto, necessária a contribuição de todos para formar e apoiar a adaptação e inclusão destas pessoas - familiares, amigos, cuidadores, governos, instituições e profissionais de saúde devem cooperar para que estas pessoas se integrem o melhor possível nos novos sistemas de saúde, cada vez mais digitalizados. A 8 2.1. ENQUADRAMENTO necessidade deste trabalho conjunto, que será necessariamente gradual, é urgente, pois acredita-se que a telessaúde ajudará as pessoas a preservarem durante mais tempo a sua autonomia e a prolongarem a sua qualidade de vida nos seus locais de conforto, evitando mudanças prematuras e, muitas vezes, indesejadas. No entanto, apesar de as soluções de telemonitorização serem centradas no paciente e no seu bemestar, também é necessário ter em conta o envolvimento e as dificuldades de quem faz o acompanhamento, ou seja, dos cuidadores formais e informais, onde se enquadram, respetivamente, os profissionais de saúde e os familiares. Estes podem levantar o mesmo problema em termos de literacia digital. Não obstante a maior probabilidade de os utentes terem menos conhecimento tecnológico do que quem está a cuidar deles, também existem casos em que os próprios cuidadores têm dificuldades, pelo que também é necessário formar estas pessoas. Por outro lado, apesar de, naturalmente, os profissionais de saúde apresentarem uma maior literacia em saúde, podem não estar suficientemente “digitalizados”, o que implica também a necessidade de alguma formação no sentido de se familiarizarem com as soluções mais atuais de telemedicina e telessaúde, sendo que neste caso se espera um processo de adaptação mais ágil. Em suma, o processo de criação de um serviço de telemonitorização, deverá ser inicialmente pensado e centrado no doente, pois será ele o principal interessado. Contudo, deve-se considerar com igual atenção o papel dos cuidadores, sobretudo dos informais, pois serão eles em muitos casos, e também no caso particular a desenhar no âmbito desta dissertação, a dar apoio direto ao doente. É necessário, portanto, considerar ambos na especificação e desenvolvimento da solução, tentando antever as possíveis dificuldades que possam vir a ter. Em termos de usabilidade, após criar a solução para estes dois tipos de utilizadores, será mais fácil no futuro estendê-la aos cuidadores formais. Um serviço de telemonitorização clínica deve conseguir retratar, com a maior precisão possível, o estado de saúde em que se encontra o paciente, de forma a poder prestar auxílio em caso de necessidade e evitar o espoletar de condições agravadas. Para que isto aconteça, deve-se considerar conectar um conjunto de dispositivos que permitam recolher a informação necessária da pessoa e integrá-la de forma automática na solução de telemonitorização. Os dispositivos podem ser de uso próprio ou instalados no ambiente circundante. Com o avanço tecnológico as pessoas usam cada vez mais dispositivos que lhes permitem ter algum controlo sobre a sua vida e a sua saúde, e têm cada vez mais dispositivos inteligentes em casa que lhes possibilitam obter diferentes tipos de informação sobre o que está a acontecer na casa e, por consequência, ter mais segurança. Neste contexto, é interessante cruzar informação proveniente de todos os dispositivos que rodeiam a pessoa, clínicos e não clínicos, para se poder ter um retrato mais holístico da situação. A título de exemplo, enumeram-se aqui tipos de informação que se podem extrair de um ambiente tecnológico caseiro, rico em dispositivos inteligentes: • Estado e atividade do residente: em que divisão se encontra, se está a dormir ou acordado, se se encontra em movimento, etc.; 9 CAPÍTULO 2. ESTADO DA ARTE • Consumos energéticos da casa: total ou por dispositivo; a partir destes desta informação também de pode inferir estados de presença, sobre se a pessoa se encontra ou não em casa. • Informação de portas e/ou janelas abertas ou fechadas: permitindo detetar invasões indesejadas e de forma indireta estados de espírito. Complementarmente, a partir dispositivos clínicos e/ou usáveis ( wearables ), é possível obter informação sobre os sinais vitais e outras atividades diárias, como por exemplo: número de batimentos cardíacos, número de passos, tempo de sono, peso, temperatura, nível de oxigénio, localização, etc. Individualmente, por dispositivo, a informação pode ser correta e precisa, mas nunca retrata a situação no seu todo. Só interpretando e combinando dados provenientes de várias fontes permite construir uma visão mais alargada da situação e, por conseguinte, do estado de saúde e bem-estar de uma determinada pessoa; informação proveniente de vários dispositivos, quando devidamente processada e correlacionada, acrescenta valor e conhecimento aos dados coletados por cada sensor, permitindo recomendar e sugerir ações preventivas e corretivas. Analisando, por exemplo, os coletes que os jogadores de futebol profissionais atualmente usam que recolhem informação GPS e quantificam o esforço desenvolvido durante um jogo ou treino; ao mesmo tempo, permitem analisar a frequência cardíaca, distância percorrida, sprints , impactos e mudanças de direção. De acordo com José Soares, fisiologista, estes dispositivos, que na sua forma mais simples são um conta-quilómetros e um conta-rotações, geram informação que após analisada, permite ao treinador e à sua equipa técnica, perceber se os jogadores estão bem e a cumprir com as metas estabelecidas [22]. No entanto, estes dados não devem ser analisados só na vertente, física, técnica ou tática, devem ser vistos no seu conjunto, de forma a capitalizar o conhecimento proveniente da informação recolhida e aplicá-lo no melhoramento da performance dos jogadores. Este é apenas um exemplo, mas na realidade, todos os serviços de telemonitorização têm o mesmo objetivo - melhorar processos, tratamentos e condições físicas e/ou mentais, assim como prevenir e alertar, em caso de agravamento ou emergência. Pelo que ao cruzar informação proveniente de diferentes dispositivos, sejam estes wearables , pessoais ou instalados na habitação (e.g., sinais vitais, presença, movimento, localização), é possível realizar uma análise mais profunda e detalhada da situação e, por conseguinte, tomar decisões mais informadas e acertadas. Contudo, como foi referido anteriormente, a população idosa não tem, no geral, grandes conhecimentos tecnológicos, pode até não possuir dispositivos inteligentes na sua habitação e a simples utilização de um smartphone pode ser complicada. Para estes casos, existem dispositivos de fácil utilização (e.g., botão de pânico, cinto, relógio) que permitem recolher alguma informação básica, mas que pode melhorar a segurança de quem vive sozinho e dar mais tranquilidade a quem cuida. Para além disso, devido à sua simplicidade permitem também suavizar a curva de aprendizagem e adaptação das pessoas às novas tecnologias. Por estas razões, optou-se por criar uma solução de telemonitorização que permita acompanhar pessoas à distância, recolhendo essencialmente informação de localização e, dependendo do dispositivo, sinais vitais básicos. Apesar de simples, esta solução deve abranger uma gama de funcionalidades que 10 2.1. ENQUADRAMENTO permita a cuidadores informais (e.g., familiares) acompanhar pessoas idosas ou com alguma fragilidade física ou mental, pouco digitalizadas, que vivam isoladas ou que passem bastante tempo sozinhas. Assim, este trabalho tem em vista a criação de serviços focados na deteção de localização e na identificação de situações de risco daí decorrentes. Destinam-se a idosos, sobretudo aos que sofram de doenças físicas algo restritivas ou doenças mentais degenerativas leves. Nos casos em que exibam algumas dificuldades de locomoção ou comportamentos erráticos, é esperado que a solução a desenvolver possibilite, com base na informação recolhida, fazer uma ”vigilância” eficiente, podendo assim minimizar o efeito negativo em situações de risco como quedas, desaparecimentos, desorientações, pânico, etc. O conceito Confort@Home abrange cenários complementares, indoor e outdoor . No caso indoor , consideraram-se sensores não invasivos, de simples instalação na residência para fornecer informação complementar sobre o idoso. Pretende-se desta forma, monitorizar a sua atividade para distinguir situações que se encontram dentro do normal/habitual, de eventos que correspondem a desvios ao considerado normal e que podem ser considerados de risco. Os dispositivos a considerar podem ser: lâmpadas e/ou tomadas inteligentes que para além de cumprirem a sua função e permitirem verificar consumos e frequência de utilização, poderão também ser usados para inferir estados de presença e ausência; fechaduras inteligentes poderão ser usadas também para reforçar este tipo de inferência, para além executarem a função de deteção de intrusões; detetores de movimento que podem ser instalados em várias divisões da casa. Combinando informação proveniente de todos estes dispositivos será possível ter uma ideia de diferentes situações de potencial risco, como por exemplo se não se detetar movimento no quarto ao acordar e deitar, se a lâmpada da mesinha de cabeceira não for ligada antes de dormir, etc. Se se basear esta análise em rotinas, será ainda mais precisa a inferência do risco. No cenário outdoor , usar-se-ão essencialmente dispositivos equipados com GPS para monitorizar a localização do utente no exterior. Entre eles, serão considerados relógios, cintos e botões. O familiar ou o próprio utente poderá adquirir o que for lhe for mais conveniente, pois para além da localização poderão dar informação adicional, como por exemplo sinais vitais básicos (no caso do relógio). Podem também ser considerados outros dispositivos, como por exemplo, o de deteção de quedas, que pode ser usado quer no interior quer no exterior da casa. Este dispositivo em particular, permite detetar uma queda e espoletar automaticamente uma chamada para números de emergência previamente configurados. Caso não aconteça de forma automática, é possível manualmente iniciar a chamada pressionando o botão de que o dispositivo dispõe. Dispositivos com GPS permitem distinguir lugares e trajetos de visita comum, de lugares e trajetos estranhos e, em consequência, agir em situações de risco. Em casos de utentes, por exemplo, com demência ou outro tipo de patologia do género que perdem a orientação por várias horas e por vezes têm dificuldade em encontrar o caminho de regresso a casa, este tipo de dispositivos pode ser muito útil. Para aumentar a segurança do utente, ir-se-á criar uma cerca virtual, em que, a partir do momento em que é detetado que saiu da zona habitual ou da zona definida como permitida/segura para circular, é ativado um aviso e enviado para o cuidador. Dado o tempo previsto da dissertação, este será o principal foco do trabalho de desenvolvimento a realizar. 11 CAPÍTULO 2. ESTADO DA ARTE 2.2 Serviços de Telemonitorização A telemonitorização ajuda os pacientes a sentirem-se mais acompanhados, seguros, e ao mesmo tempo, mais autónomos e participativos no seu próprio processo de tratamento. Quanto aos cuidadores, ajuda-os a prestar melhores cuidados e a sentirem-se mais produtivos e confiantes, pois podem estar remotamente em qualquer lugar a seguir os seus doentes, sendo notificados só nos casos mais urgentes. No entanto, para obter real entendimento sobre o estado de saúde de um paciente, é necessário selecionar um conjunto relevante de medições/indicadores que permitam tirar conclusões acertadas, assim como criar algoritmos que ajudem a obter conhecimento adicional, criando correlações, inferências e recomendações adequadas [20]. Para que tal aconteça, existe na base da telemonitorização clínica a recolha de dados, em particular de sinais vitais que, de forma direta ou indireta, avaliam as funções básicas do corpo humano e providenciam informação crucial sobre o bem-estar geral. Estes dados permitem aos profissionais avaliar o estado de saúde do paciente e tirar conclusões sobre algumas disfunções e/ou doenças [20]. Conseguem, deste modo, aconselhar e avançar para a realização de exames, se necessário, assim como sugerir tratamentos ou alterações ao estilo de vida. Os sinais vitais mais comuns e abrangentes, ou seja, que permitem despistar um maior número de situações anómalas são: a temperatura corporal, a pressão arterial, o ritmo cardíaco e/ou pulsação, e complementarmente, o peso e a altura. Temperatura Corporal A temperatura normal do corpo humano não varia muito. Ainda assim, varia conforme o sexo, a atividade física, a comida, os fluídos ingeridos e, no caso das mulheres, com o ciclo menstrual. De acordo com o SNS, os valores de temperatura corporal são considerados normais quando se encontram entre 36ºC e 37,5ºC [31]. A temperatura corporal é controlada pela região do cérebro chamada hipotálamo; quando há um vírus, por exemplo, o sistema imunitário envia informação para esta parte do cérebro, com o intuito de aumentar a temperatura corporal e enfraquecer o vírus [31]. A temperatura corporal é considerada anormal quando se tem febre (alta temperatura), ou seja, acima dos 37,5ºC, ou hipotermia (baixa temperatura), abaixo dos 36ºC. A variação da temperatura corporal de forma anómala e inesperada, é motivo de preocupação, pelo que a medição regular deste sinal vital é crucial, pois permite tomar ações preventivas e/ou tratar a condição em causa. Pressão Arterial A pressão arterial é a força que o sangue exerce sobre as paredes das artérias durante a sua circulação [32]. Cada vez que o coração bate, é bombeado sangue para as artérias, resultando num aumento da pressão à medida que o coração contrai e numa redução à medida que relaxa. A pressão é calculada em duas medidas, sistólica (ou ”máxima”) que se refere à pressão na artéria quando o coração contrai e bombeia sangue para o resto do corpo e a diastólica (ou ”mínima”) que diz respeito à pressão na artéria quando o coração relaxa. 12 2.2. SERVIÇOS DE TELEMONITORIZAÇÃO Genericamente, a pressão arterial pode ser considerada normal quando os valores sistólica/diastólica se encontram abaixo de 120/80, mas a avaliação mais fina depende de outros fatores, como a idade e condições clínicas associadas. De qualquer forma, considera-se hipertensão no Estado 1 quando a sistólica se encontra entre 130 e 139 e a diastólica entre 80 e 89, e no Estado 2 quando se encontram acima de 140/90, respetivamente. A unidade de medida da pressão arterial, tanto na sistólica como na diastólica, é mmHg (milímetros de mercúrio) e corresponde objetivamente à altura de uma coluna de mercúrio de um milímetro num dispositivo chamado manómetro, que é elevada pela pressão do sangue. Os valores da pressão arterial podem variar durante o dia devido a esforços físicos ou emocionais e com o avançar da idade tendem a aumentar. De qualquer forma, é necessário monitorizá-los, pois quando estes atingem valores que mediante um padrão verificado anteriormente são considerados anómalos, podem indicar algum problema de coração ou mesmo iminência de ataque cardíaco. A monitorização regular da pressão arterial permite avaliar se é necessário fazer ajustes ao estilo de vida e/ou prosseguir para tratamento médico/medicação. Ritmo Cardíaco O ritmo ou frequência cardíaca é a velocidade do ciclo cardíaco, medido pelo número de contrações do coração por minuto (BPM). O valor pode variar de acordo com as necessidades físicas do organismo, incluindo a necessidade de absorção de oxigénio e de excreção de dióxido de carbono. É normalmente igual ou próxima da pulsação arterial, medida em qualquer ponto periférico. Pode ser alterada pelo exercício físico, sono, ansiedade, stress, doença ou ingestão de estupefacientes. O valor considerado normal em adultos saudáveis varia entre 60 e 100 batidas por minuto, em repouso. Durante o sono, a frequência cardíaca desce para valores entre 40 e 50 batidas por minuto. Taquicardia corresponde a uma alta frequência cardíaca definida como acima de 100 batidas por minuto e arritmia é quando o coração não bate a uma frequência regular. Anomalias na frequência cardíaca geralmente indicam doença. A medição do ritmo cardíaco pode ser efetuada manualmente, recorrendo a dois dedos no pulso ou pescoço, ou usando dispositivos como oxímetros ou relógios que em poucos segundos indicam o valor recolhido. Deve ser medido regularmente, pois valores fora do normal podem implicar medidas clínicas para evitar situações mais sérias de doenças cardiovasculares ou outro tipo de problemas do foro cardíaco. Peso e Altura Apesar de não serem considerados sinais vitais, como os anteriormente descritos, são os indicadores físicos que complementarmente permitem avaliar o estado de saúde de uma pessoa. Variações bruscas indicam normalmente problemas sérios de saúde. Uma variação na altura pode indicar perda de densidade óssea e aumentam o risco de desenvolver osteoporose com o avançar da idade. O aumento ou diminuição do peso pode indicar uma vasta gama de problemas médicos subjacentes (como a doença da tiroide) a maus hábitos de vida. Saber o peso e altura de um paciente, em comparação com os valores normais para a idade, permite calcular outros indicadores (e.g., massa corporal) e ajuda a tomar decisões 13 CAPÍTULO 2. ESTADO DA ARTE mais acertadas relativas ao seu bem-estar. De uma forma geral, pode-se verificar que todos estes valores são úteis para indicar se há alguma anomalia no estado de saúde do paciente. Ao efetuar uma monitorização regular destas medidas, pode-se determinar uma média, dentro da qual os valores para aquele paciente podem ser considerados normais, e delinear limites para quando estes valores forem ultrapassados. Deste modo, pacientes e cuidadores serão notificados quando alguma coisa não estiver bem e podem agir em conformidade de forma a evitar o agravamento do quadro clínico. Apesar de um só sinal vital poder per si dar bastante informação sobre o estado de saúde, cruzando e correlacionando várias medições obtém-se um quadro mais completo e preciso, até porque muitos dos sinais acima mencionados estão relacionados entre si, como é o caso da pressão arterial e do ritmo cardíaco - por exemplo, quando o ritmo cardíaco aumenta a pressão arterial também tende a aumentar. O mercado dos serviços de telemonitorização está ainda em fase embrionária, o que se deve essencialmente a alguma inércia por parte das instituições, falta de pessoal especializado e alocação de tempo para treino. Com o aparecimento da pandemia e a consequente necessidade de prestar serviços de saúde remotamente, tem-se verificado uma crescente utilização da telessaúde, nomeadamente de teleconsulta e da telemonitorização. Atualmente, em Portugal, já existem alguns projetos em curso nesta área, como por exemplo, o projeto de telemonitorização do Hospital Distrital de Santarém (HDS), o do Centro Hospitalar Universitário Cova da Beira (CHUCB), o do Serviços Partilhados do Ministério da Saúde/Centro Nacional do TekSaúde (SPMS/CNTS) e o da Altice Portugal com o Centro Hospitalar Universitário Lisboa Central (CHULC). Estes são alguns dos mencionados publicamente, mas existem muitos mais a iniciar ou já em curso. Projeto do Hospital Distrital de Santarém (HDS) O projeto do HDS foi iniciado pelo serviço de pneumologia e consiste num serviço de telemonitorização domiciliária prestado a casos de doença pulmonar obstrutiva crónica (DPOC) [30].À semelhança do que já foi explicado como sendo a base de um serviço de telemonitorização, este consiste no acompanhamento remoto de pacientes quando estes se encontram no conforto da sua casa. De acordo com a notícia divulgada pelo SNS, este projeto está a ser testado em cinco pacientes, sendo recolhidos parâmetros fisiológicos, designadamente a frequência cardíaca, a saturação de oxigénio, a temperatura e o número de passos que o doente dá por dia. Os valores são registados pelo paciente e supervisionados pelos profissionais de saúde. Para facilitar, existe um conjunto de limites que geram alertas caso sejam ultrapassados, e em consequência o utente é contactado. Projeto do Centro Hospitalar Universitário Cova da Beira (CHUCB) Este projeto, denominado Telemonitorização de Doentes em Risco - TERI, é uma solução focada em pessoas clinicamente consideradas em situação de risco, quer se encontrem em regime de urgência ou internamento, ou, em hospitalização domiciliária. Tal é alcançado através da monitorização constante de 14 2.2. SERVIÇOS DE TELEMONITORIZAÇÃO sinais vitais e da implementação de sistemas de alerta em caso de descompensação, o que permitirá tornar os processos mais eficientes e a atuação das equipas mais célere, para maior conveniência e segurança dos utentes [1]. Serviço da SPMS/CNTS Esta solução já se encontra disponível no mercado para utilização dos utentes. Trata-se de uma solução de telemonitorização que pretende dar resposta às necessidades de acompanhamento digital dos utentes do Serviço Nacional de Saúde, quando estes não se encontram nas unidades de saúde. Denominada Telemonit SNS 24 , a aplicação móvel permite aos utentes aceder ao um plano de monitorização clínica proposto por um profissional de saúde, podendo registar sinais vitais ou outras medições biométricas, adicionados manualmente ou através de equipamentos ligados ao telemóvel. É uma solução indicada para situações de pós-consulta, alta de internamento, alta de um episódio de urgência ou para qualquer outro tipo de situação resultante de contacto com um profissional de saúde. Neste momento, está apenas disponível para utentes com insuficiência cardíaca congestiva, doença pulmonar obstrutiva crónica e recuperados pós-COVID-19. Esta aplicação está limitada à recomendação de um profissional de saúde, pelo que não é permitida a sua utilização de forma individual ou por cuidadores informais [33]. Smart AL SmartAL é a solução desenvolvida pela Altice Labs com vista a telemonitorizar pessoas que necessitem de acompanhamento remoto por parte de profissionais de saúde e/ou cuidadores informais. O serviço visa simplificar a vida de ambos, quer do ponto de vista da saúde quer socialmente. O SmartAL oferece um conjunto de tecnologias, dispositivos e serviços de apoio, que permitem acompanhar, em tempo real, doentes crónicos, idosos e pessoas em convalescença, hospitalização domiciliária, confinamento, pós-internamento, etc., pois permite a telemonitorização de sinais vitais, teleconsultas e suporte de outras atividades relacionadas com a saúde, o bem-estar e a segurança. É uma solução personalizável e adaptável às necessidades de cada cliente, permitindo ao utilizador final usufruir de uma maior independência, autonomia e dignidade, fazendo-o sentir-se seguro dentro e fora de casa. Para além de permitir a monitorização de diferentes sinais vitais provenientes de dispositivos clínicos e/ou wearables , torna possível cruzar estes dados com outros complementares recolhidos através de ficheiros, imagens ou mesmo dispositivos de IoT/domótica. É uma solução disponível em diferentes tipos de interfaces (PC, Tablet, Smartphone, TV, etc.). A aplicação TV (possível disponibilizar a clientes MEO) permite a utentes pouco digitalizados e que não disponham de outro tipo de interfaces aceder de forma simples ao serviço, recolher medições, receber alertas e lembretes e ter acesso a questionários e vídeos. A aplicação móvel, com funções mais evoluídas, está disponível para vários perfis (utente, cuidador formal, informal, administrativo, etc.) e permite recolher dados de vários dispositivos, enviá-los para a Cloud para cruzar com limites pré-definidos e disparar notificações e alarmes, sempre que se justificar. Por último, a aplicação web que é naturalmente a mais completa está também disponível para vários perfis, mas é mais usada essencialmente pelos cuidadores 15 CAPÍTULO 2. ESTADO DA ARTE formais, administrativos e administradores, pois permite-lhes todo tipo de ações, como por exemplo: criar instituições, adicionar utilizadores, definir tarefas e planos de medição, incluir novos questionários e vídeos e, no caso dos profissionais de saúde, ter acesso ao mais importante, ou seja à informação médica do utente (doenças, alergias, prescrições, exames) e à monitorização em tempo real de toda a informação recebida. Em suma, das várias funcionalidades disponíveis no SmartAL destacam-se então as seguintes: • Gestão de atividades do dia-a-dia; • Agendamento de tarefas e planos; • Monitorização dos sinais vitais; • Alertas, notificações e lembretes; • Questionários para avaliação social e de saúde; • Teleconsulta, chat e transferência de ficheiros; • Tutoriais em vídeo; • Relatórios estatísticos; • Automação da casa; • Proteção de dados pessoais e informação sensível. O SmartAL é um serviço dirigido tanto a idosos como a crianças; na realidade a qualquer pessoa que necessite de cuidados no seu dia-a-dia, seja por motivo de doença crónica, temporária ou qualquer outro que a coloque em situação de fragilidade (e.g., idade, isolamento, confinamento). É indicado para instituições do tipo lar, hospital, casa de repouso, etc., mas também pode ser usado num contexto mais abrangente, como por exemplo ao serviço de câmaras municipais ou no âmbito do serviço nacional de saúde [18]. O produto disponível no mercado segue um modelo B2B e B2B2C , ou seja, é vendido às instituições que depois disponibilizam aos seus utentes conforme as suas necessidades. 2.3 Serviços de Localização Os serviços de localização GPS já estão estabelecidos no mercado há vários anos, com permissão para uso civil desde 1995. Os primeiros telemóveis com GPS surgiram em 1999 e, com este serviço permitem fornecer informações sobre a localização exata de pontos de interesse, através do uso de satélites [5]. Desde então, a tecnologia GPS tem-se tornado cada vez mais barata, passando por um processo rápido de evolução. Começou com a criação de dispositivos GPS em veículos para orientação dos condutores, e a partir daí foi aumentando a sua utilização até à situação atual, em que a tecnologia é usada 16 2.3. SERVIÇOS DE LOCALIZAÇÃO em praticamente todos os dispositivos eletrónicos, pois muitas das aplicações comummente utilizadas necessitam de informação da localização para garantirem o seu funcionamento. A evolução da tecnologia GPS resultou numa variedade de utilização em diversas áreas: comunicações, segurança, agricultura, transportes etc. Atualmente, existem inúmeros serviços que permitem localizar animais, pessoas ou objetos, através do uso de dispositivos equipados com GPS. Também na área da saúde e do bem-estar existem dispositivos GPS que permitem localizar pacientes em tempo real e acompanhar à distância o seu desempenho, dando-lhes mais segurança e evitando, se possível, visitas desnecessárias às instituições de saúde. O objetivo é ajudar a prevenir situações de risco e prestar auxílio com a maior brevidade possível. Através da utilização de serviços de localização, podem-se desbloquear uma série de problemas e prever determinadas situações desagradáveis, tendo em conta a possibilidade de estabelecer de limites e regras, assim como analisar as rotinas e os percursos executados que permitam distinguir anomalias da atividade considerada regular. Para tornar o acompanhamento mais eficiente, pode-se cruzar a localização com dados complementares obtidos pelos dispositivos GPS, ou por outros quaisquer dispositivos já instalados em casa ou utilizados pelo paciente e que forneçam informação útil, como por exemplo os a atividade e os sinais vitais (obtidos através de dispositivos clínicos ou wearables ); contudo, por constrangimentos temporais não se irá analisar esse cruzamento de informação no trabalho de implementação. No entanto, quanto mais informação e conhecimento efetivo se obtiver do utilizador, mais rapidamente será possível ao familiar/cuidador informal chegar a uma conclusão sobre o está a acontecer, em caso de risco. Por exemplo, o paciente utiliza um smartwatch que fornece periodicamente sinais vitais (batimentos cardíacos, saturação do oxigénio, etc.), mas o cuidador constatou que está há bastante tempo sem receber este tipo de dados. Ao verificar a localização do seu paciente, percebe que este se encontra a caminhar dentro de uma zona segura e que tem na aplicação uma notificação sobre falta de bateria do dispositivo; contacta o paciente que rapidamente compra novas baterias, ou pede-lhe para recolher a casa e aguardar pela sua visita. Do ponto de vista de segurança e do bem-estar, todo o tipo de informação pode ser útil para proteger o paciente, mesmo noutros cenários mais caseiros. Por exemplo, em situações em que o familiar/cuidador saiba que o paciente vive sozinho e está a dormir (por informação proveniente de um relógio, por exemplo), mas através dos sensores espalhados pela casa é detetado movimento, e/ou que uma porta ou uma janela se abriu, pode ligar ao paciente para verificar que está tudo bem, ou optar por rapidamente contactar a segurança do prédio por se poder tratar de uma invasão. Estes são apenas alguns exemplos da aplicação e importância de recolher informação complementar à de saúde, e da necessidade de a cruzar com outros dados para se poder tirar conclusões mais precisas e salvaguardar a segurança daqueles que são mais vulneráveis. 17 CAPÍTULO 3. MODELAÇÃO E ARQUITETURA 3.2.1.7 Micro Use Case - Criar e/ou editar Lugares Seguros Tabela 7: Criar e/ou editar Lugares Seguros Pré-Requisitos Cuidadores que criaram conta na plataforma, subscreveram um plano, compraram os dispositivos, registaram-nos na App e associaram-nos aos dependentes Descrição O cuidador tem a possibilidade de atribuir locais seguros a cada dependente. Cada local seguro está designado por uma localização específica, ficando ativo quando criado, sendo possível desativar posteriormente. Quando ativo, são enviadas notificações ao utilizador assim que o dependente atribuído se encontrar no local seguro. Por fim, é possível editar um local existente ou até mesmo eliminá-lo. Cenário O Sr. Carlos sofre de demência leve e passa grande parte do seu tempo sozinho em casa. Um dia, decidiu ir ao café ter com os seus amigos. O seu filho estava no trabalho e não viu imediatamente a notificação de saída da cerca virtual que tinha definida para a casa do pai. Entretanto o Sr. Carlos chegou ao café e esta localização estava definida como lugar seguro, pois costuma ir ao café todas as tardes encontrar-se com os seus amigos. Nesta altura o filho já estava com mais disponibilidade e recebeu a notificação que o pai estava num lugar seguro por isso continuou o seu trabalho normalmente. No final da tarde o Sr. Carlos decidiu regressar a casa, pelo que o sistema alertou o filho que ele tinha saído do lugar seguro, passando a poder monitorizar o seu percurso até casa. 3.2.1.8 Micro Use Case - Deteção de Queda/SOS Tabela 8: Deteção de Queda/SOS Pré-Requisitos Cuidadores que criaram conta na plataforma, subscreveram um plano, compraram os dispositivos, registaram-nos na App e associaram-nos aos dependentes Descrição As quedas podem ser detetadas por botões/sensores. Estes dispositivos, são capazes de detetar quando ocorre uma queda e desencadear chamadas de emergência para números pré-configurados. Além disso, se, por qualquer alteração, o equipamento estiver a funcionar mal e não conseguir detetar automaticamente a queda, o utilizador pode sempre enviar um sinal de emergência premindo o botão SOS. Caso nenhum número esteja configurado, o dispositivo emite um sinal que é enviado diretamente para a aplicação e apresentado sobre a forma de notificação, de forma a informar o seu cuidador da ocorrência. Cenários 1. O Sr. Joaquim gosta de caminhar durante a tarde e normalmente caminha cerca de 7 km por dia. Um dia, foi dar um passeio e tropeçou numa rocha, acabando por cair. A sua filha Maria logo recebeu um alerta de que o seu pai tinha caído, e foi à aplicação para descobrir onde ele estava, utilizando o GPS incorporado no aparelho. Graças a isso, ela conseguiu encontrá-lo e enviar ajuda para o local. 2. A Sra. Rita, tem 79 anos e decidiu sair para fazer compras no mini-mercado perto da sua casa. Ao regressar a casa, ela escorregou e acabou por cair no chão. Por alguma razão, o detetor de queda não estava a funcionar corretamente, e não contactou a sua filha. Assim que se apercebeu do mau funcionamento, a Sra. Rita premiu o Botão SOS e contactou a sua filha. 24 3.3. REQUISITOS 3.2.1.9 Micro Use Case - Notificações Tabela 9: Notificações Pré-Requisitos Cuidadores que criaram conta na plataforma, subscreveram um plano, compraram os dispositivos, registaram-nos na App e associaram-nos aos dependentes Descrição As notificações serão apresentadas ao cuidador com diferentes níveis de severidade. As de maior gravidade serão representadas a vermelho (e.g., quando houver uma queda registada), a laranja, as de gravidade média (e.g., quando alguém sai da cerca virtual), e por fim a verde, as de menor gravidade (e.g., quando alguém entra na cerca virtual ou se encontra num local seguro). Cenários Durante o dia, a Sara não está constantemente no telemóvel ou computador o que a impede de estar a par de tudo o que se passa com a sua mãe que está com inicio de demência. No entanto, recebe várias notificações com informação que lhe permite tomar ações para o bem da sua mãe. Ainda ontem, a Sara recebeu uma notificação que o dispositivo que a sua mãe usa estava com pouca bateria, então, antes que recebesse uma notificação a indicar que o mesmo tinha ficado sem bateria e desligado, entrou em contacto com a mãe e pediu-lhe que pusesse o dispositivo a carregar. 3.3 Requisitos Com o intuito de identificar os requisitos necessários para a elaboração do projeto, foram realizadas reuniões com a equipa da empresa Altice Labs , de forma a ter uma perspetiva mais pormenorizada das funcionalidades desejadas. Desta forma, foi possível identificar os requisitos chave para serem a base da implementação do projeto, assim como os requisitos facultativos, permitindo uma redução na probabilidade de insucesso da aplicação. 3.3.1 Requisitos Funcionais Com a análise da solução pretendida, e depois de algum trabalho de investigação, foram alcançados os seguintes requisitos funcionais, que devem permitir ao utilizador: • Registar na aplicação, fornecendo o seu nome, email, contacto, número de identificação fiscal e a palavra-passe que lhe irá dar permissão para entrar na plataforma; • Alterar os seus dados pessoais; • Alterar os seus dados de acesso; • Autenticar na aplicação, indicando o seu email e palavra-passe; • Subscrever a um plano para uso das funcionalidades da aplicação; 25 CAPÍTULO 3. MODELAÇÃO E ARQUITETURA • Adicionar dependentes a seu cuidado, fornecendo dados sobre os mesmos; • Alterar dados dos dependentes • Adicionar dispositivos que serão usados para obter dados; • Associar dispositivos a dependentes; • Alterar dados dos dispositivos e/ou alterar dependente associado; • Visualizar localização dos diferentes dependentes no mapa; • Desenhar cercas virtuais com diferentes formas geométricas(círculo, quadrado e polígono); • Alterar dados das cercas virtuais; • Remover cercas virtuais; • Atribuir cercas virtuais a dependentes; • Assinalar locais seguros no mapa; • Alterar dados de lugares seguros; • Remover lugares seguros; • Atribuir lugares seguros a dependentes; • Receber notificações que informem sobre os diferentes eventos espoletados pelos dispositivos (bateria, desconexão, conexão, entrada e saída de cercas virtuais, entrada e saída de locais seguros e avisos SOS); • Obter um histórico de localizações de um dependente num determinado intervalo de tempo. 3.3.2 Requisitos Não Funcionais • A aplicação tem de estar disponível na língua portuguesa e inglesa; • A aplicação não deve ser ofensiva em termos religiosos, étnicos ou sexuais; • O sistema deve suportar o registo de, pelo menos, 100 utilizadores por ano; • O sistema deve estar operacional pelo menos 361 dias por ano (99%) • O sistema deve apresentar resposta a qualquer pedido do utilizador em menos de 2 segundos, desprezando atrasos na rede; 26 3.4. ARQUITETURA FUNCIONAL • Cada página deve ser totalmente carregada em menos de 2 segundos, desprezando atrasos na rede; • Qualquer atualização na aplicação deve ser realizada nos períodos de menor utilização; • O sistema deve prevenir a introdução de dados errados; • O sistema deve prevenir o acesso indevido aos dados pessoais; • A aplicação deve ser suportada pelos browsers: Safari, Mozilla Firefox, Google Chrome, Opera e Microsoft ; • A aplicação deve garantir a privacidade dos dados dos utilizadores; • A aplicação deve processar e lançar alertas em menos de 5 segundos; • Deve possuir uma interface intuitiva e responsiva. 3.4 Arquitetura Funcional A Altice Labs já possui uma solução de telemonitorização, o SmartAL ; uma solução focada em telemonitorizar pessoas que necessitem de acompanhamento remoto por parte de profissionais de saúde e/ou cuidadores informais. O SmartAL não possui serviços de localização implementados, daí o surgimento deste trabalho, com vista a desenvolver uma aplicação que permita telelocalizar pacientes. No entanto, o SmartAL já é uma solução com algum avanço do ponto de vista tecnológico, pelo que muitos serviçosbase de uma aplicação web já se encontravam implementados, sendo apenas necessário alinhá-los com a solução descrita na secção 3.1 e os seus casos de uso e requisitos. Deste modo, foi alcançada a arquitetura funcional apresentada na figura 2. Na figura 2 é possível ver os vários serviços que irão permitir a implementação deste serviço de telelocalização. Os serviços a azul são os serviços já implementados por parte da equipa da Altice Labs ; serviços utilizados pelo SmartAL e que serão também utilizados pelo Teleloc . A verde estão assinalados os microsserviços a implementar para ser possível criar uma aplicação de telelocalização. De seguida serão apresentadas as funcionalidades dos serviços presentes nesta arquitetura; no entanto, só no capítulo 4.2 serão detalhadas todas as características de implementação desses serviços, com foco nos microsserviços Outdoor e Geofences . •API Gateway - Serve de ”ponte”entre a interface gráfica/clientes externos e os diferentes microsserviços. Este serviço recebe os pedidos dos clientes e da interface e encaminha-os para os diferentes microsserviços que compõem a aplicação. Após receber a resposta dos microsserviços, o gateway devolve a informação a quem efetuou o pedido; 27 CAPÍTULO 3. MODELAÇÃO E ARQUITETURA Figura 2: Arquitetura Funcional •Auth - Utiliza o Keycloak como identity provider 1(IdP) e é responsável pela autenticação dos utilizadores na aplicação; •Entities - Serviço responsável por gerir os utilizadores e perfis do sistema. No caso desta solução as entidades serão apenas duas, o Cuidador (”Caregiver”) e o Dependente (”Dependent”). Apenas o Cuidador tem permissões de autenticação, o Dependente é um perfil sem funcionalidades ativas, servindo apenas para associar os dados de dependentes ao Cuidador. Este perfil, foi implementado para no futuro ser mais fácil de atribuir aos dependentes um uso mais ativo na aplicação, caso se deseje; •Payment/Invoices - Serviço responsável por efetuar e gerir todos os pagamentos feitos na solução e por fazer a ponte entre a plataforma e uma API de faturação externa ; •Message Bus - Serviço para permitir a comunicação assíncrona entre alguns dos serviços da rede, através de um padrão de publicação-subscrição; •Notifications - Serviço responsável por gerir as notificações do sistema. Os diferentes microsserviços publicam notificações no Message Bus e o serviço de notificações está à escuta nos diferentes canais de forma a obter e armazenar a informação do que foi publicado. Sempre que é requisitado, este serviço espoleta push notifications para o browser , e envia SMS e emails; •Geofences - Serviço responsável por gerir a informação das cercas virtuais e a sua lógica de serviço. Dado que as cercas virtuais e as suas verificações exigem alguma complexidade, este 1Sistema que guarda e gere as informações das entidades (utilizadores reais e aplicacionais) de determinado sistema. 28 3.5. DIAGRAMAS DE SEQUÊNCIA serviço foi separado do serviço Outdoor de forma a simplificar o sistema. Este armazena a informação de todas as cercas virtuais da aplicação e, mediante as posições que recebe dos diferentes dependentes, verifica as suas posições relativas às diferentes cercas; •Outdoor - Serviço responsável por gerir a informação relacionada com a localização exterior e a sua lógica de serviço. Este serviço gere os dispositivos, as localizações e os lugares seguros do sistema. Como o serviço de Geofences é um serviço frequentemente utilizado pelo Outdoor , os pedidos entre eles são efetuados diretamente, sem a necessidade de passar pela API Gateway . 3.5 Diagramas de Sequência Dado ser uma aplicação assente em microsserviços, a lógica e a informação passada entre eles deve ser simples e de fácil compreensão para uma boa implementação. Para isso foram utilizados diagramas de sequência, que permitiram perceber como a informação iria navegar desde a execução de um pedido até à resposta ao cliente. Os diagramas de sequência são diagramas em UML que representam a sequência de processos num software . Assim, é possível visualizar de forma simples e lógica os diferentes métodos e classes e como estes surgem no sistema e colaboram entre si. Os diagramas de sequência são representados por •Linhas de vida: linhas verticais que representam diferentes processos ou objetos; •Linhas horizontais: mensagens ou pedidos trocados entre os diferentes processos; •Atores: entidades externas que interagem com o sistema e executam pedidos. Normalmente enviam a primeira mensagem que inicia toda a sequência. De forma a entender o funcionamento do sistema e a comunicação entre os diferentes serviços, serão apresentados alguns diagramas de sequência, que demonstram a lógica das principais funcionalidades da aplicação. 3.5.1 Login Quando um utilizador acede à plataforma, será apresentada a habitual interface da página principal. Aqui é realizada a primeira ação por parte do utilizador, em que tem de escolher se pretende aceder, caso tenha conta, ou, caso não tenha, se se quer registar. Neste exemplo, representado na figura 3, assume-se que o utilizador já possui uma conta no sistema e seleciona a opção de login , demonstrando à interface a intenção de se autenticar, sendo-lhe apresentado o formulário para inserir as suas credenciais. Após preencher e enviar o formulário, o serviço de front-end irá comunicar com a API Gateway para aceder ao serviço de autenticação (”Auth”). Este, por sua vez, valida os dados inseridos com recurso ao Keycloak . Caso estejam corretos, irá realizar a autenticação, 29 CAPÍTULO 3. MODELAÇÃO E ARQUITETURA Figura 3: Diagrama de Sequência: Login gerar um token e devolvê-lo à API Gateway para devolver a resposta de ” login efetuado”à interface do utilizador. Caso os dados não estejam corretos, a sequência é semelhante, com a única diferença de que a autenticação não é efetuada, o token não é gerado, e a resposta que é apresentada ao utilizador é de insucesso. 3.5.2 Criar Dependente Figura 4: Diagrama de Sequência: Criar Dependente Após autenticado na aplicação, o cuidador pode realizar várias ações. Assumindo que esta é a primeira interação com a aplicação, o utilizador não terá quaisquer perfis de dependentes adicionados, pelo que é essencial criá-los para poder posteriormente adicionar um dispositivo e receber posições. Para tal, o utilizador irá indicar a intenção de adicionar um dependente e a interface responsabilizar-se-á por apresentar o formulário que permite o envio dos dados do dependente. 30 3.5. DIAGRAMAS DE SEQUÊNCIA Seguidamente, o utilizador envia o formulário de criação e o serviço de front-end faz um pedido à API Gateway para a criação de um dependente. Este, por sua vez, encaminha o pedido para o microsserviço responsável (neste caso é o Entities ), que irá executar a função de criação de dependente e adicionar à sua base de dados um novo dependente, associado ao cuidador que efetuou o pedido. Consequentemente, será devolvida a resposta de sucesso ao utilizador, fazendo o percurso inverso ao da realização do pedido. À semelhança do exemplo anterior, caso haja algum problema na criação do dependente, como dados incorretos ou erro por parte do serviço, será devolvida ao utilizador uma resposta a indicar o sucedido. 3.5.3 Criar Dispositivo Figura 5: Diagrama de Sequência: Criar Dispositivo Para se poder receber e apresentar a localização dos dependentes na aplicação, é necessário que o cuidador adicione um dispositivo e atribua o mesmo ao dependente. À semelhança dos exemplos anteriores, o utilizador irá indicar na interface que quer adicionar um dispositivo e ser-lhe-á mostrado o formulário para a criação do mesmo. Após o seu envio, o front-end indicará à API Gateway o pedido de criação de dispositivo e este, por sua vez, encaminhará para o serviço Outdoor , onde será criado e persistido na base de dados. Por fim, a resposta será apresentada ao utilizador, caso o pedido tenha sido realizado com sucesso, ou a mensagem de erro em caso contrário. 3.5.4 Visualizar Localização dos Dependentes Após o cuidador criar um dependente e ter associado um dispositivo, o sistema começará a receber informações da localização GPS que o dispositivo equipado pelo dependente emite e a guardá-las na base de dados. Cada localização estará associada a um dispositivo, que estará associado a um dependente. Tendo um ou vários dependentes, a lógica para visualizar a localização dos dependentes é a mesma - o cuidador indicará na interface que quer visualizar o mapa, será feito um pedido à API Gateway , que encaminhará o pedido de obter a localização de todos os dependentes para o serviço Outdoor (que é 31 CAPÍTULO 3. MODELAÇÃO E ARQUITETURA Figura 6: Diagrama de Sequência: Visualizar Localização dos Dependentes responsável por gerir a informação relacionada com localizações outdoor ). Este retornará a localização mais recente de todos os dependentes à API Gateway e esta será apresentada no mapa ao utilizador. 3.5.5 Criar Cerca Virtual Figura 7: Diagrama de Sequência: Criar Cerca Virtual Para além de visualizar a localização dos dependentes, o cuidador poderá também querer criar cercas virtuais para ser notificado sempre que o dependente sai ou entra de uma determinada área. Para tal, o utilizador seleciona a opção de criar cerca virtual, em que lhe é apresentada a interface de criação da cerca. O cuidador desenha a área que pretende ser verificada (círculo, retângulo ou polígono) e envia o pedido de criação. A API Gateway recebe o pedido e encaminha o mesmo para o serviço Geofences , serviço responsável pela gestão das cercas virtuais e que irá persistir os dados de criação da cerca. Após isso, será retornada pelos diferentes serviços a resposta de confirmação de criação de sucesso, ou a resposta com erro de criação, caso tenha acontecido algum erro. Para a criação de um lugar seguro, a lógica da sequência é muito semelhante à criação da cerca virtual; no entanto, a interface de criação é diferente, pois neste caso quer-se apenas assinalar uma posição no mapa, ao invés de desenhar uma área. O pedido efetuado pela API Gateway também será a um serviço diferente - em vez de ser ao serviço Geofences , será ao serviço Outdoor que, para além de ser 32 3.5. DIAGRAMAS DE SEQUÊNCIA responsável por gerir os dados e pedidos de dispositivos e localizações, também é responsável por gerir os lugares seguros. Excetuando estes dois casos, a sequência de criação de um lugar seguro é igual à de criação de uma cerca virtual. 3.5.6 Verificar Localização dos Dependentes Figura 8: Diagrama de Sequência: Verificar Localização dos Dependentes Após o utilizador criar os dependentes, associar dispositivos e desenhar cercas virtuais, como foi descrito nas secções anteriores, o sistema encontra-se capaz de verificar a localização dos dependentes à medida que vai recebendo as posições GPS por parte dos dispositivos. No exemplo apresentado no diagrama da figura 8, a API Gateway recebe regularmente a posição GPS enviada pelos dispositivos e encaminha-a para o serviço Outdoor . Este serviço, por sua vez, regista a localização do dispositivo para ser apresentada ao utilizador mais tarde, caso pretenda, e comunica diretamente com o serviço de Geofences para confrontar a posição recebida com as cercas ativas, sem passar pela API Gateway . O serviço Geofences irá fazer a verificação com base na posição GPS recebida e enviará a resposta de volta para o Outdoor , indicando se o dependente se encontra dentro de uma cerca virtual, se saiu de uma, ou se entrou numa após algum tempo. Caso a informação recebida seja de que o dependente se encontra dentro de uma cerca virtual, não será espoletado nenhum alerta para o cuidador, pois tudo se encontra dentro da normalidade. No entanto, caso seja verificado que o dependente se encontrava numa cerca virtual e saiu, o serviço Outdoor vai criar uma mensagem e enviar para o Message Bus , que irá comunicar diretamente com o serviço Notifications , que, por sua vez, irá criar a notificação a ser enviada para o utilizador. Caso seja verificado que o dependente esteve algum tempo fora de uma cerca mas entretanto já retornou à área ”autorizada”, a lógica anterior repete-se, com diferença no conteúdo da mensagem a apresentar ao utilizador, que indica que o dependente retornou à cerca virtual. A sequência descrita na figura 8 também se aplica aos lugares seguros, mas, como foi referido anteriormente na criação de cercas virtuais e lugares seguros, a diferença encontra-se na comunicação entre os serviços Outdoor e Geofences (que não existe), e na verificação que é feita. Neste caso, a 33 CAPÍTULO 4. IMPLEMENTAÇÃO DA APLICAÇÃO Figura 13: Arquitetura Tecnológica Docker 4para criação e gestão de containers , o Github 5para controlo de versões e o Postman 6para fazer pedidos às API’s e testar as mesmas. Por fim será explicado o porquê da utilização da Google Cloud 7 para fazer o deployment da aplicação, assim como as suas vantagens e desvantagens. 4.1.1 React O React é uma biblioteca JavaScript open-source para criar interfaces para os utilizadores em aplicações web, criado e mantido pela empresa Meta [27]. Dado que o front-end do SmartAL já se encontrava desenvolvido em React , e de forma a reutilizar certos componentes e estilos, tirando assim o máximo proveito das suas funcionalidades, a interface nesta solução foi também desenvolvida em React . O React organiza-se em componentes, em que cada um contém pequenos elementos da UI que, unidos, formam a página final. Esta abordagem permite a atualização e gestão dos dados de forma independente, sendo as atualizações aos dados feitas estritamente onde estão colocados, resultado do conceito de ”Virtual DOM”. Esta capacidade permite ao React ter uma excelente performance e ser fácil de escalar, uma vez que o código está todo separado em pedaços que funcionam de forma independente. 4https://www.docker.com/ 5https://github.com/ 6https://www.postman.com/ 7https://cloud.google.com 40 4.1. ARQUITETURA TECNOLÓGICA Uma das particularidades do React é o facto de usar o JSX para escrever código HTML diretamente com o JavaScript . Esta funcionalidade traz flexibilidade na ligação dos dados com a estrutura da página web. Relativamente a esta ligação, ela é one-way data flow , ou seja, os dados dos componentes não são afetados pelas mudanças nos dados dos descendentes, permitindo um código mais estável e controlável em projetos complexos. Por fim, esta framework é a mais popular dos últimos anos, tendo crescimentos exponenciais a nível de funcionalidades e atualizações, e de integração em diversos projetos, que resultou numa vasta comunidade que disponibiliza plug-ins e torna a aprendizagem mais fácil [9]. De seguida serão apresentadas as vantagens e desvantagens do React . Vantagens • Fácil de aprender e utilizar, qualquer desenvolvedor com background em JavaScript consegue perceber facilmente e começar a desenvolver utilizando React ; • Virtual DOM – resulta numa performance otimizada, já que apenas são atualizados os elementos necessários; • One-way data flow – dados dos componentes não são afetados pela alteração dos descendentes; • Baseado em componentes reutilizáveis que se interligam, mas funcionam independentemente; • Otimizado para motores de busca; • Diversos plug-ins disponíveis – grande suporte da comunidade, o que também torna a aprendizagem fácil; • Cross-platform – muitas frameworks de desenvolvimento web/mobile utilizam o React ; • Ferramentas de testagem incluídas - Jest . Desvantagens • Dada a rápida evolução do React (o que pode parecer uma vantagem), os desenvolvedores têm de estar constantemente a atualizar-se com novos processos e mecânicas da biblioteca; • Fraca documentação – a comunidade será o melhor meio de obter conhecimento das potencialidades do React . 4.1.2 Node.js No que diz respeito às API , ambas foram desenvolvidas em Node.js , um ambiente em JavaScript que permite a execução de código do lado do servidor [11]. É uma tecnologia com excelente performance 41 CAPÍTULO 4. IMPLEMENTAÇÃO DA APLICAÇÃO e baixo consumo de memória, o que faz com que tenha ganho cada vez mais popularidade. Outra vantagem que influenciou a escolha do Node.js foi a sua flexibilidade e escalabilidade, graças ao seu gestor de pacotes e bibliotecas ( Node Package Manager (NPM) ), que contém inúmeros componentes reutilizáveis, e também ao facto de ser possível escalar não só horizontalmente, adicionando mais nós, como verticalmente, adicionando mais recursos. Com estas características, o Node é cada vez mais utilizado, o que resulta num grande apoio da comunidade, sendo partilhado o conhecimento por todos os utilizadores desta tecnologia. No entanto, a utilização do Node tem algumas desvantagens, dado que, devido à vasta quantidade de bibliotecas, alguns recursos podem não estar suficientemente preparados para ambientes de produção, o que muitas vezes impossibilita o seu uso. Apesar de o Node.js ser um ambiente em JavaScript , como foi referido, também é possível utilizar o mesmo com TypeScript . TypeScript 8é uma linguagem de programação open-source que é um superconjunto de JavaScript , isto é, adiciona funcionalidades próprias às já existentes do JavaScript , neste caso static typing . O typing consiste em atribuir tipos a objetos, fazendo com que a aplicação esteja melhor documentada e exista um maior controlo sobre o código, uma vez que o compilador de TypeScript valida se as operações estão corretas – cada vez que objetos, funções, etc. são chamados no decorrer do projeto, os seus campos têm de estar de acordo com os tipos definidos, sendo detetados os erros mais rapidamente. Apesar de inicialmente parecer mais complexo que o JavaScript , tem vindo a ganhar popularidade entre a comunidade, pelo que se optou por utilizar TypeScript neste projeto ao invés do JavaScript . 4.1.3 Prisma Para fazer a comunicação com a base de dados utilizou-se Object-relational mapping (ORM) , que é um mecanismo que encaminha, acede e manipula os dados de forma agnóstica em relação à base de dados utilizada, não sendo necessário executar comandos em SQL , utilizando ao invés uma interface de programação que faz todo o trabalho de persistência dos dados [8]. Por exemplo, com o uso de um ORM com uma linguagem de programação orientada a objetos, este mecanismo irá converter as classes em tabelas na base de dados, incluindo os seus atributos e as relações entre si. Para o desenvolvimento desta solução, utilizou-se o Prisma 9, um ORM open-source para aplicações com back-end em Node.js e Typescript . Está dividido em três camadas: •Prisma Client - camada em que é gerado um construtor para definir e executar as consultas; •Prisma Migrate - sistema de migração responsável por converter as classes em tabelas; •Prisma Studio - interface para o utilizador visualizar e editar os dados. O facto de ser um ORM recente faz com que não exista ainda muita documentação por parte da comunidade, o que por vezes pode dificultar a solucionar certos problemas, no entanto, dado a sua simplicidade e fácil utilização, foi o escolhido para a execução deste trabalho. 8https://www.typescriptlang.org/ 9https://www.prisma.io/ 42 4.1. ARQUITETURA TECNOLÓGICA 4.1.4 PostgreSQL O PostgreSQL é um Sistema de Gestão de Base de Dados (SGBD) open-source e relacional, que utiliza Structured Query Language (SQL) para o tratamento dos dados, combinando com muitas outras funcionalidades que permitem guardar e escalar dados de variada complexidade, de data types avançados e com uma excelente performance [14]. Suporta muitos tipos de dados, alguns que são mais comuns noutros SGBD, como string, integer, float, boolean etc., mas também dados documentais como JSON, XML e até formas geométricas. A sua robustez, alta disponibilidade, tolerância a falhas, ser open-source , requerer baixa manutenção e ser suportado em todos os sistemas operativos faz com que seja uma ferramenta muitas vezes escolhida para o desenvolvimento de soluções. Para a sua escolha para este projeto, aliou-se o facto dos microsserviços do SmartAL também utilizarem todos este SGBD, e assim facilitar o deployment das bases de dados dos diferentes serviços. 4.1.5 RabbitMQ O RabbitMQ é um software open-source para mensagens, que implementa o protocolo Advanced Message Queuing Protocol (AMQP) , isto é, permite a criação de queues (canais) nos quais as aplicações se conectam e trocam mensagens [15]. Permite lidar com o tráfego de mensagens de forma rápida e confiável e é compatível com diversas linguagens de programação. Após existir um canal definido, é criada uma mensagem por uma aplicação que se conecta ao canal, mensagem essa que permanece na queue até que outra aplicação a receba. Os conceitos mais importantes para perceber o funcionamento do RabbitMQ são os seguintes: •Producer - aplicação que envia a mensagem; •Consumer - aplicação que recebe a mensagem; •Queue - canal que transmite e guarda as mensagens; •Exchange - agente responsável por encaminhar as mensagens para a queue , dependendo das regras definidas; •Routing Key - atributo anexado ao header das mensagens, que indica como a mesma deve ser tratada pelo exchange . 4.1.6 Docker Docker é uma plataforma que permite virtualizar sistemas operativos, na forma de containers . É utilizado para automatizar o desenvolvimento de aplicações, pois utiliza containers portáteis, isto é, componentes do Docker que contêm toda a informação de uma aplicação ou serviço, podendo ser transferido para outro computador ou cloud e ser executado sem ser necessário configurar toda a aplicação novamente. 43 CAPÍTULO 4. IMPLEMENTAÇÃO DA APLICAÇÃO O Docker tem como objetivo o isolamento, criando múltiplos ambientes no mesmo servidor, isolados dos restantes, no entanto, possibilitando a comunicação entre eles. Para criar um ambiente Docker é necessário criar um dockerfile , um ficheiro com as instruções para a criação de imagens, ou seja, os comandos a serem executados, os ficheiros a serem utilizados e as variáveis de ambiente necessárias. As imagens, por sua vez, são os ficheiros que têm as instruções para criar containers . Enquanto um dockerfile tem as instruções para criação de várias imagens, as suas variáveis de ambiente, canais de comunicação etc., as imagens são como que um snapshot , que, quando executado cria os containers . Os containers são os referidos ambientes isolados, que são vários neste projeto, pois cada serviço será um container . Mais uma vez, a escolha do Docker neste trabalho recaiu sobre o facto da equipa da Altice Labs já usar esta tecnologia no desenvolvimento; assim, ao criar os containers e utilizá-los para desenvolver o projeto, o processo de deployment foi facilitado, pois apenas foi necessário carregar e executar as imagens na Google Cloud . 4.1.7 Github O Github é uma plataforma para controlo de versões e colaboração entre desenvolvedores e equipas, permitindo a várias pessoas trabalharem no mesmo projeto em simultâneo. Consiste na criação de repositórios, que se traduzem em projetos, que contêm todos os ficheiros dos mesmos, permitindo criar várias versões do mesmo projeto para várias pessoas poderem contribuir em simultâneo, sendo possível fazer um merge (fusão) dessas versões para obter um produto mais complexo. A escolha desta plataforma deveu-se ao facto de ser a plataforma utilizada pela Altice Labs para o controlo de versões de outros projetos, como por exemplo o SmartAL , com o qual a presente solução possui serviços em comum. 4.1.8 Postman O Postman é um API Client open-source usado para facilitar o desenvolvimento de API . Com esta ferramenta é possível realizar pedidos HTTP , sendo possível catalogá-los, facilitando a documentação da API . Ao criar um pedido é possível especificar o seu tipo ( GET, POST, PUT, DELETE , etc.), personalizar a informação enviada e receber as respostas. Com o Postman é possível realizar testes às API de forma simplificada e partilhar os pedidos com outros membros de equipa, melhorando assim a colaboração e evolução do projeto. 4.1.9 Google Cloud Google Cloud é uma plataforma que fornece recursos de cloud computing , permitindo, entre outras funcionalidades, processar e armazenar dados, ajudar no desenvolvimento, correr testes e instalar aplicações. Dada a sua infraestrutura completa e as diversas funcionalidades que fornece, a Google Cloud permite a empresas gerir os seus dados e aplicações de uma forma mais simples, eficaz e com segurança. 44 4.2. IMPLEMENTAÇÃO DE MICROSSERVIÇOS Este serviço foi utilizado no deployment deste projeto, dado que a Altice Labs possui uma conta, não havendo necessidade de subscrever outra ferramenta do género, centralizando assim todos os microsserviços. Apesar de esta ser a razão principal da escolha da Google Cloud , o autor salienta as seguintes características, que tornam esta uma escolha acertada para serviço de cloud : • Alta produtividade - consegue gerir vários dados de vários utilizadores ao mesmo tempo sem comprometer o serviço; • Facilidade de colaboração - múltiplos utilizadores podem trabalhar no mesmo projeto ao mesmo tempo; • Abstração - dado ser um serviço na cloud e aí serem processados todos os dados, os utilizadores podem trabalhar/contribuir a partir de qualquer lado sem se preocuparem com compatibilidade de hardware/software; • Escalável - é altamente escalável e usa escalamento automático para ajustar o uso de máquinas virtuais conforme a variação de acessos à aplicação; • Fiabilidade - dispõe de alta fiabilidade; caso um serviço vá abaixo o sistema imediatamente utiliza um secundário, sem que qualquer interrupção seja notada pelos utilizadores. 4.2 Implementação de Microsserviços Nesta secção serão apresentados os microsserviços e como estes foram implementados. De uma forma mais detalhada, serão abordados os microsserviços Outdoor e Geofences , que são os que foram criados no âmbito deste projeto; no entanto, serão também abordadas as alterações feitas a outros serviços já implementados por parte da equipa do SmartAL , como é o caso do serviço Notifications . De notar que nesta secção apenas serão apresentados os microsserviços que constituem a camada de negócio, isto é, o back-end , deixando a camada de apresentação, front-end , para a próxima secção. 4.2.1 Notifications O serviço de notificações é um serviço que, como foi dito anteriormente, já se encontrava implementado pela equipa da Altice Labs . No entanto, este foi desenhado com vista a ser utilizado exclusivamente pelo SmartAL , pelo que foram necessárias fazer alterações para ser também utilizado pelo Teleloc . Serão essas as alterações descritas nesta secção, sendo apenas explicadas as funcionalidades que são necessárias para a presente solução. Na figura 14 é possível visualizar a estrutura do serviço Notifications , e de seguida será explicado como este se encontra organizado assim como uma explicação dos ficheiros mais relevantes. 45 CAPÍTULO 4. IMPLEMENTAÇÃO DA APLICAÇÃO Figura 14: Estrutura do serviço Notifications prisma Nesta pasta estão os ficheiros de configuração do ORM Prisma , nomeadamente o ficheiro schema.prisma . Este ficheiro contém a conexão à base de dados, com o URL de ligação a ser passado numa variável de ambiente, e os models que se vão traduzir em tabelas na base de dados. configs Nesta pasta estão ficheiros com configurações do projeto como variáveis globais, portas de comunicação, etc. mappers, middleware Estas diretorias contêm ficheiros com funções e ferramentas que auxiliam o restante código. Na pasta mappers encontra-se o ficheiro DateTimeFormater.ts , que é responsável por formatar uma data recebida de acordo com a linguagem e fuso horário que recebe como argumentos quando é chamada. Já na pasta middleware está o ficheiro ExpressAuthTokenValidator.ts , que é responsável por fazer receber e validar o token , verificando se se encontra válido ou se há um erro na autenticação. types Como é utilizado TypeScript , é necessário definir os tipos a serem utilizados. Nesta pasta encontramse ficheiros com os tipos necessários para a escrita do código. Na figura 15 vê-se a estrutura de uma notificação (neste caso, de um aviso sobre cercas). A notificação é composta pelo ID da cerca, pelo ID do cuidador a ser notificado, pelo ID do dependente em questão, pelo tipo da notificação (que neste caso é se o dependente entrou ou saiu da cerca virtual) e pela severidade da notificação - alta, média ou baixa. O último campo é o texto a ser adicionado posteriormente à notificação para ser apresentada ao utilizador. 46 4.2. IMPLEMENTAÇÃO DE MICROSSERVIÇOS Figura 15: Estrutura de uma notificação de geofences mqConsumers Como foi mencionado na secção 4.1.5, utiliza-se o RabbitMQ para fazer a troca das mensagens entre os serviços. Para tal é necessário implementar funções que consumam as diferentes mensagens recebidas. Nesta pasta encontra-se o ficheiro TelelocStatusConsumer.ts , onde estão definidas as funções que recebem as notificações e as configuram para serem guardadas na base de dados e enviadas ao utilizador. Cada função é referente a uma routing key , um elemento análogo a um endereço para o qual a mensagem é enviada na queue , existindo uma para cada tipo de notificação. Após receber uma mensagem a função respetiva vai buscar toda a informação necessária para construir uma notificação para poder ser apresentada ao utilizador. routes Contém os ficheiros com as rotas a serem chamadas pela API Gateway para obter as notificações. •GET /api/userNotifications/history - retorna todas as notificações de um utilizador, sendo necessário enviar queryParams com o ID do utilizador; •GET /api/userNotifications/unread - retorna todas as notificações não lidas de um utilizador; •PUT /api/userNotifications/read/notificationId - atualiza o estado de uma notificação não lida para lida. services Nesta pasta encontram-se os ficheiros de serviço, isto é, ficheiros que realizam a comunicação com outras ferramentas e tecnologias, como é a base de dados e o RabbitMQ . Nesta pasta encontra-se o ficheiro EntityService.ts , que comunica com o serviço das entidades para obter informação dos cuidadores e dependentes. O MessageQueueService.ts estabelece a comunicação com o serviço RabbitMQ , conectandose aos diferentes exchanges onde vão ser recebidas as mensagens. O ficheiro UserNotificationService.ts é responsável por persistir os dados das notificações na base de dados, com recurso ao Prisma . Adicionalmentem, existem ficheiros comuns a uma aplicação em Node.js : index.ts - ficheiro com a implementação geral da API ; 47 CAPÍTULO 4. IMPLEMENTAÇÃO DA APLICAÇÃO .env - responsável pelas variáveis de ambiente; Dockerfile - ficheiro responsável por gerar a imagem Docker ; package.json - ficheiro com as dependências a serem instaladas e respetivas versões; tsconfig.json - ficheiro de configuração do TypeScript . 4.2.2 Outdoor Um dos microsserviços especificamente implementados para este trabalho é o serviço Outdoor , que é responsável por gerir os dispositivos, as localizações e os lugares seguros dos dependentes. O desenvolvimento deste microsserviço que, como referido, foi realizado em Node.js , começou pela definição do modelo de dados; de seguida, criou-se uma rota e respetiva lógica de negócio para satisfazer cada requisito e, por fim, implementou-se a persistência das alterações na base de dados. Este processo foi realizado ao longo de todo o desenvolvimento, ciclicamente até se obter o número de rotas que satisfizesse os requisitos definidos na modelação do projeto. Figura 16: Estrutura do serviço Outdoor Na figura 16 é possível observar a estrutura do repositório do serviço Outdoor , pelo que será explicado em detalhe de seguida. prisma À semelhança do serviço Notifications , e dado que ambos usam o Prisma ORM , na pasta prisma encontram-se o ficheiro prisma.schema , que contém a conexão à base de dados (sendo também o URL de ligação fornecido pela variável de ambiente) e o diretório models , que contém as classes que se vão traduzir em tabelas na base de dados. Os modelos a serem criados são os que foram representados na figura 10, na secção 3.6, sobre o modelo de dados da aplicação. 48 4.2. IMPLEMENTAÇÃO DE MICROSSERVIÇOS configs À semelhança do serviço anteriormente apresentado, a pasta configs contém ficheiros com configurações do projeto, como variáveis globais, portas de comunicação e a public key do JWT 10. middleware Esta diretoria contém como o nome indica, ficheiros de middleware , que servem para realizar validações em certos casos, possuindo os ficheiros DeviceValidator.ts , ExpressAuthTokenValidator.ts e LocationValidator.ts . Figura 17: DeviceValidator.ts Na figura 17 pode-se ver o ficheiro DeviceValidator.ts . Este middleware vai ser chamado aquando da criação de um novo device, para fazer a verificação de certos campos. Primeiro, verifica se o campo IMEI11 se encontra vazio e, caso não se encontre, verifica se já está registado na base de dados. De seguida, verifica se o nome ou número de telemóvel estão em falta e, caso não estejam, se já se encontram na base de dados. Em todos os casos, se for detetado algum erro, é devolvida essa informação. 10JSON Web Token, um padrão para transmitir credenciais de forma segura – https://jwt.io 11International Mobile Equipment Identity – número que identifica univocamente um dispositivo móvel 49 CAPÍTULO 4. IMPLEMENTAÇÃO DA APLICAÇÃO No caso dos eventos em que é recebida uma atualização da bateria, os dispositivos são atualizados no campo battery_level e, caso o mesmo se encontre abaixo dos 20%, é enviado um alerta ao cuidador a indicar bateria baixa. Nos restantes tipos de eventos não é necessário haver nenhum tipo de verificação, sendo apenas necessário enviar os alertas com o aviso correspondente. Na figura 25 é possível verificar a criação de uma mensagem sobre um alerta SOS que corresponde a uma queda. Figura 25: Envio de alerta sobre queda para o RabbitMQ services Na última camada dos microsserviços encontram-se os services , ficheiros responsáveis por fazer a persistência na base de dados, utilizando o Prisma ORM . Os ficheiros nesta diretoria são DeviceService.ts , LocationService.ts e SafePlaceService.ts . Nos services encontram-se as funções que são chamadas pelos controllers para persistir os dados, pelo que não possuem muita lógica, apenas recebendo dados ou campos e realizando operações CRUD ( create, read, update, delete ). Nas operações de criação, apenas é necessário indicar a tabela que se pretende criar e os dados a persistir. Nas operações de leitura, pode-se obter a informação pretendida de várias maneiras: • findUnique ()- obtém-se apenas uma entrada da tabela, indicando um identificador único; • findMany() - obtêm-se várias entradas, que correspondam a um filtro; • findFirst() - obtém-se a primeira entrada encontrada na tabela que corresponda ao critério indicado. Nestas operações também é possível selecionar apenas alguns campos a serem devolvidos com a query select . As operações de atualização são semelhantes às de criação, com a exceção de que é necessário indicar as condições que devem ser respeitadas para uma ou mais entradas serem atualizadas com a respetiva informação. Por fim, existe a operação de apagar, em que é possível apagar um ou mais registos que respeitem os critérios definidos. Na figura 26, é apresentado o exemplo da função utilizada para persistir os dados de um novo dispositivo em que é recebido um objeto com os dados do mesmo, passados no campo data da operação 56 4.2. IMPLEMENTAÇÃO DE MICROSSERVIÇOS create do prisma para a tabela device . Neste caso também é utilizado um bloco try/catch , pelo que, se for espoletado algum erro, este é devolvido ao controller . Figura 26: Função do Service createDevice Neste serviço existem também ficheiros que servem de configuração do projeto, assim como a sua configuração para um Docker Container : app.ts - ficheiro com a implementação geral da API ; .env - responsável pelas variáveis de ambiente; Dockerfile - ficheiro responsável por gerar a imagem Docker ; package.json - ficheiro com as dependências a serem instaladas, assim como as suas versões; tsconfig.json - ficheiro de configuração do TypeScript . 4.2.3 Geofences O segundo e último microsserviço implementado especificamente para a aplicação Teleloc foi o serviço Geofences , que gere toda a informação relativa às cercas virtuais, assim como a sua lógica de serviço. À semelhança do serviço Outdoor , inicialmente foi implementado o modelo de dados e criadas as classes e de seguida implementaram-se as rotas, a lógica de cada uma e a lógica de persistência dos dados tratados por cada rota. Na figura 27 é possível observar a estrutura do repositório do serviço Geofences . Muitos dos ficheiros que se encontram neste repositório têm o mesmo propósito de ficheiros que foram descritos nos serviços anteriores. As diretorias prisma , config , middleware e types possuem ficheiros com as mesmas funções que as suas homónimas nos outros serviços, servindo respetivamente para fazer a ligação com a base de dados e criar as tabelas, definir variáveis globais e portas de comunicação, validar dados ao longo da 57 CAPÍTULO 4. IMPLEMENTAÇÃO DA APLICAÇÃO aplicação e definir os tipos (estruturas de dados/interfaces) a serem utilizadas pelo projeto. Figura 27: Estrutura do serviço Geofences models Nesta pasta encontra-se o ficheiro geofencesModel.ts , que define os tipos (classes) que são utilizados ao longo do projeto. Estes tipos vão ser um reflexo do modelo de dados definido, à semelhança do que acontece na definição dos modelos no schema.prisma . Na figura 28 pode-se ver o exemplo de um tipo definido em TypeScript , neste caso da classe Geofence . Figura 28: Classe Geofence em TypeScript routes Dado que este serviço é mais pequeno e com menos funcionalidades geridas, em comparação ao Outdoor , possui apenas um ficheiro de rotas, o GeofencesRouter.ts , que define todas as rotas necessárias para a gestão das cercas virtuais. 58 4.2. IMPLEMENTAÇÃO DE MICROSSERVIÇOS GeofencesRouter.ts •POST /createGeofence - criar uma cerca virtual, em que os dados são recebidos no body do pedido; •POST /setDependentGeofence - atribuir uma cerca a um dependente, em que os ID são enviados no body ; •POST /removeDependentGeofence - remover a relação entre uma cerca e um dependente, em que os ID são enviados no body do pedido; •PUT /editGeofence/:id - editar uma cerca, com dados enviados no body do pedido e o ID passado em parâmetro; •PUT /changeGeofenceDependentStatus/:dependentId/geofence/:geofenceId - alterar o estado de uma cerca entre ativa/inativa relativamente a um dependente, em que os ID são enviados como parâmetros; •DELETE /removeGeofence/:id - apagar uma cerca, indicando o seu ID; •GET /getGeofence/:id - obter todos os dados de uma cerca através do seu ID; •GET /geofences - obter todas as cercas associadas ao cuidador que efetua o pedido; •GET /getDependentGeofences/:id - obter todas as cercas de um dependente através do seu ID; •GET /getDependentActiveGeofences/:id - obter todas as cercas ativas de um dependente através do seu ID; •GET /getFenceData/:id - obter os dados de localização de uma cerca através do seu ID; •GET /getGeofenceDependents/:id - obter os dependentes de uma cerca através do seu ID. Na figura 29 pode-se ver a rota para a criação de uma cerca virtual implementada. Esta rota é um pedido POST com o caminho /createGeofence ; recebe no body os dados necessários para a criação da cerca, pelo que é necessário fazer uma validação dos campos obrigatórios (mais simples do que na criação de um dispositivo, pois apenas é verificado o campo name ). À semelhança do serviço Outdoor , a rota faz esta validação através das funções creationSchema e validateRequestSchema . Após tudo validado, é chamada a função do Controller que vai executar a criação da cerca e encaminhar os dados para o Service para serem persistidos na base de dados. Após criada a cerca e persistidos os dados, é devolvida uma resposta à função no GeofencesRouter.ts , que verifica a resposta e devolve a mesma com sucesso (ou com erro, caso não tenha sido possível criar a cerca). 59 CAPÍTULO 4. IMPLEMENTAÇÃO DA APLICAÇÃO Figura 29: Rota POST /createGeofence Existe também neste ficheiro a rota POST /internal/checkLocationGeofences , uma rota que é utilizada pelo serviço Outdoor para fazer a validação das posições recebidas relativamente às cercas de cada dependente. Cada vez que é recebido um novo liveEvent no serviço Outdoor , como já foi verificado, é feito um pedido por parte desse mesmo serviço para esta rota, indicando no body o ID do dependente cuja posição verificar e a localização em questão, sendo a verificação feita no controller . controllers O GeofencesController.ts executa as funções lógicas no serviço. Cada vez que uma rota é chamada, o pedido é encaminhado para a respetiva função no controller para ser tratado. Figura 30: Função do Controller createGeofence 60 4.2. IMPLEMENTAÇÃO DE MICROSSERVIÇOS Na figura 30 pode-se observar o exemplo da função do GeofencesController.ts , que é chamada pela rota POST /createGeofence , utilizada na criação de uma cerca virtual, recebendo a informação do pedido e o ID do cuidador. Mais uma vez, é utilizado um bloco try/catch , em que é executada lógica no try ou, caso seja espoletada uma exceção/erro, é tratada no catch . No bloco try , vai ser criado um objeto do tipo CircularFence ou PolygonalFence . Este objeto possui os dados de localização da cerca e tem uma estrutura diferente, consoante a cerca for circular ou poligonal (dependendo do atributo is_circular que é recebido no body ). Após verificada se é circular ou não, atribuem-se os dados ao objeto conforme o seu tipo, sendo gerado um UUID com recurso à biblioteca uuid em ambos os casos. Caso seja circular, o objeto vai conter a latitude e longitude do centro da circunferência e o raio da mesma. Se for poligonal, vai ser criado um atributo points que contem um array com os pontos (latitude e longitude) dos vértices do polígono. Todos os outros campos encontram-se no body do pedido e são atribuídos aos respetivos atributos. Após isso é criado um objeto do tipo Geofence , em que são acrescentados os restantes dados e a referência para o ID do objeto fence que contém os dados da localização. Posteriormente é feito o pedido ao GeofencesService , para onde é enviado o objeto para os dados serem persistidos. Após recebida a resposta por parte do service , é possível devolver à route o objeto criado para ser devolvido ao utilizador. Caso a execução do bloco resulte num erro, é espoletado o bloco catch , que é responsável por registar o sucedido nos logs e enviar ao utilizar a mensagem sobre erro em questão. No GeofencesController.ts existe a função checkLocationGeofences , que é chamada pela rota POST /internal/checkLocationGeofences quando é necessário verificar uma posição recebida em relação às cercas do dependente. A função vai receber o pedido como parâmetro, para ser possível aceder ao body e obter os dados necessários para a verificação, que são a localização e o dependente que se encontra na mesma. Inicialmente vai ser criado um array de objetos que vão indicar a posição do dependente em relação às várias cercas ( in ou out ) e que serão adicionados à medida que a verificação é feita para cada uma das cercas ativas. Em seguida, é verificado se o dependente, na atualização anterior a esta posição, se encontrava dentro de uma cerca, sendo feito um pedido ao Service para obter informação da tabela ActualFence (explicada no modelo de dados na secção 3.6). Finalmente, são obtidas as cercas do dependente – caso não tenha nenhuma, a função termina neste passo, pois não há nenhuma verificação a fazer; caso contrário continua e será feita uma verificação para cada cerca, sendo diferentes as verificações nas cercas circulares das poligonais. Na figura 31 é apresentada a função que faz a verificação da posição numa cerca circular. Primeiramente são obtidos os dados de localização da cerca (ponto do centro e raio). Para fazer esta verificação foi utilizada a fórmula de haversine , uma fórmula utilizada para calcular a distância entre dois pontos numa esfera (neste caso no planeta Terra). Para utilizar a fórmula são definidas as seguintes variáveis e equações: •Rraio da Terra em metros; •dx - latitude da localização recebida em radianos; 61 CAPÍTULO 4. IMPLEMENTAÇÃO DA APLICAÇÃO •dy - latitude do centro da cerca em radianos; •rx - diferença entre a latitude do centro da cerca e a latitude do ponto recebido em radianos; •ry - diferença entre a longitude do centro da cerca e a longitude do ponto recebido em radianos. 𝑎=sin(𝑟𝑥/2)2+cos (𝑑𝑥) · cos (𝑑𝑦) + sin(𝑟𝑦/2)2(4.1) 𝑐=2·𝑎𝑡𝑎𝑛2(𝑎, 1−𝑎)(4.2) 𝑑=𝑅·𝑐(4.3) As equações 4.1 e 4.2 são a fórmula de haversine dividida para simplificar a sua implementação. Através da resolução destas duas equações obtém-se a variável c , que representa o ângulo central, um arco entre os dois pontos. Após obtido o ângulo central, o mesmo é multiplicado pelo raio da Terra, o que se vai traduzir na distância entre os dois pontos, em metros. Posteriormente este valor é comparado com o raio da cerca e, caso seja menor, significa que o ponto se encontra dentro da cerca, caso contrário está fora da cerca. Figura 31: Verificação da Posição numa Cerca circular 62 4.2. IMPLEMENTAÇÃO DE MICROSSERVIÇOS Figura 32: Verificação da Posição numa Cerca poligonal A verificação do ponto relativamente a uma cerca poligonal inicia da mesma forma, sendo obtidos os pontos que constituem os vértices do polígono. Após isso, inicia-se a verificação que se pode ver implementada na figura 32. É criada uma matriz com os valores da longitude e latitude dos vértices e serão percorridos todos os valores da matriz, sendo a mesma realizada aos pares de forma a ser formada uma “linha” entre os dois pontos e verificar a localização obtida em relação a esta “linha”. Após feita a verificação, é devolvida à função a variável is_in , que pode ser verdadeira ou falsa, consoante a localização do ponto em relação ao polígono (dentro ou fora, respetivamente). Cada vez que uma destas verificações é feita, o resultado é devolvido à função principal e é adicionado ao objeto o ID da cerca de que foi feita a verificação e o resultado, como é possível verificar na figura 33. Após criado este objeto, o mesmo é percorrido de forma a verificar se houve uma atualização na cerca em que o dependente se encontra atualmente. Se saiu de uma cerca em que se encontrava, é criada uma resposta com um alerta para ser enviado ao utilizador como notificação. 63 CAPÍTULO 4. IMPLEMENTAÇÃO DA APLICAÇÃO Figura 33: Loop de verificação de posição Figura 34: Resposta de alerta de saída de uma cerca Na figura 34 é possível visualizar a criação de uma notificação no caso de o dependente não se encontrar em nenhuma cerca. Inicialmente é obtida a data em que está a ser feita a verificação e a data em que o dependente esteve na cerca pela última vez. Comparando estes dois tempos, e caso a diferença seja superior a 5 minutos e a flag indique (por ter o valor falso) que não foi ainda enviada uma notificação ao cuidador, esta mesma é atualizada para verdadeiro e é criada uma notificação de severidade alta a indicar que o dependente saiu da cerca em que se encontrava. Neste caso foi utilizado uma margem de 5 minutos, para evitar situações de erro que por vezes ocorrem na obtenção das localizações, pois um dependente pode-se encontrar no limiar da cerca e assim estariam constantemente a ser enviadas notificações ao utilizador no caso de as localizações por vezes saírem um pouco do limite. Caso a flag esteja a verdadeiro (indicando que o cuidador já foi avisado) ou ainda não tenham passados 5 minutos, nenhuma ação é realizada. services Dada a necessidade de persistência dos dados relativos às cercas, como a informação das suas localizações, a cerca em que o dependente se encontra atualmente, relações, etc., é utilizado, à semelhança dos serviços anteriores, o ficheiro GeofencesService.ts , que realiza as operações CRUD de conexão à base de dados que foram apresentadas anteriormente. Na figura 35 é apresentado o exemplo da função utilizada para persistir os dados de uma nova cerca em que são recebidos dois objetos: um relativo às informações da cerca – nome, se é circular, data de criação, cuidador e ID da cerca – que guarda os dados de localização, e essa mesma cerca com os dados 64 4.3. INTERFACE DO UTILIZADOR de localização. Dado haver uma dependência entre a tabela Geofence e Fence , é necessário persistir os dados nesta primeiro, pois a primeira possui a referência para o ID de uma entrada desta tabela. De seguida, utilizando a operação Create , são persistidos os dados com a informação genérica da cerca. À semelhança dos exemplos anteriores, esta implementação encontra-se num bloco try/catch , pelo que, em caso de sucesso, a informação da criação da cerca é devolvida ao utilizador, caso contrário é devolvido o erro. Figura 35: Função do Service createGeofence Neste serviço também se encontram os ficheiros de configuração de projeto, com as mesmas funções que foram descritas no serviço Outdoor (4.2.2), aplicadas a este cenário. 4.3 Interface do Utilizador Como foi referido anteriormente na apresentação das tecnologias utilizadas (secção 4.1), o front-end da aplicação Teleloc foi desenvolvido em React . O desenvolvimento utilizando esta tecnologia careceu de alguma aprendizagem, sendo necessário familiarizar com certos conceitos, como é o caso dos elementos, componentes, props , eventos, hooks , etc.; no entanto, como esta solução será um complemento da aplicação já desenvolvida, SmartAL , foi possível reutilizar a grande maioria das componentes e estilos já desenvolvidos pela equipa da Altice Labs , o que simplificou e agilizou todo o processo de desenvolvimento, sendo apenas necessário aplicar ao presente caso de uso, realizando as adaptações necessárias e construindo as interfaces pretendidas. Em seguida, é realizada uma demonstração da aplicação desenvolvida, com foco na interface implementada, explicando como podem ser utilizadas as funcionalidades requeridas. Na página inicial, o utilizador depara-se com o formulário de login , que lhe permite aceder ao conteúdo da plataforma. Para tal o utilizador tem de inserir o seu email e palavra-passe para iniciar sessão e poder 65 CAPÍTULO 4. IMPLEMENTAÇÃO DA APLICAÇÃO Figura 47: Aplicação - Página de Dados de um Dependente Ao selecionar o separador “Dispositivos”, serão apresentados os dispositivos associados ao dependente em questão, com a possibilidade e editar, eliminar ou então adicionar mais dispositivos, como se pode verificar na figura 48. Figura 48: Aplicação - Página de Dispositivos de um Dependente No separador histórico, é possível obter um histórico das notificações recebidas relativas a um dependente. A figura 49 mostra esta funcionalidade, com as notificações recebidas relativas a um dependente criado. Estas serão apresentadas ordenadas por dia e hora, sendo possível pesquisar pelo conteúdo de forma a filtrar as notificações exibidas. No separador histórico também é possível alterar no menu dropdown (1) para o histórico de localizações, onde se pode definir um intervalo de tempo e ver a sua representação no mapa. Na figura 50 é possível observar um exemplo, onde se definiu um intervalo de tempo e foi desenhado no mapa o percurso realizado por um dependente nesse período. 72 4.3. INTERFACE DO UTILIZADOR Figura 49: Aplicação - Página de Histórico de Notificações de um Dependente Figura 50: Aplicação - Página de Histórico de Localizações de um Dependente Uma das opções da página principal é a visualização de um mapa onde se encontram as posições atuais dos dependentes. Esta interface engloba as principais funcionalidades da aplicação, onde é possível visualizar a posição dos dependentes e criar cercas virtuais e lugares seguros. Na figura 51 é apresentada a interface com o mapa sem qualquer cerca ou lugar seguro definido. No canto superior esquerdo encontra-se um filtro (1), onde se pode ativar e desativar a visualização de cercas virtuais ou lugares seguros, para simplificar a visualização e realização de ações quando o mapa apresentar demasiados elementos para uma compreensão rápida. Por baixo dos botões de filtro encontram-se duas caixas (2) com informações sobre cada um dos dependentes; a cada dependente é atribuída uma cor, que se reflete depois na cor dos elementos relativos a cada um (cercas e lugares seguros). Nesta caixa também é possível centrar o mapa num dos dependentes e adicionar cercas ou lugares habituais. No canto superior direito (3) encontra-se um menu que serve para a edição das cercas virtuais. Quando selecionado, pode-se selecionar uma cerca e editá-la ou removê-la. No canto inferior direito (4) encontram-se os controlos genéricos comuns aos mapas on-line , como zoom in/out e centrar na localização atual. 73 CAPÍTULO 4. IMPLEMENTAÇÃO DA APLICAÇÃO Figura 51: Aplicação - Página de Mapa sem Cercas/Lugares seguros Na figura 52 é possível observar a mesma página, mas com elementos atribuídos aos dependentes. Como se pode verificar, a dependente criada para esta demonstração, Rute Pereira, possui um lugar habitual denominado “Altice Labs”, cuja localização é visível no mapa com a cor atribuída à dependente. Já no caso do segundo dependente criado para o exemplo, Pedro Pereira, é possível verificar que tem uma cerca virtual definida, assim como o nome da mesma (“parque”) e que se trata de uma circunferência numa zona de lazer. Ambos os elementos podem ser ativados ou desativados, através do toggle (1) à frente do nome do elemento. Esta ativação/desativação reflete-se no estado do elemento, para, quando é feita uma verificação da posição relativa aos elementos de um dependente, o sistema saber quais os elementos que deve verificar e quais não o necessitam por estarem desativados. Figura 52: Aplicação - Página de Mapa com Cercas/Lugares seguros 74 4.3. INTERFACE DO UTILIZADOR Caso o cuidador queira definir uma nova cerca ou lugar habitual para um dependente, deve clicar nos botões indicados para cada uma dessas funcionalidades. No caso dos lugares habituais, após clicar no botão “Adicionar Lugar Habitual”, bastará selecionar a posição no mapa onde deseja alocar o elemento. No caso das cercas virtuais, é ativado um menu, que na figura 52 pode ser visualizado no canto superior direito (2), onde o cuidador poderá selecionar a forma que deseja desenhar a cerca. Após concluídas ambas as ações, é ativada uma caixa de diálogo, como a que pode ser observada na figura 53, onde o cuidador deve inserir o nome que deseja atribuir à cerca ou lugar habitual e clicar no botão “Adicionar” para confirmar a sua intenção. Após isso, o elemento fica disponível para ser visualizado no mapa, junto dos restantes. Figura 53: Aplicação - Caixa de Diálogo para criação de uma cerca Para editar ou eliminar um elemento, basta clicar sobre o mesmo; é aberto um menu que permite efetuar alterações, como a localização ou o nome, ou então proceder à eliminação. Na figura 54 é possível visualizar o menu que permite gerir um lugar habitual. Figura 54: Aplicação - Caixa de Diálogo para editar um Lugar Habitual Dado que o cuidador pode ter a seu encargo mais do que um dependente, é possível aceder na página principal às notificações de todos os dependentes (em vez de um a um, como na figura 49), carregando no ícone do sino no canto superior direito, onde é indicado o número de notificações por ler. Aqui serão apresentadas as notificações de todos os dependentes, indicando o grau de severidade das mesmas, com a possibilidade de ir para o mapa para verificar a situação do dependente em questão, como é possível observar na figura 55. 75 CAPÍTULO 4. IMPLEMENTAÇÃO DA APLICAÇÃO Figura 55: Aplicação - Pop-up para notificações 4.4 Deployment Para facilitar a gestão de todos os microsserviços referidos acima, num ambiente cloud , foi escolhido o Kubernetes 13. Esta solução de orquestração de containers controla o lançamento das imagens Docker , o seu ciclo de vida e, caso necessário, permite escalar serviços para dar resposta a um aumento de carga, lançando várias instâncias da mesma imagem para processamento em paralelo, podendo até fazê-lo de forma automática e dinâmica. Outra vantagem do uso de Kubernetes é sua adoção pelas clouds públicas mais conhecidas, como é o caso da Google Cloud , as quais disponibilizam ambientes geridos pelas próprias, o que reduz o tempo de inicialização e configuração do cluster Kubernetes [13]. Para escolher qual cloud contratar, a equipa de desenvolvimento do SmartAL fez um estudo comparativo sobre os 3 grandes cloud providers: Google Cloud, Amazon Web Services e Microsoft Azure . Concluiu-se que não existia um vencedor claro, todos têm um excelente catálogo de serviços de qualidade, com preços competitivos. A escolha final acabou por incidir na Google Cloud , devido a outros fatores externos, que já foram referidos na secção 4.1.9. Foi instanciado um cluster no Google Kubernetes Engine , composto por 3 máquinas virtuais, num total de 48 vCPU e 48 GB RAM. Cada microsserviço é lançado neste ambiente, com o Kubernetes a fazer o balanceamento de carga pelas 3 máquinas, de forma a distribuí-la uniformemente. 13https://kubernetes.io/ 76 4.4. DEPLOYMENT As imagens Docker são guardadas no GitHub Package Registry , podendo até ser geradas automaticamente, sempre que se lança uma versão, através de GitHub Actions . A configuração destes serviços no Kubernetes é feita através de ficheiros yaml , que contêm o URL do GitHub Package Registry onde reside a imagem Docker do serviço, além de outros parâmetros de configuração específicos do serviço. O Kubernetes age ao detetar mudanças nestes ficheiros yaml – por exemplo, ao mudar o URL da imagem, é lançado um “pod”14 com a nova imagem, que irá substituir o existente assim que acabe de iniciar, minimizando desta forma o downtime (o pod contendo a imagem antiga permanece ativo até o novo estar pronto). 14Unidade mínima que o Kubernetes orquestra; tipicamente um conjunto de um ou mais containers Docker 77 5 Conclusões e Trabalho Futuro Neste capítulo são apresentadas as conclusões obtidas na realização desta dissertação, os desafios e dificuldades encontrados e como estes foram ultrapassados, sendo realizada uma análise sobre todo o projeto. Também serão discutidos aspetos a serem melhorados e funcionalidades que poderiam ser implementadas num trabalho futuro. 5.1 Conclusões Esta dissertação teve como objetivo o desenvolvimento de uma aplicação de telelocalização, que permitisse a cuidadores formais ou informais visualizar em tempo real, delinear limites e verificar o estado dos seus dependentes através do simples uso de uma aplicação. Inicialmente foi necessário realizar um estudo sobre as áreas de eHealth e Assisted Living , de forma a entender a situação atual – social e tecnológica – nestas áreas e perceber de que forma seria possível a implementação de uma solução deste tipo e qual a melhor maneira de o realizar. Foi realizado também um estudo sobre serviços de telemonitorização que se encontram já disponíveis, assim como sobre dispositivos de localização, de forma a identificar os requisitos necessários e desafios que poderiam surgir no desenvolvimento da solução. Dada a metodologia utilizada no desenvolvimento deste projeto DSR , após o problema identificado e feito o estudo da área de atuação e definidos os objetivos pelo qual se basearia o desenvolvimento, procedeu-se ao design e desenvolvimento, onde se definiu o modelo de dados e a arquitetura a utilizar, e se pôs em prática a implementação da aplicação em si. Foi na fase inicial da implementação que começaram a surgir as primeiras dificuldades. Inicialmente, surgiu o problema de como obter a localização de dispositivos, pelo que, durante o processo, vários foram testados, de forma a perceber qual fornecia melhores informações e melhor fiabilidade para o sistema. No entanto, após vários testes, vários problemas surgiram, ora na configuração dos dispositivos, que não eram compatíveis ou adaptáveis para uma API, ora na informação que estes forneciam, que não era útil para o caso em questão. Este desafio foi ultrapassado através da realização de uma parceria entre a Altice Labs e a Neki , que cedeu dispositivos que enviavam eventos com localização para a API 79 CAPÍTULO 5. CONCLUSÕES E TRABALHO FUTURO desenvolvida neste projeto, e assim permitiu realizar o desenvolvimento com a utilização de dados de localização reais obtidos pelos dispositivos de teste. Ultrapassado o primeiro desafio, surgiu um segundo, que seria a implementação da aplicação. O facto de ser o primeiro projeto realizado em ambiente laboral e a utilização de tecnologias novas, nomeadamente de front-end , criou uma barreira inicial que resultou num arranque mais lento; no entanto, após a prática e apoio por parte da restante equipa, este problema foi facilmente ultrapassado, sendo que posteriormente o desenvolvimento foi mais simples e rápido. Durante o desenvolvimento da aplicação, já numa fase final, a mesma passou pelo processo de demonstração e avaliação, de forma a aplicar o artefacto desenvolvido a uma simulação ou experiência e comparar com os requisitos pretendidos. Esta etapa foi realizada numa apresentação ao vivo da aplicação no aniversário da empresa Altice Labs , em que soluções de telemonitorização e eHealth foram o destaque do evento [12]. A aplicação Teleloc teve um papel de destaque, tendo sido possível testar o seu uso e apontar as qualidades e defeitos identificados por uma maior quantidade de utilizadores do que até então, com diversos graus de experiência, e assim melhorar a solução. Nesta solução é possível destacar a interface gráfica, que cumpre com princípios de usabilidade que permitem ao utilizador menos experiente realizar facilmente as ações pretendidas de forma simples e rápida. De notar também a resposta dada por toda a parte lógica, que cumpre com os requisitos delineados, garantindo a execução de todas as funções de forma fiável e com tempo de resposta baixo. Por último, é possível afirmar que a aplicação desenvolvida é um produto que irá contribuir ativamente para a proteção e melhoria da qualidade de vida da população a que se destina, garantido um maior acompanhamento por parte dos cuidadores e consequentemente uma maior segurança. Assim, o autor conclui que a realização desta dissertação foi positiva, contribuindo para uma evolução nas áreas de eHealth e Assisted Living , para a Altice Labs e para a sociedade no geral. 5.2 Trabalho Futuro Os objetivos traçados para a execução deste projeto foram alcançados; no entanto, existe a possibilidade de implementar melhorias ou funcionalidades a acrescentar. De seguida serão apresentadas algumas sugestões para um trabalho futuro na melhoria da aplicação Teleloc : • Melhoria de responsividade da aplicação para dispositivos mobile ; • Aprimorar as funções de verificação de posicionamento em relação às cercas virtuais; • Incluir cenários de deteção de rotinas, com recurso a algoritmos de machine learning , de forma a prever eventuais situações de perigo para os dependentes; • Implementar o perfil de aplicação para os dependentes, para que os mesmos também possam utilizar a aplicação em certos cenários; 80 Bibliografia [1] C. H. U. C. da Beira. TERI - Telemonitorização Doentes em Risco . [Online; acedido em 23/11/2021]. url: http://www.chcbeira.min-saude.pt/investigacao-no-chcb/projetos/ projetos-ue/projeto-teri/ (acedido em 23/11/2021) (ver p. 15). [2] K. Bittner, I. Spence e I. Jacobson. Use Case Modeling . Addison-Wesley object technology series. Addison Wesley, 2003. isbn: 9780201709131. url: https://books.google.pt/books?id= zvxfXvEcQjUC (ver p. 21). [3] D. M. Cruz. “Literacia em ehealth dos portugueses: estudo exploratório”. Em: (fev. de 2013). url: http://hdl.handle.net/10400.6/2942 (ver p. 8). [4] Deco. Idosos em lares perderam vitalidade durante a quarentena . [Online; acedido em 01/12/2021]. url: https://www.deco.proteste.pt/familia-consumo/orcamento-familiar/ noticias/idososemlaresperderamvitalidadeduranteaquarentena (acedido em 01/12/2021) (ver p. 6). [5] B. Escalada. A história do GPS: O aparelho que revolucionou o montanhismo . [Online; acedido em 28/01/2022]. url: https://blogdescalada.com/historia-do-gps/ (acedido em 28/01/2022) (ver p. 16). [6] Eurostat. Number of persons by sex, age groups, household composition and working status (1 000) . [Online; acedido em 27/11/2021]. url: https://ec.europa.eu/eurostat/databrowser/ view/LFST_HHINDWS__custom_1070805/bookmark/table?lang=en&bookmarkId= 7362c1ab-c97e-425f-a51e-29e085585173 (acedido em 27/11/2021) (ver p. 5). [7] Eurostat. Population structure and ageing . [Online; acedido em 29/11/2021]. url: https://ec. europa.eu/eurostat/statistics-explained/index.php?title=Population_ structure_and_ageing (acedido em 29/11/2021) (ver p. 5). [8] hibernate.org. What is Object/Relational Mapping? 2022. url: https://hibernate.org/orm/ what-is-an-orm/ (acedido em 21/09/2022) (ver p. 42). 81