LA METHODE DE RESTITUTION DE JEAN PIERRE GOLVIN

Na Figura 5.9, é possível verificar que o sistema de informação inclui especificamente uma Web API, uma aplicação web, uma aplicação mobile, uma base de dados e também a implementação restante do sistema, no qual esta última será apresentada mais à frente.

5.9.3.1 Web API

Web API é uma API sobre a web que pode ser acedida usando o protocolo HTTP. Com

esta API é possível a produção de serviços baseados em HTTP que podem ser acedidos por diferentes aplicações e plataformas. Web API é baseada na arquitetura REST, por isso, usa o seguinte conjunto de operações que se aplica a qualquer tipo de informação:

POST (operações de escrita), GET (operações de leitura), PUT (operações de atualização) e DELETE (operações de eliminação).

Relativamente à autenticação desta API, optou-se por utilizar uma autenticação baseada em tokens (JSON Web Token (JWT)). Usando este tipo de autenticação, primeiro existe o envio das credenciais de acesso à API. No caso das credenciais serem válidas, o servidor envia para o cliente um token que terá que ser sempre enviado, no header Authorization com a flag

Bearer, quando o cliente pretende aceder aos conteúdos guardados no servidor. Para melhor

entendimento deste fluxo de pedido/reposta, a Figura 5.11 demonstra a interação descrita.

5.9.3.2 Aplicação web

A aplicação web é uma componente essencial neste sistema já que é através da mesma que a configuração dos vários polos remotos é possível, para além da monitorização e controlo dos vários tanques associados a esses polos remotos.

A framework escolhida para o desenvolvimento da camada de apresentação da plataforma

web foi o Durandal.js. Durandal.js [69] é uma framework leve em JS desenhada para criar Single Page Application (SPA) de uma forma simples e elegante. Esta framework é construía

em bibliotecas conhecidas no desenvolvimento de aplicações web como o jQuery, Knockout.js e RequireJS.

Para o desenvolvimento da aplicação web foram utilizadas as seguintes lingua- gens/bibliotecas/frameworks:

• HTML, CSS, JS: os pontos de partida para a criação da interface web foram o HTML

Started Kit disponibilizado no site oficial do Durandal.js e o template denominado por SufeeAdmin2 baseado em Bootstrap 4;

• jQuery [70]: biblioteca JS que permite o Asynchronous JavaScript and XML (AJAX) mais simples com uma API que funciona em vários browsers. A versão utilizada foi a 3.4.1;

• Bootstrap [71]: framework open-source para o desenvolvimento de aplicações web usando HTML, CSS e JS. Permite a criação de aplicações responsivas e amigáveis melhorando assim a experiência do utilizador. A versão utilizada foi a 4.3.1;

• Knockout.js[72]: biblioteca JS que fornece uma forma simples e limpa de lidar com interfaces complexas baseadas nos dados, ou seja, quando o modelo de dados altera, a interface gráfica irá ser atualizada automaticamente. A versão utilizada foi a 3.5.0; • RequireJS[73]: biblioteca JS e um carregador de módulos. Esta biblioteca pode ser

vista como um gestor de ficheiros que permite gerir as dependências entre ficheiros JS, e divide todas as funcionalidades em módulos diferentes, ajudando a melhorar a velocidade e a qualidade do código. A versão utilizada foi a 2.3.6;

• ZingChart[74]: biblioteca JS que permite visualizar dados graficamente. Estes gráficos criados são responsivos. A versão utilizada foi a 2.8.6;

• Date Range Picker[75]: biblioteca JS que permite escolher um intervalo de dias, ao aparecer dois calendários, ou escolher um intervalo de dias predefinidos como os últimos 7 dias. A versão utilizada foi a 3.0.5;

• Amplify.Store[76]: biblioteca JS que é um wrapper para vários sistemas de armazena- mento persistente do lado do cliente. A versão utilizada foi a 1.1.2;

