Skip to content

Latest commit

 

History

History
197 lines (153 loc) · 17.2 KB

doc-arq.md

File metadata and controls

197 lines (153 loc) · 17.2 KB

Taskiano: Projeto Arquitetural do Software


Criado a partir de: Processo BSI - Projeto Arquitetural


Sumário

1. Descrição

Neste documento é abordado a arquitetura da plataforma e suas peculiaridades, tecnologias, decisões de design, implantação, entre outros. Através deste, objetivo atendido é a apresentação do sistema ser realizada de forma que seja possível compreender os aspectos gerais das funcionalidades internas do projeto e suas respectivas finalidades.

1.1. Histórico de revisões

Data Versão Descrição Autor
05/07/2021 1.0 Documento Inicial Zaú Júlio
05/07/2021 1.1 Organização da estrutura e adição de index Zaú Júlio
05/07/2021 2.0 Adição da descrição das tecnologias Zaú Júlio
06/07/2021 3.0 Adição da imagem e descrição da arquitetura Zaú Júlio
06/07/2021 4.0 Adição da descrição do documento Zaú Júlio
06/07/2021 5.0 Conclusão do tópico de Mecanismos arquiteturais Zaú Júlio
06/07/2021 6.0 Adição do tópico de Decisões de Design Zaú Júlio
14/07/2021 7.0 Adição da imagem do diagrama UML de componentes Wanessa Bezerra
14/07/2021 8.0 Adição da descrição dos componentes Wanessa Bezerra

2. Visão Geral

A arquitetura de microserviços empregada nesse projeto está ilustada na Fiura 1, logo abaixo. O núcleo arquitetural é a camada de interface gráfica com usuário, implementada em Javascript e Typescript com Next.js/React e hospedada na Vercel. Esta camada da aplicação comunica-se diretamente com o serviços do Firebase, Authentication e Storage, e com a camada de controle de entidades.

Esta camada por sua vez é implementada em Python através do meta-framework Django REST e hospedada no Heroku, em conjunto com o banco de dados relacional MariaDB. A aplicação de controle das entidades também está estreitamente conectada ao serviço de autenticação do Google Firebase. A conexão com o Firebase Authentication fornece mecanismos de autenticação e autorização a aplicação, garantindo a segurança e confiabilidade necessárias para a plataforma.

Modelo Entidade-Relacionamento

Figura 1. Imagem que representa a visão geral no documento.

3. Requisitos Não Funcionais

Requisitos não-funcionais: foi elaborada uma lista de requisitos não funcionais que fazem parte do sistema, descrevendo cada requisito, mostrando sua finalidade e funcionamento para uma boa experiência do usuário final.

RequitosDescrição
RNF001
Design

1. O desing do sistema deve ser intuivo e com menus bem organizados em diferentes níveis.

RNF002 Portabilidade

1. O software deve ser responsivo e projetado LTS(long-term support), para que tenha suporte por um período de tempo maior que o normal e futuramente dar suporte a plataforma mobile.

RNF003 Interoperabilidade

1. O software deve ser desenvolvido com os frameworks Django e NextJs com banco de dados MariaDB server e firebase para autenticação.

RNF004
Segurança

1. O software deve possuir autenticação social para garantir a integridade dos dados de usuário.

4. Mecanismos arquiteturais

A seguir está listado os principais mecanismos arquiteturais presentes no sistema, os mecanismos de análise, design e implementação. O intuito desta etapa é verificar e garantir que todas as preocupações técnicas relativas à arquitetura do sistema tenham sido capturadas.

Mecanismo de Análise Mecanismo de Design Mecanismo de Implementação
Persistência Banco de dados relacional MariaDB Server
Autenticação Authentication as service Google Firebase Authentication
Autenticação Social is human Authentication as service Google Firebase Authentication
Autorização Tokens de autenticação JWT
Interface interativa 3º grau Drag-and-drop React(react-beautiful-dnd)
Notificações in browser Toasts React(react-hot-toast)
Integração com sistemas legados (Cobrança) Interface utilizando XML em serviço e arquivo texto. Web Service e System.IO
Front-End Interface gráfica de usuário. Next.js/React.
Back-End Interface de controle de dados. Django/Django-REST-framework.
Host Disponibilização da plataforma. Vercel, Heroku, Google Firebase

4.1. Tecnologias

A seguir descrevemos brevemente as principais tecnologias empregadas no desenvolvimento desta aplicação, suas funcionalidades e o papel que desempenham.

