A notao UML

Introduo

Este apndice apresenta os principais conceitos da UML (Unified Modeling Language) que so
utilizados neste livro. No objetivo deste texto a descrio completa de cada conceito, e muitos so
apresentados de forma simplificada; os interessados nas descries completas devem consultar
[Rumbaugh+99] ou as especificaes oficiais da UML, que podem ser obtidas no stio do OMG
(Object Management Group).
Por outro lado, utilizam-se aqui algumas convenes de notao que o processo Praxis adota, em
situaes nas quais a UML permite o uso de alternativas. Por exemplo, as convenes de descrio
textual dos casos de uso no so estipuladas pela UML, mas so aqui includas por estarem
intimamente associadas maneira de utilizao dos casos de uso dentro do Praxis.

2
2.1

Modelagem funcional
Atores

Os papis dos usurios de um produto so modelados atravs dos atores (Figura 1). Cada ator
representa uma classe de usurios. Os atores modelam os papis e no as pessoas dos usurios; por
exemplo, o mesmo usurio fsico pode agir como Gerente, Gestor de Estoque ou Gestor de
Compras. Pode-se tambm definir atores no humanos, para modelar outros sistemas que devam
interagir com o produto em questo: por exemplo, o Sistema Financeiro.

Caix ei ro

G es tor de
Com pras

G es tor de
E s toque

G erente

S is tem a
Financ eiro

Figura 1 - Exemplos de atores

Caso exista grande nmero de atores, deve-se procurar agrup-los em atores genricos, que
representem caractersticas comuns a vrios grupos de usurios de comportamento semelhante em
relao ao produto. Atores genricos e especficos so ligados por relacionamentos de herana. Na
Figura 2, indica-se que Gerente de Vendas e Gerente de Compras tm alguns aspectos em comum,
que so abstrados atravs do ator Gerente.

G er ente

G ere nte de
Com pras

G erente de
V endas

Figura 2 Herana entre atores

2.2

Casos de uso

Os casos de uso representam funes completas do produto. Um caso de uso realiza um aspecto maior
da funcionalidade do produto: deve gerar um ou mais benefcios para o cliente ou os usurios. Na
Figura 3 so mostrados os casos de uso que representam a funcionalidade de um produto de
informatizao de uma mercearia. O conjunto dos casos de uso cobre toda a funcionalidade do
produto, e cada caso de uso representa uma fatia independente de funcionalidade.

G e st o d e U su ri o s

Em i sso d e R e l a t rio s

E m i ss o d e N o ta Fi sc a l

G e st o M a n u a l d e E sto q u e

A b e rtu ra d o C a i x a

G e st o d e M e rca d o ri a s

Fe c h a m e n to d o Ca i xa

O p er a o de V e n da

G e st o d e Fo rn ec e do re s

G e st o d e P e d i d o s d e C o m p ra s

Figura 3 - Casos de uso

2.3
2.3.1

Diagramas de casos de uso

Relacionamentos entre atores e casos de uso

Diagramas de casos de uso podem especificar os relacionamentos entre casos de uso e atores (Figura
4). Os relacionamentos indicam a existncia de comunicao entre atores e casos de uso. Um caso de
uso pode estar associado a mais de um ator, quando a sua execuo requer a participao de diferentes
atores.

A bertura do Caix a

G erente

F ec ham ento do Caix a

Figura 4 - Exemplo de casos de uso de um ator

Normalmente, a comunicao ser representada como ligao sem direo; convenciona-se, nesse
caso, que a iniciativa de comunicao parte do ator. Quando a iniciativa parte do caso de uso (por
exemplo, alarmes, mensagens, dados enviados para outros sistemas etc.), a comunicao deve ser
direcionada para o ator (Figura 5). Nesse exemplo, o caso de uso Gesto Manual de Estoque,
acionado pelo ator Gestor de Estoque, envia dados para o Sistema Financeiro.

G es tor de
E s toque

G es to M anual de E s toque

S is tem a
F inanc eiro

Figura 5 - Caso de uso com mais de um ator

Os diagramas de casos de uso podem ser simplificados por meio da herana entre atores. Neste caso,
mostra-se um caso de uso comum aos atores especficos, que se comunicam apenas com o ator
genrico (Figura 6). Neste exemplo, tanto o Gerente de Compras quando o Gerente de Vendas
podem executar o caso de uso Emisso de relatrios, porque eles so herdeiros (especializaes) de
Gerente.

G erente de
V endas

G erente

V enda
E m is s o de relatrios

Gerente de
C om pras

C om pra

Figura 6 Uso de atores genricos

O diagrama de contexto (Figura 7) um diagrama de casos de uso que mostra as interfaces do produto
com seu ambiente de aplicao. Os diversos tipos de usurios e outros sistemas com os quais o produto
deva interagir so representados por atores situados fora de um retngulo que marca a fronteira do
produto.

Operacao de Venda

Caixeiro

Sistema
Financeiro

Gesto Manual de Estoque

Gestor de
Estoque

Abertura do Caixa

Gesto de Pedidos de Compras

Fechamento do Caixa

Gesto de Mercadoria

Gerente

Gesto de Usurios

Gesto de Fornecedores

Gestor de
Compras

Emisso de Relatrios

Figura 7 - Diagrama de contexto

2.3.2

Relacionamentos entre casos de uso

Notaes especiais so utilizadas para facilitar a descrio de funcionalidade mais complexa. Entre
estas notaes, destacam-se os casos de usos secundrios, que simplificam o comportamento dos casos
de uso primrios atravs dos mecanismos de extenso e incluso. No Praxis, casos de uso primrios
so aqueles que so invocados por iniciativa direta de um ator; casos de uso secundrios so invocados
em um passo de outro caso de uso. Os termos primrio e secundrio, quando referentes a casos de
uso, no fazem parte da UML.
O caso de uso B estende o caso de uso A quando B representa uma situao opcional ou de exceo,
que normalmente no ocorre durante a execuo de A. Essa notao pode ser usada para representar
fluxos complexos opcionais ou anormais. O caso de uso estendido referenciado nas precondies
do caso de uso extensor. As precondies so a primeira parte dos fluxos dos casos de uso. Na
Figura 8, a Emisso de Nota Fiscal uma funcionalidade que pode ser invocada ou no, durante a
Operao de Venda.