• Animate.css[77]: biblioteca CSS de animações. A versão utilizada foi a 3.7.0; • Font Awesome[78]: biblioteca CSS de ícones. A versão utilizada foi a 5.9.0; • Themify Icons[79]: biblioteca CSS de ícones. A versão utilizada foi a 11.3.4;

• Materialize[80]: biblioteca JS e CSS que permite a criação de alertas discretos para os utilizadores através de toasts. A versão utilizada foi a 1.0.0;

2

https://colorlib.com/polygon/sufee/index.html

• Socket.io[81]: biblioteca JS que permite comunicações bidirecionais em tempo real. A versão utilizada foi a 2.2.0;

• Crypto-js[82]: biblioteca JS para encriptação de dados. A versão utilizada foi a 3.1.9-1; • DataTable[83]: plugin para jQuery que adiciona funcionalidades as tabelas HTML. A

versão utilizada foi a 1.10.9.

5.9.3.3 Diagrama de atividades

Nesta subsecção, são apresentados diagramas de atividades de alguns dos fluxos a criar no sistema de informação para o registo de tanques, estações remotas e de utilizadores.

Adição de um tanque

Para o registo de um novo tanque no sistema, utilizando a aplicação web desenvolvida, são necessários três parâmetros importantes que são: o ID associado a esse tanque, o endereço IP do microcontrolador Raspberry Pi que controla localmente esse tanque, e por fim, a estação remota a que se irá associar esse novo tanque. Após o preenchimento destes campos, por parte do utilizador, é verificado se o ID escolhido pelo utilizador pode ser efetivamente usado. Se o ID já é usado, o utilizador terá que escolher um novo ID. Caso contrário, o ID escolhido é válido e por consequência é publicado no tópico <remoteStationID>/newTankValidation, a configuração inicial do tanque para proceder a validação do seu endereço IP. A estação remota respetiva, ao receber a configuração inicial de um novo tanque, faz um POST para o url http://<ipAddressOfTank>:1880/validate. Se receber uma resposta 200 OK, então quer dizer que o endereço IP, inserido pelo utilizador, é válido e publica no tópico <remoteStationID>/<tankID>/validation a mensagem “true”. Se receber uma resposta diferente de 200 OK ou se não obtiver nenhuma resposta, após um intervalo de tempo, quer dizer que o endereço é inválido e publica no tópico <remoteStationID>/<tankID>/validation a mensagem “false”. O servidor central, após publicar a configuração inicial do tanque, subscreve ao tópico <remoteStationID>/<tankID>/validation para receber uma resposta em relação à validação da configuração inicial escolhida pelo utilizador da aplicação web. Se a mensagem recebida for “false”, o servidor envia ao cliente uma mensagem a dizer que o endereço IP introduzido não corresponde ao endereço IP do Raspberry Pi que controla localmente o tanque, por isso, o mesmo deve alterar o endereço IP para o correto. Se a mensagem recebida for “true”, o servidor envia ao cliente a mensagem de que a configuração inicial foi feita com sucesso e que pode preencher o resto da configuração do novo tanque.

Após esse preenchimento, o novo tanque é registado no servidor, ao armazenar a informação na base de dados. Depois, certas partes da configuração como o ID, os sensores e os atuadores instalados, são publicados no tópico <remoteStationID>/newTank, para que a estação remota respetiva guarda certas informações localmente e também as reencaminhe para o tanque respetivo, através de um POST para o url http://<ipAddressOfTank>:1880/config. Por fim, o utilizador é notificado que o tanque foi adicionado com sucesso.

Para um melhor entendimento do fluxo explicado, a Figura 5.12 apresenta o diagrama de atividades da adição de um novo tanque utilizando a aplicação web.

Figura 5.12: Diagrama de atividades da adição de um tanque ao sistema Adição de uma estação remota

