Vous êtes sur la page 1sur 37

Universidade Federal do Pará

Centro de Ciências Exatas e Naturais


Departamento de Informática

Modelagem de Objetos com


UML

Prof. Rodrigo Quites Reis, M.Sc.


http://sites.uol.com.br/quites
Junho, 2000

Modelagem de Objetos com UML – 1


Modelagem de Objetos com UML
Autoria: Rodrigo Quites Reis
Última atualização: Maio/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.

UNIVERSIDADE FEDERAL DO PARÁ


Centro de Ciências Exatas e Naturais
Departamento de Informática – http://www.ccen.ufpa.br
Fone: (91) 211-1409

Modelagem de Objetos com UML – 2


SUMÁRIO

1 INTRODUÇÃO .................................................................................................................4

2 MODELO DE OBJETOS EM UML ............................................................................... 5


2.1 Classes e seus relacionamentos..................................................................................... 5
2.2 Tipos de Associações entre classes............................................................................... 6
2.3 Multiplicidade (Cardinalidade) ..................................................................................... 7
2.4 Classes Associativas ..................................................................................................... 8
2.5 Qualificador ................................................................................................................ 10
2.6 Agregação ................................................................................................................... 11
2.6.1 Agregação Compartilhada......................................................................................................... 12
2.7 Navegabilidade ........................................................................................................... 12
2.8 Generalização/Especialização..................................................................................... 13
2.8.1 Restrições de Herança ............................................................................................................... 14
2.9 Restrições .................................................................................................................... 15
2.10 Interface .................................................................................................................... 15
2.11 Resumo da Notação .................................................................................................. 16
2.12 Estudo de Caso.......................................................................................................... 17

3 DIAGRAMAS DE CASOS DE USO (USE CASES) .................................................... 19


3.1 Caso de Uso ................................................................................................................20
3.2 Interação em caso de uso ............................................................................................ 20
3.3 Exemplos de casos de uso........................................................................................... 21
3.3.1 Caixa eletrônico [FUR98] ......................................................................................................... 21
3.3.2 Biblioteca [ERI98] .................................................................................................................... 22
3.3.3 Sistema de Vendas [TOG00]..................................................................................................... 23

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


4.1 Diagrama de Sequência............................................................................................... 25
4.2 Diagrama de Colaboração........................................................................................... 28

5 DIAGRAMA DE TRANSIÇÃO DE ESTADO............................................................. 31


5.1 Elementos do diagrama de estado............................................................................... 31
5.1.1 Estado........................................................................................................................................ 32
5.1.2 Eventos...................................................................................................................................... 32
5.1.3 Transições ................................................................................................................................. 33
5.2 Exemplos..................................................................................................................... 33

6 ESTUDOS DE CASO E EXERCÍCIOS........................................................................ 36


6.1 Estudo de Caso 1: Locadora de Veículos.................................................................... 36
6.2 Estudo de Caso 2: Hospital ......................................................................................... 36

REFERÊNCIA BIBLIOGRÁFICA...................................................................................... 37

Modelagem de Objetos com UML – 3


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., sendo
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.

Modelagem de Objetos com UML – 4


2 MODELO DE OBJETOS 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 metodologia.

2.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 1 mostra a notação UML para classes.

Figura 1. 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;

Modelagem de Objetos com UML – 5


• Associação: 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.

2.2 Tipos de Associações entre classes


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 a seguir mostra um exemplo de associação unária:

Funcionário 1

* supervisiona

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

Associação Binária: Relacionamento entre duas classes distintas. A figura a seguir ilustra o
exemplo de associação binária:

Funcionário 0..* trabalha 4 1 Departamento

Figura 3. Exemplo de Associação binária.

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:

Modelagem de Objetos com UML – 6


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

2.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 a seguir mostra um exemplo de uso de multiplicidade onde a classe


Modelagem de Objetos com UML – 7
financeira está associada a 0 ou mais vendas da classe venda através da associação
financiamento. E a classe venda está associada a no máximo um elemento da classe vendedor
através da associação venda (notar que o nome da associação pode ser um substantivo).

