UML 

Diagramas Estáticos / Estruturais (OCCIPE) 

Diagrama de Classes 
  Os diagramas de classes descrevem os tipos de objetos presentes no sistema e os 
vários tipos de relacionamentos estáticos existentes entre eles. Mostram também as 
propriedades e operações (atributos e métodos) de uma classe e as restrições que se aplicam à 
maneira como os objetos estão conectados. 
  As propriedades representam as características estruturais de uma classe, são 
correspondentes aos campos de uma classe. Elas aparecem em duas notações distintas: 
atributos e associações 
  Os atributos são as “variáveis” da sua classe e a notação completa é: 
 
Visibilidade nome: tipo [multiplicidade] = valor_por_omissão {lista de propriedades} 
 
• Visibilidade: ‐ privado, + público, ~ pacote, # protegido. 
• Nome corresponde ao nome de sua “variável”. 
• Tipo: restrição sobre o tipo de objeto que pode ser colocado no atributo 
• Multiplicidade:  indicação de quantos objetos podem preencher a propriedade, 
exatamente como em banco de dados. [mínima..máxima] 
• Valor_por_omissão: valor do novo objeto caso o atributo não seja especificado 
durante a criação. 
• Lista de propriedades: permite que você indique propriedades adicionais para 
o atributo. {readOnly}, {ordered}, {nonUnique}, etc. 
 
As associações podem mostrar as mesmas informações que um atributo. Uma 
associação é uma linha cheia entre duas classes, direcionada da classe de origem para a classe 
de destino. O nome da propriedade fica no destino final da associação junto com sua 
multiplicidade.  As associações podem ser unidirecionais ou bidirecionais. Podemos dizer que 
uma pessoa é proprietária de zero ou vários carros e que um carro é de somente uma pessoa. 
As figuras a seguir mostram as mesmas informações representadas nas duas notações 
diferentes, atributos e associações e uma associação bidirecional: 
Pedido
Pessoa Carro
+ datadeRecebimento : Date[0..1] Proprietário
+ éPréPago : boolean[1] *
+ itensdeLinha : LinhadePedido[*] {ordered} 0..1

Associação bidirecional

Date 0..1 Pedido. Boolean

* 1

+datadeRecebimento +éPréPago

1..1
+itensdeLinha
Mesmas {ordered}
*
informações
com Linha de Pedido
notações
diferentes
 
1
  
  Operações são as ações que uma classe sabe realizar, ou seja, são os métodos da 
classe. A sintaxe completa da UML para operações é: 
 
Visibilidade nome (lista‐de‐parâmetros): tipo‐de‐retorno {lista‐de‐propriedades} 
 
• Visibilidade: ‐ privado, + público, ~ pacote, # protegido. 
• Nome é uma seqüência de caracteres. 
• Lista‐de‐parâmetros são os parâmetros da operação. Possuem a sintaxe: 
o Direção nome: tipo = valor‐por‐omissão 
o A direção indica se o parâmetro é de entrada (in), saída (out) ou ambos 
(inout). Por padrão será IN. 
o Exemplo: + saldoEm (in data: Date = 22/12/1981): Dinheiro 
• Tipo‐de‐retorno é o tipo do valor de retorno, se houver algum. 
• Lista‐de‐propriedades indica os valores de propriedade que se aplicam à 
operação. 
Funcionário
Uma classe com
- nome : String um atributo e uma
+ SetNome () : void operação
 
A Generalização é a herança em Linguagens Orientadas a Objetos. Ela é indicada por 
uma seta cheia que sai da classe específica para a classe geral, ou seja, das classes filhas para a 
classe pai. Na generalização, a classe filha herda todos os atributos e operações da classe pai. A 
figura abaixo exibe a herança e a herança múltipla: 
Pai
Pai 1 Pai 2

Filho 1 Filho 2 Filho Bastardo

 
Generalização                                             Herança Múltipla 

Uma dependência entre dois elementos existe se mudanças na definição de um 
elemento (o independente) podem causar mudanças no outro (o dependente). É importante 
observar que mudanças na classe dependente não causam nenhum impacto na classe 
independente. A UML tem vários tipos de dependências, utilizamos um estereótipo para 
identificar tais tipos (dependência estereotipada). A forma mais básica de dependência (não‐
estereotipada) não é transitiva, ou seja, se A depende de B e B depende de C, A NÃO depende 
de C. A dependência é identificada por uma seta pontilhada que aponta do cliente para o 
fornecedor. A figura abaixo exemplifica a dependência normal e estereotipada: 
Entrada de Dados de Funcionáio Entrada de Dados de Benefício

Plano de Benefícios Funcionário

