🚀 Engenharia de Software

O Raio-X da Matéria: Diagrama de Classes UML

(Mapeando a Anatomia e o Tecido Conectivo do Sistema)

👨‍🏫 Professor: Ricardo Pires
📚 Unidade IV

🏛️ O Alfa e o Ômega: O Diagrama de Classes

Se uma bomba atômica caísse no servidor da empresa e sobrasse apenas 1 diagrama da UML para os engenheiros recostruírem o Itaú ou o Nubank amanhã, este diagrama é o Diagrama de Classes.

O Diagrama de Caso de Uso mostra a “Intenção Humana” (O que o app faz).
O Diagrama de Classes abre o esqueleto e mostra a “Verdade Matemática Inflexível”.

Nenhuma linha de Java é codificada ou Tabela de Banco de Dados PostgreSql é concebida sem que as “Caixinhas” deste diagrama autorizem estruturalmente!

🧊 Trindade Geométrica: A Estrutura de uma Classe

Na geometria restrita da UML, uma Classe real corporativa nunca é uma bolota, ela é um Retângulo Austero dividido em exatos 3 andares:

 ┌──────────────────────────────────────────────┐
 │                  📦 Cliente                    │ ◄─ Andar 1 (NOME)
 ├──────────────────────────────────────────────┤
 │ - id_cliente : Integer                       │
 │ - cpf_hash : String                          │ ◄─ Andar 2 (ATRIBUTOS / DADOS)
 │ # limite_credito : Double = 0.00             │
 ├──────────────────────────────────────────────┤
 │ + aumentarLimite(valor: Double): Boolean     │ 
 │ - validarFraudeSerasa(): Boolean             │ ◄─ Andar 3 (MÉTODOS / VERBOS)
 └──────────────────────────────────────────────┘

