Home	Escopo e Cronograma	Processo	Design/Mockups	Configuração	Arquitetura	Código	BD	Qualidade	Utilização

Arquitetura do Sistema

Descrição

Esta seção irá abordar a arquitetura selecionada para o Backend e Frontend explicando os motivos das escolhas das tecnologias utilizadas junto ao funcionamento da aplicação.

Sumário

• Arquitetura do Sistema
  • Descrição
  • Sumário
  • Tecnologias
    • Flutter
    • Firebase
    • Integração
  • Diagrama de Comunicação
  • Padrão Arquitetural Front-end
    • Módulos do Sistema
  • Design System
    • Estrutura
    • Features
    • Shared

Tecnologias

O time realizou um debate para mapear os conhecimentos tecnológicos de todos os integrantes da equipe para facilitar e nortear as decisões sobre as tecnologirias a a serem usadas no desenvolvimento da aplicação levando em consideração o tempo de entrega, conhecimentos existentes de cada integrante da equipe e conhecimentos a serem adquiridos durante o desenvolvimento. Após realizar esse levantamento, optamos por trabalhar com as tecnologias citas abaixo:

Flutter

O Flutter é um kit de desenvolvimento de interface de usuário(front-end), de código aberto, criado pela empresa Google em 2015, baseado na linguagem de programação Dart, que possibilita a criação de aplicativos compilados nativamente, para os sistemas operacionais Android, iOS, Windows, Mac, Linux e Fuchsia e Web.

A escolha do flutter foi baseada em quatro pontos:

• Conhecimento prévio de alguns membros da equipe referente a tecnologia;
• Necessidade por parte dos stakeholders para aplicativos nativos para o plataforma IPad.
• Curva de aprendizagem mais baixa em relação a tecnologias semelhantes.
• Integração perfeita com o Firebase, pois ambas tecnologias são da Google.

Firebase

Firebase é uma plataforma desenvolvida pelo Google para a criação de aplicativos móveis e da web de uma forma efetiva, rápida e simples. Ele contém diversas funcionalidades já desenvolvidas, incluindo dois bancos de dados integrados, e possui um cota free para utilização, sendo perfeito para desenvolvimento back-end de MVPs, POCs e soluções em estágio inicial.

A escolha do Firebase foi baseada em cinco motivos:

• Perfeita integração com o Flutter;
• Cota free suficiente para a aplicação;
• Banco de dados integrado - FireStore;
• Autenticação de usuário já desenvolvido, sendo necessário apenas chamar no Flutter;
• Diversos recursos disponíveis já desenvolvidos;

Integração

Como mencionado anteriormente, ambas tecnologias escolhidas são mantidas pela Google e possui uma integração perfeita. Desse modo, conseguimos desenvolver todo o projeto com mais facilidade e velocidade. Para realizar a integração dentro do Flutter com o Firebase foi necessário importas as dependências do Firebase no Flutter da seguinte forma no arquivo pubspec.yaml:

Para consulta, clone o projeto, abra o arquivo pubspec.yaml e vá até a linha 38 do arquivo.

Após, na classe main.dart na pasta lib do projeto, basta instancia-lo na aplicação com abaixo:

Para consulta, clone o projeto, abra o arquivo main.dart e vá até a linha 15 do arquivo.

Diagrama de Comunicação

Abaixo está representado graficamente como funciona a comunicação do front-end (Flutter) com o back-end (Firebase)

Padrão Arquitetural Front-end

Para o projeto em questão, foi definida uma arquitetura chamada de MVVM para desenvolvimento com o Flutter, utilizando apenas as chamadas ao nosso Firebase, visto que ele já possui um back-end pronto.

Módulos do Sistema:

A Arquitetura MVVM para projetos mobile é um padrão arquitetural que desacopla o que realmente é interface do usuário com o que é parte lógica. Esse padrão é definido em três módulos integradas:

Model é a camada que representam os dados de domínio do sistema, sendo completamente independente das outras duas camadas e que muitas vezes possui lógica acoplada.

View é a camada que representa a parte visual da aplicação, ou seja, a parte que realiza a interação com o usuário do sistema, ela, como a camada de Model, é totalmente independente das outras duas camadas, sendo alimentada, quando necessária pela camada ViewModel.

ViewModel é a camada que representa a parte lógica da aplicação, sendo ela responsável por intermediar a View e a Model. Ela é responsável por fazer as chamadas ao back-end, fazer mapeamento dos dados vindos dele para o Model e alimentar a View e vice-versa, receber dados vindos da View mapear para um Model e após fazer a integração com o Firebase.

Para o projeto em contexto utilizamos nomenclaturas diferentes que representam essas camadas dentro do Flutter, com exceção da Model.

A View é traduzida como nome da feature mais o sufixo de screen, que, como o nome já diz, representa uma tela daquela feature. Exemplo.: HomeScreen.

A ViewModel foi modificada em duas camadas diferentes, uma camada que realiza a conexão direta com o backend e uma camada de lógica da aplicação, que mapeia os objetos da Model para a View e da View para o Model. A camada que realiza a conexão com o Firebase é traduzida pelo nome da feature seguida do sufixo repositor, como por exemplo, LoginRepository, já a camada que faz a intermediação entre a View e a Model é traduzida com o nome da feature e o sufixo controller pois ela representa o controle e a integração entre essas outras duas camadas. Exemplo.: StudentListController.

Para facilitar o gerenciamento de estados da aplicação, utilizamos dentro do projeto o Provider. O Provider no Flutter representa um estado global, onde ele provê para todos os Widgets (Componentes do Flutter) o conteúdo armazenado nele, centralizando assim todo o estado da aplicação.

Abaixo podemos ver visualmente através de um diagrama como ficou a implementação do padrão arquitetural do Flutter:

Design System

O design system apresenta formas facilitadas de gerenciar e implementar o padrão arquitetural descrita acima.

Estrutura

O projeto foi estruturado com duas pastas principais, Features e Shared. No inicio do projeto encontramos a classe Main, que inicializa toda a aplicação e também a classe Routes, onde estão armazenadas todas as rotas do sistema:

Features

As features representam todas as funcionalidades do sistema.

Cada feature possui conteúdos internos (Components por exemplo) que são apenas relevantes a ela e não a toda a aplicação.

Shared

A Pasta Shared contém todos os arquivos compartilhados do sistema, onde todos os componentes, repositórios, telas, controladores e estados podem usufruir.

Também, contém arquivos relevantes que permitam centralizar informações compartilhadas como por exemplo:

• Assets: Contém todos as imagens/audios/gifs que serão reutilizáveis ao longo do projeto.

• Components: Contém todos os componentes que serão reutilizáveis ao longo do projeto. (ex: Botão principal)

• Models: Contém todos os Models que serão comuns a aplicação. (ex: GradeModel)

• State: Contém todos estados que são comuns e compartilhados na aplicação. (ex: GradeController);

• 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.

• Constants: 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.

• Styles: Definição das estilos utilizadas ao longo do projeto. Esse arquivo tem como objetivo centralizar os estilos do projeto, provendo assim, um maior controle quando algum estilo for alterada, no qual reflete em todos os items que utilizam aquela fonte.