Usando UML

Usando UML para Especificação de Sistemas
Orientados a Objetos
Prof. Rodrigo Quites Reis

Fevereiro, 2003
quites@computer.org
http://www.inf.ufrgs.br/~quites
Usando UML para Especificação de Sistemas Orientados a Objetos
Modelagem de Objetos com UML

Autoria: Rodrigo Quites Reis
Última atualização: fevereiro/2000
Nenhuma parte desta apostila pode ser utilizada ou reproduzida, em qualquer meio ou forma,
seja mecânico ou eletrônico, fotocópia, gravação, ou outros, sem autorização, prévia,
expressa e específica do Autor.
Prof. Rodrigo Quites Reis - Fevereiro/2003

SUMÁRIO
1 INTRODUÇÃO ................................................................................................................. 4
2 DIAGRAMAS DE CASOS DE USO (USE CASES) ...................................................... 5

2.1 Caso de Uso .................................................................................................................. 5
2.2 Interação em caso de uso .............................................................................................. 6
2.3 Exemplos de casos de uso............................................................................................. 8
2.3.1 Caixa eletrônico ............................................................................................................................. 8
2.3.2 Telefone celular.............................................................................................................................. 8
2.3.3 Sistema de Vendas [TOG00] ......................................................................................................... 9
3 DIAGRAMA DE CLASSES EM UML ......................................................................... 10

3.1 Classes e seus relacionamentos................................................................................... 10
3.2 Associações Simples ................................................................................................... 11
3.3 Multiplicidade (Cardinalidade) ................................................................................... 13
3.4 Classes Associativas ................................................................................................... 14
3.5 Qualificador ................................................................................................................ 15
3.6 Agregação ................................................................................................................... 16
3.7 Navegabilidade ........................................................................................................... 18
3.8 Generalização/Especialização..................................................................................... 18
3.9 Restrições .................................................................................................................... 19
3.10 Estudo de Caso.......................................................................................................... 20
4 DIAGRAMAS DE INTERAÇÃO .................................................................................. 21

4.1 Diagrama de Seqüência............................................................................................... 22
4.2 Diagrama de Colaboração........................................................................................... 24
5 ESTUDOS DE CASO E EXERCÍCIOS........................................................................ 27

5.1 Estudo de Caso 1: Locadora de Veículos.................................................................... 27
5.2 Estudo de Caso 2: Hospital ......................................................................................... 27

1 INTRODUÇÃO
O presente texto tem como objetivo apresentar uma visão geral das técnicas de
modelagem de sistemas orientados a objetos chamada UML – Unified Modelling Language.
Atualmente, UML consiste na principal linguagem para descrição de sistemas O.O., tendo
sido definida como padrão do OMG1 em 1997.
Apesar deste não se propor a substituir qualquer um dos livros clássicos escritos
nesta área, o objetivo deste texto é o de complementar as atividades realizadas em sala de
aula, proporcionado uma visão geral dos conceitos de modelagem com UML. Além disso,
somente os modelos UML mais importantes são apresentados, deixando de lado aqueles que
possuem sua aplicação condicionada a sistemas com características específicas.
1
OMG = Object Management Group. Organismo internacional para definição de padrões da orientação a
objetos.

2 DIAGRAMAS DE CASOS DE USO (USE CASES)
Os diagramas de caso de uso fornecem um modo de descrever a visão externa do

sistema e suas interações com o mundo exterior, representando uma visão de alto nível de
funcionalidade intencional mediante o recebimento de um tipo de requisição de usuário.
A modelagem de caso de uso é uma técnica utilizada para descrever a funcionalidade
de um sistema através de atores externos interagindo em casos de uso. Atores representam um
papel e iniciam o caso de uso que, por sua vez, deve entregar um valor tangível de retorno ao
ator. Atores e casos de uso estão conectados através de associações e podem ter
relacionamentos de generalização que descreva o comportamento comum em superclasses
herdadas por uma ou mais subclasses especializadas.
A modelagem de casos de uso é utilizada para capturar necessidades de um novo
sistema ou acrescentar novas necessidades para criar uma nova versão. Neste sentido, a nova
funcionalidade é adicionada ao contexto do modelo de caso de uso através da inserção de
novos atores e casos.
Os objetivos principais de um diagrama de caso de uso são:
• Descrever os requisitos funcionais do sistema de maneira uniforme para usuários
e desenvolvedores;
• Descrever de forma clara e consistente as responsabilidades a serem cumpridas
pelo sistema, formando a base para a fase de projeto;
• Oferecer as possíveis situações do mundo real para a fase de testes do sistema.
Um diagrama de caso de uso é um gráfico de atores, um conjunto de casos incluído
por um limite de domínio, comunicação, participação e associações entre atores, assim como
generalizações entre casos de uso. Os elementos básicos de um diagrama de caso de uso são:
ator, caso de uso, interação e sistema, todos ilustrados na figura a seguir.
Sistema
Caso de uso 1
Ator
Figura 1. Componentes de um diagrama de caso de uso.
2.1 Caso de Uso

