Diagrama de Classes UML: Estrutura, Notação e Aplicação na Engenharia de Software

O Diagrama de Classes é o principal artefato da Linguagem de Modelagem Unificada (UML – Unified Modeling Language) para representar a estrutura estática de sistemas orientados a objetos. Ele funciona como um blueprint do software, descrevendo suas classes, atributos, operações e os relacionamentos entre elas.

Exemplo Geral: Diagrama de Classes Básico

classDiagram class Cliente { -id: int -nome: string +getNome(): string +setNome(nome: string): void } class Pedido { -numero: string - Date +calcularTotal(): BigDecimal } class ItemPedido { -quantidade: int -precoUnitario: BigDecimal } Cliente "1" --> "0..*" Pedido : faz Pedido "1" --> "1..*" ItemPedido : contém

1. Classes, Objetos e Orientação a Objetos

2. O Diagrama de Classes no Contexto Ágil

Usado com propósito, ele complementa práticas ágeis ao facilitar comunicação, prevenir retrabalho e acelerar alinhamento.

3. Representação da Classe no UML

No UML, uma classe é representada por um retângulo dividido em até três compartimentos:

  1. Nome da classe: Escrito em negrito, no topo. Define a identidade do tipo (ex: Cliente, Pedido).
  2. Atributos: Listados no compartimento do meio. Cada atributo pode incluir:
    • Visibilidade: + (público), - (privado), # (protegido)
    • Nome e tipo (ex: - nome: String)
  3. Operações (métodos): No compartimento inferior. Cada operação pode incluir:
    • Visibilidade (mesmos símbolos)
    • Nome, parâmetros (com tipos) e tipo de retorno (ex: + calcularTotal(): BigDecimal)

A notação UML é flexível por design. Em muitos contextos — como reuniões de alinhamento ou esboços iniciais — é comum mostrar apenas o nome da classe, ou nome + atributos, omitindo métodos. O nível de detalhe deve refletir o propósito da comunicação, não uma exigência burocrática.

Níveis de Detalhe: Representações da classe Cliente

Da esquerda para a direita: (1) só nome, (2) com atributos, (3) com atributos e operações.

classDiagram class ClienteBasico { Cliente } class ClienteComAtributos { Cliente -- -id: int -nome: string } class ClienteCompleto { Cliente -- -id: int -nome: string -- +getNome(): string +setNome(nome: string): void }

4. Relacionamentos Estruturais: Notação Precisa e Atualizada

No Diagrama de Classes UML, as relações estruturais representam ligações permanentes entre classes — ou seja, conexões que existem durante toda a vida do sistema (diferentes de interações temporárias, que são modeladas em diagramas de sequência). Esses relacionamentos definem como os objetos colaboram, se compõem e se especializam.

Existem quatro tipos fundamentais de relações estruturais, cada um com uma notação gráfica específica e um significado conceitual distinto:

1. Associação

O que é: Uma ligação semântica entre duas classes, indicando que uma classe conhece ou utiliza a outra.

Notação: Linha reta e contínua entre as classes.

Características:

Exemplo: Cliente ——— Pedido. Um cliente pode fazer vários pedidos, mas um pedido pode não existir sem um cliente. No entanto, se o cliente for excluído, o pedido pode persistir (ex: para fins fiscais), o que mostra independência de ciclo de vida.

💡 Dica: A associação é o relacionamento mais genérico. Use-a quando não houver herança, composição ou agregação.

2. Generalização (Herança)

O que é: Um relacionamento de especialização/generalização, onde uma classe filha (subclasse) herda atributos e operações de uma classe pai (superclasse).

Notação: Seta com triângulo vazio apontando para a superclasse.

Características:

Exemplo: Cachorro ───▷ Animal. Um Cachorro é um Animal. Ele herda propriedades como nome e métodos como emitirSom(), mas pode ter comportamentos próprios como latir().

⚠️ Cuidado: Evite heranças profundas ou apenas para reutilizar código — prefira composição nesses casos (“favoreça composição sobre herança”).

3. Agregação

O que é: Um tipo especial de associação que representa um relacionamento “tem um” fraco (has-a), onde o todo (contêiner) contém partes, mas não controla seu ciclo de vida.

Notação: Linha com losango vazado (◇) do lado da classe todo.

Características:

Exemplo: Departamento ◇—— Professor. Um departamento tem professores, mas se o departamento for extinto, os professores continuam existindo (podem ser transferidos ou demitidos, mas não “destruídos” junto com o departamento).

🔍 Como identificar: Pergunte: “Se o todo for destruído, a parte deixa de existir?” Se a resposta for não, é agregação.

4. Composição

O que é: Um tipo de associação forte, onde o todo controla o ciclo de vida das partes. É um relacionamento “tem um” forte (tem-a).

Notação: Linha com losango preenchido (◆) do lado da classe todo.

Características:

Exemplo: Carro ◆—— Motor. Um motor não existe como parte funcional fora do carro no contexto do sistema. Se o carro for sucateado, o motor (como componente do sistema) também é descartado.

🔍 Como identificar: Se a parte não faz sentido sem o todo, ou se o todo cria e destrói a parte, é composição.

📌 Regra Fundamental de Notação

O losango — seja vazado (agregação) ou preenchido (composição) — sempre está conectado à classe que representa o “TODO” (o contêiner).

Essa regra evita um dos erros mais comuns na modelagem UML: inverter o lado do losango.

Composição vs Agregação

classDiagram class Carro { +ligar(): void } class Motor { +injetarCombustivel(): void } class Departamento { +nome: string } class Professor { +nome: string +titulacao: string } Carro "1" *-- "1" Motor : contém Departamento "1" o-- "0..*" Professor : emprega

Generalização (Herança)

classDiagram class Animal { +nome: string +emitirSom() } class Cachorro { +latir() } class Gato { +miar() } Animal <|-- Cachorro Animal <|-- Gato

Associação com Multiplicidade

classDiagram class Cliente { +nome: string } class Pedido { + Date } Cliente "1" --> "0..*" Pedido : faz

🧩 Comparação Visual Rápida

RELACIONAMENTO NOTAÇÃO GRÁFICA DEPENDÊNCIA DE CICLO DE VIDA? EXEMPLO
Associação ————— ❌ Não Cliente → Pedido
Generalização ———▷ (triângulo vazio) N/A (herança) Cachorro → Animal
Agregação ◇——— ❌ Não Departamento → Professor
Composição ◆——— ✅ Sim Carro → Motor

✅ Quando usar cada um?

5. Aplicações Práticas do Diagrama de Classes

  1. Modelagem de projeto: Definir estrutura antes de codificar.
  2. Engenharia reversa: Entender sistemas existentes.
  3. Esboço colaborativo: Alinhar ideias rapidamente.

Conclusão

O Diagrama de Classes é uma ferramenta poderosa quando usada com propósito. Em equipes ágeis, menos (mas bem feito) é mais.