Criado a partir de: Processo BSI - Projeto Arquitetural
- 1. Descrição
- 2. Visão Geral
- 3. Requisitos Não Funcionais
- 4. Mecanismos arquiteturais
- 5. Decisões de Design
- 6. Validação com Casos de Teste
- 7. Componentes
- 8. Implantação
- 9. Referências
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.
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 |
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.
Figura 1. Imagem que representa a visão geral no documento.
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.
Requitos | Descriçã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. |
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 |
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. |
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.
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 Story | Motivos 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. |
Ilustração do diagrama de componentes do Taskiano na figura 2 e o detalhamento das responsabilidades de cada componente na tabela a seguir.
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. |
Figure 3. Representação gráfica da fase de implantação.
(coloque aqui, artigos, livros e sites utilizados e citados no documento)