Cada caso de uso é uma seqüência completa de cenários de interação mostrando

como eventos externos iniciais são respondidos no caso. Um cenário é uma narrativa de uma
parte do comportamento global do sistema e uma coleção completa de cenários é usada para
especificar completamente um sistema. Um caso de uso está para um cenário assim como uma
classe está para um objeto. Ou seja, um caso de uso representa uma declaração de um aspecto
de comportamento que é caracterizado por um lote de cenários concretos.
Um ator é uma entidade externa ao sistema que de alguma forma participa de um
caso de uso. Um ator estimula o sistema com eventos externos e tipicamente recebe algo do
sistema. Um ator pode ser um ser humano, máquinas, dispositivos, ou outros sistemas. Atores
típicos incluem, por exemplo, clientes, usuários, gerentes, computadores e impressoras.
2.2 Interação em caso de uso

O ator comunica-se com o sistema através do envio e recebimento de mensagens,
sendo que um caso de uso é sempre iniciado a partir do momento em que o ator envia sua
mensagem (estímulo). As seguintes interações são importantes dentro de um diagrama de caso
de uso:
• Comunicação: Um ator comunica-se com o caso de uso, tal como no exemplo
da Figura 2;
Telefone Celular
Fazer ligação
Usuário A comunicação é representada através

de um arco simples
Figura 2. Exemplo de Comunicação
• Inclusão: Quando um número de casos de uso tem comportamento comum, esse

comportamento pode ser modelado em um simples caso de uso que é utilizado
por outros casos. Assim, quando um caso de uso faz uso de outro, o
relacionamento de inclusão se aplica. É desenhado como uma seta pontilhada do
caso de uso que faz o uso ao caso de uso que é usado (da parte para o todo),
etiquetada com <<includes>>. A Figura 3 apresenta um exemplo do
relacionamento de inclusão.

Telefone Celular
<<includes>>
Identifica
Fazer ligação
destinatário
Usuário A comunicação é representada através

de um arco pontilhado com o rótulo <<includes>>
Figura 3 Exemplo de Inclusão
• Extensão. É usada para descrever casos de uso que são ativados opcionalmente
em um sistema. O relacionamento de extensão é representado graficamente
através de uma seta pontilhada com o rótulo <<extends>> que tem origem no
caso de uso opcional e atinge o caso de uso obrigatório associado. A Figura 4
mostra um exemplo do uso de Extensão na modelagem de casos de uso.
Telefone Celular
Receber
<<extends>>
ligação Receber
ligação
adicional
Usuário Opcional
Figura 4 Exemplo de Extensão
• Generalização. Expressa um relacionamento do tipo herança entre casos de uso.

Assim, um super-tipo de caso de uso indica um caso geral, enquanto que suas
especializações indicam casos particulares. A Figura 5 apresenta um exemplo do
relacionamento de generalização, onde Efetua pagamento é um super-tipo o qual
é especializado em Pagto com Cartão de Crédito e Pagto com Débito em Conta.
Super tipo
Efetua
pagamento
Pagto com Pagto com

Usuário Cartão de crédito Débito em Conta
Sub tipos
Figura 5 Exemplo de Generalização

2.3 Exemplos de casos de uso

2.3.1 Caixa eletrônico
O exemplo da Figura 6 mostra um diagrama de caso de uso que ilustra os serviços

tipicamente fornecidos por um Caixa eletrônico bancário. O diagrama distingue
explicitamente dois grupos de serviços: aqueles casos de uso para o Cliente, enquanto que
“Abastecer dinheiro” e “Recolher envelopes de depósitos” são de uso exclusivo do ator
Funcionário.
Caixa eletrônico
Consulta
de saldo Abastecer
dinheiro
Solicitação
de extrato Recolher
envelopes de
depósitos
Saque
Cliente Funcionário
Figura 6 Exemplo de diagrama de caso de uso (extraído de [FUR98])

