|[Home](home)|[Cronograma](cronograma)|[Sprints](sprints)|[Requisitos](requisitos)|[Arquitetura](arquitetura)|[Configuração](configuracao)|[Mockups](mockups)|[Telas](telas_desenvolvidas)|[Banco de Dados](banco_dados)|[Gerência de Projeto](gp)|[Horários Disponíveis](horarios)|
|---|---|---|---|---|---|---|---|---|---|---|

# Página da Arquitetura do Sistema


Esta é a página em que irão constar todas as informações da Arquitetura do Projeto CarMy.


# Segurança

* Para garantir a segurança da aplicação utilizamos JWT (JSON *Web Token*) para fazer a autenticação do usuário.
* O JSON *Web Token*  é um padrão da Internet para criar *tokens* de acesso baseados em JSON. 
* Por exemplo, um servidor pode gerar um *token* com a declaração "logado como administrador" e fornecê-lo a um cliente. 
* O cliente pode então usar esse *token* para provar que está logado como administrador. 
* Os *tokens* são assinados pela chave privada de uma parte (geralmente do servidor), de modo que ambas as partes (a outra já, por algum meio adequado e confiável, de posse da chave pública correspondente) possam verificar se o *token* é legítimo. 
* Os *tokens* são projetados para serem compactos, seguros para URLs, e utilizáveis ​​especialmente em um contexto de logon único (SSO) no navegador da web .
* As declarações JWT geralmente podem ser usadas para transmitir a identidade de usuários autenticados entre um provedor de identidade e um provedor de serviços ou qualquer outro tipo de declaração conforme exigido pelos processos de negócios.


# Rotas do Backend
Disponível abaixo o arquivo contendo as rotas do *backend*.

* [CarMy.postman_collection.json](/uploads/f822d5e15bda4b4f9e46ee7be79ff0dc/CarMy.postman_collection.json)



# Diagrama de Deploy:

![Deployment_DiagramCarmy](http://tools.ages.pucrs.br/Carmy/wiki/blob/master/05.%20Arquitetura/Diagrama%20de%20Deploy.png)



# Análise dos principios SOLID

S — Single Responsiblity Principle (Princípio da responsabilidade única)

O — Open-Closed Principle (Princípio Aberto-Fechado)

L — Liskov Substitution Principle (Princípio da substituição de Liskov)

I — Interface Segregation Principle (Princípio da Segregação da Interface)

D — Dependency Inversion Principle (Princípio da inversão da dependência)

### SRP — Single Responsibility Principle:

Princípio da Responsabilidade Única — Uma classe deve ter um, e somente um, motivo para mudar.
Esse princípio declara que uma classe deve ser especializada em um único assunto e possuir apenas uma responsabilidade dentro do software, ou seja, a classe deve ter uma única tarefa ou ação para executar.

**A violação do Single Responsibility Principle pode gerar alguns problemas, sendo eles:**

* Falta de coesão — uma classe não deve assumir responsabilidades que não são suas;

* Alto acoplamento — Mais responsabilidades geram um maior nível de dependências, deixando o sistema engessado e frágil para alterações;

* Dificuldades na implementação de testes automatizados — É difícil de “mockar” esse tipo de classe;

* Dificuldades para reaproveitar o código;

### OCP — Open-Closed Principle:

Princípio Aberto-Fechado — Objetos ou entidades devem estar abertos para extensão, mas fechados para modificação, ou seja, quando novos comportamentos e recursos precisam ser adicionados no software, devemos estender e não alterar o código fonte original.

### LSP— Liskov Substitution Principle:

Princípio da substituição de Liskov — Uma classe derivada deve ser substituível por sua classe base.

O princípio da substituição de Liskov foi introduzido por Barbara Liskov em sua conferência “Data abstraction” em 1987. A definição formal de Liskov diz que:

>>>
Se para cada objeto o1 do tipo S há um objeto o2 do tipo T de forma que, para todos os programas P definidos em termos de T, o comportamento de P é inalterado quando o1 é substituído por o2 então S é um subtipo de T
>>>

**Exemplos de violação do LSP:**

* Sobrescrever/implementar um método que não faz nada;

* Lançar uma exceção inesperada;

* Retornar valores de tipos diferentes da classe base;

### ISP — Interface Segregation Principle:

Princípio da Segregação da Interface — Uma classe não deve ser forçada a implementar interfaces e métodos que não irão utilizar.

Esse princípio basicamente diz que é melhor criar interfaces mais específicas ao invés de termos uma única interface genérica.

### DIP — Dependency Inversion Principle:

Princípio da Inversão de Dependência — Dependa de abstrações e não de implementações.

De acordo com Uncle Bob, esse princípio pode ser definido da seguinte forma:

>>>
1. Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender da abstração.
>>>

>>>
2. Abstrações não devem depender de detalhes. Detalhes devem depender de abstrações.
>>>

---

# Diagrama de Pacotes 
* **Back-End**
![diagramaBackEnd](/uploads/e58630bc7a6679164e3c08c819ea3d90/diagramaBackEnd.png)

* **Front-End**
![diagramaFrontEnd](/uploads/1767fccfb1bba72dc993b0258bd87280/diagramaFrontEnd.png)