Waitz: uma aplicação web para filas de espera em hospitais e clínicas médicas

(1)

Arthur Vinícius Diniz Santos

Waitz: uma aplicação web para filas de

espera em hospitais e clínicas médicas

Natal – RN

(2)

Arthur Vinícius Diniz Santos

Waitz: uma aplicação web para filas de espera em

hospitais e clínicas médicas

Trabalho de Conclusão de Curso de Engenha-ria de Computação da Universidade Federal do Rio Grande do Norte, apresentado como requisito parcial para a obtenção do grau de Bacharel em Engenharia de Computação Orientador: Prof. Dr. Carlos Manuel Dias Viegas

Universidade Federal do Rio Grande do Norte – UFRN Departamento de Engenharia de Computação e Automação – DCA

Curso de Engenharia de Computação

Natal – RN

2 de dezembro de 2019

(3)

Arthur Vinícius Diniz Santos

Waitz: uma aplicação web para filas de espera em

hospitais e clínicas médicas

Trabalho de Conclusão de Curso de Engenha-ria de Computação da Universidade Federal do Rio Grande do Norte, apresentado como requisito parcial para a obtenção do grau de Bacharel em Engenharia de Computação Orientador: Prof. Dr. Carlos Manuel Dias Viegas

Trabalho aprovado. Natal – RN, 29 de Novembro de 2019:

Prof. Dr. Carlos Manuel Dias Viegas - Orientador UFRN

Prof. MSc. Sergio Natan Silva - Convidado UFRN

MSc. André Grilo - Convidado SINFO/UFRN

Natal – RN

2 de dezembro de 2019

(4)

AGRADECIMENTOS

Aos meus pais, Evilásio e Maria José, pelo amor, incentivo e suporte desde sempre. Aos meus amigos, por estarem sempre presentes e dedicados a me ajudar e por sempre incentivarem durantes todos esses anos. Agradeço aos meus amigos mais antigos Lucas Menescal e Lucas Félix pela companhia e por todo suporte durante nossa vida; a Daniel Vitor por sempre me ouvir nos momentos mais difíceis; a Elvis Ferreira, Daniel Menescal, Eduardo Macedo, Deangela Neves, Isis Gomes, Matheus Pessoa e Luciana Dewire por se tornarem meus amigos e colegas mais próximos durante essa graduação e com eles que foi possível chegar até aqui.

Ao meu orientador Carlos Viegas, por desde o início ter me incentivado com este projeto e dedicado o seu tempo para isso acontecer.

E a todos que direta ou indiretamente fizeram parte da minha formação, o meu obrigado.

(5)

RESUMO

O crescente número de habitantes em áreas urbanas traz consigo consequências, sendo uma delas as grandes filas de espera nas localidades onde se prestam serviços. Em alguns desses locais, grandes tempos de espera podem prejudicar a saúde humana, a exemplo do que acontece em hospitais e clínicas médicas. O gerenciamento das filas de espera em casas de saúde é, geralmente, feito de forma ineficiente, onde o maior problema é o direcionamento do paciente para a local correto. Este trabalho propõe uma solução para este último problema por meio de uma aplicação web colaborativa, na qual usuários poderão visualizar uma estimativa da quantidade de pessoas em determinada casa de saúde e também fazer checkins. A plataforma será alimentada pelos próprios utilizadores por meio de checkins, comentários e checkouts; com tais dados os pacientes poderão determinar o local mais adequado para suas necessidades e seu tempo disponível para espera. Este trabalho descreve a metodologia e os processos de construção dessa aplicação, bem como apresenta a plataforma colaborativa em sua forma final.

Palavras-chaves: Gerenciamento de filas, colaborativo, aplicações web, unidades de saúde.

(6)

ABSTRACT

The growing number of inhabitants in urban areas has consequences, one of which is the long queues in places where services are provided. In some of these places long waiting times can damage human health, which is what is happening in hospitals and medical clinics. Specifically observing the management of these queues in nursing homes one can see how inefficiently they are handled, with the biggest problem being the lack of ability to direct the patient to the ideal location. The work in this thesis proposes a solution to this problem through a collaborative web application in which users will be able to view an estimated number of people in certain health care queues and also check-in to their appointments. The platform will be fed by the users themselves through check-ins, comments, and checkouts. Using this data, patients will be able to determine the most appropriate place for their needs and their available time. This paper describes the methodology and construction processes of this application as well as presents the collaborative platform in its final form.

(7)

LISTA DE ILUSTRAÇÕES

Figura 1 – Diagrama do Event Loop . . . . 13

Figura 2 – Funcionamento básico do HTML . . . 14

Figura 3 – Funcionamento básico do CSS . . . 15

Figura 4 – Fluxo de dados do padrão flux . . . 16

Figura 5 – Comunicação entre Aplicações e uma API . . . 17

Figura 6 – Troca de mensagens do protocolo HTTP . . . 18

Figura 7 – Diferença entre a comunicação do protocolo HTTP e WebSocket . . . . 21

Figura 8 – Diagrama dos modelos do banco de dados . . . 23

Figura 9 – Diagrama da visão geral da API . . . 25

Figura 10 – Diagrama de uso da funcionalidade de cadastro . . . 26

Figura 11 – Diagrama de uso da funcionalidade de login . . . 27

Figura 12 – Diagrama de uso da funcionalidade de checkin . . . 29

Figura 13 – Diagrama de uso da funcionalidade de checkout . . . 30

Figura 14 – Diagrama de uso da funcionalidade de comentário . . . 31

Figura 15 – Diagrama das regras de negócio do checkin . . . 32

Figura 16 – Tela: início da aplicação . . . 33

Figura 17 – Tela: unidade médica selecionada . . . 34

Figura 18 – Tela: checkin realizado . . . 34

Figura 19 – Tela: possíveis erros do checkin . . . 35

Figura 20 – Tela: comentário realizado . . . 36

Figura 21 – Tela: possíveis erros do comentário . . . 36

(8)

LISTA DE ABREVIATURAS E SIGLAS

HTML HyperText Markup Language

CSS Cascading Style Sheets

DOM Document Object Model

I/O Input/Output

FIFO First In First Out

UI User Interface

API Application Programming Interface

HTTP Hypertext Transfer Protocol

JSON JavaScript Object Notation

JWT JSON Web Token

MVC Model View Controller

URL Uniform Resource Locator

SQL Structured Query Language

HMAC Hash-based Message Authentication Code

RSA Rivest–Shamir–Adleman

ECDSA Elliptic Curve Digital Signature Algorithm

TCP Transmission Control Protocol

(9)

SUMÁRIO

1 INTRODUÇÃO . . . 10 1.1 Objetivos e motivações . . . 11 1.2 Estrutura do trabalho . . . 11 2 FUNDAMENTAÇÃO TEÓRICA . . . 12 2.1 JavaScript . . . 12 2.1.1 NodeJS . . . 12 2.1.1.1 Event Loop . . . 12 2.2 Camada de apresentação . . . 14 2.2.1 HTML e CSS . . . 14 2.2.2 React . . . 15 2.2.2.1 Virtual DOM. . . 15 2.2.3 Redux . . . 15 2.3 Camada de acesso . . . 16 2.3.1 API . . . 16 2.3.2 Express . . . 17 2.3.2.1 Protocolo HTTP . . . 17 2.3.3 Cron . . . 17