Figura 5. Exemplo de uso de multiplicidade.

2.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 a seguir ilustra um exemplo de classe associativa onde quando ocorre um

casamento entre dois vendedores, então uma classe associativa armazena a data do casamento
e o regime.
Figura 6. Exemplo de classe associativa em uma associação unária.

Modelagem de Objetos com UML – 8


A figura a seguir mostra um exemplo de associação onde é representado que quando
ocorre o financiamento de uma venda, são guardadas também as informações do
financiamento. Deve-se notar que nem toda venda é financiada, e que a classe associativa
também possui métodos.

Figura 7. Exemplo de classe associativa com associação binária.

A figura a seguir ilustra um exemplo de classe associativa em associação n:n. Neste


exemplo os itens de venda são representados através de uma classe associativa.

Figura 8. Exemplo de classe associativa n:n.

Uma classe associativa pode ser transformada em uma classe regular conforme

Modelagem de Objetos com UML – 9


mostra a figura a seguir.

Figura 9. Transformação de uma classe associativa em classe regular.

2.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 consequê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 10. 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 11. Exemplo de qualificador.

Modelagem de Objetos com UML – 10


2.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 12. Agregação regular ou relacionamento por referência.

Todo Parte

Agregação de composição

Figura 13. Agregação de composição ou relacionamento por valor.

Um exemplo de agregação é apresentado a seguir:

Figura 14. Exemplo de agregação.

Modelagem de Objetos com UML – 11


Outro exemplo de agregação com notação compacta é apresentado na figura a seguir,
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 15. Agregação de várias classes com notação compacta.

2.6.1 Agregação Compartilhada

É um tipo de agregação onde as partes podem ser de vários “todos”. A figura a seguir
mostra um exemplo onde um time é composto de vários membros e uma pessoa pode ser um
membro de muitos times.
* membros *
Time Pessoas

Figura 16. Exemplo de agregação compartilhada.

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

Modelagem de Objetos com UML – 12


pedido tem a responsabilidade de informar a qual cliente pertence, mas um cliente em

fonte alvo
Pedido * 1 Cliente

navegabilidade
particular não precisa indicar quais pedidos possui.

Figura 17. Exemplo de Navegabilidade

2.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 a seguir mostra um exemplo do uso de herança onde Pessoa física e Pessoa
jurídica são especializações de Cliente. As entidades especializadas herdam todas as
propriedades (atributos, métodos, relacionamentos, generalizações) da entidade genérica.

Figura 18. Exemplo de generalização/especialização.


Modelagem de Objetos com UML – 13
2.8.1 Restrições de Herança

Podem ser usadas restrições predefinidas para indicar condições semânticas entre
subclasses. Uma lista de palavras-chaves separada por vírgula é colocada entre chaves
próxima ao triângulo da herança ou próximo a uma linha tracejada que cruza a generalização
(ver figura abaixo). As palavras-chaves que podem ser usadas são apresentadas na tabela 2.

Figura 19. Uso de restrição na herança.

Tabela 2 – Restrições de herança.


Palavra-chave Semântica
{Sobreposição} Subclasses derivadas de uma superclasse podem ocorrer
simultaneamente para uma mesma ocorrência da superclasse
{Disjunção} Subclasses derivadas de uma superclasse podem ocorrer de maneira
mutuamente exclusiva para uma mesma ocorrência da superclasse
{Completo} Todas as subclasses foram especificadas. Nenhuma subclasse adicional é
esperada
{Incompleto} Algumas subclasses foram especificadas mas a lista está incompleta.

Modelagem de Objetos com UML – 14


2.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 20 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 20. 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.

0..1 Indivíduo

0..*
Conta {ou}
Organização
Corrente 0..* 0..1

Figura 21. Uso de restrição {ou}

