Documento de Arquitetura de Software

Histórico de Revisão

Data	Versão	Descrição	Autor(es)
14/09/2020	0.1	Criação do Documento e Adição do template e do sumário	Guilherme Aguiar
18/09/2020	0.2	Criação da visão de casos de uso	Bruno Nunes
21/09/2020	0.3	Criação das Metas e Restrições Arquiteturais	Tomás Veloso
14/12/2020	0.4	Reestruturação Visão Lógica	Bruno e Hércules

Sumário

1. Introdução
1.1 Objetivo
1.2 Escopo
1.3 Definições, Acrônimos e Abreviações
1.4 Referências
1.5 Visão Geral
2. Representação Arquitetural
2.1 Plataforma ReactJS
2.2 API
2.2.1 User
2.2.2 Resolution
2.2.3 Reports
2.2.4 News
2.2.5 Benefits
2.2.6 Adverts
2.3 Banco de Dados
3. Restrições e Metas Arquiteturais
4. Visão Lógica
4.2.1 Back-End
4.2.2 Front-End
4.3 Modelagem de dados
5. Visão de Implementação

1. Introdução

1.1 Objetivo

Este documento tem como finalidade fornecer uma visão arquitetural abrangente do sistema Vamos Cuidar Gestão, por meio de diversas visões arquiteturais para representar diferentes aspectos da aplicação. Com o propósito de demonstrar as decisões arquiteturais tomadas no desenvolvimento do Vamos Cuidar Gestão.

1.2 Escopo

1.3 Definições, Acrônimos e Abreviações

As Definições, Acrônimos e Abreviações para entendimento do documento são:

UnB: Universidade de Brasília
FGA: Faculdade do Gama - Campus da Universidade de Brasília
API: Application Programming Interface (Interface de Programação de Aplicativos)
REST: Representational State Transfer (Transferência de Estado Representacional)
HTTP: Hypertext Transfer Protocol (Protocolo de Transferência de Hipertexto)
IDE: Integrated Development Environment (Ambiente de Desenvolvimento Integrado)
App: Application (Aplicativo)
MVC: Model-View-Controller
UC: Use Case (Caso de Uso)
VCU: Vamos Cuidar Usuário: Plataforma desenvolvida pelo grupo de MDS da professora Carla, com a qual nossa aplicação irá se comunicar.
VCG: Vamos Cuidar Gestão: A nossa plataforma

1.4 Referências

As referências aplicáveis são:

1.5 Visão Geral

Este documento visa detalhar as soluções arquiteturais desenvolvidas no sistema. Deste modo, neste documento serão abordados os seguintes aspectos:

Representação Arquitetural
Restrições e Metas Arquiteturais
Visão de Casos de Uso
Visão Lógica

2. Representação Arquitetural

O sistema é composto de três frentes:

A frente da aplicação, será feita com em Javascript com a biblioteca ReactJS, que oferece ao usuário gestor as opções de interação com a plataforma feita da outra turma de MDS (VCU), tais como resolver uma postagem, relatórios sobre a plataforma e a criação de notícias e benefícios.
A frente das API's, também utilizaremos Javascript, mas no server usaremos o NodeJS. Baseando-se na arquitetura de microserviços, é composta por 5 serviços (pacotes), cada um com suas próprias responsabilidades e deveres.
A frente de dados, onde teremos um banco de dados PostgreSQL, hospedado na infraestrutura da Unb, onde serão persistidos os dados que iremos receber do VCU e onde iremos salvar os artefatos criados na nossa plataforma. Já no ambiente de desenvolvimento, usaremos o postgres localmente com o Docker. Para facilitar a criação das visualizações, optamos pela utilização da ferramenta Kibana.

Cada frente possui sua própria arquitetura interna.

2.1 Plataforma ReactJS

Em poucas palavras, o React é uma biblioteca JavaScript para criação de interfaces para o usuário, desenvolvida e mantida pelo Facebook, sua primeira release saiu em 2013. É uma lib open-source com mais de 1k de colaboradores ativos no GitHub.

Ela está presente no nosso dia-a-dia mais do que você imagina, em empresas grandes como Facebook, Instagram, AirBnB, NFL, Yahoo e muito mais. O mercado para essa biblioteca só cresce.

2.2 API

Os microserviços da aplicação vão seguir o mesmo padrão, será usado o Nodejs para a lógica no back-end, seguindo a o padrão arquitetural MVC, onde a camada da View fica como o ReactJS. O padrão de organização dos elementos arquiteturais está representado no diagrama acima. f