2.3.4 JSON Web Token . . . 18

2.3.4.1 JSON . . . 18

2.3.5 Banco de dados não relacional . . . 19

2.3.5.1 MongoDB . . . 19

2.4 Socket . . . 19

2.4.1 WebSocket . . . 20

3 DESCRIÇÃO DA IMPLEMENTAÇÃO . . . 22

3.1 Aplicação do servidor . . . 22

3.1.1 Modelagem do banco de dados . . . 22

3.1.2 Rotas, eventos e suas regras de negócio . . . 24

3.1.2.1 Regras de negócio para requisições HTTP . . . 26

3.1.2.1.1 Funcionalidade de autenticação . . . 26

3.1.2.1.2 Aquisição das localidades próximas . . . 27

3.1.2.1.3 Obtenção de comentários . . . 27

3.1.2.2 Regras de negócio para eventos de WebSocket . . . 28

(10)

3.1.2.2.2 Realização de checkin e checkout . . . 28

3.1.2.2.3 Criação de um comentário . . . 28

3.2 Aplicação do cliente . . . 28

3.2.1 Funcionalidades do cliente . . . 29

3.2.1.1 Gerenciador de estados e contextos . . . 29

3.2.1.2 Autenticação na plataforma . . . 30

3.2.1.3 Ações de checkin, checkout e comentário . . . 31

3.2.1.4 Carregamento das localidades e comentários . . . 32

4 RESULTADOS . . . 33

5 CONCLUSÃO . . . 38

(11)

10

1 INTRODUÇÃO

Os serviços de urgência possuem um papel cada vez mais importante no Sistema Nacional de Saúde, onde nestes os tempos de espera são fatores determinantes para a satisfação dos pacientes. Um serviço de urgência em que os pacientes são atendidos rapidamente é considerado um bom atendimento (VELOSO, 2019). O tempo de espera dos pacientes está diretamente relacionado a quantidade de pessoas que estão na fila daquele serviço. Este é um grande gargalo das unidades médicas: com o crescente número de pacientes e a estagnação do número de emergências hospitalares, o tempo de espera para ser atendido só tende a crescer. O aumento de casos de acidentes e violência urbana, nos últimos tempos, tem provocado a superlotação das emergências hospitalares, transformando-as em uma dtransformando-as área de saúde mais problemátictransformando-as do atual sistema de saúde (OLIVEIRA et al., 2015). Fica claro que a área da saúde apresenta problemas, em diferentes âmbitos, e necessita de soluções, sendo uma delas a redução das filas de espera.

Os Sistemas de Informação de Saúde (SIS), de forma geral, contêm todos os dados desse contexto. Os SIS podem ser definidos como um agregador de componentes que coletam, processam, armazenam e distribuem a informação para alicerçar o processo de tomada de decisão. Como premissa básica, esse sistema de informação deve colaborar para a melhoria da eficiência, da qualidade e da eficácia do atendimento em saúde. Dessa forma, um SIS serve para gerenciar a informação possibilitando a comunicação entre profissionais da saúde e também pacientes (MARIN, 2010).

Soluções inovadores estão surgindo cada vez mais e a maioria delas por meios de comunicação de fácil acesso, como a Internet. Esta, mais especificamente a web, vem mudando nossas vidas de várias formas. A Internet amadureceu e se tornou uma plataforma muito atraente e dominante para se criar negócios, sites de informações, aplicações e sistemas (ROSSI et al., 2008). Com a constante evolução e adoção deste meio pela sociedade, faz-se necessário desenvolver soluções em diferentes áreas que facilitem o cotidiano do corpo social. A interação com a sociedade é almejada para se obter informações valiosas a respeito de diferentes situações; dentre elas, o atual contexto de uma unidade de saúde.

Esse compartilhamento de informações é premissa da aplicação Tem Fila? (TEM-FILA, 2019), que propõe uma plataforma colaborativa em que usuários podem partilhar dados sobre estabelecimentos e seus tempos de espera. A aplicação para dispositivos móveis

Skiplino (SKIPLINO, 2019) também possui a premissa de redução de tempos de espera

em filas, onde nessa plataforma os usuários podem pegar sua ficha de atendimento online e apenas comparecer ao local quando estiver próximo do seu número de chamada. Ambas as soluções ajudam com o cotidiano da população de uma cidade com a tentativa de reduzir

(12)

Capítulo 1. Introdução 11

tempos de espera em estabelecimentos comerciais.

Diferentemente das aplicações anteriores, este trabalho apresenta o desenvolvimento de uma aplicação web que propõe uma solução para o problema das filas de espera em urgências médicas. De forma mais específica, esta aplicação tentará melhor redirecionar a população para os hospitais e clínicas médicas para localidades com menores números de pessoas. A solução contará com ações de checkins, comentários e checkouts, pelos quais os pacientes poderão visualizar, alimentar a plataforma e assim decidir qual casa de saúde atende melhor às suas necessidades.

1.1 Objetivos e motivações

Este trabalho objetiva desenvolver a plataforma Waitz, uma proposta de solução para as filas médicas, mostrando o processo de implantação e também os resultados encontrados. A aplicação proposta será colaborativa e em tempo real, na qual usuários poderão fazer checkins e checkouts, consultar a quantidade de pessoas num determinado local e também avaliar, por meio de comentários, atendimentos e locais. Esta plataforma constitui-se de uma aplicação web intuitiva e também um web server para controlar a lógica de eventos e banco de dados. Para a camada de apresentação foi utilizado o framework

React juntamente à plataforma do Google Maps com a finalidade de criar uma interface

de usuário, na qual estarão dispostas unidades de saúde em um mapa a fim do paciente visualizar tais locais próximos a ele. No lado da camada de acesso, foi utilizado a biblioteca

Express e SocketIO para criação de uma API, os quais tratarão todos os dados e eventos

provenientes dos navegadores e também fornecerão informações relevantes para os usuários. O problema das filas em unidades hospitalares, que está diretamente associado com grandes tempos de espera, foi a grande motivação para o desenvolvimento deste trabalho, visando aproximar esta tecnologia ao cotidiano da população, na qual poderá consultar estimativas de filas de forma online e assim decidir qual local os atende melhor.

1.2 Estrutura do trabalho

Além desta introdução, este trabalho está dividido em 4 capítulos. O Capítulo 2 aborda os principais conceitos sobre desenvolvimento web e tecnologias utilizadas para o entendimento deste trabalho. Ademais, a descrição de como foi implementada a solução proposta está relatada no Capítulo 3 separando nas duas camadas da aplicação, camada do cliente e do servidor, também expondo como foi implementada a plataforma colaborativa. Em seguida, o Capítulo 4 aborda e discute os resultados obtidos. Por fim, o Capítulo 5 traz as considerações finais, bem como apresenta trabalhos futuros.

