Ir para o conteúdo

Documento de Arquitetura

Introdução

Objetivo

  O presente documento de arquitetura tem como objetivo elucidar e descrever os aspectos mais importantes no que tange os estilos e padrões arquiteturais acerca da concepção e desenvolvimento do projeto Curumim.

Escopo

  Através desse documento é possível se ter um entendimento detalhado sobre os aspectos inerentes ao projetos contidos no conjunto "4 + 1" de visões arquiteturais definido pelo RUP[1] e a visão de dados.
  Além disso, esse documento aborda uma representação mais detalhada da arquitetura, as metas arquiteturais, restrições e aspectos acerca da qualidade, tamanho e desempenho do produto
  Sendo assim, esse documento serve de guia para o entendimento do design e desenvolvimento do projeto.

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

  A tabela a seguir contém as definições dos mais variados termos utilizados neste documento de arquitetura. Mais definições sobre termos pertencentes ao domínio do projeto podem ser encontrados no documento de Léxicos.

Termo Descrição
RUP Rational Unified Process
MVC Model View Controller

Visão geral

  Esse documento de arquitetura é composto pelos seguintes tópicos:

Representação da arquitetura

Back-End

  O NodeJs é uma estrutura do lado do servidor, útil para construir aplicações altamente escaláveis, rápidas e de fácil manutenção. O NodeJs foi projetado para lidar com facilidade com aplicações de entradas/saídas intensivas que são projetadas na arquitetura bloqueante, blocking-thread. "Embora o Nodejs possa servir funções de maneira síncrona, ele geralmente executa operações de forma assíncrona "(Gackenheimer, Cory. Node.Js Recipes: A Problem-Solution Approach, 2013).

  O "Express.js é um web framework que atua como uma camada no topo do Node.js, facilitando e deixando o desenvolvimento de APIs em node mais prático", (BARSOTI, N.; GIBERTONI, D. 2020). Com o express fica mais fácil organizar as funcionalidades da aplicação usando middleware e roteamento, contribuindo para a renderização de páginas HTML dinâmicas.

  O Sequelize Sequelize é um Node.js ORM baseado em promises para Postgres, MySQL, MariaDB, SQLite e Microsoft SQL Server(SEQUELIZE ORG). Essa tecnologia oferece suporte a transações sólidas, relações, replicações de leituras. Além disso, essa tecnologia permite criar, buscar, alterar e remover dados da base de dados e, para isso utiliza métodos JavaScript. O framework Sequelize permite também que os desenvolvedores modifiquem estruturas de tabelas e isso facilita bastante na criação, população e migração de banco de dados.

Front-End

  O React.js é a representação da camada de view no MVC, no front-end é onde ocorre a interação e apresentação das informações ao usuário da aplicação. React.js é um framework Javascript utilizado para desenvolver interfaces com alto nível de valor agregado e qualidade final no produto, com fácil aprendizagem e facilidade de aplicação por parte da equipe.

Banco de Dados

  Segundo André Milani, "O PostgreSQL é um Sistema de Banco de Dados (SGBD) Relacional, utilizado para armazenar informações de soluções de informática em todas as áreas de negócios existentes" (Milani, André. PostgreSQL: Guia do Programador. Novatec. 2008). O Sequelize integra muito bem com o Sequelize, tem uma imensa comunidade bastante ativa. A estabilidade do PostgreSQL é um de seus recursos muito interessante, o mesmo foi projetado para ser capaz de executar no modelo 24/7 (24 horas por dia, sete dias por semana). Por essas características esse Banco de Dados tem sido bastante utilizado no contexto geral de negócios, sites, lojas virtuais, portais ou soluções de informática.

Metas Arquiteturais e Restrições

Metas

Metas Descrição
Responsividade A aplicação deve ser responsiva e ser usável em todas as interfaces sem que haja comprometimento nas funções da aplicação
Usabilidade O usuário deverá ser capaz de realizar as tarefas no menor tempo possível
Escalabilidade A aplicação deve ser capaz de crescer junto com a ascensão de novos usuários. Assim, como ser escalável para implementação de novas funcionalidades
Segurança O aplicativo deve ser seguro e lidar com os dados confidenciais dos usuários com segurança

Restrições