Para o registo de uma nova estação remota no sistema, utilizando a aplicação web desen- volvida, são necessários dois parâmetros importantes que são, o ID associado a essa estação remota e o endereço IP do dispositivo que irá desempenhar o papel de estação remota. Após o preenchimento destes campos, por parte do utilizador, é verificado se o ID escolhido pelo utilizador pode ser efetivamente usado. Se o ID já é usado, o utilizador terá que escolher um novo ID. Caso contrário, o ID escolhido é válido e por consequência é publicado no tópico centralServer/newRemoteStation a configuração inicial da adição de uma estação remota. Todas as estações remotas, que ainda não foram configuradas, subscrevem a esse tópico. Quando recebem uma mensagem nesse tópico, verificam se a mesma contém o seu endereço IP. No caso de conter, publica no tópico centralServer/newRemoteStation/validation

a mensagem a dizer que está pronta para receber a configuração final. Depois da publica- ção, subscreve ao tópico <remoteStationID>/configRemoteStationRemotely para receber a configuração final. Entretanto, no servidor central, este subscreve ao tópico centralSer- ver/newRemoteStation/validation à espera que uma estação remota lhe resposta. Se dentro de 5 segundos não receber uma mensagem desse tópico, quer dizer que o endereço é inválida e é enviado para o cliente a mensagem de que o endereço IP introduzido não corresponde ao endereço IP do dispositivo que irá desempenhar o papel de estação remota, por isso, o mesmo deve alterá-lo para o correto. Se dentro de 5 segundos receber uma mensagem, então quer dizer que o endereço IP, inserido pelo utilizador, é válido e é enviado para o cliente a mensagem de que a configuração inicial foi feita com sucesso e que pode preencher o resto da configuração da estação remota.

Após esse preenchimento, a nova estação remota é registada no servidor, ao armaze- nar a informação na base de dados. Depois, certas partes da configuração como o ID são enviados para a nova estação remota através de uma mensagem para o tópico <remoteStatio- nID>/configRemoteStationRemotely. Por fim, o utilizador é notificado que a estação remota foi adicionada com sucesso.

Para um melhor entendimento do fluxo explicado, a Figura 5.13 apresenta o diagrama de atividades da adição de uma nova estação remota utilizando a aplicação web.

Registo de um novo utilizador

Existem duas maneiras de adicionar novos utilizadores ao sistema. Uma é através do mesmo, utilizando a página de registo disponibilizada tanto pela aplicação web como pela aplicação mobile, a outra é quando um utilizador admin decide adicionar um novo utilizador. Quando um utilizador admin adiciona um novo utilizador, o mesmo escolhe quais são as estações remotas que vão estar a seu cargo e o seu papel no sistema, ou seja, se é um utilizador normal ou se é um utilizador admin. Após o registo, e quando o novo utilizador faz login no sistema, é fortemente encorajado a alterar a informação pessoal do mesmo, já que o perfil foi criado por uma outra entidade.

Quando um novo utilizador quer se registar no sistema, é lhe apresentado a página de registo com um formulário com vários campos a preencher. Um desses campos é a estação remota que gostaria de ser associado para poder controlar os tanques pertencentes a ela. Após o preenchimento e verificação da validação da informação inserida pelo utilizador, o novo utilizador registado e autenticado pode utilizar as aplicações web e mobile apenas para monitorizar os tanques registados no sistema. Depois do registo do novo utilizador, é enviada uma notificação para todos os utilizadores admin, que tem a seu cargo a estação remota escolhida pelo novo utilizador, com o objetivo de notificar esses utilizadores que existe um novo pedido pendente de junção a essa estação remota. Após o novo pedido, qualquer utilizador

admin pode aceitar ou rejeitar esse pedido. Se for aceite, o novo utilizador é notificado que o

seu pedido foi aceite e a partir desse momento pode controlar todos os tanques dessa estação remota. Se for rejeitado, o novo utilizador também é notificado de que o seu pedido foi rejeitado e por consequência continua a não conseguir controlar qualquer tanque, apenas o consegue fazer quando for designado para controlar uma estação remota.

Para um melhor entendimento do fluxo explicado, a Figura 5.14 apresenta o diagrama de atividades do registo de um novo utilizador.

Figura 5.14: Diagrama de atividades de registo de um novo utilizador no sistema 72