(13)

12

2 FUNDAMENTAÇÃO TEÓRICA

Neste capítulo são apresentados os conceitos e tecnologias utilizadas no trabalho desenvolvido. Serão apresentadas a linguagem de programação utilizada, bibliotecas, pacotes, bem como concepções sobre Programação Reativa e Sockets.

2.1 JavaScript

A linguagem de programação JavaScript foi criada, em 1995 pela empresa responsá-vel pelo navegador de internet Netscape, com o objetivo de rodar programas em browsers. Desde então, esta ferramenta foi adotada pelos principais navegadores de internet, sendo um dos núcleos da World Wide Web. De acordo com (HAVERBEKE, 2018), a criação de aplicações web modernas só se tornou possível com o advento da linguagem JavaScript.

A escolha desta linguagem para desenvolver este trabalho foi devido aos principais

browsers exporem funcionalidades, desde manipulação do DOM à Geolocalização, através

de APIs nas quais o JavaSript tem acesso. Somando-se a isso, a quantidade de bibliotecas e pacotes open source disponíveis facilita a criação de aplicabilidades e também torna a linguagem altamente versátil. Contudo, navegadores não são a única plataforma que esta linguagem é utilizada, também é possível utiliza-la no lado dos servidores com o NodeJS.

2.1.1 NodeJS

NodeJS, um executador de JavaScript criado a partir do motor V8 do projeto de código aberto Chromium, possibilita a execução de códigos JavaScript fora do ambiente dos navegadores. Com isso, pode-se construir tudo desde ferramentais de linha de comando até servidores HTTP que alimentam sites dinâmicos e aplicações (HAVERBEKE, 2018). Esta linguagem foi criada para ser assíncrona e também baseada em eventos, isso se tornou possível através do event loop, o que permitiu a construções de aplicações altamente escaláveis (NODE, 2019a).

2.1.1.1 Event Loop

O Event Loop é um dos conceitos mais importantes do NodeJS, visto que possibilitou esta linguagem ser assíncrona e com operações de I/O não bloqueantes e também o que construiu o sucesso da linguagem. Como o fato do JavaScript ser executado em apenas uma thread, NodeJS utiliza-se da entrega de operações diretamente ao sistema operacional sempre que possível.

(14)

Capítulo 2. Fundamentação Teórica 13

Assim que NodeJS começa a executar, ele inicializa o processamento do event loop, no qual o diagrama da Figura 1 mostra de forma simplificada a ordem das suas operações (NODE, 2019b).

Figura 1 – Diagrama do Event Loop

Timers Pending callbacks Idle, Prepare Poll Check Close callbacks Incoming: connections, data, etc. Fonte – (NODE, 2019b)

Cada fase do diagrama contêm uma fila do tipo FIFO de callbacks para serem executados. Quando o event loop entra em determinada fase, ele irá performar operações específicas e executar os callbacks daquela fase até chegar ao seu limite ou quando todos os

callbacks forem executados, semelhante como ocorre com processos no sistema operacional,

mudando depois para a próxima etapa (NODE, 2019b). As responsabilidades de cada fase de forma bem simplificada:

Timers: um temporizador especifica o limite após cada callback fornecido pode ser executado.

Pending callbacks: esse estágio executa quase todos os callbacks, com exceção de da-queles agendados.

Idle, Prepare: esse passo é usada apenas para o processo ideal e se prepara para a próxima fase.

(15)

Check: esse ponto permite que uma pessoa execute callbacks imediatamente após a conclusão da fase de poll

Close callbacks: essa fase observa se algum callback foi fechado de forma repentina e se sim emite um evento de ’fechar’.

2.2 Camada de apresentação

A camada de apresentação é aquela em que usuário estará interagindo diretamente, sendo mais conhecida como Frontend ou Client-side. Interfaces de usuário são construídas nessa camada utilizando linguagens como HTML, CSS e JavaScript. Este último importante para interações mais dinâmicas e acesso a dados contidos na camada de acesso. Os web

sites e as web applications são hospedadas na camada de apresentação, abaixo algumas

das tecnologias utilizadas no desenvolvimento do frontend deste trabalho.

2.2.1 HTML e CSS

HyperText Markup Language é o código usado para estruturar uma página web

e seu conteúdo. Confundido por muitos, HTML não é uma linguagem de programação mas sim uma linguagem de marcação, consistindo de uma série de elementos usados para incluir ou agrupar diferentes partes do conteúdo (Figura 2) para que ele apareça de uma certa maneira ou aja de certo modo (MOZILLA, 2019a). Criar um documento HTML com conteúdo marcado corretamente é a primeira etapa do desenvolvimento de uma página web (JAMES, 2019a).

Figura 2 – Funcionamento básico do HTML

Fonte – (JAMES, 2019a)

Cascading Style Sheets é uma linguagem declarativa que controla a aparência das

páginas da web nos navegadores. O navegador aplica as declarações de CSS aos elementos selecionados para exibi-las corretamente, como mostrado na Figura 3. Uma declaração de estilo contém as propriedades e seus valores, que determinam como um elemento irá de comportar no quesito visual (MOZILLA, 2019a).

(16)

Figura 3 – Funcionamento básico do CSS

Fonte – (JAMES, 2019b)

2.2.2 React

React é uma biblioteca JavaScript usada no desenvolvimento web para ajudar à construir interfaces de usuários em sites e aplicações. UIs são uma coleção de elementos interativos como menus, barras de pesquisa, botões e qualquer outra coisa que o usuário interaja com (MORRIS, 2019). Antes do React, desenvolvedores construíam partes intera-tivas nas suas aplicações com JavaScript puro, porém com o advento dessa biblioteca a implantação de tais funcionalidades se tornou praticamente indolor. React, como o nome diz, se trata de uma programação reativa em que esta ferramente atualizará e renderizará com eficiência os componentes certos quando os dados forem alterados (REACT, 2019), essa grande eficiência se da principalmente pela característica chamada Virtual DOM. 2.2.2.1 Virtual DOM

Em sites sem o uso de React, quem fica responsável por atualizar o DOM, o processo de atualizar as mudanças para a tela do usuário sem precisar atualizar a janela do navegador, é o HTML. Isso funciona para sites simples e estáticos, entretanto para sites dinâmicos que envolvem intensa interação do usuário, isso pode se tornar um problema visto que todo o DOM precisa ser recarregado para toda vez que o usuário clica em um recurso que solicita uma atualização da interface (MORRIS, 2019). O React traz consigo uma solução para este problema de eficiência, o Virtual DOM (VDOM). Este é uma cópia do DOM original e o React utiliza o VDOM para ver quais partes do DOM real precisam ser alterados quando algum evento acontece. De acordo com (MORRIS, 2019), esse tipo de atualização seletiva exige menos poder de computação e menos tempo de carregamento.

