Início

Software Design

UA11 — Diagrama de Classes

O diagrama de classes é o bloco de construção principal da modelagem OO. Representa a estrutura estática do sistema: classes, atributos, métodos e relacionamentos. É a base para os diagramas de comunicação, sequência e estados.

A UML como Extensão do Pensamento
UML como rascunho ágil e como planta definitiva
A planta baixa que evita a refatoração dolorosa
Estrutura, comportamento e arquitetura — os três eixos da UML

As três perspectivas do diagrama de classes

O diagrama de classes pode ser analisado sob três perspectivas diferentes:

Conceitual

Representação dos conceitos do domínio. Direcionada ao cliente. Não inclui detalhes de implementação.

Especificação

Foca nas principais interfaces e métodos da arquitetura. Para quem precisa entender o sistema sem ver o código.

Implementação

A mais usada. Inclui detalhes de navegabilidade, atributos completos, tipos. Voltada para o time de desenvolvimento.

O que é uma Classe?

Classes são descrições de um grupo de objetos com papéis semelhantes no sistema. Objetos derivam de:

  • Coisas: objetos tangíveis do mundo real (produto, livro, veículo).
  • Papéis/funções: atores em sistemas (estudante, gerente, enfermeiro).
  • Eventos: ocorrências registráveis (admissão, matrícula, venda).
  • Interações: resultados de relações entre entidades (reunião, contrato).

Anatomia de uma Classe UML

Uma classe é representada por um retângulo com 3 compartimentos verticais:

CompartimentoConteúdoConvenção
SuperiorNome da classeNegrito, centralizado, primeira letra maiúscula
MeioAtributos: visibilidade nome: tipoAlinhado à esquerda, primeira letra minúscula
InferiorMétodos: visibilidade nome(params): retornoAlinhado à esquerda, primeira letra minúscula
A anatomia estrutural: Dissecando a Classe
Identificador, estado (atributos) e comportamento (métodos)

Visibilidade

SímboloVisibilidadeAcessível de
+publicQualquer lugar
-privateApenas dentro da própria classe
#protectedClasse e suas subclasses
~packageClasses no mesmo pacote
Controle de acesso lógico: Visibilidade
Public, private, protected e package — controle de acoplamento

Multiplicidades

NotaçãoLeitura
0..1No máximo um (pode ser zero)
1 ou 1..1Exatamente um
0..* ou *Zero ou muitos
1..*Um ou muitos (pelo menos um)
3..5Entre três e cinco

Leitura: “Um Funcionário trabalha em 0..1 Empresa” E “Em uma Empresa trabalham 0..* Funcionários”.

Multiplicidade: Traduzindo regras de negócio
Cada notação expressa uma regra de negócio real

Relacionamentos

RelaçãoNotaçãoDefinição
AssociaçãoLinha sólidaRelacionamento estrutural — instâncias de uma classe ligadas a outra. Pode ser bidirecional ou unidirecional.
DependênciaLinha tracejada com setaUma mudança em um elemento afeta o outro. Objeto de uma classe usa serviços de outra.
Generalização (herança)Linha sólida com seta fechadaElemento específico herda de um mais geral. Subclasses herdam todos os atributos e métodos da superclasse.
AgregaçãoLinha com losango vazioObjeto-parte é atributo do todo, mas pode existir independentemente.
ComposiçãoLinha com losango cheioAs partes só existem com o todo — são criadas e destruídas com ele. Vínculo forte (FILHA depende da PAI).
O Espectro de Relacionamentos: Medindo o Acoplamento
Do acoplamento fraco (dependência) ao forte (herança) — escolha consciente

Pacotes

Pacotes agrupam elementos semanticamente relacionados em namespaces. Ao remover um pacote, todos os seus elementos são removidos junto. Use convenção de domínio invertido: br.com.empresa.app.modulo.

Pacotes servem para dividir sistemas grandes em subsistemas, facilitando manutenção e compreensão. O nome do pacote deve expressar o propósito de suas classes.

Passos para criar um diagrama de classes

  1. Identificar frases nominais dos casos de uso — candidatos a classes.
  2. Eliminar candidatos inapropriados: redundantes, vagos, fora do escopo, simples atributos.
  3. Identificar os verbos — candidatos a métodos e relacionamentos.
  4. Validar o modelo — verificar se não há classes que prejudiquem o modelo.

Erros comuns de modelagem

  • Análise excessiva de frases nominais — coletar mais classes do que o necessário.
  • Nomes de classes e associações ambíguos ou incompreensíveis.
  • Inserir multiplicidades antes de estabilizar a estrutura do diagrama.
  • Pensar em questões de implementação durante a fase de modelagem.
Matriz Diagnóstica: Escolhendo a Ferramenta Certa
Classes vs. Sequência vs. Componentes — quando usar cada diagrama

N:N sempre gera uma classe associativa

Um Pedido contém vários Produtos e um Produto aparece em vários Pedidos — relação N:N. Não pode ser mapeada diretamente: gera a classe ItemPedido, que armazena os atributos da relação (quantidade, preço na data da compra).

Práticas Modernas — Diagrama de Classes

  • Diagramas gerados do código: plugins para IntelliJ IDEA, VS Code e Eclipse geram diagramas de classes automaticamente a partir do código Java/TypeScript. O diagrama fica sempre sincronizado.
  • Mermaid classDiagram permite escrever diagramas de classes em Markdown — renderizado pelo GitHub, GitLab e Notion. Substitui ferramentas pesadas como Enterprise Architect.
  • TypeScript interfaces e types são a implementação moderna de “classe abstrata” no ecossistema JS/TS — mais leves e composíveis que herança tradicional. Preferência pelo padrão composition over inheritance.
  • Code reviews como design review: Pull Requests em equipes maduras funcionam como revisão do design OO — alterações em class diagrams são discutidas via diff de código, não de documentos.

Dicas para a Prova

  • Diagrama de classes = representação da estrutura e relações das classes que servem de modelo para objetos.
  • Classes são representadas por retângulos (não círculos, quadrados ou setas).
  • Associação = relacionamentos estruturais entre instâncias; Dependência = relacionamentos de utilização; Generalização = herança.
  • Multiplicidades = informam a quantidade de instâncias de objetos que uma classe pode ter em relação a outra.
  • Visibilidades UML: público (+), protegido (#), privado (-) e pacote (~).

Referências bibliográficas desta UA

  • LEDUR, C.L. Análise e Projeto de Sistemas, 2017.
  • AMBLER, S.W. UML 2 Class Diagram Guidelines, 2016.
  • BELL, D. Fundamentos básicos de UML: o diagrama de classes, IBM developerWorks, 2016.