arquitetura

Home	Cronograma	Sprints	Requisitos	Arquitetura	Configuração	Mockups	Telas	Banco de Dados	Gerência de Projeto	Horários Disponíveis

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

Diagrama de Deploy:

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:

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

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

Diagrama de Pacotes

Back-End
Front-End