2.3.2 Telefone celular
A Figura 7 apresenta um diagrama de caso de uso para um telefone celular. Deve-se

observar que o serviço “Faz ligação” faz uso de “Identifica destinatário” e opcionalmente
utiliza “Fazer ligação em conferência”. O caso de uso “Receber ligação”, por sua vez,
opcionalmente utiliza o “Receber ligação adicional”.
Telefone Celular
Fazer <<includes>> Identifica

Rede ligação
destinatário
Celular <<extends>>
Fazer
Receber ligação em
ligação conferência
<<extends>>
Uso Receber
programado ligação
adicional
Usuário
Figura 7 Exemplo de caso para telefone celular (adaptado de [BOO00])

2.3.3 Sistema de Vendas [TOG00]
A Figura 8 mostra um diagrama de caso de uso fornecido como exemplo na

ferramenta Together Control Center. São fornecidos dois sistemas inter-relacionados (“Point
of Sale” e “Product System”) com casos de uso particulares. O ator Cashier representa o
usuário do sistema que assume o papel de Caixa (atendente), enquanto que Inventory System é
um sistema externo.
Figura 8. Caso de uso de Sistema de vendas.

3 DIAGRAMA DE CLASSES EM UML
O modelo de objetos em UML é representado através de um diagrama de classes.

Um diagrama de classes denota a estrutura estática de um sistema e as classes representam
coisas que são manipuladas por esse sistema. A notação utilizada para representar o diagrama
de classes em UML é fortemente baseada na notação de Diagramas Entidade-Relacionamento
[CHE90] e no Modelo de Objetos de OMT [RUM94]. As seções a seguir apresentam
resumidamente a notação utilizada nesta linguagem.
3.1 Classes e seus relacionamentos

Uma classe é representada por um retângulo sólido com três partes: uma para o nome
da classe; outra para os atributos da classe; e a terceira para a declaração das operações
definidas para a classe. A Figura 9 mostra a notação UML para classes.
Figura 9. Notação para classe em UML
Os tipos principais de relacionamentos entre classes são:

• Generalização/Especialização (Herança): Indica relacionamento entre um
elemento mais geral e um elemento mais específico (superclasse e subclasse,
respectivamente). A subclasse pode conter somente informação adicional acerca
da superclasse. Por exemplo um médico é um funcionário;
• Agregação: Usada para denotar relacionamentos todo/parte. Por exemplo, um
item de compra é parte de um pedido;
• Associação (simples): Usada para representar relacionamentos entre as classes
(por exemplo, um cliente pode alugar várias fitas de vídeo);
• Dependência: Um relacionamento entre um elemento independente e outro

dependente, onde uma mudança no elemento independente afetará o elemento
dependente.
3.2 Associações Simples

Uma associação descreve um conjunto de vínculos entre objetos das classes
relacionadas. A associação entre duas ou mais classes permite um conjunto de ligações entre
os objetos das classes. Os tipos de associação são:
Associação Unária: Relacionamento entre uma classe e ela mesma. Também conhecida
como associação recursiva, cujo relacionamento pode conectar dois diferentes objetos de uma
mesma classe. A Figura 10 mostra um exemplo de associação unária:
Funcionário 1
* supervisiona
Figura 10. Exemplo de associação unária.
Associação Binária: Expressa o relacionamento entre duas classes distintas. A Figura 11

ilustra o exemplo de associação binária.
Multiplicidade da associação
Pessoa
Livro
Nome: Str
autoria
Endereço: {
Título: Str 0..* 1..* Logradouro: Str,
ISBN: Int Bairro: Str,
Editora: Str Cidade: Str. }
Telefones: Array of Int
Rótulo da associação
Figura 11 Exemplo de associação binária
Em geral, toda associação deve ser rotulada, tal como na associação de ‘autoria’ na
Figura 11. Alternativamente, pode ser expresso o papel de uma classe na associação, tal como
titular na Figura 12.
Conta Bancária
Pessoa
número
Nome: Str
saldo
* 1 Endereço: {
dataAbertura
Logradouro: Str,
titular Bairro: Str,
criar()
Cidade: Str. }
bloquear()
Telefones: Array of Int
desbloquear()
creditar()
debitar()
Papel da classe na associação
Figura 12 Segundo exemplo de associação binária
As associações têm sua semântica definida como relações entre conjuntos. O