Restrições Descrição
Público O aplicativo será voltado para administradores, professores, pais e responsáveis por crianças matriculadas no centro educacional que utiliza o aplicativo Curumim
Conectividade É necessário conexão com a internet para usar a aplicação
Língua A aplicação tem idioma somente para o português do Brasil
Prazo final O escopo proposto deve ser concluído até o final do curso, Arquitetura e Desenho de Software

Visão de Casos de Uso

  Apresentando uma representação mais próxima do usuário, a visão de casos de uso auxilia no entendimento das interações dos atores com o sistema de forma a descrever os cenários de uso da aplicação. O diagrama de casos de uso do projeto Curumim pode ser acessado pelo documento de casos de uso desenvolvido anteriormente.
  A seguir, tem-se uma descrição resumida dos casos de uso mais significativos do projeto, os quais contemplam as funcionalidades mais prioritárias do sistema.

Descrição dos casos de uso mais significativos

Visão Lógica

  A visão lógica consiste na organização conceitual do projeto. O tópico de visão lógica é utilizado para mostrar de forma a decompor o agrupamento dos subsistemas e pacotes da arquitetura do sistema.
  O projeto Curumim é estruturado no padrão MVC, o qual consiste em três camadas lógicas que interagem entre si. Aqui dividimos os pacotes em agrupamentos lógicos e apresentamos suas dependências entre eles.

Diagrama de Pacotes

  O diagrama de pacotes será utilizado para representar a visão lógica da arquitetura empregada no projeto Curumim pois aborda de forma bem decomposta as camadas e pacotes utilizados no sistema.
  A seguir, tem-se um melhor detalhamento desse diagrama de acordo com as duas frentes de implementação do projeto.

Front-End

Diagrama de Pacote - Front End

Figura 01 : Diagrama de Pacotes - Front End

  O front-end, o qual contém a camada de view, é responsável pela interação e apresentação das informações ao usuário. Todas as pastas estão alocadas de forma paralela no pacote App. O ponto de partida é a pasta Routes, onde se tem as rotas e a chamada do conteúdo da aplicação, conteúdo esse que pode ser oriundo tanto dos arquivos da pasta Pages quanto da pasta Components. Além disso, temos as pastas de Assets e a Styles com caráter de armazenamento de mídia estática e configuração de estilo, e a pasta Utils para funções auxiliares ao projeto. Por fim temos a pasta Services responsável pela lógica de comunicação com a API do sistema e da lógica de autenticação.

Back-End

Diagrama de Pacote

Figura 02 : Diagrama de Pacotes - Back End
  No back-end está contida a camada de controle (controller do MVC), onde os componentes recebem requisições de componentes externos. Conforme o necessário, a camada de controle cuida das solicitações de requisições enviadas pela visão. Segundo os autores do artigo, Arquitetura de Software de Referência para Sistemas de Informação Governamentais. “Deve-se considerar que a camada de controle é responsável por colaborar com a camada de modelo.” (XI Brazilian Symposium on Information System, Goiânia, GO, Maio 26-29, 2015, p.81)[4]
  As classes de domínio do sistema estão contidas na camada de modelo (model do MVC), que contém, também, as relações entre as classes bem como a definição das informações que serão persistidas no banco de dados e suas regras.
  Controller e model estão representadas no diagrama de pacotes pelos diretórios controllers e models que estão dentro do diretório app.
  Ainda no diretório app, estão contidos os diretórios middlewares e utils os quais contém classes que dão auxílio à camada de controle na aplicação das regras de negócios e dos padrões de projeto.
  Paralelamente ao diretório app, estão o diretório config, o qual contém definições e variáveis referentes a configurações de ambiente, autenticação e banco de dados, e o diretório database, o qual contém as regras de criação e modificação de tabelas no diretório migrations e se estabelece a conexão com o banco de dados.
  Todos os diretórios citados acima são subdiretórios do diretório src, o qual agrupa todo o código fonte desenvolvido da aplicação. Esse diretório está em paralelo com o diretório node_modules, o qual é composto dos módulos e bibliotecas da ferramenta Node.js.