<<call>>

  2

Dependência & Dependência Estereotipada 
  
A UML permite que sejam adicionadas regras de restrição descritas em notas ligadas a 
classe por uma linha pontilhada, a regra deve estar obrigatoriamente entre chaves {}: 
Funcionário
+ salário : int
+ quebrado : boolean

{Se salário for menor que

"mínimo" então quebrado
= true}
 
Uma interface da UML é uma classe que possui apenas operações públicas, sem 
nenhum corpo de método, o que corresponde às interfaces da linguagem Java. Ela é mostrada 
usando‐se a palavra chave <<interface>>. Existem várias outras palavras chave em UML. A 
notação de interfaces em UML pode ser do tipo bola e soquete ou do tipo “pirulito”, no caso 
do soquete, a classe que fornece a interface é a bola e a classe que utiliza a interface é o 
soquete:  
Controle do BD Pedido

Controle do BD 2 Pedido 2

I2
 
 
Podemos nos referir a atributos e operações estáticas (que se aplicam a uma classe e 
não a uma instância dela, “variável global”) em UML sublinhando o nome da propriedade. 
A agregação é o relacionamento “parte de”. Neste relacionamento, as partes existem 
isoladamente. A agregação é representada graficamente como uma seta com um diamante 
vazio na ponta da classe agregadora. Na composição as partes não existem isoladamente, 
deletando o todo, as partes também são deletadas, uma controla o tempo de vida da outra. A 
composição é representada graficamente por uma seta com um diamante cheio na ponta da 
classe compositora (a que junta tudo...): 
Banco Cliente

Menus * Janela
1

*
Botões

 
   

3
  

Diagrama de Objetos 
  O Diagrama de objetos representa uma fotografia do sistema em um dado momento. 
São parecidos com os diagramas de classes, porém com o nome do objeto sublinhado e 
seguindo a sintaxe nome‐do‐objeto: nome‐da‐classe. As duas partes do nome são opcionais, 
portanto, João, :Pessoa e nomePessoa são válidos. Observe que se usar somente o nome da 
classe, deve obrigatoriamente usar os dois pontos. 
  No diagrama de objetos não devem ser representadas as multiplicidades dos 
relacionamentos 
12345 João:Cliente :Pedido

 
Um objeto de Cliente e dois de Pedido 

Diagrama de Componentes 
  Identifica os componentes que fazem parte de um sistema, subsistema ou mesmo os 
componentes ou classes internas de um componente individual. Seria como peças que se 
encaixam formando um sistema de software. A notação do diagrama de componentes da UML 
2.0 é  a seguinte: 
Conecta ao Banco GUI

Negócios

Diagrama de Pacotes 
  Um pacote é uma construção de agrupamento (em tempo de compilação) que permite 
a você pegar qualquer construção na UML e agrupar seus elementos em unidades de nível 
mais alto. Um pacote pode conter subpacotes e classes. Um diagrama de pacotes mostra os 
pacotes e suas dependências, pode mostrar as interfaces entre os pacotes e também 
generalizações. 

Aplicação Gateway do BD

Gateway do Oracle Gateway do MySQL

 
   

4
Diagrama de Implantação / Instalação 
  Os diagramas de instalação mostram o layout físico de um sistema, revelando quais 
partes do software são executadas em quais partes do hardware. 
  Os principais itens do diagrama são nós conectados por caminhos de comunicação. Um 
nó será um dispositivo (hardware) ou um ambiente de execução (software que contém 
software). Os nós contêm artefatos, que são os arquivos. Podemos rotular nós ou artefatos 
com valores para indicar informações a respeito deles. 

Servidor WEB
Servidor de Aplicação
Java/RMI
{SO = Windows}
{Apache}
Aplicação.exe
___________
herculesWEB.jar
 

Diagrama de Estrutura Composta 
  Um diagrama de estrutura composta contém classes, interfaces, pacotes os 
relacionamentos entre esses itens e provê uma visão lógica do todo ou de parte de um sistema 
de software. O diagrama mostra a estrutura interna de uma classe, um conjunto de elementos 
internamente conectados que colaboram, em tempo de execução, para atingir um objetivo.  
  O exemplo a seguir representa a estrutura interna das classes TitleSql (que contém 
duas classes internas) e TitleImp (que contém duas partes), e representa também como elas 
estão conectadas pelas interfaces. 

Diagramas Dinâmicos/ Comportamentais / de Interação 
(MCASCIT) 
Diagrama de Casos de Uso 
  O modelo de casos de uso é uma representação das funcionalidades externamente 
