UML: diagrama de classes, relações, multiplicidade e casos de uso

A UML (Linguagem de Modelagem Unificada) é uma notação padronizada para modelar sistemas, mantida pelo grupo OMG. Ela não é um método nem uma linguagem de programação: é um conjunto de diagramas para descrever estrutura e comportamento. Os dois diagramas mais cobrados em provas são o de classes e o de casos de uso, e é neles que se concentram as pegadinhas.

Os 14 diagramas, em dois grupos

A UML 2 define diagramas estruturais (o que o sistema tem) e comportamentais (o que ele faz). Para saber a qual grupo pertence um diagrama, vale decorar a lista:

Grupo	Diagramas
Estruturais	classes, objetos, componentes, estrutura composta, implantação, pacotes, perfis
Comportamentais	casos de uso, atividades, máquina de estados, sequência, comunicação, visão geral de interação, temporização

Os diagramas de sequência, comunicação, visão geral de interação e temporização formam o subgrupo das interações. Eles aparecem em UML: diagramas de sequência, atividades e estados.

Diagrama de classes

Mostra as classes do sistema, seus atributos e operações e as relações entre elas. Cada classe é um retângulo com três compartimentos: nome, atributos e operações.

+---------------------+
|      Servidor       |
+---------------------+
| - nome: String      |
| # matricula: int    |
+---------------------+
| + pontos(): int     |
+---------------------+

Visibilidade

Símbolo	Visibilidade
`+`	pública
`-`	privada
`#`	protegida
`~`	de pacote

Na notação, o tipo vem depois dos dois-pontos (nome: String). Classe abstrata tem o nome em itálico (ou o estereótipo de abstrata); interface usa o estereótipo «interface». Um membro estático aparece sublinhado.

Multiplicidade

Indica quantas instâncias participam de uma relação. Fica nas extremidades da linha:

Notação	Significado
`1`	exatamente um
`0..1`	zero ou um
`` ou `0..`	zero ou mais
`1..*`	um ou mais
`2..5`	de dois a cinco

Leitura: se uma linha liga Unidade a Servidor, com 1 do lado de Unidade e 0..* do lado de Servidor, lê-se “uma unidade possui zero ou mais servidores, e cada servidor pertence a exatamente uma unidade”.

As relações

Relação	Linha	Sentido	Exemplo
Associação	linha simples	“conhece” ou “usa”	Aluno cursa Disciplina
Agregação	losango vazio no lado do todo	todo-parte, partes independentes	Departamento e Professores
Composição	losango cheio no lado do todo	todo-parte, parte depende do todo	Pedido e Itens do pedido
Generalização (herança)	linha cheia, triângulo vazio na superclasse	“é um”	Analista é um Servidor
Realização	linha tracejada, triângulo vazio	classe implementa interface	Classe implementa uma interface
Dependência	seta tracejada	uma classe usa outra de forma passageira	Classe usa outra como parâmetro

Diferença que a banca adora: na agregação, as partes têm vida própria (se o departamento deixa de existir, os professores continuam existindo). Na composição, o ciclo de vida da parte está atado ao do todo (se o pedido é excluído, os seus itens também são). O losango fica sempre do lado do “todo”.

Associação pode ter navegabilidade (seta indicando quem conhece quem) e classe de associação, quando o relacionamento tem atributos próprios, como a nota na ligação entre aluno e disciplina. A classe de associação corresponde, no modelo relacional, à tabela associativa explicada em modelagem de dados: MER e mapeamento.

Diagrama de casos de uso

Descreve o que o sistema faz do ponto de vista do usuário, sem mostrar como. É uma ferramenta de levantamento de requisitos funcionais.

Elementos:

Ator: papel externo que interage com o sistema (pessoa, outro sistema, dispositivo). Desenhado como boneco. Ator é papel, não pessoa específica.
Caso de uso: funcionalidade que entrega valor ao ator. Desenhado como elipse, com nome em forma de verbo (Registrar protocolo).
Fronteira do sistema: retângulo que contém os casos de uso; os atores ficam fora.
Associação: linha entre ator e caso de uso.

Relacionamentos entre casos de uso

Relação	Ideia	Seta
`«include»`	o caso base sempre usa o incluído (comportamento obrigatório e reutilizável)	tracejada, do caso base para o incluído
`«extend»`	o caso de extensão pode acrescentar comportamento ao base, sob condição	tracejada, do caso de extensão para o base
Generalização	um caso (ou ator) é uma especialização de outro	linha cheia com triângulo vazio

Exemplo: “Emitir certidão” inclui “Autenticar usuário” (sempre exige login). “Emitir certidão” pode ser estendido por “Solicitar segunda via” quando a certidão já foi emitida antes. Memorize: include é obrigatório e a seta sai do que inclui; extend é opcional e a seta sai do que estende.

Cada caso de uso costuma ser acompanhado de uma descrição textual: pré-condições, fluxo principal, fluxos alternativos e de exceção, e pós-condições. O diagrama dá a visão geral; a descrição traz os detalhes.

Como resolver uma questão

Identifique o diagrama pelo desenho: retângulos de três partes (classes), bonecos e elipses (casos de uso).
Em classes, leia a multiplicidade dos dois lados de cada linha.
Diferencie agregação de composição pela vida independente da parte.
Em casos de uso, decida se a relação é obrigatória (include) ou condicional (extend).
Releia o enunciado para ver se pede estrutura ou comportamento.

Erros comuns

Trocar o lado do losango: ele fica no todo.
Confundir agregação com composição.
Achar que o ator é sempre uma pessoa.
Inverter o sentido das setas de include e extend.
Colocar no diagrama de casos de uso detalhes de implementação, como telas e tabelas.
Dizer que a UML define o processo de desenvolvimento: ela só define notação.

Fontes e atualização

Não há norma oficial brasileira sobre a UML; o conteúdo segue a especificação padronizada da notação e a literatura da área de engenharia de software. O tema é notação e não há código a executar; a lista de diagramas segue a organização da UML 2. Notações antigas (UML 1) diferem em detalhes: confira a versão citada no edital.

Próximos passos

Veja os diagramas de comportamento em UML: sequência, atividades e estados.
Relacione com o código em programação orientada a objetos.
Entenda requisitos em engenharia de software: requisitos e testes.