2.3 Banco de dados

PostgreSQL é um sistema de banco de dados relacional de objeto de código aberto com mais de 30 anos de desenvolvimento ativo que lhe rendeu uma forte reputação de confiabilidade, robustez de recursos e desempenho. O banco é divido em schemas, cada microserviço irá interagir com um único esquema, o que contribui para a independência dos microserviços e a diminuição do acoplamento. A seguir serão representadas o diagrama dos esquemas.

3. Restrições e Metas Arquiteturais

A tomada de decisão pela arquitetura de pequena escala (software), foi tomada a partir da Engenharia de Requisitos conciliado com o levantamento de restrições para o desenvolvimento do software e o usuário de destino. Entretanto, existem restrições no funcionamento do software, restrições de design, operacionais e de compatibilidade. Sendo assim, para melhor atender os requisitos definidos e utilizar das melhores tecnologias disponíveis, foram selecionadas as metas e restrições de arquitetura.

3.1 Metas

A usabilidade da aplicação website, podendo ser acessada pelos navegadores modernos, terá interface de um dashboad para fácil entendimento de suas informações em dados visuais intuitivos. Por tanto, a eficiência do site será conceder os dados e suas informações de forma clara e rápida ao usuário, para que assim possa gerenciar e acompanhar os processos de forma imediata. Para que o usuário gestor cumpra o objetivo de visualizar os dados e operar suas informações de forma clara e simples, tendo como meta uma aplicação eficiente. A manutenibilidade do software será a capacidade de ser modificado para adequa-se a novos requisitos solicitados, para melhorias de funcionalidades ou incrementos de novas funções. Para a execução de suas funções de forma eficiente, as funcionalidades devem ser submetidas a testes, para verificação e validação do seu comportamento e assim possuir um produto de software eficiente e com qualidade.

3.2 Restrições

As restrições de design estão relacionadas às ferramentas e tecnologias escolhidas para para o desenvolvimento do software. A elaboração do projeto, website, utilizando JavaScript, ReactJS, HTML, CSS, NodeJS, Docker e PostgreSQL. Existem restrições operacionais referentes à aplicação, o fato que a tecnologia desenvolvida para sua operação necessita da interação com um servidor de hospedagem disponibilizado por terceiros. A tecnologia será desenvolvida em parceria com outro desenvolvimento de software, portanto, o software deve está de acordo com outro projeto para consumir seus dados e gerá-los no site, em que a interação entre as tecnologias funcionem corretamente, sem problemas de compatibilidade entre elas.

4. Visão Lógica

4.1 Visão Geral

Mostra a seguir a hierarquia dos pacotes, onde tem-se a decomposição do back-end, e juntamente o front-end. Em conjunto, a distribuição dos microserviços.

4.2 Diagrama de pacotes

4.2.1 Back-End

Para o back end, cada microserviço tem sua visão geral composta de quatro pacotes:

Controller
Possui classes que são responsáveis pela execução de código que prepara os dados para sua exibição no React, também são responsáveis por controlar as chamadas à API e despachar o resultado para o local adequado, seja o React que esteja aguardando ou outros objetivos.
Models
Classes que fazem representação dos dados que o aplicativo deve persistir localmente, como os dados das postagens a aplicação deve listar. Essas classes também contém algumas operações específicas aos seus objetos.
Routes
A camada de roteamento define a maneira como as solicitações do cliente são tratadas pelos endpoints do aplicativo.
Test
Pacote da aplicação onde são realizados os testes unitários da lógica da aplicação (controllers) e da estrutura da model.

4.2.2 Front-End

Para o front end, cada microserviço tem sua visão geral composta de quatro pacotes:

Public
É onde residem seus arquivos estáticos. Se o arquivo não for importado por seu aplicativo JavaScript e precisar manter seu nome de arquivo, coloque-o aqui.
Assets
Na pasta assets ficam as dependências compartilhadas por seu aplicativo - como mixins SASS, imagens, etc. - podem ir para o diretório.
Components
A pasta onde ficam os componentes únicos do react.
Pages
A pasta pages possuem componentes constituidos por vários componentes, que forman as páginas finais que são exibidas.
Utils
Esta é uma pasta cheia de funções auxiliares que são usadas globalmente. Mantenha seu código DRY (Don Don't Repeat Yourself) exportando a lógica repetida para um único local e importando-o onde for usado.