exemplo da Figura 13 ilustra como que as classes Funcionário e Departamento representam
conjuntos, enquanto que a associação ‘trabalha’ define uma relação bidirecional entre os
conjuntos, indicando que o Funcionário João ‘trabalha’ no Departamento Financeiro e vice
versa.
Funcionário Departamento
0..* trabalha 4 1
João Financeiro
Figura 13 Mapeamento da semântica estrutural de uma associação

Associação n-ária: Associação entre três ou mais classes. Neste caso a notação inclui um
losango para representar a associação, como mostra a figura a seguir:

Figura 14. Representação de associação ternária.
3.3 Multiplicidade (Cardinalidade)
A cardinalidade das associações em um diagrama de classes é denominada de

multiplicidade e especifica quantas instâncias de uma classe podem participar da associação
(semelhante à abordagem ER). A tabela 1 a seguir apresenta as multiplicidades.
Tabela 1 – Multiplicidades de associações entre classes.
Multiplicidade Significado
0..1 Zero ou um
1 Somente 1
0..* Maior ou igual a zero
* Maior ou igual a zero
1..* Maior ou igual a 1
1..15 (m..n) De 1 a 15 (m a n), inclusive
A Figura 15 mostra um exemplo de uso de multiplicidade onde a classe financeira

está associada a 0 ou mais instâncias classe venda através da associação financia. A classe
venda está associada a um objeto da classe vendedor através da associação venda (notar que o
nome da associação pode ser um substantivo).

financia realizada por

Financeira 0..1 * Venda * Vendedor
código data número
nome hora nenha
nívelAutorização
Figura 15. Financeira: exemplo de uso de multiplicidade (adaptado de [HEU 99])
3.4 Classes Associativas

São classes que representam a associação entre outras classes. Somente ocorrem
instâncias da classe associativa quando ocorre a associação entre classes. Comparando com a
abordagem Entidades-Relacionamentos (ER), uma classe associativa equivale a uma entidade
associativa ou agregação de entidades. Da mesma forma, quando em um diagrama ER existe a
necessidade de representar atributos de relacionamentos, em um diagrama de classes cria-se
uma classe associativa.
A Figura 16 mostra um exemplo de classe associativa onde quando ocorre um
casamento entre duas pessoas, então uma classe associativa armazena a data do casamento e o
regime.
casamento
Data
Regime
esposa 0..1
Pessoa
Nome
Endereço: {
Logradouro; 0..1
Bairro; marido
Cidade. }
Sexo
Figura 16. Exemplo de classe associativa em uma associação unária.
A Figura 17 mostra um exemplo de associação onde é representado que quando

ocorre a matrícula de um Aluno em uma Disciplina. A classe associativa armazena as
informações de matrícula, isto é, o conceito e semestre correspondentes.
* matriculado *
Aluno Disciplina
conceito
semestre

Figura 17. Exemplo de classe associativa com associação binária.
A Figura 18 ilustra um exemplo de classe associativa entre Financeira e Venda,

complementando o diagrama apresentado anteriormente na Figura 15
financia realizada por
Financeira 0..1 * Venda * Vendedor
código data número
nome hora nenha
nívelAutorização
Financiamento
registroAprovação
dataAprovação
Figura 18 Evolução do modelo de Financeira com classe associativa
Uma classe associativa pode ser transformada em uma classe regular conforme
mostra a Figura 19 a seguir. A parte superior da figura mostra o modelo duas classes regulares
e uma associativa, enquanto que a parte inferior apresenta um modelo análogo que é
composto por três classes regulares.
1 trabalha 4 0..1
salário
dataContratação
Funcionário Emprego Departamento

* * 0..1
salário
dataContratação
Figura 19. Transformação de uma classe associativa em classe regular.
3.5 Qualificador
Qualificadores ou Associações Qualificadas são usadas com associações 1:N ou N:N.
O qualificador distingue (divide) o conjunto de objetos do outro lado da associação. A figura
a seguir ilustra um exemplo de qualificador. O modelo informa que um prédio possui vários
números de andar. Um número de andar de um prédio está associado a exatamente um andar.
Como conseqüência um andar é identificado pelo seu número e pelo prédio. Este conceito é
análogo ao conceito de entidade fraca ou relacionamento identificador em modelos entidade-
relacionamento.
Figura 20. Exemplo de uso de qualificador.
Outro exemplo de qualificador é apresentado na figura a seguir, onde um diretório

