Вы находитесь на странице: 1из 28

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


Usando UML para Especificação de Sistemas Orientados a Objetos

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

Prof. Rodrigo Quites Reis - Fevereiro/2003


Usando UML para Especificação de Sistemas Orientados a Objetos

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.

Prof. Rodrigo Quites Reis - Fevereiro/2003


Usando UML para Especificação de Sistemas Orientados 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

Prof. Rodrigo Quites Reis - Fevereiro/2003


Usando UML para Especificação de Sistemas Orientados a Objetos

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.

Prof. Rodrigo Quites Reis - Fevereiro/2003


Usando UML para Especificação de Sistemas Orientados a Objetos

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

Prof. Rodrigo Quites Reis - Fevereiro/2003


Usando UML para Especificação de Sistemas Orientados a Objetos

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])

Prof. Rodrigo Quites Reis - Fevereiro/2003


Usando UML para Especificação de Sistemas Orientados a Objetos

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.

Prof. Rodrigo Quites Reis - Fevereiro/2003


Usando UML para Especificação de Sistemas Orientados a Objetos

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);
Prof. Rodrigo Quites Reis - Fevereiro/2003
Usando UML para Especificação de Sistemas Orientados a Objetos

• 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
Prof. Rodrigo Quites Reis - Fevereiro/2003
Usando UML para Especificação de Sistemas Orientados a Objetos

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

Funcionário Departamento

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:

Prof. Rodrigo Quites Reis - Fevereiro/2003


Usando UML para Especificação de Sistemas Orientados a Objetos

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).

Prof. Rodrigo Quites Reis - Fevereiro/2003


Usando UML para Especificação de Sistemas Orientados a Objetos

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

Prof. Rodrigo Quites Reis - Fevereiro/2003


Usando UML para Especificação de Sistemas Orientados a Objetos

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.

Funcionário Departamento
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.
Prof. Rodrigo Quites Reis - Fevereiro/2003
Usando UML para Especificação de Sistemas Orientados a Objetos

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.


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

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.

Prof. Rodrigo Quites Reis - Fevereiro/2003


Usando UML para Especificação de Sistemas Orientados a Objetos

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.

Prof. Rodrigo Quites Reis - Fevereiro/2003


Usando UML para Especificação de Sistemas Orientados a Objetos

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
Prof. Rodrigo Quites Reis - Fevereiro/2003
Usando UML para Especificação de Sistemas Orientados a Objetos

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

Prof. Rodrigo Quites Reis - Fevereiro/2003


Usando UML para Especificação de Sistemas Orientados a Objetos

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).

Prof. Rodrigo Quites Reis - Fevereiro/2003


Usando UML para Especificação de Sistemas Orientados a 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.

Prof. Rodrigo Quites Reis - Fevereiro/2003


Usando UML para Especificação de Sistemas Orientados a Objetos

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].


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

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.

Prof. Rodrigo Quites Reis - Fevereiro/2003


Usando UML para Especificação de Sistemas Orientados a Objetos

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.

Prof. Rodrigo Quites Reis - Fevereiro/2003


Usando UML para Especificação de Sistemas Orientados a Objetos

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

Prof. Rodrigo Quites Reis - Fevereiro/2003


Usando UML para Especificação de Sistemas Orientados a Objetos

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

Prof. Rodrigo Quites Reis - Fevereiro/2003


Usando UML para Especificação de Sistemas Orientados a Objetos

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)

Prof. Rodrigo Quites Reis - Fevereiro/2003