Página da Arquitetura do Sistema

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

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:

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

• Front-End

• Segurança

• Rotas de Backend (Arquitetura funcional)

• Objects – Backend API

• Methods – Backend API

• Arquitetura Não Funcional)

(Arquitetura de software)

• Diagrama de Deploy
• Documentação sobre aplicação de Design do Projeto
• Code Review

Devem ser apresentados das seguintes formas:

• Imagens ou Gifs
• Diagramas ou Sistemas
• Descrições ou Textos explicativos