Documento de Arquitetura
| Data | Versão | Descrição |
|---|---|---|
| 28/08/2023 | 0.1 | Criação do documento, Modelo e Representação |
| 02/09/2023 | 0.2 | Atualização do diagrama de pacotes e detalhamento dos componentes |
| 05/09/2023 | 1 | Adicionado o diagrama de classes inicial do projeto |
| 16/11/2023 | 2 | Adicionado o diagrama de classes completo e o diagrama de casos de uso do projeto |
1. Introdução
1.1. Objetivo
Este documento tem como finalidade fornecer uma visão arquitetural do sistema Mindhub, assim como demonstrar as decisões arquiteturais tomadas no desenvolvimento do projeto.
2. Modelo Arquitetural
O sistema é dividido em uma aplicação mobile android (Front end) e uma API RESTful (Back end). Além disso, são usados serviços de terceiros para notificações (Firebase Cloud Messaging) e geolocalização (Google Maps API).
2.1. Back End
O back end utilizará o modelo de arquitetura em camadas, no qual a aplicação é separada em módulos de acordo com as responsabilidades de cada componente, e a troca de mensagens entre esses módulos é feita somente em uma direção ou por meio de inversão de dependência. As camadas da aplicação, da mais externa a mas interna, serão: Controllers, Providers e Entities
2.1.1. Controllers
Os controllers formam a camada mais externa da API, e são responsáveis por tratar as requisições recebidas e retornar uma reposta para elas. O mecanismo de rotas define qual controlador está associado a cada recurso/serviço disponível no servidor.
2.1.2. Providers
Os providers são dependências injetáveis nos controladores, podendo assumir responsabilidades baseadas no seu tipo. Os tipos de providers existentes na aplicação serão Services (execução de serviços e casos de uso) e Repositories (Gerenciamento de entidades).
2.1.3. Entities
As entidades são representações dos objetos do modelo de negócio e estão diretamente associadas à representação do banco de dados. As entidades são acessadas por meio de repositórios e possuem métodos para modificação do banco de dados.
2.2. Front End
O front end utilizará o modelo MVVM (Model, View, View-Model), que é o recomendado pela Google para o desenvolvimento de aplicações. Nesse modelo, a camada Model armazena os dados locais e acessa dados remotos, enquanto a camada de View-Model faz uma ligação entra a camada de View e os dados do modelo. Uma camada intermediária de serviços (Services) também é utilizada.
2.2.1. View
A view é a camada mais externa da aplicação, sendo responsável por apresentar os dados e lidar com a interação com usuário. É composta por Activities e Composables, ambos componentes nativos do Android para composição visual das interfaces.
2.2.2. Model
A camada model representa o modelo de dados do negócio, tanto local por meio dos repositórios, quanto remoto por meio da API.
2.2.3. View-Model
A camada view-model faz uma ligação entre os dados do modelo com a interface gráfica, permitindo a sincronização entre essas duas camadas. Também é responsável pelo tratamento e transformações das entradas do usuário e dos dados do modelo.
2.2.4. Services
Essa camada serve como um conjunto de utilitários para o desenvolvimento da aplicação, oferecendo a execução de serviços.
2.3. Serviços de Terceiros
Os serviços de terceiros são utilizados apenas por meio de interfaces disponíveis pelos seus desenvolvedores. Esses serviços são: Firebase Cloud Messaging e o Google Maps API.
2.3.1. Firebase Cloud Messaging
O FCM é um serviço oferecido pela Google para o gerenciamento de notificações para aplicações Android. Permite o envio e leitura em tempo real de notificações, com baixo custo de bateria para os aparelhos conectados.
2.3.2. Google Maps API
O Google Maps API é uma API fornecida pelo Google que oferece serviços de geolocalização, possibilitando a visualização e interação com pontos geográficos pela aplicação.
3. Representação Arquitetural
3.1. Diagrama de Pacotes UML
O diagrama acima demonstra a organização das três partes do sistema.
4. Modelo de Dados
4.1. Modelo relacional do banco de dados
O diagrama acima representa as entidades do sistema e suas relações.
5. Modelagem UML
5.1. Diagrama de casos de uso
O diagrama acima representa os casos de usos do sistema. Para uma melhor visualização, abra a imagem aqui
5.2. Diagrama de classes
O diagrama acima representa as classes implementadas do sistema e suas relações. Para uma melhor visualização, abra a imagem aqui.