observáveis do sistema e dos elementos externos ao sistema que interagem com ele. Os casos 
de uso são utilizados no levantamento dos requisitos funcionais do sistema, eles não 
especificam os requisitos não funcionais do sistema! 
  Um caso de uso representa quem faz o que com o sistema, sem considerar o 
comportamento interno do sistema. Um cenário é uma seqüência de passos que descreve uma 
interação entre um usuário e um sistema, em outras palavras, um cenário é a descrição de 
uma da maneiras pelas quais um caso de uso pode ser realizado. 
Um ator é qualquer coisa externa ao sistema que interaja com ele. Um ator é um papel 
que um usuário desempenha com relação ao sistema, pode ser uma pessoa, um hardware, 
outro sistema, etc. Os atores realizam os casos de uso. 
5
  Os diagramas de casos de uso mostram os atores, os casos de uso e os 
relacionamentos entre eles: quais atores realizam quais casos de uso; quais casos de uso 
incluem outros casos de uso; etc. Os casos de uso ficam contidos num retângulo (fronteira). 
Relacionamentos: 

• Comunicação (associação) 
o Representa a informação de quais atores estão relacionados a quais 
casos de uso; 

matricular em disciplina

Aluno
 
 
• Inclusão <<include>> 
o Existe somente entre casos de uso! 
o Um caso de uso inclui o outro, indica que um caso de uso terá seu 
procedimento copiado num local especificado em outro caso de uso, 
identificado como base da seta pontilhada e com o estereótipo 
<<include>>. A seta aponta para o caso incluído! 
o Sempre que ocorrer a execução do caso de uso base, ocorrerá a 
execução do caso de uso incluído, SEMPRE! 

<<include>>
Obter Extrato Bancário Validar correntista

Caso de uso base Caso de uso incluído

   

6
 • Extensão <<extend>> 
o Existe somente entre casos de uso! 
o Utilizado para modelar situações em que diferentes seqüências de 
interações podem ser inseridas em um caso de uso, cada seqüência 
representa um comportamento que só ocorre sob certas condições, 
normalmente em casos de exceção. 
o A execução do caso de uso extend não é obrigatória, só ocorre dentro 
de certas circunstâncias. 
o A seta do <<extend>> aponta para o caso de uso “estendedor” e não 
para o caso de uso “estendido”. 
o O caso de uso pode ter especificado o local onde a extensão ocorrerá, 
são os pontos de extensão (extension points): Um ponto de extensão 
identifica um ponto no comportamento de um caso de uso 
(estendedor) onde aquele comportamento do caso de uso estendido 
será executado. 

<<extend>> cadastrar usuário

fazer pedido

<<include>>
Extend = seta aponta
para classe principal
Include = seta aponta
para classe incluída

validar login do usuário

 
• Generalização (herança) 
o Existe entre casos de uso e atores! 
o Permite que um caso de uso (ou ator) herde características de um caso 
de uso (ou ator) mais genérico, chamado de caso de uso base (ator 
base). 

Realizar pagamento

Pessoa

Pagar com Cartão Pagar com Cheque

Cadastrar produtos

Funcionário
 
 
7
   
Diagrama de Máquinas de Estados / de Transição de Estados 
  Os diagramas de Estados são utilizados para descrever o comportamento de um 
sistema. Um objeto muda de estado quando acontece algum evento interno ou externo ao 
sistema. Através da análise das transições entre estados dos objetos do sistema, podemos 
prever todas as possíveis operações realizadas, em função dos eventos que possam ocorrer. 
  A notação dos diagramas de estado possui: 

• Estados = situação na vida de um objeto que ele satisfaz a alguma condição ou 
realiza alguma atividade, o estado é determinado pelos atributos do objeto. 
o O estado inicial indica o estado de um objeto quando ele é criado. Só 
pode haver um estado inicial. É representado por um círculo cheio. 
o O estado final é representado como um círculo cheio dentro de um 
círculo vazio menor. É um estado opcional e pode haver mais de um. 
• Transições = os estados são associados a outros pelas transições. Uma 
transição é representada graficamente como uma seta de um estado para o 
outro.  Uma transição tem um evento associado. Um evento é algo que 
acontece em algum ponto no tempo e pode modificar o estado de um objeto. 
A notação da transição é esta mostrada abaixo: 
o Evento(lista‐parêmetros) [condição] / ação 
• Ações = ao passar de um estado para outro, um objeto pode realizar ações. 
Uma ação é uma expressão definida em termo dos atributos, operações, 
associações da classe ou dos parâmetros do evento. UMA AÇÃO NÃO PODE 
SER INTERROMPIDA! 
• Atividades = uma atividade está sempre associada a um estado e pode ser 
interrompida. 
Realizar depósito(quantia)/ depositar(quantia)