(Notem os símbolos +, -, # denunciando visualmente o Encapsulamento de segurança!)

🤖 A Mágica do Dicionário (Exportação de Código)

A Ferramenta CASE (ex: Astah, Enterprise Architect) não é apenas para gerar fotos JPG para reunião. O Desenho da UML acima contém sintaxe estrita (id: Integer).

Quando o Arquiteto aperta o botão mágico de “Export via UML-To-Code” na ferramenta de modelagem, ela cospe esse código em milissegundos para o Backend trabalhar na IDE:

public class Cliente {
    private Integer id_cliente;
    private String cpf_hash;
    protected Double limite_credito = 0.00;
 
    public Boolean aumentarLimite(Double valor) { /* A equipe coda a lógica aqui */ }
    private Boolean validarFraudeSerasa() { /* Logica oculta */ }
}

🔀 A Teia Sistêmica: Multiplicidade

Classes reais isoladas são blocos de tijolo inertes no chão. Elas precisam de Associações Matemáticas.

Regras de Leitura Cardinais (De “mim” olhando para o “outro”): Sempre paramos na classe atual, e olhamos até a beirada encostar na outra, respondendo a pergunta existencial: “Quantos eu suporto?”

1 : Sou obrigado a ter exatamente Um daquele.
0..1 : Facultativo. Zero se não quiser, no máximo Um se quiser.
1..* : Obrigatório multiverso. Tenho que ter 1 fixo, mas aguento ilimitados.
* : Vale-tudo. De Zero a Infinito.

👩‍🏫 Oratória Prática: Analisando uma Seta Multipla

O Casamento Bancário (Banco vs Titular):

 ┌─────────┐                                      ┌───────────────┐
 │ Gerente │ 1 ------------------------- 0..* │ ContaBancaria │
 └─────────┘                                      └───────────────┘

Lendo fluente de forma natural para a Diretoria Comercial:

Ida do Sujeito: “1 Gerente do Santander Administra de Nenhuma até Infinitas Contas Bancárias (A carteira de clientes do cara).”
Volta Matemática: “Dado 1 registro exato da tabela ContaBancaria do João lá no banco de dados isolado… ele é obrigatoriamente tutorado fisicamente por Exatamente (1) Gerente CPF Responsável”.

💎 Agregação (O Todo e a Parte) - Diamante Vazio

Saímos das linhas comuns. Agora entraremos na Anatomia de objetos compostos (um sendo pai/dono e esmagando partes menores dentro da sua hierarquia).

Agregação (Diamante Vazio ♢): O Objeto “Todo” possui a “Parte”, contudo, NÃO É UMA RELAÇÃO LETAL. A parte inferior moraria feliz em outro canto se o objeto superior pegar fogo.
- UML Clássica: [ 🏢 Estádio SoccerCity ] ♢--------- [ ⚽ Bola de Ouro ].
- A Conclusão: A Bola de Ouro compõe o acervo daquele estádio (O Todo). Mas se um Míssil destruir e explodir a classe/Entidade “Estádio”, o registro da Entidade “Bola de Ouro” viaja no caminhão para existir e brilhar intacta no “Museu”! A bola sobrevive.

🖤 Composição Mortal (Diamante Preenchido ♦)

Composição (Diamante Preenchido ♦): “Dependência Existencial e Exclusiva”. A “Parte inferior” não faz o menor sentido abstrato se o “Todo” pai dezenraizar da Terra. É a morte cruzada instantânea em Banco de Dados (Cascade Delete).
- UML Letal: [ 🧾 Nota Fiscal N.555 ] ♦--------- [ 🛒 Item (Caneta no Carrinho) ].
- A Conclusão Arquitetural: O Item “Caneta azul” da compra especifica “Nota 555” pertence apenas ao corpo daquela nota. Se o gerente Financeiro Clicar em DELETAR NOTA N.555 do SGBD, o registro do filhote “Item Caneta Especifica” não deve boiar perdidamente na nuvem num vácuo galáctico inútil de lixo eletrônico. Ele deve morrer junto no Banco!

🗣️ QUIZ VERBAL: Diamante da Arquitetura Clássica

Pergunta Fria e Arquitetural: Você é Consultor Sênior dimensionando os servidores de Banco de Dados de um Mega-Hospital. Você desenha a classe central Quarto 201M e a classe mobiliária Cama Eletrônica UTI-Z7. Como a “Cama” está logicamente posicionada nas coordenadas 3D de dentro do “Quarto”, temos claramente um relacionamento “O Todo e a Parte”. Num dia de expurgo, o mestre de obras avisa que demoliu o Quarto 201M abrindo um buraco no chão, exigindo um DELETE SQL naquele registro local. Como o sistema lidará com a Cama se você usar Agregação ♢ ao invés de Composição ♦ na ligação dessas duas tabelas?

✅ RESPOSTA DO QUIZ

Se a equipe usar Agregação (Diamante Vazio ♢), a Cama sobrevive sorrindo ao apocalipse do quarto! 🛏️

Explicação Lógica: A Cama de 50 mil reais é Ativo de Patrimônio Imobilizado valioso, que não está soldada a moléculas de plutônio do cimento do Quarto. Sob a égide do diamante vazio, se o Hospital efetivar o .destroy() no objeto [Quarto_201_M], a Cama eletrônica meramente terá seu atributo de alocação flutuante, podendo ser atrelada futuramente num objeto emergente [Enfermaria_Central]. Se o Arquiteto usasse a Composição Fatal ♦, deletar o quarto deletaria no Banco do Patrimônio um equipamento caríssimo, destruindo a auditoria contábil do hospital!

📐 Matemática de Classes: CBO (Acoplamento)

CBO — Coupling Between Objects: Métrica que mede quantas outras classes uma classe depende.

$C B O_{c l a sse} = ∣ {c l a sses r e f er e n c ia d a s d i r e t am e n t e} ∣$

| CBO | Avaliação | ||----------| | $C B O \leq 5$ | ✅ Baixo acoplamento — fácil de testar e manter | | $5 < C B O \leq 10$ | ⚠️ Médio — atenção ao crescimento | | $C B O > 10$ | ❌ Alto acoplamento — fragilidade elevada |

Risco prático: Uma classe PedidoService com $C B O = 14$ significa que alterar qualquer uma das 14 classes que ela usa pode quebrá-la. Em microserviços, isso é um desastre de dependência.

🗣️ QUIZ VERBAL: Agregação ou Composição?

Cenário Logístico (iFood): Modele as seguintes situações:

Um Pedido possui vários ItemDoPedido (ex: X-Burguer + Fritas). Se o Pedido for cancelado e excluído do sistema, os Itens também devem ser excluídos.
Um Restaurante possui vários Prato no cardápio. Se um prato for removido do restaurante, o registro hierárquico do prato pode ser mantido para fins de histórico de vendas.

Para cada situação, escolha entre Agregação ♢ e Composição ♦ e justifique.

✅ RESPOSTA DO QUIZ FINAL

Situação 1 = Composição ♦ | Situação 2 = Agregação ♢ 🚚

[ Pedido ] ♦---------- [ ItemDoPedido ]   (Morte cruzada: Cascade Delete)
[ Restaurante ] ♢------ [ Prato ]          (Prato sobrevive autonomamente)

Explicação:

Composição no Pedido: ItemDoPedido não tem razão de existir sem o Pedido pai. Se o pedido é cancelado, os itens são lixo sem contexto.
Agregação no Cardápio: Um Prato tem vida própria — pode ser análisado em relatórios de histórico, custo e popularidade mesmo após ser removido do restaurante.

🎯 Por que Investir a Alma Neste Diagrama?

Seja o software gerenciando satélites ou vendendo Pão de Queijo:

Este diagrama extirpa os jargões, ele crava “o que vai ter de campo de texto pra digitar”. Evita Redundância de Memória e sobrecarga JSON.
Ele previne que desenvolvedores Junior Java matem classes cruciais ao efetuarem um delete não intencional devido as indicações do “Diamante Sombrio da Composição”.
A Ferramenta CASE converte o diagrama quase magicamente em Migrations, APIs e Entidades Django/Spring Boot, diminuindo o “trabalho braçal braçal” em 70% da equipe para sobrar tempo para pensar no que importa!

Explorador

RicardoTecPro

Slide Aula Conceitual 10 - Unidade IV - Eng Soft