Para o armazenamento de dados serão utilizados dois tipos de banco de dados, SQL e NoSQL. No banco SQL, serão armazenados os dados de controle do sistema, como os cadastro de dispositivos, exibição de dados e as informação de segurança. Já no banco NoSQL serão armazenados os dados enviados pelos dispositivos de IoT.

Deve ser configurado o ambiente para essas bases, além de ser preparado o código de leitura e escrita nas bases de dados para que sejam utilizadas de maneira simples, quando chegarmos nas etapas de manipulação desses dados.

Além das configuração de ambiente e do código para conexão, é necessário montar um ambiente de gerenciamento de migrations, ou seja, maneira de versionar e atualizar as versões da base automaticamente.

Importante ressaltar que para esta etapa não será necessário a criação das estruturas de armazenamento do sistema, essas serão feitas ao decorrer da implementação do sistema e conforme a necessidade de cada etapa.

Para o módulo de gerenciamento, vamos separar em duas partes, backend e frontend. Para o backend, uma API Rest onde será possível criar, ler, escrever e deletar os dados de acordo com as permissões dadas ao usuário que está solicitando a ação. Esse usuário será identificado pelo token JWT a cada requisição a API.

O frontend será responsável por efetuar requisições ao backend, exibir os dados e executar as solicitações de maneira simples para o usuário no qual está trabalhando com a aplicação. As telas necessárias para a aplicação estão divididas em subtítulos para facilitar o entendimento e em cada uma das divisões será executado as alterações para o backend e para o frontend.

• #8
• #9
• #10
• #11
• #12
• #13
• #14

Para facilitar a montagem do ambiente local da aplicação, será implementada a conteinerização da aplicação usando Docker e a orquestração usando o Docker Compose. Um script será criado, para que a aplicação seja gerada e publicada de maneira simples. Com isso, também se tem a necessidade de criar uma documentação básica com os requisitos e o passo-a-passo para executar a aplicação localmente. A documentação deverá ser feita em um arquivo de Markdown, pois é formato compatível com o GitHub, facilitando a visualização de quem acessar a página do projeto.

Esta é a tela principal do sistema. Um painel visual que apresenta, de maneira centralizada informações sobre os dispositivos do usuário corrente. Esses indicadores podem ser montados de maneiras personalizada pelo usuário de acordo com os dados gerados em cada dispositivo.

Figura 1: Separação da tela de dashboard.

O dashboard será dividido em infinitos quadros conforme a figura 1. O usuário terá a opção de incluir gráficos XY (figura 2) onde ele poderá selecionar os valores para os valores em X e Y, de acordo com os tipos de dados cadastrados para o dispositivo selecionado na montagem do gráfico o gráfico. Além disso, o usuário poderá informar um título e quantidade de quadros serão utilizados na horizontal e a na vertical.

Figura 2: exemplo de gráfico XY (3x5) no dashboard.}

Outra tela de controle administrativo da aplicação e será responsável pelo controle dos usuários permitindo redefinir a senha atual e vincular o usuário a novos grupos de acesso.

Esta é a tela que é responsável pelo cadastro de tipos de dados recebidos por um dispositivo. Esses tipos de dados pode ser simples, como número, texto livre, data hora e etc. ou pode ser dados complexos nos quais são um agrupamento de dados simples e/ou complexos.

Como inicio do processo será criado o repositório dos arquivos junto com o versionamento do projeto. Para isso, será utilizado a ferramenta Git para o controle de arquivos e versionamento e como repositório de arquivos, será utilizado a plataforma do GitHub, já que uma das diretrizes do trabalho é que seja um sistema de código aberto e de fácil acesso a comunidade de desenvolvimento.

Esta tela deve listar e permitir a edição dos dados do usuário corrente logado na aplicação. Nela o usuário pode alterar as suas informações e visualizar as suas permissões de acesso. Por questão de segurança, na lista de permissões não serão listadas as telas nas quais o usuário corrente não possui nenhum tipo de acesso.

Uma das maneiras de leitura dos dados gerados, será uma API Rest. Ela irá disponibilizar informações sobre os dispositivos do usuário, assim como os dados recebido deles, os tipos e modelos desses dados. Todas as informações de acesso, passam pela autenticação JWT e apenas são disponibilizadas de acordo com o contexto do usuário logado previamente por uma rota de autenticação.

Esta é uma tela de acesso administrativo na qual o usuário que possui acesso pode gerenciar as permissões dos grupos existentes e criar novos grupos. Nessa tela será feito o vinculo de cada grupo as rotas existente e o tipo de permissão de acesso.