<<extend>>

Emisso de Nota Fiscal

Operao de Venda

Caixeiro

Figura 8 - Caso de uso de extenso

O caso de uso A inclui o caso de uso B quando B representa uma atividade complexa, comum a vrios
casos de uso. Essa notao pode ser usada para representar subfluxos complexos e comuns a vrios
casos de uso. O caso de uso includo referenciado no fluxo do caso de uso incluidor. Na Figura
9, Baixa no Estoque representa um comportamento comum a Gesto Manual de Estoquee
Operao de Venda.

Gesto Manual de Estoque

Gestor de
Estoque

<<include>>

Baixa no Estoque
<<include>>

Operao de Venda

Caixeiro

Figura 9 - Caso de uso de incluso

2.4

Fluxos dos casos de uso

No Praxis, os fluxos dos casos de uso so detalhados por meio de descries textuais. A UML no
impe formatos obrigatrios para as descries dos fluxos, mas a forma de descrio textual aqui
apresenta semelhante s formas usadas pela maioria dos autores que utilizam os casos de uso.
O detalhamento dos fluxos dos casos inclui as suas precondies, ou seja, as condies que supem
estejam satisfeitas, ao iniciar a execuo de um caso de uso (Tabela 1); o fluxo principal, que
representa a execuo mais normal da funo; e os subfluxos e fluxos alternativos, que representam
variantes que so executadas sob certas condies. A UML permite que diversas notaes sejam
utilizadas para descrever os detalhes dos casos de uso.
Toda mercadoria a ser vendida (item de venda) deve estar previamente cadastrada.
O Merci deve estar no Modo de Vendas.
Tabela 1 - Precondies de um caso de uso

Os fluxos so comumente descritos em linguagem natural, na forma de uma seqncia de passos

(Tabela 2). Cada passo corresponde a uma ao de um ator ou do produto; estes devem aparecer
explicitamente como sujeitos da frase. Outros atores podem aparecer como objetos verbais de uma
ao. Condies e iteraes podem aparecer, mas os detalhes destas devem ser descritos em subfluxos,
de preferncia. Isso ajuda a manter a legibilidade do fluxo, que essencial para garantir o bom
entendimento de todas as partes.
6

O Caixeiro faz a abertura da venda.

O Merci gera o cdigo da operao de venda.
Para cada item de venda, o Merci aciona o subfluxo Registro.
O Caixeiro registra a forma de pagamento.
O Caixeiro encerra a venda.
Para cada item de venda, o Merci aciona o subfluxo Impresso de Linha do Ticket.
O Merci notifica o Sistema Financeiro informando: Data, Nmero da Operao de Venda, Receita, Valor
Total, Nome do Cliente (caso tenha sido emitida a nota fiscal).
Tabela 2 - Fluxo principal

Quando uma condio ou iterao for composta por uma seqncia muito curta de passos, elas podem
ser representadas por meio de endentao.
O Gestor de Compras seleciona a mercadoria.
O Merci verifica se existe algum pedido pendente que contenha esta mercadoria.
Se no houver pedido pendente contendo a mercadoria a ser excluda:
o Merci desvincula a mercadoria dos fornecedores (os fornecedores no mais fornecero a mercadoria
que esta sendo excluda).
o Merci faz a remoo da mercadoria.
Se houver pedido pendente contendo a mercadoria a ser excluda
o Merci emite uma mensagem de erro.
Tabela 3 Fluxo principal com condicionais endentados

Os subfluxos descrevem geralmente detalhes de iteraes, ou de condies executadas com freqncia

(Tabela 4).
O Caixeiro registra o item de venda, informando a identificao e a quantidade.
O Merci totaliza a venda para o cliente da mercearia.
Tabela 4 - Exemplo de subfluxo: Registro de item em Operao de Venda

Os fluxos alternativos descrevem condies pouco habituais ou excees (Tabela 5).

Se o Gestor de Compras solicitar:
o Merci imprime o pedido de compra.
Tabela 5 - Exemplo de fluxo alternativo: Impresso de Pedido de Compras

2.5

Diagramas de estados

Para casos de uso complexos, pode-se descrever seu comportamento de maneira mais formal, atravs
de um diagrama de estados ou diagrama de atividade da UML. Diagramas de estados so utilizados
para descrever fluxos de lgica complexa ou com muitos detalhes, como costuma acontecer nos casos
de uso de desenho (Figura 10). As principais convenes so mostradas na Tabela 6.

Smbolo

Descrio

Retngulo com cantos

arredondados

Estado.

Seta cheia

Transio entre estados diferentes ou de um estado

para si mesmo (transies reflexivas).

Pequeno crculo cheio

Estado inicial.

Crculo cheio dentro

de crculo vazio

Estado final.

Tabela 6 - Smbolos dos diagramas de estados

Os eventos que provocam as transies aparecem como rtulos destas. Se a transio depender de uma
condio, esta pode ser representada por uma guarda (texto entre colchetes). Anotaes so utilizadas
para complementar o modelo; por exemplo, indica-se, na Figura 10, que se pode invocar a tela de nota
fiscal no estado Atualizada.

E m itir N F

F ec ha r
[ c o nf irm a o ]

Tela d e N ota

A tua li za da

F is c a l

In c luir I tem

F ec har

E x c lu ir Ite m [ s e algu m it em

[ c o nf irm a o ]
C on f irm ar V en da

tiv e r s id o s e le c io n ad o ]

A lte ra da

V azia
C an ce la r Vend a