2.2.3 Redux

Redux é uma ferramenta que permite criar um contêiner de estado previsível para aplicações JavaScript. Ele ajuda a escrever aplicativos que se comportam de maneira consistente (REDUX, 2019). A centralização do estado e da lógica da aplicação permitem recursos avançados como desfazer e refazer, persistência de estado e mais outros recursos.

(17)

Essa biblioteca utiliza o padrão Flux para gerenciar o fluxo de dados, o conceito mais importante é que os dados fluem em uma direção (FACEBOOK, 2019), como mostrado na Figura 4.

Figura 4 – Fluxo de dados do padrão flux

Action Dispatcher Store View

Action

Fonte – (FACEBOOK, 2019)

Basicamente, as Views enviam ações para o Dispatcher, o Dispatcher envia ações para a Store e este envia dados para as Views; tornando assim um fluxo de dados unidirecional e concentrando todos os dados da aplicação na Store. A utilização do Redux é uma boa forma de armazenar dados, provenientes também da camada de acesso, no

frontend.

2.3 Camada de acesso

A camada de acesso, também conhecida como Backend ou Server-side, é o onde fica toda a lógica que envolve dados de uma aplicação. Isso se refere a tudo que o usuário não pode ver no navegador, com banco de dados e servidores. Abaixo algumas das tecnologias e conceitos utilizados no desenvolvimento do backend deste trabalho.

2.3.1 API

Segundo (PIRES, 2019), o acrônimo API que provém do inglês Application

Program-ming Interface, trata-se de um conjunto de rotinas e padrões estabelecidos e documentados

por uma aplicação ’A’, para que outras aplicações consigam utilizar as funcionalidades desta aplicação ’A’, sem precisar conhecer detalhes da implementação de software. Desta forma, entendemos que as APIs permitem uma interoperabilidade entre aplicações; em outras palavras, a comunicação entre aplicações e entre os usuários (como mostrado na Figura 5).

(18)

Figura 5 – Comunicação entre Aplicações e uma API

Fonte – (PIRES, 2019)

2.3.2 Express

O Express, de acordo com a sua documentação oficial (EXPRESS, 2019), é um

framework do NodeJS mínimo e flexível que fornece um conjunto robusto de recursos

para aplicações web e móvel, apresenta uma abundância de métodos utilitários HTTP e

middlewares a disposição facilitando a criação de APIs. Este framework provê uma camada

fina de rescursos fundamentais para aplicações web, sem obscurecer os recursos do NodeJS. 2.3.2.1 Protocolo HTTP

HTTP é um protocolo que permite a busca de recursos, como documentos HTML. É a base de qualquer troca de dados na Web e é um protocolo cliente-servidor, no qual significa que as solicitações são iniciadas pelo destinatário, como o navegador de internet ou um dispositivo móvel. Clientes e servidores se comunicam através da troca de mensagens individuais (MOZILLA, 2019b). Esse protocolo é a fundação base da World

Wide Web, utiliza-se do paradigma (mostrado na Figura 6) de request, geralmente browsers

faz solicitações aos servidores, e response, na qual servidores enviam uma respostas para as solicitações a si feitas (SHKLAR; ROSEN, 2009). Esse paradigma request/response é realizado através de alguns tipos de métodos (GET, POST, DELETE dentre outros) e códigos de estado (200, 400, 404 dentre outros).

2.3.3 Cron

Cron é um dos utilitários mais úteis em qualquer sistema operacional semelhante ao Unix. Esta ferramenta permite agendar execuções de comandos em um horário específico. Esses comandos ou tarefas agendadas são conhecidos como Cron Jobs. Normalmente, o Cron é utilizado para agendar backups, monitorar espaço de disco, enviar algum email periódico e muito mais (SK, 2019).

(19)

Figura 6 – Troca de mensagens do protocolo HTTP

HTTP Clients

HTTP Server HTTP Request Message

HTTP Response Message

Fonte – Elaborado pelo autor

2.3.4 JSON Web Token

JSON Web Token (JWT), de acordo com a documentação oficial (AUTH0, 2019),

é um padrão aberto (RFC 7519 1) que define uma maneira compacta e independente de transmitir com segurança informações entre partes como um objeto JSON. Essas informações podem ser verificadas e confiáveis porque são assinadas digitalmente. Os JWTs podem ser assinados usando um segredo (com o algoritmo HMAC) ou um par de chaves pública/privada usando o algoritmo RSA ou ECDSA. O JSON Web Token é comumente usado para autorização de usuários e para troca de informações de forma segura. De forma básica, JWT consiste de três partes separados por pontos (.), nas quais são: Header,

Payload e Signature.

Header: o cabeçaho geralmente consiste em duas partes: o tipo do token, que é JWT, e o algoritmo de assinatura que está sendo usado.

Payload: esta segunda parte do token é a carga útil, na qual contém as declarações. Declarações sobre uma entidade e dados adicionais. Nessa parte está definida as informações a serem trocadas entre as partes e também informações de configuração, como o tempo de expiração do token.

Signature: para criar a parte da assinatura, é necessário pegar o cabeçalho codificado, a carga útil codificada, um segredo, o algoritimo a ser usado no cabeçalho e assinar tudo isso.

2.3.4.1 JSON

JavaScript Object Notation é uma formatação leve de troca de dados no qual foi

criado para ser fácil para humanos ler e escrever e também fácil para máquinas analisar e

(20)

gerar. Apesar do seu nome conter JavaScript, JSON não pertence a nenhuma linguagem de programação. Essa notação é usada por diversas linguagens e foi construída em cima de duas estrututas: uma coleção de pares chave/valor e uma lista ordenada de valores, como mostrado na Lista 2.1 (CROCKFORD, 2019).

{ " id ": "1" , " i m a g e ": " u s e r . jpg " , " u s e r n a m e ": " r o w l i n g " , " e m a i l ": " r o w l i n g @ g m a i l . com " }

Lista 2.1 – Exemplo de formato do JSON

2.3.5 Banco de dados não relacional

Um banco de dados não relacional (NoSQL), de acordo com (MICROSOFT, 2019), é um tipo de banco que não utiliza o esquema de tabela de linhas e colunas encontrado na maioria dos sistemas de banco de dados tradicionais. Em vez disso, esses bancos não relacionais usam um modelo de armazenamento otimizado para os requisitos específicos do tipo de dados que está sendo armazenado. Esses dados podem ser pares chave/valor, como documentos JSON ou como um grafo que consiste em bordas e vértices.

2.3.5.1 MongoDB

MongoDB é um banco de dados de documentos no qual a armazenagem de dados é flexível semelhantes ao JSON, o que significa que os campos podem variar de doumento para documento e a estrutura de dados pode ser alterada ao longo do tempo. Em adição a isso, a essência do MongoDB é ser um banco de dados distribuído, portanto, alta disponibilidade e escala horizontal estão incorporadas a esta tecnologia (MONGODB, 2019).

2.4 Socket

