|[Home](home)|[Sprints](sprints)|[Requisitos](requisitos)|[Arquitetura](arquitetura)|[Configuração](configuracao)|[Mockups](mockups)|[Banco de Dados](banco_dados)|[Instalação](instalacao)|[Gerência de Projeto](gp)|[Horários Disponiveis](horarios)|[Boas Práticas](Boas Praticas)|[Git](git)|
|---|---|---|---|---|---|---|---|---|---|---|---|

# Diagrama de componentes

O Diagrama de componentes tem como objetivo apresentar uma ideia geral da estruturação dos componentes macro da aplicação - no caso, as telas do sistema -, mostrando como estão dispostos e com quais outros componentes interagem.

![](https://i.imgur.com/pt1EsAH.png)

Alguns pontos que necessitam atenção:

* A comunicação com o *Firebase* deve ser feita através dos *services*  **PlaceService**, **ContactsService**, **UsersService** e **AuthService**. Desta maneira, mantemos um ponto único de consumo de dados dentro da aplicação e facilitamos a manutenção no caso de erros.

* O sufixo **Model** é utilizado para denotar objetos que representam entidades no banco de dados. Estes objetos serão representados dentro do sistema por interfaces. As demais interfaces **que não representarem entidades do banco de dados** devem ser nomeadas da seguinte forma: **Nome da interface em PascalCase** + ```Interface```

* * Exemplo: `export interface PlaceFiltersInterface {}`

* Componentes oferecem ou requerem alguma interface para poder se conectar com outros componentes. No exemplo da imagem abaixo, o componente **ListPlaces** espera receber um objeto, com formato definido por uma interface, do componente **FilterPlace**.
![](https://i.imgur.com/MlMIc4N.png)

# Fluxogramas de uso da aplicação

O fluxo principal da aplicação é buscar por espaços, ver detalhes dos espaços e para alugar é preciso entrar em contato com o proprietário. O fluxograma abaixo exemplifica este fluxo principal.

![](https://i.imgur.com/WpNUYyt.png)

# Estruturação de testes