Tecnologias Descrição
Typescript O Typescript é um superset criado pela Microsoft que adiciona, principalmente, tipagem ao Javascript. A agregação de tipagem adiciona mais segurança ao código ao oferecer um error handler para controle de tipos, o que consequentemente auxilia o desenvolvedor a criar soluções para o tratamento de exceções.
Reactjs React é uma biblioteca de criação de componentes interativos, criada pelo Facebook, com foco na performance e produtividade. Utilizada para manipular a DOM, estados e contexto encapsulados. Através do princípio de componentes a crescente atomicidade da aplicação auxilia no controle de falhas e consequentemente no aumento da confiabilidade da aplicação.
Next.js O Next.js é um framework construído pela Vercel que envolve o React e agrega diversos recursos como SSR, SSG, otimização de imagens, roteamento, entre vários outros. Com o Next podemos reduzir a quantidade de código JS/TS empregado diretamente na página, expondo assim, cada vez menos a aplicação.
MariaDB O MariaDB Server é um banco de dados relacional SQL, de código aberto, construído a partir de um fork do MySQL. O MariaDB oferece suporte a JSON, versionamento de tabelas, integração com a Oracle, além de todas as demais funcionalidades básicas de um banco de dados.
Firebase: Storage O Firebase Storage é um storage as service desenvolvido pelo Google, com alta escalabilidade, segurança rígida e integrada ao Firebase Authentication. O serviço oferece storage para objetos independente do formato, áudio, vídeo, imagens, etc. O serviço é integrado ao SDK do Firebase, o que facilita a construção e manipulação da aplicação enquanto garante sua segurança.
Firebase: Authentication O Firebase Authentication, desenvolvido pelo Google, oferece back-end as service para autenticação e autorização de maneira simples e estreitamente integrado a outros serviços do Google. Assim como o Firebase Storage ele também tira proveito do SDK e da segurança fornecida fornecida pelo seu uso.
Django Django é um framework construído em Python de alto nível de desenvolvimento rápido, design limpo e pragmático. O Django possui alta escalabilidade e vários recursos de segurança, como suporte embutido a autenticação e proteção contra sql injection.
Django REST Framework O padrão REST empregado nesse meta-framework possui os preceitos empregados no desenvolvimento desta aplicação, além de contar com a alta escalabilidade oferecida pelo Django, também emprega ORM e integrações de autenticação, como python-social-auth.

5. Decisões de Design

5.1. Da arquitetura

A escolha da arquitetura foi ponderada sobre a experiência da equipe com as tecnologias, metodologias e designs. Dentre as opções estavam arquitetura Monolítica, Microkernel, Camadas e Microserviços.

A arquitetura monolítica foi descartada devido a necessidade da utilização de serviços externos e do tempo necessário para implementação. A arquitetura de Microkernel foi considerada de integração complexa e devido a falta de experiência da equipe, foi descartada. A arquitetura em camadas fornece uma boa integração com testes é possível descentralização, o que auxilia na escalabilidade da aplicação, horizontalmente e verticalmente. Contudo, a possibilidade de integração com múltiplos serviços através do Google Firebase, para lidar com funcionalidades como Autenticação e Autorização e Cloud Storage, outra arquitetura proposta foi selecionada.

A arquitetura selecionada, ponderando sobre o ambiente proposto para a plataforma, foi de Microsserviços. Entretanto, qualquer uma das demais arquiteturas poderiam ser empregadas sem grandes problemas. A arquitetura de Microservices foi selecionada por oferecer as seguintes vantagens:

  • Descentralização
  • Alta escalabilidade
  • Implementação fracionária
  • Estrutura modular
  • Módulos independentes
  • Fácil Integrabilidade
  • Experiência da equipe

Sendo assim a arquitetura do sistema foi dividida em módulos de Front-End, com Next.js/React, Back-End, com a Aplicação REST e o banco de dados MariaDB e por fim, uma camada de acesso a serviços do Google Firebase no Front-End (Autenticação e Storage) e no Back-End (Autorização). O uso da arquitetura REST se deu devido a baixa complexidade de implementação, fácil utilização e alta experiência da equipe projetando e implementando este modelo.

6. Validação com Casos de Teste

Nesta fase selecionar User Stories com cenários escolhidos para a validação da arquitetura apresentada. Casos de uso, backlog, requisitos de usuários ou qualquer outro nome que represente os itens relevantes para o funcionamento do sistema final, o intuito é exercitar e testar os principais aspectos de risco da arquitetura.

Exemplo:

User StoryMotivos da escolha e descrição
US-003
Manter projeto

Este conjunto de funcionalidades devem ser testados, pois implicam na experiência que o usuário virá a ter com a criação e administração de seus projetos.

1. Criar projetos de tarefas
Deve ser verificado se o projeto tem um nome válido, se o projeto tem uma data de encerramento correta e se existe ou não uma descrição.
2. Excluir Projetos de Tarefas
Deve ser feita uma busca para saber se o projeto a ser excluído existe e está ativo.
3. Alterar Projetos de Tarefas
Deve ser validados todos os campos que estão sucetíveis a mudanças, validações de nome e quantidade de caracteres.
4. Consultar Projetos de Tarefas
Dever ser testado o campo de entrada para saber se o está retornando os dados solicitados.
5. Colocar Prioridades em Tarefas ou Projetos
Realizar apenas um teste de unidade simples para dar prioridade ao projeto criado.
6. Arquivar Projetos de Tarefas
Apenas um teste de unidade simples.

7. Componentes

Ilustração do diagrama de componentes do Taskiano na figura 2 e o detalhamento das responsabilidades de cada componente na tabela a seguir.

Modelo Entidade-Relacionamento

Figure 2. Representação gráfica com diagrama UML para representar os componentes.

Componente Descrição
User O User é responsável por armazena somente informações cruciais para a descrição do agente no sistema, além disso, possui o Score para definir a experiência do usuário utilizando o sistema e atráves do email podemos entrar em contato e enviar notificações.
Project O Project é responsável por agrupar tarefas com uma finalidade em comum, para que o usuário possa dividir em grupos menores suas pendências e objetivos, e para que possa encontrar mais facilmente tarefas correlacionadas.
Task A Task têm uma estrutura maior, ela é responsável por armazena o conteúdo da anotação, podendo conter links, tabelas e afins. Task também contém a data de criação, conclusão e o prazo para conclusão, além de possuir a atribuição de prioridade a tarefa que está e execução.
Reminder Reminder é responsável pelas notificações para o usuário, seja através de alertas no navegador ou e-mails.

8. Implantação

Diagrama de Implantação

Figure 3. Representação gráfica da fase de implantação.

9. Referências

(coloque aqui, artigos, livros e sites utilizados e citados no documento)