Estado inicial
disponível
<<conta criada>> <<conta fechada>>

Realizar Saque($$$) [quantia=$$$]/ Sacar($$$)

Aqui ficam as Bloqueada

atividades
relacionadas
ao estado

Após(30 dias)/ aplicarJuros() 8

 
Diagrama de Seqüência 
  Um diagrama de seqüência captura o comportamento de um único cenário. Ele mostra 
os objetos (ou uma classe estática) e as mensagens passadas entre eles. Os diagramas 
mostram a interação, exibindo cada participante com uma linha de vida, que percorre 
verticalmente a página, e a ordem das mensagens, lendo a página de cima para baixo. Ele 
exibe as mensagens ordenadas no tempo e é um diagrama mais utilizado durante a fase de 
projeto (solucionar o problema). 
  Na UML 1 os nomes dos objetos aparecem com seus nomes sublinhados, conforme o 
diagrama de objetos, mas na UML 2 os nomes dos objetos não aparecem mais sublinhados. 
  No diagrama podemos mostrar a troca de mensagens assíncronas (seta normal) e as 
mensagens síncronas (seta cheia). As primeiras não esperam a resposta enquanto que as 
segundas esperam a resposta antes de continuar o processamento. O resultado (resposta a 
uma mensagem) é uma seta pontilhada que retorna para o objeto que enviou a mensagem 
original, ela é opcional. 
  A linha de vida do objeto é uma linha pontilhada na vertical, nela colocamos o foco de 
controle (barra de ativação) do objeto, que é de onde “saem e chegam” as mensagens.  
  Para criar um novo participante, basta um já existente enviar uma mensagem 
diretamente para a caixa do novo. Um participante pode se auto‐excluir ou ser excluído por 
outro participante, um X é colocado no fim da sua linha de vida para denotar que este foi 
excluído. 
  É possível mostrar nos diagramas os laços de repetição e comportamentos 
condicionais usando quadros de interação (não vou tratar disso aqui pq estou com preguiça). 
SÃO EQUIVALENTES AOS DIAGRAMAS DE COMUNICAÇÃO! 
Diagrama de Seqüência

Um tratador

Actor_1 um Comando de Consulta

consultando BD criação

criação
uma instrução de BD

executar comando

resultados

Extrair resultados

fechar

resultados

 
  9
Diagrama de Comunicação (Colaboração) 
  Os diagramas de comunicação enfatizam os vínculos de dados entre os vários 
participantes na interação. Permite o livre posicionamento dos participantes, permite 
desenhar vínculos para mostrar como eles se conectam e usa numeração para mostrar a 
seqüência das mensagens. O esquema de numeração utilizado é a numeração decimal 
aninhada.  
SÃO EQUIVALENTES AOS DIAGRAMAS DE SEQÜÊNCIA! 

1: calcularPreço Fazedor de pedidos

5: calcularPreço
6: calcularDesconto

7: obterValorDesconto

um Pedido um Cliente

4: obterDetalhesdoPreço
2: obterQTDE
3: obterProduto

uma Linha do Pedido um Produto

Diagrama de Temporização  
  Os Diagramas de Temporização são usados para mostrar o comportamento dos 
objetos através de um período de tempo. É uma forma especial de diagrama de seqüência. A 
diferença é que os eixos são invertidos, ou seja, o tempo é contado no eixo vertical e não no 
horizontal. A figura ta horrível, mas não tem programa pra fazer esse diagrama.

10

 
Diagrama de Atividades 
  Os diagramas de atividades descrevem lógica de procedimento, processo de negócio e 
fluxo de trabalho. Os diagramas permitem que mostremos quem faz o que, ou seja, podemos 
dizer qual classe é responsável por cada ação no diagrama com o uso de raias (swimlanes): 

Receber Pedido

bifurcação

Preencher Pedido Enviar Fatura

ramificação

segue
apenas um
dos caminhos

Entrega Normal Receber Pagamento

Entrega Rápida

ponto de união

junção

Fechar Pedido

Execução Serviço de Atendimento ao Cliente Departamento Financeiro

Receber Pedido

Preencher Pedido Enviar Fatura

Entregar Pedido Receber Pagamentos

Fechar Pedido

 
Diagrama de atividades com raias 
11
 
 Os diagramas podem mostrar atividades que recebem ou enviam sinais e que esperam 
por um determinado período de tempo: 

Diagrama de Interação Geral 
  É uma mistura entre diagramas de atividade e diagramas de seqüência. As atividades 
são substituídas por pequenos diagramas de seqüência, com a notação do  diagrama de 
atividades para mostrar o fluxo de controle. 

  12