Diagrama de Comunicação

  Utilizados para definir e esclarecer funções de objetos e classes, os diagramas de comunicação mostram as interações entre objetos e/ou partes. Dessa forma, esses diagramas podem ser utilizados para complementar a representação da visão lógica da arquitetura do projeto, visto que sua modelagem se deu forma a abordar um contexto mais macro do sistema mais focado na lógica da aplicação.
  Tais artefatos podem ser acessados pelo documento dos diagramas de comunicação.

Diagrama de Estados

  Esses diagramas visam demonstrar as transições entre os diferentes objetos que compõem o sistema. E, seguindo a mesma linha do que foi citado no tópico acima, também contribui para uma melhor representação da visão lógica da arquitetura.
  Sendo assim, tais artefatos pode ser acessados pelo documento dos diagramas de estados.

Visão de Processos

  A visão de Processo evidencia as ações processadas pelo sistema em tempo de execução, além da alocação de objetos e classes para tarefas. É uma visão que permite a visualização das partes dinâmicas do sistema, onde é evidenciado os processos, as threads e as interações entre elas.

Diagrama de Sequência

  O diagrama de sequência é uma solução dinâmica de modelagem em UML bastante utilizada para demonstrar um conjunto de interações entre os componentes de um sistema. Em nossa implementação utilizamos de alguns diagramas de sequência para mostrar alguns processos de nosso sistema.

Administrador cadastrando Professor

Administrador cadastrando professor

Figura 03: Diagrama de sequência do administrador cadastrando professor

Administrador cadastrando Evento

Administrador cadastrando professor

Figura 04: Diagrama de sequência do administrador cadastrando evento

Responsável fazendo Login

Responsável fazendo login

Figura 05: Diagrama de sequência do guardian fazendo login

Diagrama de Atividades

  Se tratam de diagramas de comportamento UML que demonstram os fluxos de controle ou os fluxos de objetos focados na sequência e nas condições de cada um de forma a elucidar o fluxo entre as ações de uma determinada atividade.
  Para complementar a representação da visão de processos da arquitetura, e tomando uma abordagem com ênfase no fluxo de controle de atividades, podem ser utilizados os diagramas de atividades desenvolvidos anteriormente.

Visão de Implantação

  A visão de implantação aborda a disponibilização da aplicação para uso. Dessa forma o seguinte fluxo elucida como se dá a implantação do projeto curumim:

  • Desenvolvimento de funcionalidade: Etapa na qual os desenvolvedores aplicam as metodologias de acordo com as políticas para criar novas funcionalidades;
  • Pull-request para a branch develop: Um pull-request do código desenvolvido é criado para a branch de desenvolvimento;
  • Build do software através de um sistema de integração contínua: Utilizando o GitHub, é realizado o build da branch da nova funcionalidade para certificar a consistência do código da aplicação na branch de desenvolvimeto da nova funcionalidade;
  • Realização de revisão por pares: Os revisores avaliam se o que foi desenvolvido atendem aos critérios de aceitação e está dentro dos padrões;
  • Mesclagem do código na branch develop: É realizada a mesclagem do código desenvolvido com o da branch de desenvolvimento;
  • Deploy do software para o ambiente de homologação: É realizado o deploy da branch de desenvolvimento para o ambiente de homologação;
  • Fechamento de Release: É criada uma branch release para o fechamento de uma versão da aplicação;
  • Mesclagem do código na branch main: A branch release é mesclada na branch main e, caso tenha ajustes, na de desenvolvimento;
  • Deploy do software para o ambiente de produção: É realizado o deploy da branch main para o ambiente de produção;

  Para tal implantação, são utilizadas as ferramentas Docker para padronização de recursos e empacotamento do software, GitHub para controle de versões e realização de rotinas CI/CD e Heroku para deploy da aplicação em homologação e produção.

Visão de Implementação

  A visão de implementação se caracteriza como uma das cinco visões de arquitetura de um sistema e sua finalidade é captar as decisões de arquitetura tomadas para a implementação, buscando descrever como os artefatos de desenvolvimento estão organizados.
  Geralmente, a visão de implementação possui:

  • Uma enumeração de todos os subsistemas no modelo de implementação;
  • Diagramas de componentes que ilustram os subsistemas, organizados em camadas e hierarquias;
  • Ilustrações de dependências de importação entre subsistemas;

  Sendo considerado extremamente útil em questões relacionadas a atribuição do trabalho de implementação a indivíduos e equipes, na avaliação da quantidade de código que será excluído, modificado ou desenvolvido e também para discussões a respeito de reutilização em larga escala e estratégias de release.