está associado a vários nomes de arquivo, e cada nome de arquivo é associado a um arquivo.
Cada arquivo está associado a um nome de arquivo e a um diretório.
Diretório Nome do arquivo Arquivo
Figura 21. Exemplo de qualificador.
3.6 Agregação
É um caso especial de associação usado para representar a relação todo/parte entre
classes. Quando o todo é criado, as partes também o são (e quando é eliminado também). As
partes não têm existência própria, somente associadas ao todo.
A notação de agregação é apresentada nas figuras a seguir:
Todo Parte
Agregação Regular
Figura 22. Agregação regular ou relacionamento por referência.
Todo Parte
Agregação de composição
Figura 23. Agregação de composição ou relacionamento por valor.

A rigor, a agregação deve ser utilizada prioritariamente para explicitar relações de

todo-parte: portanto, a Figura 24 mostra dois diagramas de classe que possuem exatamente o
mesmo significado.
0..* 0..*
Documento composto-por Parágrafo composto-por Sentença
0..* 0..*
Documento Parágrafo Sentença
Figura 24 Documento, parágrafo e sentença: duas alternativas para modelagem de agregação
Um segundo exemplo de uso de agregação em que uma Associação Esportiva é

composta por várias Equipes afiliadas que, por sua vez, são compostas por objetos da classe
Jogador.
Associação 0..* 0..*
<- afiliada Equipe Jogador
Esportiva
Figura 25. Exemplo de agregação.
Outro exemplo de agregação com notação compacta é apresentado na Figura 26,

mostrando que ao invés de ligar várias linhas a um agregado, basta usar o símbolo de
agregação uma única vez.
Figura 26. Agregação de várias classes com notação compacta [HEU 99].
Por fim, é apresentado um exemplo de composição na Figura 27. No caso, a classe

CPF é especialmente útil para ser descrito separadamente por fornecer o método validaCPF.

composição
Pessoa Pessoa Endereço
nome nome logradouro

endereço: { sexo bairro
logradouro; cidade
bairro;
cidade. } CPF
cpf
sexo número
validaCPF: bool
Figura 27 Uso de composição para descrever os detalhes de Pessoa
3.7 Navegabilidade
Uma instância de uma classe pode navegar a instâncias de outra classe e vice-versa.
Navegabilidade é percebida freqüentemente por objetos que mantêm referências de algum
tipo entre objetos associados. Uma seta é ligada entre duas classes para indicar o caminho de
navegação entre elas. Em termos de implementação isso representaria que o objeto de uma
classe conteria um apontador para o objeto da outra classe.
A figura a seguir mostra um exemplo onde as classes Pedido e Cliente possuem uma
associação onde o sentido da navegação ocorre de Pedido para Cliente. Isto indica que um
pedido tem a responsabilidade de informar a qual cliente pertence, mas um cliente em
particular não precisa indicar quais pedidos possui.
fonte alvo
Pedido * 1 Cliente
navegabilidade
Figura 28. Exemplo de Navegabilidade
3.8 Generalização/Especialização
Generalização/Especialização é um conceito também conhecido pelo nome de
Herança. Trata-se de um relacionamento de classificação entre um elemento mais geral e
outro mais específico. O elemento mais específico é completamente consistente com o mais
geral somando-se informação adicional especializada.

As subclasses herdam atributos, operações e associações da superclasse e agregam

atributos e operações particulares ao elemento de especialização a que se referem.
A Figura 29 mostra um exemplo do uso de herança onde Pessoa física e Pessoa
jurídica são especializações de Cliente. As sub-classes herdam todas as propriedades
(atributos, métodos, relacionamentos, generalizações) da classe genérica e, desta forma, em
virtude do polimorfismo de dados não é necessário repetir a associação entre Cliente e
Compra para todas as especializações de Cliente.
Cliente
* realiza *
nome Compra
PessoaFísica PessoaJurídica
CPF CGC
RG RazãoSocial
Sexo
DataNascimento
Figura 29. Exemplo de generalização/especialização.
3.9 Restrições
Uma restrição é um relacionamento semântico entre elementos de modelo que
especifica condições e proposições que devem ser mantidas como verdadeiras.
Certos tipos de restrições são predefinidas em UML, mas há a possibilidade de
definição de restrições por parte do usuário. Por exemplo, a Figura 30 mostra uma associação
onde a restrição é definida para limitar a possibilidade de associação entre Pessoa e Cidadãos
idosos.
Cidadãos {pessoa.idade>60}
Idosos Pessoa
0 1 0 *
Figura 30. Exemplo de uso de restrição.
Um exemplo de restrição bastante utilizada é a restrição {ou}. Ela indica que em uma
associação, uma instância da classe só pode participar uma vez no máximo de uma das
associações possíveis (cortadas pela linha tracejada). A figura a seguir ilustra um exemplo
onde uma conta corrente pertence a um indivíduo ou a uma organização.

