7. arquitetura

7.1 Introdução

O objetivo deste documento é fornecer uma visão geral do planejamento da arquitetura e do projeto detalhado no desenvolvimento do projeto Easywork, realizado durante o semestre 2019/01 na Agência Experimental de Engenharia de Software (AGES) do curso de Engenharia de Software (ES-360) da Pontifícia Universidade Católica do Rio Grande do Sul (PUCRS). Este documento abrange o propósito, escopo, definição, acrônimos, abreviações, referências e a visão geral da Arquitetura de Software e do Projeto Detalhado utilizados.

7.2 Diagrama de Deployment

O projeto foi dividido em camadas que executam em dispositivos diferentes, e podem ser visualizadas na figura a seguir, juntamente das principais tecnologias envolvidas. Cada componente, incluindo possíveis subcomponentes, é instanciado em um contêiner Docker conforme será explicado no item 7.4.

O dispositivo Client faz parte da camada de Front-End. Este dispositivo possui um componente React.js Application que é uma abstração de uma aplicação desenvolvida na linguagem Javascript utilizando a biblioteca React.js para comunicação com o usuário.
O dispositivo Server faz parte da camada de Back-end. Este dispositivo possui um componente REST API (Representational State Transfer - Application Programming Interface) que é uma abstração de uma aplicação desenvolvida na linguagem Java utilizando o framework Spring para implementar o conceito de microsserviços. Serve para validar regras de negócio e comunicar a camada do usuário com o servidor de banco de dados através de protocolo HTTP.
O dispositivo Persistence faz parte da camada de persistência de dados. Este dispositivo possui um componente Relational Database que é uma abstração de um banco de dados relacional PostegreSQL, que é responsável por armazenar e gerenciar todos os dados do sistema.

7.3 Visão de subcomponentes da aplicação REST

Cada rota disponibilizada para uso compõe um subcomponente do componente REST API descrito acima. Estas rotas e sua breve explicação podem ser encontradas na wiki 9. rotas api.
Outro modo de visualização e entendimento de comportamento das rotas é através da ferramenta Postman, cujas coleções de rotas por microsserviço podem ser obtidas no repositório 9. rotas api.

7.4 Conteinerização e Diagrama de Microsserviços

Para a implantação do sistema (deploy) utiliza-se Docker, uma tecnologia de software que permite que a utilização contêineres (virtualizações em nível de sistema operacional) que empacotam uma aplicação e suas dependências em um recipiente virtual.
Mais precisamente, utiliza-se Docker Compose, uma ferramenta que define e implementa um ambiente contendo múltiplos contêiners Docker.
Abaixo encontra-se o diagrama de microsserviços onde:
- a caixa em branco representa o usuário do sistema, tipicamente um browser web.
- as caixas em azul representam as aplicações dockerizadas e implementadas no projeto.
- as caixas em cinza representam as aplicações não implementadas no projeto, podendo fazer parte de um futuro MVP.

7.5 Análise dos princípios SOLID

Single Responsibility Principle:

O projeto possui três microsserviços separados em características macro: autenticação, pesquisas e respostas.
Cada microsserviço possui pacotes específicos para segurança, modelo de dados, comunicação com o banco de dados, modelo de saída, controladores e serviços.
Os controladores estão definidos conforme as rotas disponibilizadas, implementam um método para cada rota específica e delegam o processamento para os métodos de serviço.

Open Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, Dependency Inversion Principle:

O projeto possui uma lógica concisa, direta e enxuta, logo suas classes não precisam de adptações, porém podem ser estendidas quando necessário.
Novas rotas e serviços podem ser facilmente criados com base nos já disponibilizados, sendo necessário apenas definição dos endpoints e da regra de negócio.
O projeto se vale de diversas abstrações, interfaces e anotações providas pelo framework Spring e outros terceiros, assim trata-se de uma implementação que segue boas práticas consolidadas no mercado, que possui fácil manutenção e extensão, e que pratica grande reuso.

7.6 Segurança

A segurança do projeto foi implementada utilizando a dependência Spring Security e a autenticação utilizando jsonwebtoken. Funcionalmente a segurança é implementada da seguinte forma:

A rota de cadastro da api de autenticação permite registrar usuários com no mínimo cinco informações nome completo, usuário, e-mail, senha e papel (name, username, email, password e role).
Os possíveis papéis (roles) de usuários no sistema são:
- ROLE_ADMIN - administrador, só pode ser cadastrado localmente no servidor da aplicação.
- ROLE_RESEARCHER - pesquisador, cadastro via tela de cadastro em qualquer browser web.
- ROLE_RESPONDENT - respondente, cadastro via tela de cadastro em qualquer browser web.
A rota de login da api de autenticação permite que um usuário faça login no sistema utilizando usuário ou e-mail e senha. Ao validar as credenciais do usário a api retornar um token jwt que é salva pelo cliente front-end para acessar rotas protegidas do sistema.
Os clientes devem mandar o token jwt no header de cada requisição que acessar rotas protegidas.
O Spring Security será o responsável por restringir o acesso às rotas conforme abaixo:
- rotas de cadastro, login e, se necessário, recursos estáticos como imagens e scripts são acessíveis a todos que acessarem a página web do sistema, mesmo que não estejam autenticados.
- rotas de consulta a pesquisas cadastradas necessitam apenas que o usuário esteja logado.
- rotas para criar e editar pesquisas necessitam que o usuário esteja logado como administrador ou pesquisador, sendo que é possível editar apenas pesquisas cadastradas pelo próprio usuário logado.
- rotas para iniciar e finalizar uma resposta podem ser acessadas apenas por usuário respondentes.
- rotas que deletam fisicamente registros de usuários, pesquisas e respostas são acessadas apenas por usuários administradores.