2.10 Interface
Uma interface é um especificador para operações externamente visíveis de uma classe
ou componente. Um pacote, componente ou classe que possui uma interface conectada
implementa ou suporta a interface através da implementação do comportamento definido na
Modelagem de Objetos com UML – 15
interface. A representação de interface é através de um pequeno círculo conectado a classe
que a suporta. A classe que usa a interface implementada por outra classe é conectada através
de um relacionamento de dependência conforme mostra a figura seguir.

Classe de Classe
implementação Nome da interface cliente

dependência

Figura 22. Representação compacta de interface.

Além da representação compacta, uma interface pode ser representada da mesma


forma que uma classe comum, porém como a palavra-chave <<interface>> antes do nome da
classe e {abstrato} após o nome. Apenas o compartimento de métodos é preenchido nesta
representação em virtude de não existirem atributos em interfaces.

<<interface>>
nome da interface
{abstrato}

Método1 {abstrato}
Método 2 {abstrato}
...
Método N {abstrato}
Figura 23. Representação de interface.

2.11 Resumo da Notação


A figura a seguir mostra um resumo da notação utilizada para modelo de classes em
UML. Os elementos da notação são identificados através do uso de um sistema de pedidos
como exemplo.

Modelagem de Objetos com UML – 16


Figura 24. Resumo da notação UML para modelo de classes.

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

Modelagem de Objetos com UML – 17


Figura 25. Estudo de caso de Universidade.

Modelagem de Objetos com UML – 18


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

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

Modelagem de Objetos com UML – 19


3.1 Caso de Uso
Cada caso de uso especifica um serviço que a classe fornece a seus usuários. São
especificadas uma sequência completa iniciada por um usuário, as interações entre os usuários
e as classes, bem como as respostas executadas pela classe. Um caso de uso também inclui
possíveis variantes dessa sequência, como por exemplo sequências alternativas,
comportamento excepcional, manipulação de erro, etc. O conjunto completo de casos de uso
exibe todos os modos diferentes para utilizar a classe, o que significa que todo o
comportamento da classe é expresso pelos seus casos de uso.
Cada caso de uso é uma sequê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 são cliente, usuário, gerente, computador, impressora, etc.

3.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). Projeta-se o fluxo de controle entre objetos de forma que as operações
formais sejam invocadas nos momentos apropriados dentro da realização do caso de uso. Para
isso é mostrado o sistema em diagramas de interação, mas também em diagramas de estado
para as classes constituintes. 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;
• Extensão: É usada para mostrar comportamento de exceção e casos especiais
que aumentariam a quantidade de casos de uso no modelo. Trata-se de um
relacionamento de um caso de uso para outro, especificando como o
comportamento definido para o primeiro caso pode ser inserido no
comportamento definido para o segundo. Um relacionamento de extensão do
caso de uso A para o caso de uso B indica que uma instância de B pode incluir o
comportamento especificado por A.
• Uso: Quando um número de casos de uso tem comportamento comum, esse
comportamento pode ser modelado em um simples caso de uso que é utilizado

Modelagem de Objetos com UML – 20


por outros casos. Um relacionamento de uso entre casos ocorre quando há uma
parcela de comportamento similar entre eles sugerindo uma reutilização em vez
de nova cópia da descrição do comportamento. É desenhado como uma seta de
generalização do caso de uso que faz o uso ao caso de uso que é usado,
etiquetada com <<usa>>. Um relacionamento de uso do caso de uso A para o
caso de uso B indica que uma instância do caso de uso A também incluirá o
comportamento como especificado por B
Na figura a seguir, “Requisitar catálogo de pedido” estende “Colocar pedido” e
“Colocar Pedido” usa “Pedir Produto”.

<<estende>>
Colocar
pedido Requisitar
catálogo do
pedido
<<usa>>

Pedir
Produto

Figura 27. Relacionamentos em caso de uso [FUR 98].

3.3 Exemplos de casos de uso


3.3.1 Caixa eletrônico [FUR98]

Modelagem de Objetos com UML – 21


3.3.2 Biblioteca [ERI98]

Modelagem de Objetos com UML – 22