Socket é uma interface que permite a troca de dados entre aplicações, no mesmo computador ou em computadores diferentes conectados por uma rede (KERRISK, 2010). Esta interface se estabelece no fim da linha de uma comunicação entre hosts. Com o uso de sockets é possível que aplicações respondam a requisições de outros hosts ou troquem mensagens entre si.

(21)

2.4.1 WebSocket

Com essa breve introdução a Sockets podemos falar sobre a tecnologia WebSocket, na qual provê um canal de comunicação, para aplicações web e serviços, bidirecional em tempo real através de uma conexão TCP (Transmission Control Protocol). O protocolo WebSocket foi desenvolvido para ser implementado em navegadores de internet e servidores, ele independe do protocolo HTTP (ERKKILä, 2012).

A principal diferença entre WebSocket e o protocolo HTTP é que o WebSocket não utiliza o tradicional paradigma de request/response. Quando um cliente e servidor abre uma conexão de WebSocket, os dois endpoints podem enviar dados de forma assíncrona para o outro e a conexão permanece aberta e ativa até que um dos dois hosts feche a conexão (ERKKILä, 2012). Entretanto, no HTTP a cada troca de mensagem entre cliente e servidor é necessário fazer uma requisição e uma resposta, o que pode assim sobrecarregar o servidor caso múltiplos clientes o acessem e façam muitas requisições. A Figura 7 mostra como a comunicação WebSocket difere das chamadas HTTP.

Neste trabalho foram utilizados WebSockets por meio de uma biblioteca chamada

Socket.IO, a qual provê uma API tanto para o frontend quanto para o backend, que facilita o

controle e a implementação de sockets na web. Socket.IO não é de fato uma implementação do WebSocket, visto que ele adiciona algumas informações a mais no pacote do dado, entretanto ele utiliza o protocolo WebSocket para transporte. Com essas informações a mais ao pacote, é possível a criação de vários canais por meio da mesma conexão. Em síntese, essa biblioteca habilita a comunicação em tempo real e esta é baseada em eventos entre browser e servidor (ARRACHEQUESNE, 2019).

(22)

Figura 7 – Diferença entre a comunicação do protocolo HTTP e WebSocket

HTTP Client HTTP Server Client (WebSocket) Server (WebSocket) Request Response Request Response First message exchange Second message exchange Handshake connection opened Time Time Bidirectional Messages open and persistent connection One side closes connection connection closed Multiple message exchange

(23)

22

3 DESCRIÇÃO DA IMPLEMENTAÇÃO

Neste capítulo serão apresentados os detalhes do desenvolvimento da aplicação deste trabalho. A primeira etapa foi a estruturação do servidor e do banco de dados, bem como o estudo da API do Google Maps. Com essa estruturação, a próxima fase foi o desenvolvimento do frontend, utilizando principalmente a biblioteca React bem como o

Redux para gerenciamento de estados. Com essas duas etapas desenvolvidas, o último

passo foi fazer a conexão de ambas atráves de requisições HTTP e também através de WebSockets.

3.1 Aplicação do servidor

Nesta seção serão mostrados os processos durante a fase de desenvolvimento do

backend, ademais das funcionalidades implementadas. Com a utilização do NodeJS, foram

necessárias as bibliotecas ExpressJS, SocketIO e Mongoose para a criação de uma API funcional promovendo a comunicação de dados com o frontend.

3.1.1 Modelagem do banco de dados

O MongoDB foi o banco de dados escolhido para armazenagem de dados dessa aplicação, visto que ele trabalha com documentos que facilitam a compatibilidade com os objetos do JavaScript. Através da biblioteca Mongoose, um modelador de objetos do MongoDB para NodeJS, foi possível a criação das estruturas de: usuário, lugares, checkin e comentários (conforme mostrado no diagrama da Figura 8).

O estrutura do documento relacionado às localidades foi baseado a partir das informações retornadas pelas Places API do Google Maps. Informações estas que indicam: a localização da unidade médica; seu identificador, este estará presente em futuros documentos de checkins e comentários; e, também, foi adicionado as filas de especialidades, nas quais possuem três tipos: geral, ortopedia e outro. O documento do usuário possui: um identificador, que tamém estará presentes em checkins e comentários; nome de usuário e email; e, uma senha encriptada. Esta última, decodifica-se, antes de salvar um o usuário no banco de dados, com a utilização da biblioteca Bcrypt (mostrado na Lista 3.1). O documento dos usuários também possui uma função para comparação de senhas, uma enviada no ato de login (ser estar encriptada) e a outra armazenada no banco de dados (encriptada); esta comparação é realizada também pela biblioteca Bcrypt.

Por fim, os documentos de checkin e comentários. O primeiro contém os dados: usuário que realizou-o; local do checkin; tipo de fila; um atributo active para determinar

(24)

Capítulo 3. Descrição da implementação 23

Figura 8 – Diagrama dos modelos do banco de dados

User _id: ObjectId username: String email: String password: String created_at: Date updated_at: Date isCorrectPassword: Bool Place _id: ObjectId gmaps_id: String reference: String name: String geometry: {

location: { lat: Number, lng: Number }, viewport: {

northeast: { lat: Number, lng: Number }, southwest: { lat: Number, lng: Number } } } rating: Number, vicinity: String, queue: { geral: Number, ortopedia: Number, outro: Number } created_at: Date updated_at: Date CheckIn _id: ObjectId user: String place_id: String type: String active: Bool created_at: Date updated_at: Date Comment _id: ObjectId user: String place_id: String text: String active: Bool date: Date

se o documento está ativo; sua hora de criação; e, por último, um atributo chamado

updated_at que determina a hora que foi realizado o checkout. A estrutura Comment

contém, também, dados do usuário e localidade; texto do comentário; se está ativo; e data de criação.

(25)