Indivíduo
0..1
0..*
Conta
corrente {ou}
0..*
Organização
0..1
Figura 31. Uso de restrição {ou}
3.10 Estudo de Caso

A figura a seguir mostra um exemplo inicial do modelo de classes para uma
universidade. Sugere-se como exercício a complementação do modelo.
Figura 32. Estudo de caso de Controle Acadêmico de Universidade

4 DIAGRAMAS DE INTERAÇÃO
Diagrama de Interação é um termo genérico que se aplica a vários tipos de diagramas

que enfatizam interações de objetos. Uma interação é uma especificação comportamental que
inclui uma seqüência de trocas de mensagens entre um conjunto de objetos dentro de um
contexto para realizar um propósito específico, tal como a realização de um caso de uso. As
mensagens podem incluir sinais e chamadas implícitas decorrentes de condições e eventos de
tempo.
Para especificar uma interação, é necessário definir um contexto de caso de uso e
estabelecer os objetos que interagem e seus relacionamentos. Portanto, diagramas de interação
são aplicados para mostrar a realização de casos de uso e as possíveis seqüências de interação
entre objetos.
O diagrama de interação deve ser usado quando se deseja visualizar o
comportamento de vários objetos dentro de um único caso de uso, a partir de mensagens
passadas entre eles. Para se compreender o comportamento de um único objeto para muitos
casos de uso, é melhor empregar um diagrama de estado; para se analisar o comportamento de
muitos casos de uso é recomendado o diagrama de atividade. Os diagramas de interação são
apresentados de duas formas (equivalentes) em UML:
• Diagrama de Seqüência: Enfatiza o comportamento dos objetos em um sistema
incluindo suas operações, interações, colaborações e histórias de estado em
seqüência temporal de mensagem e representação explícita de ativação de
operações. Os objetos são desenhados como linhas verticais, as mensagens como
linhas horizontais e a seqüência de mensagens é lida de cima para baixo;
• Diagrama de Colaboração: Mostra o contexto completo de uma interação,
inclusive os objetos e seus relacionamentos pertinentes a uma interação
particular, sendo freqüentemente melhores para propósitos de projeto.
A figura a seguir mostra um exemplo de um diagrama de seqüência (enfatizando a
ordem de chamamento) e um diagrama de colaboração (enfatizando a interação entre os
objetos).

Figura 33 Diagramas de Seqüência e Colaboração.
4.1 Diagrama de Seqüência

Um diagrama de seqüência mostra interações de objetos organizadas em uma
seqüência de tempo e de mensagens trocadas, mas não trata associações entre os objetos como
os diagramas de colaboração.
A Figura 34 apresenta a notação utilizada para diagrama de seqüência onde são
mostrados os seus elementos básicos.

Figura 34 Elementos de um diagrama de seqüência UML [FUR98]
Um exemplo de diagrama de seqüência para o empréstimo de um livro em um

sistema de bibliotecas é apresentado na figura a seguir. Neste exemplo, o bibliotecário acessa
a janela de empréstimo que enviará mensagem para encontrar o título. Encontrado o título,
busca-se a disponibilidade do item, identifica-se o usuário e faz-se o empréstimo. Outro
exemplo de diagrama de seqüência é mostrado na Figura 36, retratando o processo de venda.
Figura 35. Exemplo de diagrama de seqüência para biblioteca [FUR 98].

Figura 36. Exemplo de diagrama de seqüência para um sistema de vendas.
4.2 Diagrama de Colaboração

Um diagrama de colaboração mostra uma interação organizada em torno de objetos e
seus vínculos formando uma base de padrões.
O diagrama de seqüência e diagrama de colaboração expressam a mesma informação
mas a apresentam de forma diferente. O primeiro exibe uma seqüência explícita de mensagens
e é melhor para especificações de tempo real (dimensão tempo) e para cenários complexos,
enquanto o segundo mostra os vínculos entre objetos e é melhor para entender os efeitos em
um determinado objeto (dimensão espaço). Para decidir qual diagrama deve ser utilizado para
estudar uma interação, uma regra geral é escolher o diagrama de colaboração quando o objeto
e seus vínculos facilitam a compreensão da interação, e escolher o diagrama de seqüência
somente se a seqüência necessita ser evidenciada.
Ao contrário de um diagrama de seqüência, um diagrama de colaboração mostra os
relacionamentos entre os objetos, mas não trata o tempo como uma dimensão separada. A
seqüência de tempo é indicada numerando-se as mensagens. Em um diagrama de colaboração
as classes e objetos são representados como na Figura 37.