Tela na qual será gerenciado todos os tipos de dispositivos. Nela será possível definir o tipo de dado enviado pelo tipo de dispositivo, que caso ainda não exista o formato, poderá ser criado um novo através de um atalho para a tela de cadastro de tipos de dados.

Para o recebimento dos dados dos dispositivos, irá existir duas opção de protocolos de envio de dados. Será possível a utilização tanto do protocolo Rest que é um padrão muito utilizado para a comunicação a aplicações da web e o protocolo MQTT, muito utilizado para a comunicação distribuída de dispositivos de IoT.

Como responsável pelo armazenamento dos dados enviados pelos dispositivos, este serviço irá armazenar os dados em um banco NoSQL, guardando as informações sobre o dispositivo que enviou o dado, data de recebimento e o dado recebido.

Em geral, um dispositivo pode enviar qualquer dado ao servidor. Esse dado enviado deve ser definido previamente em um cadastro de tipo de dispositivo que define o tipo de dado enviado pelo mesmo. Todo dado recebido de um dispositivo, será validado pelo serviço no recebimento para saber se esta dentro do modelo cadastrado.

Também nessa etapa, será montada a estrutura do banco de dados responsável pelo armazenamento do dispositivo, tipo de dispositivo e tipo de dado. A ligação destas estruturas será conforme definido na figura.

Figura: ligação de entidades de dispositivos.

O tipo de dispositivo é um cadastro genérico que específica como um dispositivo se comporta. Nele é definido as descrições e o tipo de dado que esse dispositivo envia. Um exemplo de tipo de dispositivo seria o GPS, que envia dois números, as informação de latitude e longitude.

Um dispositivo é uma instancia do tipo de dispositivo que possui um número único e tokens de acesso que são utilizadas para a identificação e autorização no envio dos dados do dispositivo. Cada token de acesso pode ser revogado ou ativado novamente a qualquer momento.

Como serão utilizados microsserviço para o funcionamento do sistema, é necessário a utilização de uma ferramenta para gerenciar a troca de mensagens entre eles. Esses serviços embora trabalhem independentes e possuam objetivos diferentes, necessitam se comunicar e trocar dados que são compartilhados entre os mesmos.

Para efetuar esse controle e garantia da entrega das mensagens, será utilizado o Apache Kafka, que é uma plataforma open-source distribuída de streaming de eventos para alta performance de pipeline de dados, análise de streaming, integração de dados e aplicações críticas. Ele será responsável pelo gerenciamento da troca de mensagens entre os serviços que poderão ser alocados em um ou mais computadores.

Nesta etapa do projeto, será estudada mais detalhadamente a ferramenta e implementado a base inicial para os microsserviços garantindo a comunicação entre eles. Além disso, também deve ser implementadas as definições dos modelos de mensagens que serão trocadas e utilizarão a notação JSON.

Aqui o cadastro de dispositivos do usuário, junto com os token de renovação. É importante ressaltar que os dados dessa tela serão visíveis de acordo com o usuário logado no sistema.

Para fazer o controle de segurança do projeto, uma estrutura de usuários e grupos de acesso será construído. Um grupo de acesso possui uma ou mais rotas de acesso e sua permissão que pode ser de criação, leitura, atualização, exclusão ou customizada. Cada usuário, pode ter vários grupos de acesso, sendo que o usuário começa sem permissão de acesso e vai adquirindo de acordo com os acessos dos seus grupos. Em caso de um usuário possuir dois grupos de acessos com permissões diferentes a uma determinada rota, o acesso desse usuário é o somatório destas permissões.

Por exemplo, o grupo de acesso Auditor possui acesso de visualização a rota de Dashboard e o grupo Controlador possui permissão de edição a rota Dashboard. Manuel possui os grupos Auditor e Controlador, e por isso, possui acesso de visualização e edição a rota Dashboard.

O controle de acessos será feito utilizando JWT e para toda requisição feita ao servidor, será avaliado se o usuário que está efetuando a solicitação, possui permissão para a ação executada.

Nesta etapa, será desenvolvido o código de geração dos tokens JWT para os usuários e o modulo de verificação destas permissões. Além disso, como padrão, a aplicação irá inicializar com dois grupos de usuários, um chamado Administrador e outro Padrão. O grupo Administrador deve possuir todos as permissões existentes na aplicação. Já o grupo Padrão apenas acesso de leitura em todas as rotas. Deve ser criado por padrão, o usuário "admin" com a senha "admin" pertencente ao grupo "Administrador". Todo usuário novo cadastrado, deverá receber o grupo "Padrão".