Padrão MVC

Camadas

  • Model: Essa camada na aplicação Curumim tem a responsabilidade de encapsular estados da aplicação, assim é possível tratar modificações de estado e notificações de estado;
  • View: Essa segunda camada tem como objetivo apresentar a interface para o usuário, na aplicação Curumim ela é a principal responsável por mostrar informações da Model para a interface do cliente;
  • Controller: Essa é camada que faz o intermédio entre as camadas View e Model, assim mapeando as ações do usuário na view para possíveis mudanças na Model;

Conclusão

  Algumas literaturas ao falar do padrão MVC acabam abordando a aplicabilidade dessa arquitetura principalmente a aplicações web, visto sua facilidade e flexibilidade de interação e visualização de dados, além disso a arquitetura MVC trás alguns padrões já conhecidos como os:

   Essa foi a principal arquitetura aplicada no projeto Curumim, visto sua eficiência e simplicidade, e por fim trazendo um código mais manutenível [2].

API

  API pode ser definida como um conjunto de protocolos e definições usados na integração e no desenvolvimento de softwares de aplicações, permitindo que uma solução ou serviço se comunique com outros produtos e serviços sem haver a necessidade de saber como eles foram implementados, simplificando assim o desenvolvimento de aplicações.
  No projeto Curumim o objetivo da divisão em camadas é possibilitar a reutilização da solução para diversas interfaces. Especificamente no back-end da aplicação a estrutura foi dividida em três componentes principais:

  • Models: Assim como explicado no item anterior, tem a responsabilidade de encapsular os estados da aplicação;
  • Controllers: Que realiza a ponte entre as Model e o cliente que consome a API;
  • Middlewares: Que são representados por uma pipeline de processamentos, com funções pré-definidas que são handles, units e filters;
  • Utils: Que auxilia a implementação dos padrões de projetos provendo interfaces e classes mais complementares.

  O diagrama de componentes ilustra bem as camadas e subcamadas da aplicação. Já para um melhor entendimento de cada subcamada se faz necessário uma análise do diagrama de classes o qual mostra com mais detalhes os métodos e as relações entre as classes contidas nas camadas de Model e Controller.

Visão de Dados

  Enquanto a visão lógica descreve como o sistema é estruturado, a visão de dados vem com o objetivo de se tratar de uma especialização nessa mesma visão lógica. A ideia principal é que essa visão seja utilizada se a persistência for um aspecto realmente significativo do sistema e se a conversão do modelo de design — para o modelo de dados — não for feita automaticamente pelos mecanimos de persistência. É possível considerar diversas visões, mas nem todas são relevantes, e a visão de dados muitas vezes é considerada uma dessas opcionais.

  Tratamos dessa visão quando o sistema tem camadas de persistência, visto que também ela contém um detalhamento do banco de dados. Um exemplo utilizado pelo projeto Curumim é o modelo conceitual (MER), o Modelo de Entidade-Relacionamento. Um outro que podemos utilizar como referência nessa visão de dados, é justamente o DER, o diagrama de Entidade-Relacionamento, que aborda uma forma de representar graficamente a modelagem do banco de dados. A figura abaixo representa o DER Conceitual.

DER

Figura 06: Diagrama Conceitual - DER

  Nota-se também que podemos citar o Diagrama Lógico ao entendê-lo como uma descrição de um banco de dados, se diferenciando do DER por ter um nível de abstração menor.

  Por fim, parte dessa persistência se encaixa no nosso projeto no Front-End quando o usuário, após o login, fica com acesso contínuo às suas funções. Para detalhar mais, basicamente um "LocalStorage" é acionado, afim de conseguir identificar um "token", que é uma identificação individual dos usuários. Caso esse "token" seja identificado e realmente exista, a aplicação apresentará uma tela ao usuário, caso não, o usuário é redirecionado para a tela de Login. Nesse caso, a persistência é um aspecto realmente significativo.