Figura 37. Elementos de um diagrama de colaboração.
A Figura 38 mostra a chamada de métodos em um diagrama de colaboração e a

Figura 39 mostra algumas convenções utilizadas quando um método é chamado. A Figura 40
mostra o uso de parâmetros de métodos no diagrama de colaboração, onde é possível chamar
um método com argumentos declarando a variável e o tipo de retorno.
Figura 38. Notação UML para diagramas de colaboração.
Figura 39. Convenções do diagrama de colaboração.

Figura 40. Parâmetros de métodos em diagramas de colaboração.

5 ESTUDOS DE CASO E EXERCÍCIOS
5.1 Estudo de Caso 1: Locadora de Veículos

Modelar um sistema OO tomando por partida a definição abaixo:
“O cliente é sócio-proprietário de uma rede de locadora de carros que possui várias
filiais espalhadas por vários estados brasileiros e países do Mercosul. Cada filial possui
diversos carros para alugar. Existem vários tipos de carro: popular, luxo, utilitário, etc. Os
carros possuem código (chapa do carro), tipo, modelo, ano, cor, chassis, km e valor do
aluguel (diárias e semanais). Os clientes da locadora podem reservar e alugar carros. Existem
clientes especiais e clientes comuns. Os especiais possuem uma taxa de desconto e um valor
de quilometragem extra para seus aluguéis. Para cada aluguel é emitida uma nota fiscal com a
quilometragem percorrida e o valor do aluguel. A locadora possui funcionários que trabalham
nas filiais. As filiais são identificadas por código, nome cidade, endereço e telefones. Os
clientes são identificados por código, nome, cpf, telefone, endereço, cidade. E os funcionários
são identificados por código, nome, endereço, telefone, cidade.”
5.2 Estudo de Caso 2: Hospital

Modelar um hospital com vários setores e funcionários que presta vários tipos de serviço aos
pacientes conforme características abaixo:
• Setores são compostos de vários sub-setores. Cada setor está dividido em salas.
Existem salas de cirurgia, consultórios, apartamentos, etc.
• Os funcionários do hospital trabalham em setores e são médicos, enfermeiros e
pessoal administrativo com diversos cargos. Existem equipes de médicos e
enfermeiros com um médico como supervisor da equipe;
• Os pacientes são submetidos a procedimentos no hospital. Procedimentos são
pagos por convênios ou pelo próprio paciente (particular) e podem ser:
- Cirurgias: ocupando salas de cirurgia com equipe médica responsável;
- Internações: ocupando enfermarias ou quartos e com tratamento prescrito
(medicação e dieta);
- Consultas: com data, hora, diagnóstico, exames solicitados e receita médica,
ocupando consultórios e com médico responsável;
- Exames: solicitados em consultas médicas, registrando os resultados;
- Outros procedimentos de hospital.
• Definir novos requisitos para o sistema

REFERÊNCIAS BIBLIOGRÁFICAS
[BEZ02] BEZERRA, E. Princípios de Análise e Projeto de Sistemas com UML. São Paulo:
Campus, 2002.
[BOO94] BOOCH, G. Object-Oriented Analysis and Design with Applications.

Benjamim-Cummings Publishing Co., 1994.
[BOO00] BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: Guia do Usuário. São
Paulo: Campus, 2000.
[CHE90] CHEN, P. Modelagem de Dados: A abordagem Entidade-Relacionamento para

Projeto Lógico. Makron Books, 1990.
[COA98] COAD, P.; MAYFIELD, M. Projeto de Sistemas em Java: Construindo

aplicativos e melhores applets. São Paulo: Makron Books, 1998.
[ERI98] ERIKSSON, H.; PENKER, M. UML Toolkit. Wiley Computer Publishing, 1998.
[FUR98] FURLAN, J.D. Modelagem de Objetos através da UML. São Paulo: Makron
Books, 1998.
[GUE91] GUEZZI, C.; JAZAYERI, M. Fundamentals of Software Engineering. Prentice-

Hall, 1991.
[HEU 99] HEUSER, C. A. Projeto Orientado a Objetos. Apostila de curso. Obtida em