3.3.3 Sistema de Vendas [TOG00]

Figura 28. Caso de uso de Sistema de vendas.

Modelagem de Objetos com UML – 23


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 sequência de trocas de mensagens entre um conjunto de objetos dentro de um
contexto para realizar um proposito 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 sequê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 Sequência: Enfatiza o comportamento dos objetos em um sistema
incluindo suas operações, interações, colaborações e histórias de estado em
sequê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 sequê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 frequentemente melhores para propósitos de projeto.

A figura a seguir mostra um exemplo de um diagrama de sequência (enfatizando a


ordem de chamamento) e um diagrama de colaboração (enfatizando a interação entre os
objetos).

Modelagem de Objetos com UML – 24


Figura 29. Diagramas de Sequência e Colaboração.

4.1 Diagrama de Sequência


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

Modelagem de Objetos com UML – 25


Figura 30 Elementos de um diagrama de sequência UML [FUR98]

Um exemplo de diagrama de sequê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 sequência é mostrado na Figura 32, retratando o processo de venda.

Modelagem de Objetos com UML – 26


Figura 31. Exemplo de diagrama de sequência para biblioteca [FUR 98].

Figura 32. Exemplo de diagrama de sequência para um sistema de vendas.

Modelagem de Objetos com UML – 27


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.
Diagrama de sequência e diagrama de colaboração expressam informação
semelhante mas a apresentam de forma diferente. O primeiro exibe uma sequê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 sequência somente se a sequência necessita ser evidenciada.
Ao contrário de um diagrama de sequência, um diagrama de colaboração mostra os
relacionamentos entre os objetos, mas não trata o tempo como uma dimensão separada. A
sequência de tempo é indicada numerando-se as mensagens. Em um diagrama de colaboração
as classes e objetos são representados como mostra a figura a seguir.

Figura 33. Elementos de um diagrama de colaboração.

A Figura 34 mostra a chamada de métodos em um diagrama de colaboração e a


Figura 35 mostra algumas convenções utilizadas quando um método é chamado. A Figura 36
mostra o uso de parâmetros de métodos no diagrama de colaboração, onde é possível chamar
Modelagem de Objetos com UML – 28
um método com argumentos declarando a variável e o tipo de retorno.

Figura 34. Notação UML para diagramas de colaboração.

Figura 35. Convenções do diagrama de colaboração.

Modelagem de Objetos com UML – 29


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

Modelagem de Objetos com UML – 30


5 DIAGRAMA DE TRANSIÇÃO DE ESTADO

Diagramas de estado foram introduzidos por D. Harel e têm sido utilizados na


orientação a objetos para prover uma definição formal explícita de comportamento. A
modelagem da transição de estados de um sistema permite uma verificação dos eventos e
transições de estados aos quais um sistema está sujeito.
A UML propõe o emprego de diagrama de estado de maneira individualizada para
cada classe, com o objetivo de tornar o estudo simples o bastante para se ter um diagrama de
estado compreensível. Modelos de estado são ideais para descrever o comportamento de um
único objeto, mas não para descrever adequadamente o comportamento que envolve vários
objetos (para isso é melhor usar um diagrama de interação ou atividade). A semântica e a
notação da UML para diagramas de estado são as mesmas das máquinas de estado finitas de
Harel com as seguintes modificações secundárias:
• Guardas em transições
• Transições propagadas
• Ações em transições
• Ações em estado inicial
• Atividades que acontecem desde que um estado esteja ativo
• Ações em um estado final
• Aninhamento de estados
• Concorrência

5.1 Elementos do diagrama de estado

A Figura 37 mostra os elementos da notação do diagrama de estado e as seções a


seguir apresentam a definição e semântica de cada elemento.

Modelagem de Objetos com UML – 31


Nome-do-estado Estado inicial

entrar: ação de entrada


fazer: atividade A
no evento 1: ação 1 Estado final
...
Sair: ação de saída
Assinatura-de-evento [condição de guarda] /

expressão de ação ^ cláusula de envio