Tamanho e Desempenho

  Levando em conta seus repositórios, ambos juntos dão menos que 1GB, sendo que não é necessária a instalação de nenhum outro programa para seu funcionamento.   Sobre o desempenho da aplicação, para que seja possível seu funcionamento, é necessário conexão com a internet e por ser uma PWA, a opção de dispositivo é flexível, podendo ser um dispositivo mobile ou um computador. Além disso, a aplicação deve suportar muitas conexões simultâneas, por se tratar de uma plataforma que deve ser usada diariamente por um grupo de pessoas.

Qualidade

  A arquitetura adotada pelo grupo para construção da aplicação utiliza o padrão MVC, possibilitando a divisão dos principais componentes do projeto em camadas e subcamadas bem definidas, conferindo uma maior organização ao projeto e facilitando o desenvolvimento pelos diferentes integrantes do grupo. Foram seguidos alguns padrões GRASP como o Controlador, o Invenção pura e o Polimorfismo. Para a manutenção, portabilidade e futuras features foram utilizados padrões criacionais entre eles o Factory Method, o Abstract Factory e o Singleton. Além de serem seguidos alguns padrões comportamentais capazes de trazer confiabilidade tais como o Command, o Iterator e o Observer.

Critérios Descrição
Portabilidade Em relação a portabilidade o projeto foi baseado em divisões entre o Front-end e o Back-end, sendo o Back-end nossa API, onde se localizar as principais features, pensando nesse modelo, qualquer outra stack pode consumir essa API, assim garantindo a portabilidade para vários Front-end diferentes.
Segurança Na aplicação da API do Curumim foram adicionados alguns gatilhos que melhoram nossa segurança, principalmente no banco de dados, como a biblioteca bcrypt, além disso usamos um sistema de autenticação que usa token para verificações, usando o JWT.
Usabilidade Para a aplicação Curumim foi escolhido algumas stack bem utilizadas no mercado de trabalho para construção de aplicação web, focamos em uma linguagem de programação que foi o javascript com auxílios de bibliotecas e frameworks.
Eficiência Utilizamos padrões de projeto principalmente na API resolvendo um problema de design existente e a escolha por WebApp permite uma fácil execução por parte dos usuários.
Manutenibilidade Foram utilizadas ferramentas populares no mercado o que tanto facilitou no desenvolvimento do projeto quanto poderá facilitar futuras manutenções uma vez que existe uma grande comunidade de desenvolvedores, além de como já citado terem sido empregados padrões de projeto que facilitam por terem caracteristicas como o alto desacoplamento.

  Para ter uma melhor visão dos principais requisitos não funcionais do projeto tem os documentos NFR-FRAMEWORK e a Especificação Suplementar.

Bibliografia

Versionamento

Versão Data Modificação Autor
1.0 29/09/2021 Abertura do documento e inclusão da introdução Daniel Porto
1.1 02/10/2021 Criando tópico de visão de implementação Francisco Ferreira e Nilo Mendonça
1.2 03/10/2021 Criação da estrutura Visão Lógica Bruno Félix e Edson Soares
1.3 04/10/2021 Adição da Visão de Processos João Pedro, Enzo Gabriel
1.4 05/10/2021 Argumentação da Visão Lógica (Intro/backend) Bruno Félix e Edson Soares
1.5 05/10/2021 Inserção do tópico Front End da Visão Lógica Bruno Félix
1.6 05/10/2021 Adição da visão dos casos de uso Mateus O. Patrício e Gabriel Bonifácio
1.7 08/10/2021 Ajustes das visões de casos de uso, lógica, de processos e de implementação Daniel Porto
1.8 10/10/2021 Criando tópico de qualidade Francisco Ferreira e Nilo Mendonça
1.9 14/10/2021 Representação da arquitetura: Backend, Banco de Dados, Metas e Restrições Edson Soares
2.0 14/10/2021 Representação da arquitetura: Frontend Bruno Félix
2.1 14/10/2021 Revisão do tópico de qualidade Daniel Porto, Mateus O. Patrício e Gabriel Bonifácio
2.2 14/10/2021 Criação do tópico Visão de Dados Mateus O. Patrício e Gabriel Bonifácio
2.3 14/10/2021 Adição da visão de implantação e atualização do diagrama de pacotes Daniel Porto
2.4 15/10/2021 Criação do tamanho e desempenho João Pedro, Enzo Gabriel