http://heuser.inf.ufrgs.br
[JAC92] JACOBSON, I. et. al. Object-Oriented Software Engineering: A Use Case Driven
Approach. Addison-Wesley Publishing Co., 1992.
[JAC99] JACOBSON, I.; BOOCH, G.; RUMBAUGH, J. The Unified Process. In: IEEE
Software. p. 96-102. May/June 1999.
[RUM94] RUMBAUGH, J. et. al. Modelagem e Projetos Baseados em Objetos. São Paulo:
Campus, 1994.
[TOG00] Together Inc. (http://www.togethersoft.com)

Usando UML

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Usando UML

Uploaded by

Copyright:

Available Formats

Usando UML para Especificação de Sistemas

Prof. Rodrigo Quites Reis

Modelagem de Objetos com UML

Prof. Rodrigo Quites Reis - Fevereiro/2003

2 DIAGRAMAS DE CASOS DE USO (USE CASES) ...................................................... 5

3 DIAGRAMA DE CLASSES EM UML ......................................................................... 10

4 DIAGRAMAS DE INTERAÇÃO .................................................................................. 21

5 ESTUDOS DE CASO E EXERCÍCIOS........................................................................ 27

Prof. Rodrigo Quites Reis - Fevereiro/2003

Prof. Rodrigo Quites Reis - Fevereiro/2003

2 DIAGRAMAS DE CASOS DE USO (USE CASES)

Os diagramas de caso de uso fornecem um modo de descrever a visão externa do

Figura 1. Componentes de um diagrama de caso de uso.

2.1 Caso de Uso

Prof. Rodrigo Quites Reis - Fevereiro/2003

2.2 Interação em caso de uso

Usuário A comunicação é representada através

Figura 2. Exemplo de Comunicação

• Inclusão: Quando um número de casos de uso tem comportamento comum, esse

Prof. Rodrigo Quites Reis - Fevereiro/2003

Usuário A comunicação é representada através

Figura 3 Exemplo de Inclusão

Figura 4 Exemplo de Extensão

• Generalização. Expressa um relacionamento do tipo herança entre casos de uso.

Pagto com Pagto com

Figura 5 Exemplo de Generalização

Prof. Rodrigo Quites Reis - Fevereiro/2003

2.3 Exemplos de casos de uso

O exemplo da Figura 6 mostra um diagrama de caso de uso que ilustra os serviços

Figura 6 Exemplo de diagrama de caso de uso (extraído de [FUR98])

A Figura 7 apresenta um diagrama de caso de uso para um telefone celular. Deve-se

Fazer <<includes>> Identifica

Figura 7 Exemplo de caso para telefone celular (adaptado de [BOO00])

Prof. Rodrigo Quites Reis - Fevereiro/2003

2.3.3 Sistema de Vendas [TOG00]

A Figura 8 mostra um diagrama de caso de uso fornecido como exemplo na

Figura 8. Caso de uso de Sistema de vendas.

Prof. Rodrigo Quites Reis - Fevereiro/2003

3 DIAGRAMA DE CLASSES EM UML

O modelo de objetos em UML é representado através de um diagrama de classes.

3.1 Classes e seus relacionamentos

Figura 9. Notação para classe em UML

Os tipos principais de relacionamentos entre classes são:

• Dependência: Um relacionamento entre um elemento independente e outro

3.2 Associações Simples

Figura 10. Exemplo de associação unária.

Associação Binária: Expressa o relacionamento entre duas classes distintas. A Figura 11

Figura 11 Exemplo de associação binária

titular na Figura 12.

Figura 12 Segundo exemplo de associação binária

As associações têm sua semântica definida como relações entre conjuntos. O

Figura 13 Mapeamento da semântica estrutural de uma associação

Prof. Rodrigo Quites Reis - Fevereiro/2003

Figura 14. Representação de associação ternária.

3.3 Multiplicidade (Cardinalidade)

A cardinalidade das associações em um diagrama de classes é denominada de

A Figura 15 mostra um exemplo de uso de multiplicidade onde a classe financeira

Prof. Rodrigo Quites Reis - Fevereiro/2003

financia realizada por

Figura 15. Financeira: exemplo de uso de multiplicidade (adaptado de [HEU 99])

3.4 Classes Associativas

Figura 16. Exemplo de classe associativa em uma associação unária.

A Figura 17 mostra um exemplo de associação onde é representado que quando

Prof. Rodrigo Quites Reis - Fevereiro/2003