Capítulo 3. Descrição da implementação 24 c o n s t s a l t R o u n d s = 10; U s e r S c h e m a . pre ( ’ save ’ , f u n c t i o n ( n e x t ) { c o n s t d o c u m e n t = t h i s ; // C h e c k if d o c u m e n t is new or a new p a s s w o r d // has b e e n set if ( d o c u m e n t . i s N e w || d o c u m e n t . i s M o d i f i e d ( ’ p a s s w o r d ’) ) { b c r y p t . h a s h ( d o c u m e n t . p a s s w o r d , s a l t R o u n d s , ( err , h a s h ) = > { if ( err ) { n e x t ( err ); } e l s e { d o c u m e n t . p a s s w o r d = h a s h ; n e x t (); } }); } e l s e { n e x t (); } });

Lista 3.1 – Encriptação de senha usando a biblioteca Bcrypt

3.1.2 Rotas, eventos e suas regras de negócio

Nessa subseção serão descritas as funcionalidades e regras de negócio no lado do servidor, como as rotas de acesso e eventos do WebSocket, consultas na API do Google Maps e também interação com o banco de dados. Para os endereços de acesso via protocolo HTTP, os endpoints foram separados em três arquivos Auth, Place e Comment. Já para os controladores de eventos WebSocket, existem apenas dois arquivos CheckIn e Comment. Uma visão simplificada de toda a API é mostrada na Figura 9.

(26)

Figura 9 – Diagrama da visão geral da API

Retorna localidades

próximas Rota HTTP

/api/place/nearby /api/commentRota HTTP

Retorna comentários de uma localidade Autenticação na aplicação Rota HTTP /api/auth/signin Cadastro na aplicação Rota HTTP /api/auth/signup Rotas com acesso livre à qualquer cliente Rotas com acesso restrito (necessário estar autenticado) Realiza um novo CheckIn Após 4 horas emite: Recebe Evento Socket newCheckIn Realiza um Checkout manual Emite Evento Socket checkout Recebe Evento Socket newCheckOut Salva um comentário Após 4 horas emite: Recebe Evento Socket newComment Eventos indiretos Realiza o Checkout automático Emite Evento Socket checkout Evento emitido em cada invalidação nas rotas de acesso restrito Emite Evento Socket invalidToken Remove comentário Emite Evento Socket removeComment

(27)

3.1.2.1 Regras de negócio para requisições HTTP 3.1.2.1.1 Funcionalidade de autenticação c o n s t e x p i r e s I n = ’24 h ’; c o n s t p a y l o a d = { id : u s e r . _id , u s e r n a m e : u s e r . u s e r n a m e , e m a i l : u s e r . e m a i l }; c o n s t t o k e n = jwt . s i g n ( payload , p r o c e s s . env . J W T _ S E C R E T , { e x p i r e s I n , });

Lista 3.2 – Criação do JSON Web Token

A autenticação na plataforma, um usuário está autenticado quando este possui um Token válido, se da a partir de duas rotas: uma para cadastro de usuário e outra para validação de entrada na aplicação. Baseado no diagrama de uso mostrado na Figura 10, a funcionalidade de cadastro quando requisitada irá retornar um Token em caso de sucesso. A criação deste Token é mostrada na Lista 3.2, no qual este tem uma data de expiração de vinte e quatro horas e possui como dados internos as informações do usuário cadastrado.

Figura 10 – Diagrama de uso da funcionalidade de cadastro

Salva novo usuário no banco de dados Cria o Token (JWT) Retorna mensagem de sucesso com o Token criado Retorna mensagem de erro Username ou Email já existente? Dados provenientes do frontend SIM NÃO

(28)

ao cadastro. Essa funcionalidade é mostrada no diagrama de uso na Figura 11, ocorrendo uma validação da senha enviada com a senha encriptada, armazenada no banco de dados, através da função isCorrectPassword, a criação do Token segue a mesma lógica da funcionalidade de cadastro.

Figura 11 – Diagrama de uso da funcionalidade de login

A senha está correta? Cria o Token (JWT) Retorna mensagem de sucesso com o Token criado Retorna mensagem de erro Existe usuário? Dados provenientes do frontend NÃO SIM Retorna mensagem de erro SIM NÃO

3.1.2.1.2 Aquisição das localidades próximas

Com as informações provenientes da API do Google Maps, mais especificamente a Places API com um filtro de hospitais, foi criado documentos das localidades próximas ao usuário e retornando-as para o cliente através de uma única rota /api/place/nearby, esta recebe como parâmetro a localização do cliente.

3.1.2.1.3 Obtenção de comentários

O retorno dos comentários de uma localização ocorre quando requerido através da rota /api/comment, enviando o identificador da unidade médica é possível a busca de todas as avaliações ativas, aquelas que são visíveis na aplicação.

(29)

3.1.2.2 Regras de negócio para eventos de WebSocket

Para enviar dados para todos os clientes conectados em tempo real, foi necessário o uso de WebSockets através da biblioteca SocketIO na aplicação. Esta subseção detalha os eventos tratados pelo servidor e suas regras de negócio.

3.1.2.2.1 Validação do token de acesso

Em todas as próximas funcionalidades é feito a validação do token enviado, esta verificação ocorre também através da biblioteca JSON Web Token e as seguintes condições são avaliadas: se o token está ainda dentro do seu tempo de expiração e se o usuário presente no token é o mesmo que enviou a solicitação.

3.1.2.2.2 Realização de checkin e checkout

Com a validação do token de acesso, a realização do checkin ainda necessita de mais uma validação: a busca por checkins já ativos do usuário solicitante. Caso este já possua, então o checkin não é realizado. O diagrama de uso da Figura 12 mostra todas as regras de negócio para essa funcionalidade; após salvar um novo checkin no banco de dados, todos os clientes conectados irão receber o evento, emitido pelo servidor, avisando que houve um novo checkin e por fim ocorre a criação de um temporizador para realizar o checkout automatizado, no qual foi determinado que terá duração de quatro horas.

A realização do checkout segue sua regra de negócio descrita no diagrama da Figura 13. Com o token validado, realiza-se uma busca por algum checkin ativo, do usuário solicitante, e caso encontre desativa-o; após, a fila daquela unidade de saúde será atualizada e também todos os clientes conectados irão se informar que ocorreu um novo checkout na aplicação.

3.1.2.2.3 Criação de um comentário

A partir dos dados provenientes do cliente e com a validação do token, a criação do comentário, para a localidade enviada, ocorre; todos os usuários conectados irão receber esta avaliação em sua interface e após um temporizador, para deleta-lo, irá ser criado com duração de quatro horas. O diagrama das regra de negócio para essa funcionalidade é mostrado na Figura 14.

3.2 Aplicação do cliente

Nesta seção serão mostrados os processos durante a fase de desenvolvimento do

(30)

Figura 12 – Diagrama de uso da funcionalidade de checkin

Usuário já tem algum CheckIn ativo? Retorna o evento invalidToken O token enviado é válido? Dados provenientes do cliente NÃO SIM Salva CheckIn no banco Atualiza a fila da localidade Emite o evento newCheckIn Cria o CronJob de CheckOut automático Retorna o evento userAlreadyHasCheckIn NÃO SIM

React, Redux, MaterialUI, SocketIO e também outras ferramentas.

3.2.1 Funcionalidades do cliente

Nesta seção serão mostrados detalhes da implementação da aplicação mostrada ao usuário, como eventos e requisições HTTP afetarão a UI e também algumas regras de negócio.

3.2.1.1 Gerenciador de estados e contextos

Através da biblioteca Redux foi criado o gerenciador de estados de toda a aplicação, estes estados foram divididos em quatro grupos: autenticação, usuário, mapa e localidades. O primeiro grupo, autenticação, constituem de estados em que demonstrarão: se o usuário

(31)

Figura 13 – Diagrama de uso da funcionalidade de checkout

Procura algum CheckIn ativo do usuário Atualiza o CheckIn para active=False Atualiza a localidade decrementando a fila específica Emite evento checkout Retorna o evento invalidToken O token enviado é válido? Dados provenientes do cliente NÃO SIM

está logado; erros em formulários de cadastro e login; armazenamento do token de acesso; e, por fim, ações de: login, cadastro e logout; nas quais terão contato direto com o servidor. O grupo de usuário engloba todos os estados que informam: se este está logado; possui algum checkin ativo; e, por último, a localização atual do mesmo. Os estados relacionados ao mapa englobam, apenas, a localização atual do centro do mapa e o zoom. Por fim, o grupo de estados relacionados às localidades, nas quais englobam as unidades médicas próximas ao paciente e a casa de saúde selecionada; porém, este grupo também possui funções nas quais são possíveis a realização de checkins, checkouts e comentários.

A aplicação contém dois contextos: mapa e socket. O contexto do mapa expõe o acesso à API do Google Maps e também funcionalidades do mapa já renderizado; e, o contexto de socket fica responsável por toda a lógica de eventos de socket no lado do cliente.

3.2.1.2 Autenticação na plataforma

A autenticação foi adicionada como forma de limitar o número de checkins por usuário, apenas clientes autenticados podem realizar checkins e também comentar em

(32)

Figura 14 – Diagrama de uso da funcionalidade de comentário

Salva comentário no banco Emite evento newComment Cria o CronJob de desativar comentário Retorna o evento invalidToken O token enviado é válido? Dados provenientes do cliente NÃO SIM

determinado local. Constituindo de duas páginas, uma para cadastro e outra pra login, a autenticação quando bem sucedida retorna o token de acesso, no qual será enviado, em todo evento emitido pelo cliente, para o servidor. Caso o servidor invalide este token, a aplicação realiza o logout automático do usuário.

Para cadastro é requisitado o nome de usuário, email, senha e confirmação da senha; a comparação das duas senhas é feita diretamente na aplicação do frontend. Para login, apenas nome de usuário ou email e senha são requisitados. Ambas as páginas podem apresentar mensagens de erro caso alguma informação esteja incorreta.

3.2.1.3 Ações de checkin, checkout e comentário

Quando selecionada uma unidade médica permite-se a realização de checkin e comentários, ambos possuem pré-requisitos para efetuação com sucesso. As regras de negócio do checkin é mostrada na Figura 15; estando autenticado, o usuário necessitará estar próximo ao local desejado e também não poderá ter nenhum checkin ativo anteriormente. Com o checkin ativo, ficará disponível na UI a opção de realizar checkout manualmente, porém não é obrigatório a sua realização visto que será efetuado um checkout automático após quatro horas. A criação de comentários segue praticamente a mesma lógica do checkin, tendo a diferença que não ocorre a validação de avaliação ativa já existente; vale lembrar que comentários são removidos automaticamente após quatro horas do período de sua

(33)

criação.

Figura 15 – Diagrama das regras de negócio do checkin

Usuário está autenticado? Está dentro do raio do local? Mensagem de aviso Possui algum checkin ativo? Mensagem de erro Mudança da UI para checkin ativo Realiza checkin (evento newCheckIn) Mensagem de aviso NÃO SIM SIM NÃO NÃO SIM

3.2.1.4 Carregamento das localidades e comentários

Essas informações são carregadas de forma indireta, não necessitando nenhuma ação direta do usuário. Para as localidades, a aplicação, assim que renderizada, solicitará do servidor as unidades médicas por meio da rota /api/place/nearby; passando como parâmetro a localização do usuário. Com as localidades carregadas, o carregamento dos comentários de cada casa de saúde será realizado quando o cliente selecionar algum local; estas informações serão provenientes através da rota /api/comment e passará o identificador daquele local para a busca no banco de dados.

(34)

33

4 RESULTADOS

Nesta seção serão apresentados os resultados da aplicação final, as telas do sistema em sua versão para computador e também para dispositivos móveis.

A tela inicial da plataforma é visível para todos os usuários, estes estando autenti-cados ou não. Os clientes poderão visualizar as unidades médicas, que se encontram como marcadores no mapa; possuindo um contador da soma geral das filas (Figura 16). Quando selecionado uma localidade (Figura 17), um card é mostrado com as informações daquela unidade bem como as filas de cada especialidade, um botão com sugestões de casas de saúde é mostrado do lado de cada especialidade e mais abaixo os comentários daquele local. Esta tela também possui uma opção para autenticação (canto superior direito); também possui um botão para re-centralizar o mapa para localização do usuário (canto inferior direito), acima deste botão, quando há um checkin ativo, mostra-se uma opção de checkout manual.

Figura 16 – Tela: início da aplicação

(a) Desktop

6 10 3 1

SIGN IN (b) Mobile 6 10 3 1

SIGN IN

Após o ato de checkin ocorre a aparição da opção de checkout manual (canto inferior direito) e também o bloqueio de novos checkins (mostrado na Figura 18). Entretanto, pode-se ocorrer erros durante a tentativa de checkin, nos quais estão apresentados na Figura 19, como: usuário não autenticado; não está dentro do raio do local; e, por último, caso o utilizador já apresente um checkin ativo na aplicação. Este último, quando ocorre, alterará a interface de usuário para de checkin ativo.

(35)

Capítulo 4. Resultados 34

Figura 17 – Tela: unidade médica selecionada

(a) Desktop

6 3

SIGN IN

Hospital Gastroprocto Rua Apodi, 596 - Tirol, Natal

Escolha sua especialidade e faça seu check-in! GERAL ORTOPEDIA OUTRO

2 1

(b) Mobile

6 3

SIGN IN

Escolha sua especialidade e faça seu check-in! GERAL

ORTOPEDIA OUTRO

2 1

Figura 18 – Tela: checkin realizado

(a) Desktop

6 4

Escolha sua especialidade e faça seu check-in!

GERAL ORTOPEDIA OUTRO

3 1 (b) Mobile 6 10 4 6 10 4

3 1

A ação de comentar é apresentada na Figura 20, assim como seus possíveis erros na Figura 21. A visualização dos comentários ocorre com o clique no botão de chat, no qual pode apresentar um contador de avaliações daquele local, e estes são ordenados do mais recente para o mais antigo.

(36)

Figura 19 – Tela: possíveis erros do checkin

(a) Autenticação

6

3

SIGN IN

2 1

Please sign in to check in! ✖

(b) Não está próximo

10

Rua Mossoró, 615 - Petrópolis, Natal Escolha sua especialidade e faça seu check-in!

GERAL ORTOPEDIA OUTRO 6 3 1

Please be near place to check in! ✖

(c) Checkin ativo

6 10

4

Rua Apodi, 596 - Tirol, Natal

ORTOPEDIA OUTRO

3 1

Ops! It seems that you already have an active checkin!✖

uma opção de realizar a saída da aplicação; além disso mostra as sugestões de unidades médicas por especialidade em ordem ascendente das suas filas.

Com a plataforma desenvolvida percebe-se que é possível a visualização de hospitais e clínicas médicas nas proximidades do paciente, juntamente com uma estimativa de pessoas nas localidades específicas. Dessa forma, o usuário pode embasar nessas informações para avaliar e decidir qual casa de saúde o melhor atende.

(37)

Figura 20 – Tela: comentário realizado

(a) Desktop

6 10

4

Comentário

Atendimento muito rápido!

arthurvds 3 1 1 (b) Mobile 6 10 4

Comentário

arthurvds

3 1

1

Figura 21 – Tela: possíveis erros do comentário

(a) Autenticação

6 3

SIGN IN

ORTOPEDIA OUTRO

2 1

Please sign in to comment! ✖

(b) Não está próximo

10

Hospital de Olhos do Rio Grande do Norte Ltda

Rua Mossoró, 615 - Petrópolis, Natal

ORTOPEDIA OUTRO

O atendimento está rápido!

6 3 1

Please be near place to comment! ✖

(38)

Figura 22 – Tela: outros recursos

(a) Informações do usuário e lo-gout

6 10

4

arthurvds arthurvdiniz@gmail.com

(b) Sugestões de localidades por especialidade

6 3

ORTOPEDIA OUTRO

2 1

Suggestions for Geral

Clínica TCC...

Geral - 0

Shopping clinic...

Geral - 0

Hospital Unimed Nata...

Geral - 0

Matern. Mun. Dr. Ara...

(39)

38

5 CONCLUSÃO

Neste trabalho foi proposto e desenvolvida uma plataforma web colaborativa voltada à área médica, com o intuito de reduzir as filas nas unidades de saúde próximas ao utilizador. Por meio de tecnologias recentes no desenvolvimento web foi possível a criação de tal aplicação, a qual reage a eventos e requisições HTTP em tempo real.

No decorrer do desenvolvimento, foram encontradas algumas dificuldades, tais como a modelagem do banco de dados para aplicação poder escalar e também a aquisição de dados para trabalhos futuros. Além disso, a aplicação apresenta limitações no quesito da comunicação via WebSockets, visto que todo evento emitido pelo servidor é validado no cliente para saber de qual localidade pertence aquele dado.

Ademais, as especialidades médicas de cada localidade foram classificadas em apenas três categorias: geral, ortopedia e outros. Além disso, a criação das localidades foi confiada a partir de um filtro, do tipo Hospital, na Places API do Google Maps e com isso nem sempre retornam espaços que se adaptam a plataforma.

Apesar dessas limitações, os objetivos da proposta foram alcançados. Como trabalhos futuros planeja-se a criação de um sistema de recomendação aprimorado baseado na distância do usuário às unidades médicas, no tempo de estadia de usuários anteriores e das avaliações, recorrendo a técnicas de análise de dados e aprendizado de máquina. Como também uma melhora no design da aplicação e uma possível integração com os sistemas das clínicas e hospitais para uma melhor estimativa de pessoas em filas daquele local.

(40)

39

REFERÊNCIAS

ARRACHEQUESNE, D. What Socket.IO is and is not. 2019.https://socket.io/docs/. Acessado em: 09 de Outubro de 2019. 20

AUTH0. Introduction to JSON Web Tokens. 2019. https://jwt.io/introduction/. Acessado em: 08 de Outubro de 2019. 18

CROCKFORD, D. Introducing JSON. 2019. https://www.json.org/. Acessado em: 08 de Outubro de 2019. 19

ERKKILä, J.-P. Websocket security analysis. 2012. 20

EXPRESS. Express: Fast, unopinionated, minimalist web framework for Node.js. 2019.

https://expressjs.com/. Acessado em: 07 de Outubro de 2019. 17

FACEBOOK. Flux Concepts. 2019.https://github.com/facebook/flux/tree/master/

examples/flux-concepts. Acessado em: 05 de Outubro de 2019. 16

HAVERBEKE, M. Eloquent JavaScript. 3. ed. London: No Starch Press, 2018. 12

JAMES, O. Basic Web Pages. 2019.https://internetingishard.com/html-and-css/

basic-web-pages/. Acessado em: 03 de Outubro de 2019. 14

JAMES, O. CSS Selectors. 2019. https://internetingishard.com/html-and-css/

css-selectors/. Acessado em: 03 de Outubro de 2019. 15

KERRISK, M. The Linux Programming Interface: A Linux and UNIX System

Programming Handbook. 1. ed. New Zealand: No Starch Press, 2010. 19

MARIN, H. d. F. Sistemas de informação em saúde: considerações gerais. 2010. 10 MICROSOFT. Dados não relacionais e NoSQL. 2019.https://docs.microsoft.com/

pt-br/azure/architecture/data-guide/big-data/non-relational-data. Acessado

em: 08 de Outubro de 2019. 19

MONGODB. What Is MongoDB? 2019.https://www.mongodb.com/what-is-mongodb. Acessado em: 08 de Outubro de 2019. 19

MORRIS, S. What is ReactJS? 2019. https://skillcrush.com/2019/05/14/

what-is-react-js/. Acessado em: 04 de Outubro de 2019. 15

MOZILLA. HTML basics. 2019.https://developer.mozilla.org/en-US/docs/Learn/

Getting_started_with_the_web/HTML_basics. Acessado em: 03 de Outubro de 2019.

14

MOZILLA. An overview of HTTP. 2019. https://developer.mozilla.org/en-US/

docs/Web/HTTP/Overview. Acessado em: 08 de Outubro de 2019. 17

NODE. About Node.js. 2019. https://nodejs.org/en/about/. Acessado em: 01 de Outubro de 2019. 12

(41)

Referências 40

NODE. The Node.js Event Loop, Timers, and process.nextTick(). 2019. https:

//nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/. Acessado em: 01

de Outubro de 2019. 13

OLIVEIRA, S. et al. Unidade de pronto atendimento – upa 24h: Percepção da enfermagem. 2015. 10

PIRES, J. O que é API? REST e RESTful? Conheça as definições e diferenças! 2019.

https://becode.com.br/o-que-e-api-rest-e-restful/. Acessado em: 07 de Outubro

de 2019. 16, 17

REACT. React: A JavaScript Library for building user interfaces. 2019. https:

//reactjs.org. Acessado em: 04 de Outubro de 2019. 15

REDUX. Redux: A predictable state container for JavaScript apps. 2019. https:

//redux.js.org/. Acessado em: 05 de Outubro de 2019. 15

ROSSI, G. et al. Web Engineering: Modelling and Implementing Web Applications. 1. ed. London: Springer-Verlag, 2008. 10

SHKLAR, L.; ROSEN, R. Web Application Architecture: Principles, Protocols and

Practices. 2. ed. London: Wiley, 2009. 17

SK. A Beginners Guide To Cron Jobs. 2019. https://www.ostechnix.com/

a-beginners-guide-to-cron-jobs/. Acessado em: 08 de Outubro de 2019. 17

SKIPLINO. Skiplino. 2019. https://skiplino.com/. Acessado em: 02 de Dezembro de 2019. 10

TEMFILA. Tem Fila? 2019. http://www.temfila.com.br/. Acessado em: 02 de Dezembro de 2019. 10

VELOSO, T. Gestão de filas de espera no Serviço de Urgência. 2019. http: