|
|[Home](home)|[Gerenciamento](gp)|[Banco de Dados](banco_dados)|[**Arquitetura**](arquitetura)|[Desenvolvimento](configuracao)
|
|
|[Home](home)|[Sprints](sprints)|[Requisitos](requisitos)|[Arquitetura](arquitetura)|[Configuração](configuracao)|[Mockups](mockups)|[Paleta](Paleta)|[Banco de Dados](banco_dados)|[Instalação](instalacao)|[GitFlow](GitFlow)|[Gerência de Projeto](gp)|[Horários Disponiveis](horarios)|[Retrospectivas](reviews)
|
|
|---|---|---|---|---|
|
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
### Definições de linguagem e bibliotecas
|
|
|
|
|
|
# Página da Arquitetura do Sistema
|
|
Pontos-chave:
|
|
|
|
|
|
Esta é a página onde irá ficar todas as informações da Arquitetura do seu projeto, Como:
|
|
* Questionário inicial para o time;
|
|
|
|
* Conhecimento geral do time em Flutter;
|
|
|
|
* Execelente compatibilidade entre Flutter e Firebase.
|
|
|
|
|
|
* Segurança
|
|
Escolhas:
|
|
* Rotas de Backend (Arquitetura
|
|
|
|
funcional)
|
|
|
|
* Objects – Backend API
|
|
|
|
* Methods – Backend API
|
|
|
|
* Arquitetura Não Funcional)
|
|
|
|
* Diagrama de Pacotes / Componentes
|
|
|
|
(Arquitetura de software)
|
|
|
|
* Diagrama de Deploy
|
|
|
|
* Documentação sobre aplicação de
|
|
|
|
Design do Projeto
|
|
|
|
* Análise dos principios SOLID
|
|
|
|
* Code Review
|
|
|
|
*
|
|
|
|
Devem ser apresentados das seguintes formas:
|
|
|
|
|
|
|
|
* Imagens ou Gifs
|
|
* Tecnologia: Flutter;
|
|
* Diagramas ou Sistemas
|
|
* Linguagem: Dart;
|
|
* Descrições ou Textos explicativos
|
|
* Frameworks: Firebase.
|
|
|
|
|
|
|
|
Antes de começar o desenvolvimento do projeto foi feito um questionário para o time para quantificar o conhecimento dos alunos em diversas tecnologias, frameworks e bancos de dados para determinar quais as tecnologias que seriam mais fáceis de acordo com o conhecimento geral da equipe.
|
|
|
|
|
|
|
|
O time optou por utilizar a tecnologia Flutter juntamente com a linguagem Dart para criação do aplicativo mobile devido a familiaridade de alguns integrantes do time com a tecnologia e pelo fato de que os stakeholders indicaram a necessidade de desenvolvimento de uma versão Android e uma versão iOS, cenário no qual o Flutter é uma ótima opção.
|
|
|
|
|
|
|
|
Para desenvolvimento do backend o time escolheu utilizar o framework Firebase devido a familiaridade de alguns integrantes com a framework e pelo fato de que o Firebase fornece diversos recursos prontos, como: Persistência, Autenticação e Notificações, recursos esses que atendem perfeitamente a demanda do projeto, tirando a complexidade do backend e trazendo o maior esforço da equipe para desenvolvimento das funcionalidades principais.
|
|
|
|
|
|
|
|
### Módulos do Sistema:
|
|
|
|
|
|
|
|
* **Model**: Camada onde ficam contidos as classes dos objetos que manipulamos ao longo do projeto. Normalmente são os objetos provindos do banco de dados.
|
|
|
|
* **View**: Parte visual da aplicação (telas), sua responsabilidade é exibir as informações para o usuário, chamar a camada de presenter para acessar algum dado e reagir as diferentes interações que o usuário pode exercer na tela (ex: toque de um botão).
|
|
|
|
* **Presenter**: Camada responsável por fazer a comunicação entre a view e as classes de serviços. A Presenter tem como responsabilidade fazer as chamadas das funções dos respositories, processar o retorno dos dados para mostrar apenas o que é necessário exibir e, por ultimo, tem a responsabilidade de chamar as funções da view para atualização da parte visual.
|
|
|
|
|
|
|
|
* **Repository**: Camada responsável por realizar a conexão com a API, sua função é fazer as chamadas para a API (através de métodos HTTP) e retornar sucesso/erro para a presenter controlar o que será apresentado.
|
|
|
|
|
|
|
|
* **Routes**: Classe responsável por ter uma referência para todas as rotas de navegação do app, facilitando assim a mudança entre as telas.
|
|
|
|
|
|
|
|
### Design System:
|
|
|
|
|
|
|
|
* **Components**: Contém todos os componentes que serão reutilizáveis ao longo do projeto. (ex: Botão principal)
|
|
|
|
|
|
|
|
* **App theme**: Nesse arquivo está contido a definição do theme exibido pelo aplicativo. Através desse arquivo é possível personalizar diversas configurações (cores principais, fontes e etc) que serão utilizados pelo app.
|
|
|
|
|
|
|
|
* **Colors**: Definição das cores utilizadas ao longo do projeto. Esse arquivo tem como objetivo centralizar as cores do projeto, provendo assim, um maior controle quando alguma cor for alterada, no qual reflete em todos os items que utilizam aquela cor.
|
|
|
|
|
|
|
|
* **Strings**: Valores String literais utilizados no projeto. Esse arquivo tem como objetivo centralizar a declaração das strings utilizadas no projeto, tornando assim mais fácil a manipulação dos valores e consequentemente evita o uso de literais dentro do código.
|
|
|
|
|
|
|
|
* **Font family**: Definição das fontes utilizadas ao longo do projeto. Esse arquivo tem como objetivo centralizar as fontes do projeto, provendo assim, um maior controle quando alguma fonte for alterada, no qual reflete em todos os items que utilizam aquela fonte.
|
|
|
|
|
|
|
|
### Diagrama do Sistema:
|
|
|
|
|
|
|
|
Maneira que as camadas do sistema se comunicam. Primeiramente, a camada de **View** tem acesso a camada de **Routes**, podendo assim, realizar a navegação para as outras views (telas). Dentro da camada de **View**, estará contida uma instância da classe **Presenter** e, através dela, serão feitas as chamadas das funções que irão manipular os dados e a interface estabelecida pela view (através dessa interface irá ser feita a comunicação para atualização da view). Já na camada de **Presenter** estará contida a instância do **Firebase** e toda lógica envolvida para realizar as chamadas.
|
|
|
|
|
|
# Arquitetura Frontend
|
|
# Arquitetura Frontend
|
|
|
|
|
|
Para desenvolvimento do projeto foi escolhido o padrão arquitetural MVP(Model View Presenter) como forma de organização e definição das responsabilidades de cada camada do programa. O padrão MVP foi escolhido por ser uma arquitetura com uma menor curva de aprendizado comparada a arquiteturas que dependem diretamente de conceitos de programação reativa. Além disso, o padrão arquitetural MVP possui uma boa modularização dos componentes e consequentemente uma melhor testabilidade do sistema. |
|
Para desenvolvimento do projeto foi escolhido o padrão arquitetural MVP(Model View Presenter) como forma de organização e definição das responsabilidades de cada camada do programa. O padrão MVP foi escolhido por ser uma arquitetura com uma menor curva de aprendizado comparada a arquiteturas que dependem diretamente de conceitos de programação reativa. Além disso, o padrão arquitetural MVP possui uma boa modularização dos componentes e consequentemente uma melhor testabilidade do sistema. |
|
|
|
\ No newline at end of file |