O K, C a nc ela r[ s e e x is t ir

In c luir I tem

a lgu m it em inc lu d o ]
In c lui r It em

C an c e la r [ s e
n o e x is tir n en hu m it em inc lu d o ]
In c lu ind o Ite m

Figura 10 Diagrama de estado de caso de uso

Diagramas de estado podem ser usados para mostrar lgica bastante complexa. Na Figura 11, os
estados complexos X e Y tem subestados, que so usados para exprimir a seguinte lgica:

O estado inicial conduz a X, dentro qual existe um subestado inicial que conduz a X1. Ao entrar
em X1, a ao A0 executada. O evento E1 leva ao subestado X2.

No subestado X2, se o evento E2 ocorrer com a condio C1, executada a ao A1 e continua-se

no subestado X2. Se E2 ocorrer com a condio C1 falsa, executa-se a ao A2 e passa-se para o
subestado Y1 do estado Y.
8

Durante a permanncia no subestado Y1 executada a ao A4. Se no subestado Y1 ocorrer o

evento E3, executa-se a ao A3 e passa-se ao subestado Y2.

Se no subestado Y2 ocorrer o evento E4, volta-se ao estado X; na sada de Y2 envia-se o evento

E5, que pode provocar alguma transio no mostrada nesse diagrama.

Se no estado Y (em qualquer subestado) ocorrer o evento E6, vai-se para um estado final.

E 2[ C1 ] / A1

X
E1

X1

X2

entry : A 0

E 2[ ~ C1 ] / A 2

E4
Y

E3 / A 3

Y1
E6

do: A 4

Y2
ex i t: ^E5

Figura 11 Diagrama de estados complexo

2.6

Diagramas de atividade

Estes diagramas so uma variante dos fluxogramas, sendo geralmente usados para descrever processos
de negcio, ou outros fluxos onde o paralelismo de atividades seja importante. A Figura 12 apresenta
um exemplo de diagrama de atividades. A Tabela 7 explica os smbolos usados.

Smbolo

Descrio

Retngulo ovalado

Atividade (passo do fluxo).

Retngulo

Objeto (artefato do fluxo).

Seta cheia

Relao de precedncia entre atividades.

Seta pontilhada

Consumo ou produo de objeto por atividade.

Linha horizontal cheia Ponto de sincronizao (onde subfluxos paralelos se

juntam).
Pequeno crculo cheio

Estado inicial.

Crculo cheio dentro

de crculo vazio

Estado final.

Tabela 7 - Smbolos dos diagramas de atividades

Nesse exemplo, mostra-se que as atividades Detalhamento dos requisitos de interface e

Detalhamento dos casos de uso so realizadas em paralelo, mas a atividade Detalhamento dos
requisitos no funcionais requer que ambas estejam completas. Os objetos mostrados direita
representam os resultados das atividades.

10

PESw

Definio do contexto

ERSw
Introduo

Definio do escopo

ERSw
Descrio
geral

Definio dos requisitos

Detalhamento
dos requisitos
de interface

Detalhamento
dos casos de uso

MASw
Viso
de casos
de uso

ERSw
Requisitos
especficos
Detalhamento
dos requisitos
no funcionais

Classificao
dos requisitos

CRSw
Itens de
requisitos

Reviso
dos requisitos

Figura 12 Exemplo de diagrama de atividades

Um diagrama de atividades mais complexo mostrado na Figura 13. Ele dividido em raias
(swimlanes), que representam os diversos papis de pessoas ou grupos envolvidos no processo (no
exemplo, cliente da mercearia, caixeiro e gerente). Os objetos situados sobre as fronteiras das raias
representam objetos partilhados entre os papis. Em um processo de negcio, eles podem representar
tanto objetos fsicos quanto informacionais. Um losango de deciso tem como sadas subfluxos
alternativos (no exemplo, a emisso opcional de nota fiscal).

11

Cliente da
mercearia

Caixeiro

Gerente

Escolha
dos itens de
mercadoria

Abertura
do caixa

Itens de
mercadoria

Registro
das compras

Totalizao
da venda

Emisso do
tquete

Caixa

Tquete

Desembolso
do pagamento

Pagamento

Recebimento do
pagamento

Empacotamento
dos itens
Registro no
caixa

Pediu nota
fiscal
No pediu
nota fiscal
Emisso da
nota fiscal

Fechamento
do caixa

Nota
fiscal

Figura 13 Exemplo de modelo de processo de negcio

3
3.1

Modelagem lgica
Objetos e classes

Nas metodologias de modelagem orientadas a objetos, os objetos representam entidades discretas, com
fronteira bem definida e identidade prpria, que encapsulam estado e comportamento. O estado
representado pelos atributos do objeto, e o comportamento pelas respectivas operaes. Os objetos
interagem entre si trocando mensagens, que so invocaes das operaes. Objetos similares so
agrupados em classes.
Na UML, um objeto representado por um retngulo, onde o nome do objeto sublinhado. Quando
um objeto aparece em um diagrama UML, podem acontecer as seguintes situaes:
12

 Um objeto pode ter classe indeterminada (Figura 14). Esta uma situao transitria que
pode acontecer durante a anlise, mas deve ser resolvida.
Um objeto pode ter denominao prpria e pertencer a uma determinada classe (Figura 15).
O nome da classe separado do nome do objeto por um sinal de dois pontos.
Um objeto pode ser annimo, representando uma instncia genrica de determinada classe
(Figura 16). O campo esquerda dos dois pontos fica vazio.
V enda
c orrente

Figura 14 - Objeto sem classe determinada

V enda c orrente
: V enda

Figura 15 - Objeto com indicao da respectiva classe

:
M erc adoria

Figura 16 - Objeto annimo

< < Control> >

V enda
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

F orm a de P agam ento

V alor
Data
Itens : Itens de V enda
Im pos tos
Ins erir Item V enda()
Totalizar()
E m itir Tick et()
E m itir Nota F is c al()
Im prim ir Nota F is c al()
F inalizar Im press o Nota F isc al()
Totalizar Im pos tos ()
F inaliz ar Im pres s o Tic k et()
E x c luir Item V enda()
Nova V enda()
G erar Cdigo()
Tipo de P agam ento()
F inaliz ar V enda()
V enda A berta()
V enda Conc luda()

Figura 17 - Representao de classe

13

Na UML, a classe representada por um retngulo dividido em trs compartimentos, que contm
respectivamente o nome da classe, os atributos e as operaes. Para maior clareza nos diagramas,
pode-se suprimir cada um dos compartimentos de atributos e operaes, ou deixar de mostrar
determinados atributos ou operaes. So opcionais tambm: a indicao da visibilidade por caracteres
ou cones; a assinatura (lista de argumentos e tipo de retorno) das operaes; e o tipo e valor padro
dos atributos.
Ven d a
- Fo rm a d e P a g am en to
- Va lo r
- D ata

Figura 18 - Representao de classe com supresso das operaes

< < Control>>

V en da
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

F orma de P ag am ento
V al or
Data
Itens : Itens de V enda
Impos tos
Ins eri r It em V enda(produ to : Merc adoria = d efau lt , quant idade = defa ult)
Totaliz ar(total do item : Item de V enda = default)
E m i ti r Tic k et()
E m i ti r Nota Fis c al()
Im prim ir Nota F is c al()
F inali z ar Im pr ess o No ta F is c a l()
T otali z ar Im pos tos () : ret urn
F inali zar Im pr es s o Tic k et()
E x c lui r Item V enda()
Nova V enda()
G erar Cdigo()
T ipo de Pa gam e nto()
F inaliz ar V enda()
V enda A berta() : return
V en da Conc luda() : ret urn

Figura 19 - Representao de classe com detalhamento das assinaturas das operaes

3.2
3.2.1

Organizao das classes

Pacotes lgicos

Os pacotes lgicos so agrupamentos de elementos de um modelo. No modelo de anlise, eles podem

ser utilizados para formar grupos de classes com um tema comum. Na Figura 20, os pacotes lgicos
Compras, Vendas e Administrao so usados para agrupar classes especializadas em relao a esses
aspectos.

14

Co m p ra s

V en d a s

A d mi n i stra o

Figura 20 - Pacotes lgicos

Pacotes lgicos podem ter relaes de dependncia e continncia entre si. Na Figura 21, os pacotes
lgicos Classes de fronteira e Classes de controle dependem (importam recursos) de Colees de
entidades. Colees de entidades contm os pacotes Colees e Elementos. Classes VB um
pacote global: seus recursos esto disponveis para os elementos de todos os outros pacotes.

Cl ass es de
fronteira

Clas s es de
c ontrole

Clas s es V B

g lo ba l

Clas s es de entidade

Cole es

E lem entos

(from Clas ses de entidade)

( from Cl as s es de en ti dade)

Figura 21 Relacionamentos entre pacotes lgicos

3.2.2

Esteretipos

Os esteretipos so extenses de elementos do modelo. Podem ser usados para denotar

especializaes significativas de classes. Os atores, por exemplo, podem ser tratados pelas ferramentas
de modelagem como classes estereotipadas. Como mostra a Figura 22, esteretipos podem ser
indicados atravs de cones prprios, ou incluindo-se o nome do esteretipo em aspas francesas (os
caracteres , representados nos desenhos por << >>).
< < Acto r>>
C a ixe iro
C a ixe iro

Figura 22 - Representaes alternativas do esteretipo "Ator"

15

Esteretipos so usados para criar especializaes da UML em relao a determinadas reas de

modelagem. Jacobson ([Jacobson94], [Jacobson+99]) prope a diviso das classes do Modelo de
Anlise de acordo com os esteretipos descritos a seguir, que foram incorporados ao padro oficial da
UML. Na Figura 23 eles so representados de forma textual, e na Figura 24 so representados na forma
icnica.
Entidades ("entity") modelam informao persistente, sendo tipicamente independentes
da aplicao. Geralmente so necessrias para cumprir alguma responsabilidade do
produto, e freqentemente correspondem a tabelas de bancos de dados.
Fronteiras ("boundary") tratam da comunicao com o ambiente do produto. Modelam as
interfaces do produto com usurios e outros sistemas, e surgem tipicamente de cada par ator
caso de uso.
Controles ("control") coordenam o fluxo de um caso de uso complexo, encapsulando
lgica que no se enquadra naturalmente nas responsabilidades das entidades. So
tipicamente dependentes de aplicao.
< < E n ti ty> >
I te m d e V en d a

< < Co n tro l >

< < B o u n d a ry> >

V e nd a

T ela de Vend as

Figura 23 - Exemplo de classes de anlise com esteretipos textuais

Item de V enda

V enda

Tela de V endas

(fro m C l a sse s d e E n ti d a d e )

(fro m C l a sse s d e C o n tro l e )

(fro m C l a sse s d e Fro n te i ra )

Figura 24 - Exemplo de classes de anlise com esteretipos icnicos

3.3
3.3.1

Relacionamentos
Relacionamentos de associao

As associaes expressam relaes bidirecionais de dependncia semntica entre duas classes. Elas
indicam a possibilidade de comunicao direta entre os respectivos objetos. Isso significa que faz parte
das responsabilidades de um objeto de uma das classes determinar os objetos correspondentes da outra
classe. Normalmente, existiro em cada classe operaes para cumprir essa responsabilidade.
Me rca d o ria

E m p re s a

in clu i r fo rne c e d or()

e xclu ir forn e ce d or()
li s ta r fo r ne ce d o re s ()

in clu ir p ro d u to ()
e xclu ir p ro d u to ()

Figura 25 - Relacionamento de associao

3.3.2

Multiplicidades e papis

A especificao das associaes inclui o seu nome, descrio e possveis restries. Em certos casos,
til batizar tambm os papis, assim como especificar vrios detalhes destes. Os nomes das
16

associaes devem ser simples e significativos. Recomenda-se usar um substantivo que descreva bem a
semntica do relacionamento. Pode-se tambm usar um verbo, desde que esteja claro qual classe
sujeito e qual classe objeto desse verbo (Figura 26). Uma conveno habitual batizar o
relacionamento de modo que ele seja lido corretamente de cima para baixo ou da esquerda para a
direita. Na ltima verso da UML, um pequeno tringulo pode ser usado para indicar a direo de
leitura, caso necessrio.

F ornec e

E m pres a

M erc adoria

E mprega

P es s oa

Figura 26 - Relacionamento com nome

A multiplicidade de um participante de um relacionamento indica quantos objetos de uma classe se

relacionam com cada objeto da outra classe. Relacionamentos obrigatrios tm multiplicidade mnima
1. A multiplicidade mxima indica o nmero mximo de instncias da classe alvo que podem existir
simultaneamente. Na Figura 27 modela-se o fato de que uma Pessoa pode estar ligada a nenhuma ou
uma Empresa, enquanto uma Empresa pode estar relacionada com uma ou mais instncia de
Pessoa (por exemplo, empregar). Uma Empresa pode estar relacionada com zero ou mais
instncias de Mercadoria (por exemplo, fornecer).

E m pres a

M erc adoria
0..*

0..*
0..1

1..*
P es s oa

Figura 27 - Relacionamentos com multiplicidades

Os papis so denominaes que exprimem em que qualidade um objeto de uma das classes do
relacionamento se relaciona com um objeto da outra classe.Os papis dos participantes devem ser
batizados explicitamente quando participarem de um relacionamento em uma qualidade que no
implcita no respectivo nome da classe. Na Figura 28 indica-se que um objeto da classe "Empresa"
participa no papel de "fornecedor" do relacionamento "Fornece", com zero ou mais objetos da classe
17

"Mercadoria", e um objeto dessa classe se relaciona com zero ou mais objetos da classe "Empresa" na
qualidade de "produto". Uma "Empresa" pode participar de outros relacionamentos em outras
qualidades; por exemplo, no papel de "empregador", em um relacionamento "Emprega" com um objeto
da classe "Pessoa".

Empresa

Fornece

fornecedor

produto

Mercadoria

0..*

0..*
empregador

Emprega

empregado
Pessoa

Figura 28 - Relacionamentos com denominao dos participantes

3.3.3

Navegabilidade

Os relacionamentos podem ter direo de navegao. Um relacionamento navegvel da classe A para

a classe B se, dado um objeto da classe A, consegue-se obter de forma direta (por exemplo, atravs de
uma operao da classe A) os objetos relacionados da classe B. Por exemplo, a Figura 29 indica que,
dada uma "Mercadoria", possvel localizar diretamente o respectivo "Fornecedor", mas a recproca
no verdadeira.

Empresa

0..*

Fornece

0..*

Mercadoria

produto

fornecedor

Figura 29 - Relacionamento com restrio de navegabilidade

3.3.4

Relacionamentos de herana

O relacionamento de herana existe entre classes de natureza mais geral (chamadas de superclasses ou
classes bases) e suas especializaes (chamadas de subclasses ou classes derivadas). As superclasses
contm atributos ou operaes comuns a um grupo de subclasses. Na Figura 30 modela-se o fato de
que um Item de Compra um tipo (uma especializao) de Item de Mercadoria, assim com um
Item de Venda.

18

< < E ntity > >

Item de Mercadoria
(fro m A d mi n i stra o )

- Q uantidade
- P re o Total
- m erc adoria : M erc adoria
+
+
+
+

Totalizar()
Ins erir()
Tipo de O pera o()
E x c luir()

< < E ntity > >

Item de Com pra

<< E ntit y> >

It em de Ven da
( fr om V e n da s)

(fro m Co m p ra s)

+ D ar B aix a()

+ Im prim ir Item Tic k et()

+ Calc ular Im pos tos ()
+ Im prim ir Item Nota F is c al()

Figura 30 - Exemplo de relacionamentos de herana

3.3.5

Relacionamentos avanados

Um relacionamento de agregao uma associao que reflete a construo fsica ou a posse lgica.
Relacionamentos de agregao so casos particulares dos relacionamentos de associao, e s
necessrio distingui-los quando for conveniente enfatizar o carter "todo-parte" do relacionamento.
Geralmente um relacionamento de agregao caracterizado pela presena da expresso "parte de" na
descrio do relacionamento, e pela assimetria da navegao.
Contorno
P olgono

+ vrtic e

1..1

P onto

3. .*

Figura 31 - Relacionamento de agregao

Um tipo mais forte de relacionamento todo-parte o relacionamento de composio. Nesse caso, os

objetos da classe parte no tm existncia independente da classe todo. A Figura 32 indica que o
"centro" de um "Crculo" no tem existncia independente deste, enquanto que a Figura 31 indica que
cada "ponto" existe independentemente do "Polgono" ao qual serve de "vrtice".
Crculo

Ponto
centro
Figura 32 - Relacionamento de composio

19

Uma associao pode ser reflexiva. Uma auto-associao indica um relacionamento entre objetos de
mesma classe que desempenham diferentes participaes. Na Figura 33 indica-se uma Pessoa na
qualidade de chefe relaciona-se com uma ou mais instncias de Pessoa que exercem o papel de
subordinado.
subordinado

Pessoa

1..*
chefe

1..1

Figura 33 - Associao reflexiva

Os relacionamentos podem ser de natureza complexa. Em certos casos, um relacionamento mais bem
explicado atravs de uma classe de associao, que exprime atributos e at operaes que so
propriedades do relacionamento como um todo e no de cada participante isoladamente. Na Figura 34
a classe Emprego inclui atributos e operaes que no esto ligados a uma Empresa ou uma
Pessoa isolada, mas ao relacionamento entre elas; por exemplo, o atributo data de incio ou a
operao imprimir atestado de emprego.
Emprega
Empresa

empregador

empregado

Pessoa

1..*

0..1

Emprego

Figura 34 - Classe de associao

Um qualificador um atributo que restringe um relacionamento atravs de uma seleo. Na maioria

dos casos, cada valor do qualificador est associado a uma nica instncia da classe alvo. Na Figura
35, o qualificador "nmero de conta" restringe a participao de objetos da classe "Pessoa" no
relacionamento. Um "nmero de conta" pode estar associado a zero ou um cliente (contas conjuntas
no so modeladas).
Banco

cliente

nmero de conta

Pessoa

0..1
0..*
Figura 35 - Relacionamento com qualificador

3.4
3.4.1

Detalhes das classes

Mensagens e operaes

Em modelos orientados a objetos, as mensagens representam os mecanismos de interao entre estes.

Um objeto s pode receber mensagens que correspondam invocao de uma operao da respectiva
20

classe. Durante a execuo da modelagem, os diagramas podem conter, em carter provisrio,

mensagens no associadas a operaes de alguma classe. Entretanto, ao trmino da anlise todas as
mensagens tm de ser resolvidas em termos de operaes de alguma classe.
Uma mensagem tem as seguintes partes:
receptor - o objeto que recebe a mensagem;
operao - a funo requisitada do receptor;
parmetros - os dados para a operao.
Na Figura 36 modela-se uma interao simples entre dois objetos, atravs de uma mensagem sem
parmetros.
1: Im prim ir Tic k et( )
: V enda

: Item de
V enda

Figura 36 - Exemplo de mensagem sem parmetro

Na Figura 37 modela-se uma colaborao complexa que envolve um ator (a rigor, uma instncia de
ator) e vrios objetos. Os parmetros das mensagens so includos no modelo.

1: c m dIncM erc O K _Clic k( )

2: Inc luir_M erc adoria(Long)
: G es t or de
Com pras

: Controle_de_G es tao
_de_F ornec edores

: frm
F ornec edores
5: E x iste_F ornec im ento(Long, Long)
6 : Ad d(F ornec im e nto, S t ring, V ar iant, V ariant)
3: E x is te_M erc adoria( Long)
4: It em (V ariant)

:
M erc adorias

:
F ornec im entos

Figura 37 Exemplo de mensagens com parmetros

3.4.2

Atributos

Atributos so propriedades que descrevem as classes. Atributos equivalem a relacionamentos de

composio em que:
a classe parte o tipo do atributo;
o papel o nome do atributo.
Atributos e relacionamentos podem ser alternativas para se expressar os mesmos conceitos (Figura 38).
A escolha entre atributo e relacionamento deve visar clareza do modelo. Geralmente atributos so de
tipos equivalentes a classes pequenas e reutilizveis, que representam abstraes de nvel superior ao
do domnio do problema.

21

Tringulo
Tringulo
vrtice[3] : Ponto
3 vrtice
Ponto

Figura 38 Equivalncia entre atributos e composies

3.4.3

Controle de acesso

Os tipos de acesso a operaes ou atributos de cada classe incluem:

pblico: qualquer outra classe pode usar (smbolo na UML +);
protegido: s subclasses dessa classe podem usar (smbolo na UML #);
privado: nenhuma outra classe pode usar diretamente (smbolo na UML -);
implementao: declarado no corpo de uma operao.
Excees ao controle normal de acesso, para determinadas classes clientes, podem ser feitas
declarando-se essas classes como amigas da classe fornecedora.
Na Figura 39 so mostrados os controles de acesso dos atributos e operaes de uma classe
implementada em Visual Basic. Note-se que todos os atributos so privados. So pblicas as operaes
provenientes do modelo de anlise e as operaes de acesso aos atributos; so privadas as operaes de
incio e trmino da vida dos objetos.

22

< < Clas s M odule> >

F ornec edor
-

m Nom e : V ariant
m Tele fone : V aria nt
m C PF _CG C : V ari ant
m E nderec o : V ari ant
m lC las s DebugID : Long

+ Co ns is t ir()
+ Ve rific ar_V inc ulo _M erc adoria()
+ Ins eri r_V inc u lo_M erc ador ia()
+ Ve rificar_P edido_Compr a()
+ Ex c lui r_V inc ulo_ M erc adoria()
+ E m i tir_Rel ator io()
< < G et> > + Clas sDebugID()
- Cl as s _Init ial iz e()
- Clas s _Term inate()
< < S et> > + N om e()
< < G et> > + N om e()
< < S et> > + Tel efon e()
< < G et> > + Tel efone()
< < S et> > + CP F _CG C()
< < G et> > + CP F_CG C()
< < S et> > + E ndere c o()
< < G et> > + E nderec o()
+ Prox i ma_M erc ador ia ()

Figura 39 - Exemplo de controles de acesso

Note-se tambm, na Figura 39, o uso de esteretipos para indicar que construes da linguagem alvo
sero utilizadas para implementar a classe (<< Class Module >>) e as operaes de acesso aos
atributos (<< Get >>, << Set >>).

3.5

Diagramas de interao

3.5.1

Diagramas de seqncia

Os diagramas de seqncia enfatizam o ordenamento temporal das aes. Eles so construdos de

acordo com as seguintes convenes:
linhas verticais representam os objetos;
setas horizontais representam as mensagens passadas entre os objetos;
rtulos das setas so os nomes das operaes;
a posio na vertical mostra o ordenamento relativo das mensagens;
o diagrama pode ser complementado e esclarecido por anotaes.
A UML prev que os retngulos situados nas linhas verticais devem indicar o tempo de vida dos
objetos. Esta conveno no foi seguida neste texto, por limitao da ferramenta de modelagem
utilizada.
23

O Gestor de Compras seleciona a mercadoria.

O Merci verifica se existe algum pedido pendente que contenha esta mercadoria.
Se no houver pedido pendente contendo a mercadoria a ser excluda,
o Merci desvincula a mercadoria dos fornecedores (os fornecedores no mais fornecero a mercadoria
que esta sendo excluda);
o Merci faz a remoo da mercadoria.
Se houver pedido pendente contendo a mercadoria a ser excluda,
o Merci emite uma mensagem de erro.
Tabela 8 - Exemplo de fluxo de caso de uso

Os diagramas de seqncia so orientados para exprimir, de preferncia, o desenrolar temporal de

seqncias de aes. mais difcil representar lgicas de seleo e repetio sem prejudicar a
inteligibilidade do diagrama. Os roteiros representam desdobramentos da lgica do caso de uso.
prefervel usar diagramas separados para representar roteiros resultantes de diferentes caminhos
lgicos. Por exemplo, a lgica contida no fluxo da Figura 40 pode ser descrita atravs dos diferentes
roteiros (Figura 41 e Figura 42). Para simplificar o exemplo, os diagramas no usam classes de
fronteira.
O Caixeiro registra itens de mercadoria.
O Merci totaliza venda.
O Caixeiro registra modo de venda.
Se venda a prazo,
o Caixeiro insere venda em contas a receber.
Seno,
o Caixeiro registra pagamento.
Figura 40 Exemplo de fluxo com lgica de seleo: Operao de Venda

24

: V enda

: Caix a

: Caix eiro

1: tot al iz ar( )

2: regis trar m odo( )

3: regi strar pagam ent o( )

Figura 41 Exemplo de roteiro alternativo: Operao de Venda Vista

: V enda

: Contas a
rec e ber

: Caix eiro
1: totaliz ar( )

2: regi strar m odo( )

3: ins erir(V enda)

Figura 42 Exemplo de roteiro alternativo: Operao de Venda a Prazo

25

Subfluxos curtos podem ser inseridos em um roteiro, indicando-se a lgica de ativao deles por meio
de expresses de recorrncia:
[condio] - lgica de seleo;
*[condio] - lgica de iterao.

: Venda

: Caix eiro

: Contas a
receber

: Ca ix a

1: totalizar( )

2: regi s tr ar m odo( )

[venda a prazo]
3: ins erir(V en da)

[venda vis ta]

4: regi s tr ar pagam ent o( )

Figura 43 Representao de lgica por meio de restries

Diagramas de seqncia podem ser complementados por meio de anotaes. Os detalhes de

processamento que no correspondem a interaes entre classes foram lanados como anotaes no
diagrama da Figura 44. Estas anotaes podem servir como especificaes das operaes das classes
envolvidas.

26

: G es tor de
C om pr as

: fr m
F orn ecedore s

: C ont role_ de_Ge s ta o_de _

F or n ec e dor e s

: M erc ador ia s

: F or necim entos

fr m For nec edor es exibe e habilita o c am po C digo

da N ova M er cador ia e o boto OK.

O Gestor de C om pr as pr eenc he o c am po
C digo da N ov a M er cador ia

1: c m dInc M er cO K_C lick ( )

fr m For nec edor es esc onde e desabilita o c am po

C d ig o d a N ova M er c ador ia e o bo t o OK.

2: Inc luir _M er cador ia( Long)

3: Exis te_M er cador ia( Long)

Se o C digo pr eenchido no exis tir na tabela

M er c ador ias do banc o de dados M er ci, C ontr ole_de
_Ges tao_de_F or nec edor es executa a exc e o
EGF - 03.

4: Item ( Var iant)

5: Exis te_For nec im ento( Long, Long)

Se o p ar fo rm ado p elo C d ig o da me r ca dor ia e pel o

C digo do F or nec edor j exis tir , C ontr ole_de_
Ges ta o_de _For nece dor es ex e cut a a exce o
EGF - 04.
6: Add( F or necim ento, Str ing, Var iant, Var iant)

fr m For nec edor es exibe m ais um a linha na gr ade d

o quadr o de M er cador ias F or nec idas, contendo os
c am pos C digo e D esc r io da m er c ador ia
inc luda.

Figura 44 Exemplo de diagrama de seqncia para realizao de um caso de uso

3.5.2

Diagramas de colaborao

Os diagramas de colaborao enfatizam os relacionamentos entre os objetos participantes. Eles so

construdos de acordo com as seguintes convenes:
nodos representam os objetos;

27

 os arcos representam as mensagens passadas entre os objetos;

os rtulos dos arcos so os nomes das operaes;
os nmeros de seqncia mostram o ordenamento relativo das mensagens;
as anotaes podem complementar o diagrama.
Nos diagramas de colaborao a ordenao das mensagens mostrada apenas pela numerao delas.
Na Figura 46 mostra-se o diagrama de colaborao que corresponde ao diagrama de seqncia da
Figura 45.

: Ges t or de

: Tela d e Merc adorias

: C on trolad or de M erc ad orias : Merc a doria

: F ornec edor

: P edido de C om pra

C om pras

1 : E x c luir( )

2: E x clu ir( Merc a doria)

3: V erif ic ar Merc adorias Pende ntes (Merc adoria)

[S e no houv er P edidos P endent es ]

4: E x c lu ir( )

* [ P ara c ada f ornec edor]

5: E x c lu ir V nc ulo(Merc adoria)

Figura 45 - Realizao de fluxo atravs de diagrama de seqncia

28

1: E x c luir( )

2: E x c lu ir(M erc a dori a)

: Tela de
M erc adorias

: Co ntrolad or de
M erc adorias

: G es tor de
Com pras

3: V erific ar M erc adorias P endentes (M erc adoria)

: P edido de
Co m pra

4: E xc l uir( )

5: E x c luir V nc ulo(M erc adoria)

: F ornec edor

:
Mer c adoria

Figura 46 - Realizao de fluxo atravs de diagrama de colaborao

3.5.3

Diagramas de objetos

Diagramas de colaborao mostram interaes entre objetos, que geralmente tm o objetivo de

cooperar para realizar roteiro de um caso de uso. Diagramas de objetos podem ser utilizados tambm
para outras finalidades. Na Figura 47, um diagrama de objetos ilustra a integrao bottom-up. No
exemplo, as unidades U21 e U22 so testadas utilizando-se os controladores C1 e C2. No passo
seguinte da integrao, os controladores so substitudos pela unidade U1. Substitudo por uma
ligao entre dois objetos.
Su bs ti tudo por

C1 :
Controlador

C2 :
Controlador

U21 :
Unida de

U22 :
Unidade

S ubs titudo por

U1 :
Unidade

U21 :
Unidade

U22 :
Unidade

DE P O IS

A NTE S

Figura 47 Exemplo diagrama de objetos utilizado para ilustrar testes

29

Os diagramas de objetos podem ser usados para mostrar a passagem de dados e de controle. Na Figura
48, por exemplo, mostram-se como objetos uma unidade sob teste e os componentes utilizados para
testa-la. As setas simples representam a direo de fluxo de controle: do objeto que chama (cliente do
servio ou emissor da mensagem) para o objeto chamado (fornecedor do servio ou receptor da
mensagem). As setas com bolinhas indicam o fluxo de dados (direo de passagem de parmetros).

: Cas o de
tes te
A : Coto

3:
2:

1:

: Controlador

: Unidade

4:

5:
B : Coto

: E x ibidor

Figura 48 - Componentes de teste

4
4.1

Modelagem fsica
Viso de componentes

A viso de componentes descreve os aspectos estticos do modelo fsico. Ela mostra os arquivos de
cdigo fonte e objeto utilizados na implementao, assim como componentes reutilizados do ambiente
e de outros projetos. Mostra tambm as dependncias existentes entre eles, que indicam o impacto das
alteraes realizadas em cada componente. Na Figura 49, mostra-se que o componente executvel
Merci_10 depende de vrios componentes de cdigo fonte correspondentes a formulrios do Visual
Basic e de um componente de cdigo binrio da tecnologia COM (um controle ActiveX de grade de
entrada).

30

frm
F ornec edores .frm

m di
P ri nc ipal.frm

frm
M erc adorias .frm

frm P edidos _de

_Com pras .frm

frm
Com pras .frm

M erc i_
10

< < A c tiveX> >

M S F lex G rid
Lib

Figura 49 Exemplo de diagrama de componentes (viso esttica)

Os componentes podem ser implementados por meio de muitos tipos diferentes de arquivos. Nos
diagramas de componentes, esses tipos de arquivos podem ser destacados por meio de esteretipos,
representados por meio de identificadores ou de cones prprios. A Figura 50 mostra alguns tipos de
arquivos fontes, com os respectivos esteretipos icnicos. A Figura 51 mostra alguns exemplos de
componentes de cdigo objeto comuns em ambientes Windows, mostrados com esteretipos textuais.
E s pec ific a o de s ubprogram a

C orp o de s ubprogram a

C om ponente
genric o

Prog ra ma p ri nci pal

E s pec ific a o de pac ote

E s pec ific a o de ta re fa

C orp o de pac ote

Co rpo de tare fa

Figura 50 Exemplo de componentes de cdigo fonte

31

A rquivo_E XE

A rqui vo _DL L

< < A c tiveX> >

Com ponente
_A c tiveX

< < A pplet> >

M ini -a pli c ativo

Figura 51 Exemplo de componentes de cdigo objeto

As interfaces representam um subconjunto dos recursos implementados por um componente, que tm

um tema comum. Por exemplo, na Figura 52, um componente ActiveX oferece duas interfaces
distintas. Aplicativos que no tratem de vendas a prazo, por exemplo, possivelmente no utilizaro a
interface Gestao_de_Clientes, utilizando apenas os recursos oferecidos atravs da interface
Operacao_de_Venda.

< < A c tiveX> >

G es tao_de_
V endas

G es tao_de_Clientes

O perac ao_de_V enda

Figura 52 Exemplo de interfaces de componente

4.2

Viso de desdobramento

O modelo fsico dinmico descrito pelo diagrama de desdobramento, que mostra os processadores, os
dispositivos e as conexes utilizados na implementao de um sistema. Em cada processador, pode-se
mostrar os processos que nele executaro. Esse modelo particularmente importante no caso de
sistemas distribudos. comum a utilizao de esteretipos para indicar diferentes tipos de
processadores e dispositivos.
Na Figura 53 mostra-se que os processadores Cliente de WWW 1, Cliente de WWW 2 e
Servidor de bancos de dados so ligados ao processador Servidor de WWW atravs de conexes
Internet. O Servidor de WWW executa os processos Personal Web Server e Aplicativo CGI.
O Cliente de WWW 1 est ligado a um dispositivo Impressora.

32

S ervi dor de
WWW

Im pres s ora

P e rso n a l We b S e rve r
A p l ica ti vo CG I

< < Internet> >

<< Internet > >

Cliente de W W W 1

Cliente de W W W 2

< < Intranet> >

S ervidor de banc os de
dados

Figura 53 - Exemplo de diagrama de desdobramento

Referncias
[Jacobson+99]

Ivar Jacobson, James Rumbaugh e Grady Booch. Unified Software

Development Process. Addison-Wesley, Reading - MA, 1999.

[Jacobson94]

Ivar Jacobson. Object-Oriented Software Engineering. Addison-Wesley,

Reading - MA, 1994.

[Rumbaugh+99]

James Rumbaugh, Ivar Jacobson e Grady Booch. Unified Modeling

Language Reference Manual. Addison-Wesley, Reading - MA, 1999.

33