Figura 37. Notação do Diagrama de Estado.

5.1.1 Estado

Todos os objetos possuem um estado. O estado é o resultado de atividades


previamente realizadas e é determinado pelos valores dos atributos ou ligações com outros
objetos. Uma classe pode conter um atributo específico de estado ou o estado pode ser
determinado através de outros valores do objeto.
Os estados dos objetos são normalmente rotulados com verbos no gerúndio (por
exemplo, discando, tocando) ou então com substantivos que claramente indiquem um estado
para o objeto.

5.1.2 Eventos

Um evento é algo que pode acontecer e causar alguma ação. Por exemplo, apertar o
botão “play” do CD player é um evento que faz com que o aparelho comece a tocar (ação).
Existem quatro tipos de eventos em UML:
• Uma condição se torna verdadeira: Mostrado como uma condição de guarda na
transição de estados;
• Recepção de um sinal explícito de outro objeto: O sinal é mostrado como uma
assinatura de evento na transição de estado. Este tipo de evento é chamado
mensagem;
• Recepção de uma chamada a uma operação por outro objeto (ou pelo próprio
objeto): Mostrado como uma assinatura de evento em transições de estado.
Também é uma mensagem;

Modelagem de Objetos com UML – 32


• Passagem de tempo: O tempo é calculado após um evento ou a passagem de um
determinado período de tempo. Mostrado como uma expressão de tempo em uma
transição de estado.
É importante notar que a semântica de eventos indica que são processados um de
cada vez. Se um evento puder ativar mais de uma transição, apenas uma será ativada. Se um
evento ocorrer, e a condição de guarda for falsa, então o evento será ignorado

5.1.3 Transições

Em um diagrama de estados, uma transição é uma seta ligando um estado a outro,


etiquetada por uma sequência de transição cujo significado é:
• Assinatura de evento: contém o nome do evento mais parâmetros;
• Condição de guarda: Expressão booleana escrita em termos de parâmetros do
evento de disparo, atributos e vínculos do objeto que possui a máquina de estado.
Uma guarda é uma condição que deve ser satisfeita antes de ocorrer a transição;
• Expressão de ação: Expressão procedural executada no disparo da transição.
Pode ser descrita em termos de operações, atributos e vínculos de objeto e
parâmetros do evento de disparo. Deve ser uma operação atômica e pode vir
acompanhada de outras expressões de ação separadas por “/”;
• Cláusula de envio: É um caso especial de ação com o formato:
Expressão de destino “.” Nome-do-evento-de-destino “(“argumento “.” ... “(“
Onde:
- Expressão-de-destino é uma expressão relacionada a um objeto ou a um
conjunto de objetos. Pode ser escrita em termos dos parâmetros de evento
de disparo e os atributos e vínculos do objeto considerado;
- Nome-do-evento-de-destino é o nome de um evento significativo para o
objeto de destino.

5.2 Exemplos
A Figura 38 mostra exemplos de diagramas de estados para um sistema eleitoral e a
figura 39 mostra o diagrama de estados do sistema de vendas.

Modelagem de Objetos com UML – 33


Eleitor

Apresentando
documentos
Urna
Habilita voto

Votando
Fecha urna
Esperando em prefeito
Voto prefeito
Habilita voto

Votando Votando
em prefeito em vereador

Voto prefeito Voto vereador

Votando Aguardando
em vereador comprovante
Voto vereador Comprovante recebido

Figura 38 Estados para classes Urna e Eleitor de um sistema eleitoral

Modelagem de Objetos com UML – 34


Figura 39. Diagrama de estados para uma venda no sistema de vendas.

Modelagem de Objetos com UML – 35


6 ESTUDOS DE CASO E EXERCÍCIOS

6.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.”

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

Modelagem de Objetos com UML – 36


REFERÊNCIA BIBLIOGRÁFICA

[BOO94] BOOCH, G. Object-Oriented Analysis and Design with Applications.


Benjamim-Cummings Publishing Co., 1994.

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

Modelagem de Objetos com UML – 37