- ----------------------------

rev e

etos
'

:( .. -/,.. ,,.':'
..
.: ,: :'I, ..
. .;: . ;:I.
. ,,,
.r;

:'i, I.'
" ,,,

. ,.. "
', ., .
.:"i/
:...
;;":,:,,_,
.:".;''
'-:\;,,,-
..'

---- -- " ,- .
---- _, ..... .. .....:

...... . ,

: ...
'

'
'

-,.-.
:;
: :', ..
-:
_;::
' '
,,. . ..:, :,:- .
. ,:

:,.,.
. ,:" . : _.'
_

. :i
;,':

. . ..

~-; ,.;-
 Associao p. 54
Classe

Nome da papel de B
p.52 Classe A Classe B
Classe
papel de A

Nome da Classe
Multiplicidades p.54
atributo:Tipo[O .. 1] = valorlnicial
1
operao(list arg): tipo de retorno
operaoAbstrata
-----:_:
I I
_c_ia_s_s_e_ __, exatamente um

Classe ffiUil0 (I@f0

.___ __, ou mais)

Generalizao p. 60
__ o_._.1-11
..
Classe I opcional (zero
__,_ ou um)

Supertipo I
m .. n
. Classe
I especificado
. numericamente
A conjunto de gener alizao
p. 84 {ordered} * I
-----i._: __
I
c_ia_s_s_e_ _, ordenado'

Subtipo 1 Subtipo 2 I Classe p--- agregao p. 79

Restrio {nome: descrio} p. 64 Classe --- composio p. :79

Palavra-chave palavra-chave p. 77

Associao Qualificada p. 85

Nota p. 61 Classe qualificador 1----

- - - -
algum texto til
\
. -- - -- Navegabilidade p. 58

.....------. nome do papel.....-----.

Origem 1-----...: Destino

Especificao de
Instncia p. 94
Dependncia p. 62
nome-do-objeto: Nome
da Classe
I Cliente ~- - - - - - - - -1 Fornecedor I
 Diagrama de Classes

.
Classe interface
Abstrata Interface
- - - - - - ... - Classe Cliente
dependncia

\ p. 80 I\ realizao
''

. ----- - - - ...' p. 82
'
Classe de
Implementao
interface fornecida - interface exigida -' i"
'
i'
: i'
- {UML 2]

classe template p. 90
r- - - - -, Classe .
Classe
I I
T '
- - -
I I
'
' ;
'
'
.
.
Conjunto Classe de .i
Associao p. 87

elemento de ligao

conjunto<lnteger> . :
.
,,
;, I
_,

Estrutura Composta p. 132 ,::

,I
:!
-
parte: Classe
p. 134
. . il
' I

' I
Componente I
' .i
' l,
:
. i
' (
.
I
I
i
..
';
'
Diagrama de Comunicao p. 129
Diagrama de Casos de Uso p. 104
nome-do-obieto: classe
Caso de Uso
1: mensagem() .
.

include ' '

Ator
nome do papel
.

:classe
.

,-,~- .
-_ .. - '
. . _,;.,
;; ... ,_

....' _-

< .'

-.

.. . ' , '...

~--
 '!

'

. . ', .\.
I
u
1,
\'.
I
ssenc1a .. '''
'
I \\
'

"
Um breve guia para a linguagem-padro 'i .I' L

de modelagem de objetos '

.

;_ ;
'

'

-~:\\
,
,
I I
'

I
' . I
::-,
-, I
''!
:1 I
--. !1
lI
I
'

'

'II,

\


i
I
:

"'I
J

u:
I
j
il
,

'. '
. . , _-

_,. : ..
.r:-

.. ,

O AUTOR

Martin Fowler cientista-chefe da ThoughtWorks, empresa de desenvolvimento de aplicaes

empresariais. Aplica tcnicas orientadas a objeto no desenvolvimento de software empresarial h mais
de uma dcada. Muito conhecido por seu trabalho com padres, UML, refatorao e mtodos geis,
Martin vive em Melorose, Massachusetts, com sua mulher, Cindy, e um gato muito estranho. O ende
reo de sua pgina na Web http://martinfowler.com.

, .

'

VJ1.vw.abpdea.org.br

F787u Fowler, Martin

UML essencial: um breve guia para a linguagem-pa
dro de modelagem de objetos I Martin Fowler; trad. Joo
Tortello. - 3.ed. - Porto Alegre : Bookman, 2005.

1. Cincia da computao - Engenharia de software. I.

Ttulo.

CDU 004.41/.428.8

Catalogao na publicao: Mnica Ballejo Canto - CRB 10/1023

ISBN 85-363-0454-5

- --.
 MARTIN FOWLER
..
'

\
'
Esta edio abrange a verso UML 2.0 OMG

a-

..'
:

'

''t r
i

! i
: 1
.:

Um breve guia para a linguagem-padro

de modelagem de objetos ,... ';

Traduo:
JOO TORTELLO

Consultoria, superviso e reviso tcnica desta edio:

ENG. ANA M. DE ALENCAR PRICE
Doutora em Cincia da Computao pela University of Sussex, Gr-Bretanha
Mestre em Informtica pela PUC-RJ
Professora do Instituto de Informtica da UFRGS na rea de
qualidade de software e linguagens de programao

Reimpresso 2006

2005

'

 ..

Obra originalmente publicada sob o ttulo:

U'Ml: Distilled: A Brief Guide to the Standard Object Modeling Language, .Ile

Copyright <) 2004 by Pearson Education, Inc. I

ISBN 0-321-19368-7

Traduo autorizada do original em lngua inglesa publicado por

Pearson Education, Irie, sob o selo Addison Wesley Professional.

Capa;
M.Rl(l R<JllNI~r;r

Leitura final:
FA!llO RESPAN ODINH(l

Superviso editorial:
ARYSINH,\ JACQUES AFFONSO

Edtorao eletrnica:
AGE -ASSESSORIA GriFrt~A E E1JJT<JRJAL Lrox.

. '

Reservados todos os direitos de publicao em lngua portuguesa

ARTMEDc" EI)ITORA S.A.
(Bookman" Companhia Editora uma diviso da Artmed" Editora S.A.)
Av. Jernimo de Ornelas, 670 - Santana
90040-340 - Porto Alegre, RS, Brasil
Fone: (51) 3027-7000 Fax: (51) 3027-7070
,
E proibida a duplicao ou reproduo deste volume, no todo ou ein parte,
sob quaisquer formas ou por quaisquer meios (eletrnico, mecnico, gravaao,
fotocpia, distribuio na Web e outros), sem permisso expressa da Editora .
-
SAO PAULO
Av. Anglica, 109 l
O 1227-1 OO - So Paulo, SP, Brasil
Fone: (11) 3665-llOOFax: (11) 3667-1333

SAC 0800 703-3444

IMPRESS() NO BRASIL
PRINTED lN BRAZii-
 presentao
da Terceira Edio

Desde os tempos antigos, os mais talentosos arquitetos e projetistas

conhecem a lei da parcimnia. Seja ela formulada como um paradoxo ("menos
"'
mais") ou como um mantra ("a mente Zen a mente do iniciante"), sua sabedoria : '
.

eterna: reduzir tudo a sua essncia para que a forma harmonize com a funo. Das 'I
pirmides ao Opera House de Sydnei, das arquiteturas de von Neumann ao UNIX e t
Smaltalk, os melhores arquitetos e projetistas tm se esmerado para seguir esse prin ., '
i
cpio universal e eterno. . .
Reconhecendo o valor de barbear com a Navalha de Occam 1, quando eu arquiteto
e leio, procuro projetos e livros que obedecem a lei da parcimnia. Conseqentemente, ;
;;;
:
.il! '
aplaudo o livro que voc est lendo agora. . iJ
.;

' ' il
A primeira vista, voc pode achar meu ltimo comentrio surpreendente. Eu sou I :1

freqentemente associado s especificaes volumosas e densas que definem a UML t

. '~:i
..

(Unified Modeling Language). Essas especificaes permitem que os fornecedores de

. :!
.::,

ferramentas implementem a UML e que os metodologistas a apliquem. Por sete anos, !

'.j
presidi grandes equipes de padronizao internacional para especificar a UML 1.1 e a
UML 2.0, assim como diversas revises secundrias intermedirias. Durante esse tempo,
a UML amadureceu em expressividade e preciso, mas tambm a ela foi acrescentada : ;' .

uma complexidade gratuita, como resultado do processo de padronizao. Lamentavel ' ' "f
mente, os processos de padronizao so mais conhecidos pelos compromissos do proje i
l
to realizado pelo cornit do que pela elegncia parcimoniosa. t
f'
O que um especialista em UML familiarizado com as mincias misteriosas da .t
:t I
especificao pode aprender com o refinamento da UML 2.0 feito por Martin? Muito, f:

assim como voc. Para comear, Martin reduz habilmente uma linguagem grande e com r.
p
; .
plexa a um subconjunto pragmtico que ele tem provado ser eficiente com a prtica. Ele
'.
'

tem resistido ao caminho fcil de anexar pginas adicionais ltima edio de seu livro. 'i' .

medida que a linguagem cresce, Martin se mantm fiel ao seu objetivo de procurar "a i .
frao mais til de UML" e dizer exatamente isso a voc. A frao a que ele se refere so '
: 1
.

os mticos 20o/o da UML que ajudam voc a fazer 80o/o do seu trabalho. Capturar e J
'
.'
domesticar essa fera arisca uma faanha considervel! I .
ainda mais impressionante que Martin atinja esse objetivo enquanto escreve em ~
I

um estilo coloquial maravilhosamente envolvente. Compartilhando suas opinies e ane II

'
dotas conosco, ele torna este livro divertido e nos lembra que definir a arquitetura de '! ' I

sistemas e projet-los deve ser uma atividade criativa e produtiva. Se buscarmos o mantra 1:

* N. de R.T.: Occam's Razor um princpio lgico atribudo ao filsofo medieval Willian, of Occam,
o qual afirma que no devemos fazer mais suposies do que o mnimo necessrio.

-. ,.

. ': _- :.. ' ..

'

_,- '
. "

. .

,- .. .

-. --.:, .
 -e:

VIII . APRESENTAO DA TERCEIRA EDIO

da parcimnia a todo custo, acharemos que os projetos modelados com a UML so to

agradveis quanto aquelas aulas de desenho e de pintura com os dedos na escola prim-
ria. A UML deve ser o pra-raios da nossa criatividade, assim como um laser para especi-
ficar precisamente projetos de sistemas, de modo que outros possam orar e construir
esses sistemas. Este ltimo a prova dos nove de qualquer linguagem genuna de projeto.
Assim, embora este possa ser um livro pequeno, ele no trivial. Com a estratgia
de modelagem de Martin, voc pode aprender tanto quanto aprende com suas explica
es sobre a UML 2.0.
Tive o prazer de trabalhar com Martin para melhorar a seleo e a corretude dos
recursos da linguagem UML 2.0 explicados nesta reviso. Precisamos ter em mente que
todas as linguagens ativas, tanto naturais quanto sintetizadas, devem evoluir ou perecer.
As escolhas das novas caractersticas feitas por Martin, junto com suas preferncias e as
de outros profissionais, so uma parte fundamental do processo de reviso da UML. Elas
mantm a linguagem viva e a ajudam a evoluir atravs da seleo natural no mercado.
Muito trabalho desafiador resta antes que o desenvolvimento orientado por mode
los se torne comum, mas sou estimulado por livros como este, que explicam claramente
os fundamentos da modelagem com UML e os aplicam pragmaticamente. Espero que
voc aprenda com ele como eu aprendi e use suas novas idias para melhorar suas pr
prias prticas de modelagem de software.

CRIS KOBRYN


Presidente, U2 Partner's UML 2.0 Submission Team
Tecnlogo-chefe, Telelogic

 --------------~J-- ;

-. .
..

:-
?
t
--.

,.

;'
-.

~
presentao
-
.

-.
da Primeira Edio ..
. .

'
--a
~
a
t
~..
~
i

\
-.. .
{

'- .. t
,.
r
'
. Quando comeamos a moldar a UML (Unified Modeling Language),
espervamos produzir um meio padronizado de expressar projetos que no somente re : rI
.. . .
t,.
fletisse as melhores prticas do setor, mas que tambm ajudasse a desmistificar o proces '. :~
r'
-. t

so de modelagem de sistemas de software. Acreditvamos que a disponibilidade de uma \

-
'
linguagem de modelagem padronizada estimularia mais desenvolvedores a modelar os : f.:.
:
l
-- .
'~
;
seus sistemas de software, antes de constru-los. A adoo rpida e muito difundida da ;
. .(.
;
~:

lt . .
;:
' UML demonstra que os benefcios da modelagem so, de fato, bem conhecidos da co . f
: t
munidade de desenvolvedores de software.
A prpria criao da UML foi um processo iterativo e incremental, muito seme
lhante modelagem de um grande sistema de software. O resultado final um padro
baseado nas muitas idias e contribuies feitas por diversas pessoas e empresas da comu
nidade. Ns comeamos o trabalho sobre a UML, mas muitos outros contriburam para
uma concluso de sucesso; somos muito gratos pelas suas contribuies.
..i

''f. Criar e entrar em acordo sobre uma linguagem de modelagem padro por si s j '
. ~
:

um grande desafio. Educar a comunidade de desenvolvedores e apresentar a UML a ela . ;

!
.: !
:
de uma forma acessvel e no contexto do processo de desenvolvimento de software, tam ...
. .~

bm um grande desafio. Neste livro aparentemente pequeno, atualizado para refletir as : :

mudanas mais recentes na UML, Martin Fowler superou, certamente, esse desafio.
Com um estilo claro e acessvel, Martin no somente introduz aspectos principais
. da UML, mas tambm demonstra claramente o papel que a UML desempenha no pro
o

cesso de desenvolvimento. Ao longo da leitura, recebemos grandes doses de sabedoria e

conhecimento de modelagem, decorrentes dos mais de 12 anos de experincia que o
autor acumulou em projeto e em modelagem. ~
;i .
Como resultado, temos um livro que apresenta a linguagem a milhares de desen !!

e '
'!
volvedores, aguando seus interesses em explorar melhor os vrios benefcios da modela .

gem utilizando UML, agora um padro. ,

l. .
.

Recomendamos o livro para qualquer modelador ou desenvolvedor interessado em . t .

1 :
conhec-la e em obter uma viso do importante papel que ela desempenha no processo I .
~ .
. I
de desenvolvimento. I
1 .
.. .,i!
.,
GRADYBOOCH !1
I
]
IVAR JACOBSON . '.,
;

JAMES RUMBAUGH ii
J
'

.
!

, I
!
!
;

.'
'

,.,.

refcio

.
'

Tenho tido sorte de vrias maneiras em minha vida; um de meus maiores

golpes de sorte foi estar no lugar certo e com o conhecimento certo para escrever a .
j
..
i

..
~. ..
primeira edio deste livro, em 1997. Naquela poca, o mundo catico da modelagem .
~:
,.
;

orientada a objetos (OO) estava apenas comeando a ser unificado sob a UM1: (Unified .I
f
Modeling Language). Depois disso, a UML se tornou o padro para a modelagem grfi .
}
:

ca de software, no apenas para objetos. Minha sorte que este livro o mais popular . I
.
'..
'

. f
sobre a UML, vendendo mais de 250 mil cpias.
Bem, isso foi timo para mim, mas voc deve comprar este livro?
Gosto de enfatizar que este um livro breve. Ele no se destina a dar os detalhes
'
sobre cada faceta da UML, que vem crescendo a cada dia nos ltimos anos. Minha
inteno encontrar aquela frao da UML que mais til e dizer a voc exatamente ,:

, rn
,.
'
isso. Embora um livro maior fornea mais detalhes, tambm demora mais para ser lido. :.: ,,
..

E seu tempo o maior investimento que voc far em um livro. Mantendo este livro . :.!
. ':t
.,!
pequeno, gastei meu tempo escolhendo os melhores pontos para evitar que voc mesmo
., tenha que fazer essa seleo. (Infelizmente, ser menor no significa ser proporcional
'
'
mente mais barato; h um certo custo fixo para produzir um livro tcnico de qualidade.)
Um motivo para ter este livro comear a aprender sobre a UML. Como este um f
livro pequeno, ele far com que voc comece a aprender rapidamente os fundamentos da {
.
UML. Com isso, voc pode entrar em mais detalhes sobre a UML, com livros maiores, :

tais como o User Guide [Booch, UML user] ou o Rejrence Manual [Rumbaugh, UML ..

:.

Reference].
Este livro tambm pode atuar como uma referncia til para as partes mais comuns
da UML. Embora ele no aborde tudo, muito mais leve para carregar do que a maioria
.. dos outros livros sobre UML.
'
Ele tambm um livro dogmtico. Trabalho com objetos h muito tempo e tenho .'
idias precisas sobre o que funciona e o que no funciona. Todo livro reflete as opinies :
.
de seu autor, e eu no tento esconder as minhas. Assim, se voc estiver procurando algo
que tenha um gosto de objetividade, talvez queira escolher outro. '

Embora muitas pessoas tenham me dito que este livro uma boa introduo a
objetos, no o escrevi tendo isso em mente. Se voc est atrs de uma introduo ao
projeto orientado a objetos, sugiro o livro de Craig Larman [Larman].
.
Muitas pessoas interessadas na UML esto usando ferramentas. Este livro se con
centra no padro e na utilizao convencional da UML, e no entra em detalhes do que
as vrias ferramentas suportam. Embora a UML tenha resolvido a torre de Babel das .
.

notaes anteriores ao seu aparecimento, muitas diferenas maantes permanecem entre .

.
.

o que as ferramentas mostram e permitem fazer, ao se desenhar diagramas UML. .

' .
.
.

.
.
. .
:

. .
.'
 Xli PREFCIO

Neste livro, no falo muito sobre MDA (Model Driven Architecture). Embora
muitas pessoas considerem os dois como sendo a mesma coisa, muitos desenvolvedores
utilizam a UML sem estarem interessados na MDA. Se voc quiser aprender mais sobre
MDA, eu comearia primeiro com este livro, para ter uma viso geral da UML, e depois
mudaria para um livro mais especfico sobre MDA.
Embora o objetivo principal deste livro seja a UML, inclu tambm algum material
sobre tcnicas, como os cartes CRC, que so valiosas para o projeto orientado a objetos.
A UML apenas uma parte do que voc precisa para ter sucesso com objetos, e acho que
importante apresentar algumas outras tcnicas.
Em um livro breve como este, impossvel entrar nos detalhes sobre como a UML
se relaciona com o cdigo-fonte, particularmente porque no existe nenhuma maneira
padronizada de fazer essa correspondncia. Entretanto, destaco tcnicas de codificao
comuns para implementar partes da UML. Meus exemplos de cdigo so em Java e C#,
pois descobri que essas linguagens so as mais amplamente entendidas. No presuma que eu
prefiro essas linguagens; j trabalhei muito com Smaltalk para dizer isso!

POR QUE UTILIZAR A UML?

As notaes grficas de projeto existem h algum tempo. Para mim, seu principal valor
est na comunicao e no entendimento. Um bom diagrama freqentemente pode aju
dar a transmitir idias sobre um projeto, particularmente quando voc quer evitar mui
tos detalhes. Os diagramas tambm podem ajud-lo a entender um sistema de sofiioare
ou um processo do negcio. Como parte de uma equipe tentando descobrir algo, <JS
diagramas ajudam toda a equipe tanto a entender como comunicar esse entendimento.
Embora eles no sejam substitutos, pelo menos ainda, para as linguagens de progran1a
o textuais, eles so um til assistente.
Muitas pessoas acreditam que, no futuro, as tcnicas grficas desempenharo um
papel preponderante no desenvolvimento de software. Sou mais ctico do que isso, mas
certamente til ter uma idia do que essas notaes podem e no podem fazer.
Dessas notaes grficas, a importncia da UML proveniente de seu uso amplo e
da padronizao dentro da comunidade de desenvolvimento orientado a objetos. A UML
se tornou no somente a notao grfica dominante dentro do mundo orientado a obje
tos, como tambm uma tcnica popular nos crculos no-orientados a objetos .

ESTRUTURA DO LIVRO

O Captulo 1 fornece uma introduo UML: o que ela , os diferentes significados que
ela tem para diferentes pessoas e de onde ela veio.
O Captulo 2 discute o processo de desenvolvimento de software. Embora isso seja
rigorosamente independente da UML, acho que fundamental entender o processo

para ver o contexto de algo como a UML. Em particular, importante entender o papel
do desenvolvimento iterativo, que tem sido a estratgia subjacente ao processo para a
maioria da comunidade orientada a objetos .
Organizei o restante do livro em torno dos tipos de diagramas da UML. Os Cap
tulos 3 e 4 discutem as duas partes mais teis da UML: diagramas de classes (bsicos) e
diagramas de seqncia. Mesmo que este livro seja fino, acredito que voc pode obter o
 ------------------------~'.""'-

PREFCIO Xlii

que h de mais valioso na UML usando as tcnicas sobre as quais falo nesses captulos. A
UML grande e est crescendo, mas voc no precisa de tudo que ela tem.
O Captulo 5 entra nos detalhes sobre as partes menos essenciais, porm ainda
teis, dos diagramas de classes. Os Captulos 6 a 8 descrevem trs diagramas teis, que
esclarecem melhor a estrutura de um sistema: diagramas de objetos, diagramas de paco
tes e diagramas de distribuio.
Os Captulos 9 a 11 mostram trs tcnicas comportamentais bastante teis: casos de
uso, diagramas de estados (embora oficialmente conhecidos como diagramas de mqui
na de estados, geralmente eles so chamados de diagramas de estados) e diagramas de
atividades. Os Captulos 12 a 17 so muito breves e abordam os diagramas que geral
mente so menos importantes; portanto, para eles, forneci apenas um rpido exemplo e
uma breve explicao.
A contracapa resume as partes mais teis da notao. Freqentemente, tenho ouvi
do as pessoas dizerem que essas capas so a parte mais valiosa do livro. Voc provavel
mente achar til se referir a elas quando estiver lendo alguma das outras partes do livro.
I
- r.

...............------------------------------------
- .
MUDANAS DA TERCEIRA EDIAO

Se voc tem as edies anteriores deste livro, provavelmente est se perguntando o que I
h de diferente e, o mais imporrante, se deve adquirir a nova edio. .I
A principal causa para a terceira edio foi a apario da UML 2. Ela acrescentou
muita coisa nova, incluindo vrios tipos novos de diagrama. At os diagramas j conhe
cidos tm muita notao nova, como os quadros de interao nos diagramas de seqn
cia. Se voc quiser saber o que aconteceu, mas no deseja percorrer a especificao (eu .
I
:;,I
;:
certamente no recomendo isso!), este livro deve lhe dar uma boa viso geral. -"
;,

. . _,

Tambm aproveitei essa oportunidade para reescrever completamente a maior par .:

'
re do livro, atualizando o texto e os exemplos. Incorporei grande parte do que aprendi
ensinando e usando a UML nos ltimos cinco anos. Assim, embora o esprito deste livro
t
ultra-fino sobre UML esteja intacto, a maioria das palavras nova. I
Com o passar dos anos, trabalhei arduamente para manter este livro o mais atuali- ; l
I
, .!
zado possvel. A medida que a UML passou por alteraes, fiz o melhor que pude para
acompanhar o ritmo. Este livro baseado nos, rascunhos da UML 2, que foram aceitas
'
.
;

pelo cornit pertinente, em junho de 2003. E improvvel que mais mudanas ocorram
entre essa votao e outras mais formais; portanto, acho que a UML 2 agora encontra-se
estvel o suficiente para que minha reviso seja publicada. Vou divulgar informaes
sobre quaisquer atualizaes em minha pgina na Web (http://martinfowler.com) .

...............------------------------------------ ,'

AGRADECIMENTOS i'
.'

Durante muitos anos, muitas pessoas fizeram parte do sucesso deste livro. Agradeo .

'
primeiramente a Carter Shanklin e Kendall Scott. Carter foi o editor da Addison-Wesley
:.,
que sugeriu este livro para mim. Kendall Scott me ajudou a fazer as duas primeiras
edies, trabalhando no texto e nos desenhos. Eles fizeram o impossvel para publicar a
primeira edio em um tempo muito curto, enquanto mantinham a alta qualidade que I

as pessoas esperam da Addison-Wesley. Eles tambm ficavam fazendo as alteraes, du

rante os primeiros dias da UML, quando nada parecia estvel .

. .: .
,'.
:, . . "
"

.
,

.
- ..

. . . .
,-;, :, . : : .
XIV PREFCIO

Jim Odell foi meu mentor e guia em grande parte do incio de minha carreira. Ele
tambm esteve profundamente envolvido com os problemas tcnicos e pessoais para
fazer metodologistas dogmticos ajustarem suas diferenas e concordarem com um pa
dro comum. Sua contribuio para este livro foi profunda e difcil de medir, e aposto
que isso tambm vale para a UML.
A UML uma criatura de padres, mas sou alrgico aos organismos de pa
dres. Assim, para saber o que est havendo, preciso de uma rede de espies que
possa me manter atualizado sobre todas as maquinaes dos cornirs. Sem esses espi
es, incluindo Conrad Bock, Steve Cook, Cris Kobryn, Jim Odell, Guus Ramackers
e Jim Rumbaugh, eu estaria arruinado. Todos eles me deram dicas teis e responde-
ram perguntas estpidas.
Grady Booch, Ivar Jacobson e Jim Rumbaugh so conhecidos como os Trs Ami
gos. A despeito das brincadeiras que tenho feito nesses anos, eles me deram muito apoio
e estmulo para este livro. Nunca esqueam que minhas brincadeiras normalmente so
reflexo de um profundo apreo.
Os revisores so o segredo da qualidade de um livro e aprendi com Carter que voc
nunca pode ter revisores demais. Os revisores das edies anteriores desde livro foram
Simmi Kochhar Bhargava, Grady Booch, Eric Evans, Tom Hadfield, Ivar Jacobson, Ro
nald E. Jeffries, Joshua Kerievsky, Helen Klein, Jim Odell, Jim Rumbaugh e Vivek Salgar.
A terceira edio tambm teve um excelente grupo de revisores:

Conrad Bock Craig Larman

Andy Carmichael Steve Mellor
Alistair Cockburn Jim Odell
Steve Cook Alan O'Callaghan
Luke Hohmann Guus Ramackers
Pavel Hruby Jim Rumbaugh
Jon Kern Tim Seltzer
Cris Kobryn

Todos esses revisores gastaram tempo lendo o manuscrito e cada um deles en

controu pelo menos um erro gritante. Meus sinceros agradecimentos a todos eles.
Todos os erros gritantes que permanecem so de minha inteira responsabilidade.
Vou divulgar uma folha de errata na seo de livros do site martinfowler.com, quan
do eu os encontrar.
A equipe que projetou e escreveu a especificao UML composta por Don Bais
ley, Morgan Bjrkander, Conrad Bock, Steve Cook, Phillipe Desfray, Nathan Dykman,
Anders Ek, David Frankel, Eran Gery, Oystein Haugen, Sridhar Iyengar, Cris Kobryn,
Birger Moller-Pedersen, James Odell, Gunnar vergaard, Karin Palmkvist, Guus Ra
mackcrs, Jim Rumbaugh, Bran Selic, Thomas Weigert e Larry Williams. Sem eles, eu
no teria nada sobre o que escrever.
Pavel Hruby desenvolveu alguns modelos excelentes no Visio, que eu utilizo muito
para diagramas UML; voc pode obt-los no endereo http://phruby.com.
Muitas pessoas tm entrado em contato comigo, pela Internet e pessoalmente,
com sugestes e perguntas, e para apontar erros. No consigo lembrar de todos, mas
meus agradecimentos no so menos sinceros.
Ao pessoal da minha livraria tcnica predileta, SoftPro, em Burlington, Massachu
setts, EUA, que me deixou passar muitas horas l, olhando seu estoque para ver como as
pessoas usam a LJML na prtica, e que sempre me serviu um bom caf.
 PREFCIO XV

Na terceira edio, o editor de aquisies foi Mike Hendrickson. Kim Arney Mul

cahy gerenciou o projeto, assim como fez o layout e a limpeza dos diagramas. John
Fuller, da Addison-Wesley, foi o editor de produo, enquanto Evelyn Pyle e Rebecca
Rider ajudaram na edio de cpia e na reviso do livro. Agradeo a todos eles.
Cindy rem ficado comigo, enquanto eu insisto em escrever livros. Ento, ela usa o
produto no jardim.

Meus pais me deram uma boa educao, a partir da qual rudo brota.

MARTIN FOWLER

Melrose, Massachusetts, EUA

http://martinfowler.com

:,.
r

";
. 1

I
.
.,,.,., f . .
.. ,);1
-.''
.I
'.i .
:!
I
I
I
.'
;
;

:i 11:
' .
. '! \'
' .

l
. . '"'
l

. \

'I

!i
'

'
'

i

I
!
''
i
I

I
, .......
)o
- . - .. - . .

. ,, . '

-.' ..

. .- .-

.-....
. ,_

'. '

- .-,: .
;, .. ,.

. .
 .
,
umano

Captulo 1: Introduo 25
O que UML? 25 ..,.
I'.
,,
Maneiras de usar a UML 25
Como chegamos UML 30 '
I
Notaes e metamodelos 31 !
Diagramas UML . 33
'
O que UML vlida? . 34 i.
!
O significado de UML . 36 !

UML no suficiente 36
Onde comear com a UML
37
Onde encontrar mais informaes
38 '

. .l
Captulo 2: Processo de desenvolvimento 39
Processos iterativo e em cascata 39
Planejamentos preditivo e adaptativo 42 I
"
;
Processos geis 43 I'
ii
Rational Unified Process 44 1'
;

'
Como adequar um processo a um projeto 45 '-
ii

Como encaixar a UML em um processo 47 '

Anlise de requisitos . 47
Projeto
48 li'
,.
Do cum en rao . 49
Como entender o cdigo legado . 50 ..
Como escolher um processo de desenvolvimento 50
Onde encontrar mais informaes . 51 'I

''!
'!
Captulo 3: Diagramas de classes: os elementos bsicos 52
'
Propriedades
52 i!
I
Atributos . 52
Associaes . 54
Multiplicidade
54
Interpretao de propriedades em programas 55
Associaes bidirecionais 57
I
Operaes 59
''
. .
Generalizao
, .
. 60
Natas e comentarios . 61
'
..J'
,.. /'

,
.. .

.. ,,,,
. - , --.. .

. ., .

. 'e,
.

. -- .

-,_,=~.i
- ., "
<, 'i
. --

--'; .,

'
--\'.~--
'\ . , ..
"- .
 18 SUJ\1RIO

Dependncia 62
Regras de restrio - 64
Quando utilizar diagramas de classes 65
Onde encontrar mais informaes 66

C ap1tu .. eta
' l o 4 : Dragrarnas d e sequen A
. (17
Como criar e excluir participantes . 70
Laos, condicionais, etc 71
Chamadas sncronas e assncronas 74
Quando utilizar diagramas de seqncia 74

Captulo 5: Diagramas de classes: conceitos avanados 77

Palavras-chave 77
Responsabilidades 78
- e a trib
O peraoes a reos
n u tos es tti . 78
Agregaao . -
- e compos1ao . 79
Propriedades derivadas 80
Interfaces e classes abstratas 80
Read Only e Frozen 83
Objetos de referncia e objetos de valor 84
Associaes qualificadas 85
Classificao e generalizao . 85
- mu' l tip
Cl assi. ficaao ' .
. l a e dimamica . 86
Classe de associao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Classe de template (parametrizada) 90
Enumeraes 91
Classe ativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2
Visibilidade 92
Mensagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Captulo 6: Diagramas de objetos 94

Quando usar diagramas de objetos 94

Captulo 7: Diagramas de pacotes 96

Pacotes e dependncias 97

Aspectos dos pacotes 99

Como implementar pacotes 99
Quando usar diagramas de pacotes................................................................ IOI
Onde encontrar mais informaes IOI

Captulo 8: Diagramas de instalao I 02

Quando usar diagramas de instalao I 03
.
Captulo 9: Casos de uso 104
Contedo de um caso de uso 105
Diagramas de casos de uso . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Nveis de casos de uso 107
Casos de uso e funcionalidades (ou histrias) 108
 22 . FIGURAS

Figura 5.17
Classe template 90
Figura Elemento de amarrao (verso 1)
5.18 90
Figura Elemento de amarrao (verso 2)
5.19 91
Figura 5.20
Enumerao 91
Figura 5.21
Classe ativa 92
Figura 5.22
Classes com mensagens 93
Figura 6.1Diagrama de classes da estrutura de composio Festa 95
Figura 6.2Diagrama de objetos mostrando exemplos de instncias de Festa 95
Figura 7.1Maneiras de mostrar pacotes em diagramas 97
Figura 7.2Diagrama de pacotes para uma aplicao comercial 98
Figura 7.3Separando a Figura 7 .3 em dois aspectos 1 OO
Figura 7.4Um pacote implementado por outros pacotes 1 OO
Figura 7.5Definindo uma interface requerida em um pacote de cliente 1O1
Figura 8.1Exemplo de diagrama de instalao 103
Figura 9.1Exemplo de texto de caso de uso 105
Figura 9.2Diagrama de casos de uso 107
Figura 10.1
Um diagrama simples de mquina de estados 111
Figura 10.2
Eventos internos mostrados com o estado de digitao de
um campo de texto 112
Figura 10.3 Um estado com uma atividade 1 12
Figura 10.4 Superestado com subestados aninhados 113
Figura 10.5 Estados concorrentes ortogonais 1 14
Figura 10.6 Uma instruo switch aninhada da linguagem C# para manipular
a transio de estados da Figura 1 O .1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 115
Figura 10.7 Uma implementao de padro de estado para a Figura 10.1 116
Figura 11. l Um diagrama de atividades simples 119
Figura 11.2 Um diagrama de atividades auxiliar 121
. Figura 11.3 A atividade da Figura 11.1, modificada para executar a atividade
da Figura 11.2 121
Figura 11.4 Parties em um diagrama de atividades 122
Figura 11.5 Sinais em um diagrama de atividades 123
Figura 11.6 Enviando e recebendo sinais 123
Figura 11.7 Quatro maneiras de mostrar uma aresta 124
Figura 11.8 Transformao em um fluxo 125
Figura 11.9 Regio de expanso 126
Figura 11.1 O Abreviao para uma nica ao em uma regio de expanso 126

Figura 11.11 Finais de fluxo em uma atividade 127
Figura 11.12 Especificao de juno 127
Figura 12.1 Diagrama de comunicao para controle centralizado 130
Figura 12.2 Diagrama de comunicao com numerao decimal aninhada 130
Figura 13.1 Duas maneiras de mostrar um visualizador de TV e
suas interfaces 133
Figura 13.2 Viso interna de um componente (exemplo sugerido por
Jim Rumbaugh) 133
Figura 13.3 Um componente com vrias portas 133

Figura 14.1 Notao para componentes 135
Figura 14.2 Um exemplo de diagrama de componentes 135
Figura 15.1 Uma colaborao com seu diagrama de classes de papis 136
Figura 15.2 Um diagrama de seqncia para a colaborao leilo 137
 FIGURAS 23

Figura 15.3 Uma ocorrncia de colaborao . 137

Figura 15.4 Uma maneira no-padronizada de mostrar o uso de padres em
,.
]Unit (junit.org) 138
Figura 16. I Diagrama de resumo de interao 140
.. Figura 17.1 Diagrama de temporizao mostrando os estados como linhas 141
Figura 17.2 Diagrama de temporizao mostrando os estados como reas 142

t_;.. . ;,;.s";
__ ,,,,,. / :.
',.,_._. ,,

_i{';::.

-i

\
I
'I

'i'
'I
I
i

''

i
i

e,,>) ..

: ,'
.>;:,,-
_.,,: --
.e:
. - .

----.

..

-., .
... (,_ . . i:'.

.
-, . ' . .
.
-...,

_--...f .:

;.

-_;~'.:'

....
-. .
 Captulo 1

ntroduo

-------------------------------------
'
OQUE E UML?

UML (Unified Modeling Language) uma famlia de notaes grficas, apoiada por um
metamodelo nico, que ajuda na descrio e no projeto de sistemas de software, particu
larmente daqueles construdos utilizando o estilo orientado a objetos (00). Essa defini
o um tanto simplificada. Na verdade, para diferentes pessoas a UML tem significa
dos diferentes. Isso ocorre devido sua prpria histria e s diferentes maneiras de ver o
que compe um processo de engenharia de software eficaz. Como resultado, em grande
parte deste captulo, minha tarefa armar o cenrio para este livro, explicando as dife
rentes maneiras pelas quais as pessoas vern e utilizam a UML.
As linguagens grficas de modelagem existem h muito tempo na indstria do ,'
I
I
software. O propulsor fundamental por trs de todas elas que as linguagens de progra I
.,I

mao no esto em um nvel de abstrao suficientemente alto para facilitar as discus !

;
.. I
ses sobre projeto. t
Apesar de as linguagens grficas de modelagem existirem h muito tempo, h uma ''
''
. : I

enorme controvrsia sobre seu papel na indstria de software. Essas controvrsias afetam I
i
. f
diretamente o modo como as pessoas percebem o papel da UML em si. )
I

A UML um padro relativamente aberto, controlado pelo OMG (Object Mana

gement Group), um consrcio aberto de empresas. O OMG foi formado para estabele
cer padres que suportassem interoperabilidade, especificamente a de sistemas orienta
dos a objetos. Talvez, o OMG seja mais conhecido pelos padres CORBA (Common
Object Request Broker Architecture).
A UML nasceu da unificao das muitas linguagens grficas de modelagem orien
tadas a objetos que floresceram no final dos anos oitenta, incio dos noventa. Desde sua
apario, em 1997, ela fez com que essa torre de Babel fosse resolvida. Trata-se de um '
'1
servio pelo qual eu e muitos outros desenvolvedores estarnos profundamente agradecidos. !

I
I

~.-------------------------------------
MANE IRAS DE USAR A UML

No centro do papel da UML no desenvolvimento de software esto as diferentes manei

ras pelas quais as pessoas querem utiliz-la, diferenas que sobraram de outras linguagens
grficas de modelagem. Essas diferenas levam a argumentos longos e difceis sobre como
a UML deve ser utilizada.
.
'
I
i
. ,-> )

'
. , ....

. . , .
. ::'.: .

. .

... '

,- ..
',' :- .
.

. . .: ::
. :: :,
; . .- .
:
-

, ,

: .
>,
.

.
. .: _-.

,, ....
 ~
. .

26 UML ESSENCIAL

Para desemaranhar isso, Steve Mellor e eu propusemos, de forma independente,

urna caracterizao dos trs modos pelos quais as pessoas utilizam a UML: esboo, pro
jeto e linguagem de programao. De longe, o mais comum dos trs, pelo menos de
acordo com minha opinio tendenciosa, utilizar a UML como esboo. Nessa utiliza
o, os desenvolvedores usam a UML para ajudar a transmitir alguns aspectos de um
sistema. Assim como no caso de projetos, voc pode utilizar esboos no desenvolvimen
to" e na engenharia reversa. No desenvolvimento, desenha-se um diagrama UML antes
de se escrever o cdigo, enquanto a engenharia reversa constri um diagrama UML a
partir de um cdigo j existente, para ajudar em seu entendimento.
A essncia dos esboos a seletividade. No esboo para desenvolvimento, voc delineia
alguns problemas em cdigo que voc est prestes a escrever, normalmente discutindo-os
com um grupo de pessoas de sua equipe. Seu objetivo usar os esboos para ajudar a transmi
tir as idias e alternativas sobre o que est prestes a fazer. Voc no fala sobre todo o cdigo
que vai escrever, mas apenas sobre as questes importantes que quer passar primeiro para seus
colegas ou sees do projeto que deseja visualizar antes de iniciar a programao. Sesses
como essa podem ser muito curtas: uma sesso de 1 O minutos para discutir algumas horas de
programao ou um dia para discutir uma iterao de duas semanas.
Na engenharia reversa, voc usa esboos para explicar o funcionamento de alguma
parte de um sistema. Voc no mostra cada classe, mas apenas aquelas que so interes
santes e sobre as quais vale a pena falar, antes de se aprofundar no cdigo.
Como os esboos so muito informais e dinmicos, voc precisa faz-los rapida
mente e com colaborao; portanto, uma mdia comum um quadro branco (white
board). Os esboos tambm so teis em documentos, no caso em que o foco a comu
nicao, em vez da perfeio. As ferramentas usadas para fazer esboos so ferramentas
de desenho leves, e freqentemente as pessoas no so muito exigentes a respeito de
manter cada regra restrita da UML. A maioria dos diagramas UML mostrada em livros,
tais como nos meus prprios, constituda de esboos. Sua nfase est na comunicao
seletiva, em vez da especificao completa.
Em contraste, a UML como projeto tem como foco a completeza. No desenvolvimen
to, a idia de que os projetos so desenvolvidos por um projetista, cujo trabalho construir
um projeto detalhado para um programador codificar. Esse projeto deve ser suficientemente
completo, no sentido de que todas as decises estejam expostas, e o programador deve ser
capaz de segui-lo como uma atividade simples e direta, que exija poucas consideraes. O
projetista pode ser tambm o programador, mas normalmente um desenvolvedor mais

experiente, que trabalha em uma equipe de programadores. A inspirao para essa estratgia

provm de outras formas de engenharia, nas quais engenheiros profissionais criam desenhos
de engenharia que so distribudos para empresas de construo edificarem .
Os desenhos podem ser usados para todos os detalhes ou um projetista pode dese

nh-los para uma rea em particular. Uma estratgia comum um projetista desenvolver
modelos em nvel de projeto, no que diz respeito s interfaces de subsistemas, mas deixando
que os desenvolvedores trabalhem nos pormenores da implementao desses detalhes.
Na engenharia reversa, os projetos tm como objetivo transmitir informaes deta

. lhadas sobre o cdigo em documentos em papel ou via um navegador grfico interativo .
Os projetos podem mostrar, de forma grfica, cada detalhe sobre uma classe, que mais
fcil para os desenvolvedores entenderem.

Os projetos precisam de ferramentas muito mais sofisticadas do que os esboos,
para manipular os detalhes exigidos para cada tarefa. As ferramentas CASE (engenharia

N. de R.T.: O autor usou o termo "forward engineering",

 .
: .
,>. "

CAPTULO 1: INTRODUO 27

de software auxiliada por computador) especializadas caem nessa categoria, em:bora o

termo CASE tenha se tornado um palavro e agora os vendedores tentem evit-lo. As

ferramentas de desenvolvimento suportam desenhos de diagramas e os armazenam em
um repositrio para manter as informaes. As ferramentas de engenharia reversa lem o
cdigo-fonte, o interpretam a partir do repositrio e geram diagramas. Ferramentas de

desenvolvimento e de engenharia reversa como essas so referidas como ferramentas de

ida e volta.
Algumas ferramentas usam o prprio cdigo-fonte como repositrio e utilizam
diagramas como uma porta de visualizao grfica do cdigo. Essas ferramentas esto

muito mais ligadas programao e freqentemente se integram diretamente com os

editores de programao. Costumo denominar essas ferramentas de estticas.
A linha entre os projetos e os esboos bastante tnue, mas a distino, acho eu,
repousa no fato de que os esboos so informaes deliberadamente incompletas que
evidenciam informaes importantes, enquanto que os projetos pretendem ser abran
gentes, freqentemente com o objetivo de reduzir a programao a uma atividade sim .
.l' .
ples e completamente mecnica. De forma sucinta, eu diria que os esboos so explora
tivos, enquanto os projetos so definitivos.
' . .
A medida que voc trabalha com a UML e a programao fica cada vez mais mec-
nica, torna-se evidente que esta deve ser automatizada. Na verdade, muitas ferramentas
CASE realizam alguma gerao de cdigo, o que automatiza a construo de uma parte
significativa de um sistema. Finalmente, voc chega em um ponto em que todo o siste
ma pode ser especificado na UML e, assim, chega UML como linguagem de progra
mao. Nesse ambiente, os desenvolvedores desenham diagramas UML que so compi
lados diretamente para o cdigo executvel e a UML se torna o cdigo-fonte. Obvia
mente, essa utilizao da UML exige ferramentas particularmente sofisticadas. (Alm
disso, as noes de engenharia direta e reversa no fazem nenhum sentido para esse
modo, pois a UML e o cdigo-fonte so a mesma coisa.) iI
l
'

..
f'
'
: l
MDA e UML Executvel f
i
.'
Quando as pessoas falam sobre a UML, freqentemente tambm falam sobre a MDA '''
.
(Model Driven Architecture) [ Kleppe et. al.]. Basicamente, a MOA uma estrat
gia padro para usar a UML corno linguagen1 de programao; o padro controla
do pelo OMG, assim como a UML. Produzindo um ambiente de modelagem de
acordo com a MOA, os fornecedores podem criar modelos que tambm podem
trabalhar com outros ambientes compatveis com a MOA.
Freqentemente, fala-se simultaneamente da MOA e da UML, pois a primeira
utiliza a segunda como linguagem de modelagem bsica. Mas, claro, voc no
precisa estar usando MOA para utilizar UML. -i
1
'
A MOA divide o trabalho de desenvolvimento em duas reas principais. Os !

modeladores representam uma aplicao em particular, por meio da criao de um

PIM (Platform Independent Model - modelo independente da plataforma). O
PIM um modelo da UML independente de qualquer tecnologia especfica. Ferra
mentas podem ento transformar o PIM em um PSM (Platform Specific Model -
modelo especfico de plataforma). O PIM um modelo de um sistema destinado a
um ambiente de execuo especfico. Assim, mais ferramentas pegam o PSM e ge
ram cdigo para essa plataforma. O PSM poderia ser feito em UML, mas isso no
obrigatrio.

'
,;,_.. ,J .

. _i'.
. '. .

,_;.:-;, .
 28 UML ESSENCIAL

Assim, se voc quiser construir um sistema de armazenagem usando MDA,

voc comear criando um PIM simples de seu sistema de armazenagem. Se desejar
que esse sistema de armazenagem seja executado em J2EE e em .NET, deve utilizar
as ferramentas de algum fornecedor para criar dois PSMs: um para cada plataforma.
Ento, mais ferramentas geraro cdigo para as duas plataformas.
Se o processo de passagem do PIM para o PSM e da para o cdigo final for
completamente automatizado, teremos a UML como linguagem de programao.
Se qualquer uma das etapas for manual, teremos os projetos.
Steve Mellor trabalha h bastante tempo nisso e, recentemente, utilizou o ter
mo UML executvel [Mellor e Balcer]. A UML executvel semelhante MDA,
mas utiliza termos ligeiramente diferentes. Analogamente, voc comea com um
modelo independente de plataforma que equivalente ao PIM da MDA. Entretan
to, a etapa seguinte consiste em utilizar um compilador de modelos para transfor
mar esse modelo UML em um sistema que possa ser distribudo em um nico passo;
portanto, no h necessidade do PSM. Conforme o termo compilador sugere, essa
etapa completamente automtica.
Os compiladores de modelos so baseados em arqutipos reutilizveis. Um
arqutipo descreve como pegar um modelo de UML executvel e transform-lo para
uma plataforma de programao em particular. Assim, para o exemplo de armazena
gem, voc compraria um compilador de modelos e dois arqutipos (J2EE e .NET).
.
.,
Execute cada arqutipo em seu modelo de UML executvel e voc ter suas duas
verses do sistema de armazenamento.
A UML executvel no usa o padro UML completo; muitas construes da
UML so consideradas desnecessrias e, portanto, no so usadas. Como resultado,
a UML executvel mais simples do que a UML completa.
Tudo isso parece bom, mas o quanto realista? No meu ponto de vista, exis
tem dois problemas aqui. Primeiro, h a questo das ferramentas: elas so maduras o
suficiente para o trabalho? Isso algo que muda com o passar do tempo; certamente,
no momento em que eu escrevia isto, elas no eram amplamente utilizadas e no
tenho visto muitas delas em ao.
Uma questo mais bsica a noo da UML como linguagem de programa
o. Em minha opinio, interessante usar a UML como linguagem de programa
o apenas se isso resultar em algo significativamente mais produtivo do que utilizar
outra linguagem de programao. No estou convencido de que seja, baseado em
vrios ambientes grficos de desenvolvimento com que trabalhei no passado. Mes
mo que seja mais produtivo, ainda necessrio obter uma massa crtica de usurios
para que seja considerado de uso comum. S isso j uma barreira enorme .

Assim como muitos usurios antigos de Smalltalk, eu considero esta linguagem
muito mais produtiva do que as linguagens de uso comum hoje. Mas, como
Smalltalk est agora relegada a segundo plano, no vejo muitos projetos que a
utilizam. Para evitar a sina da Smalltalk, a UML precisa ter mais sorte, mesmo
sendo superior .

Uma das questes interessantes sobre a UML como linguagem de programao

como modelar lgica comportamental. A UML 2 oferece trs espcies de modelagem com
portamental: diagramas de interao, diagramas de estado e diagramas de atividade. Todas
tm suas propostas de programao. Se a UML ganhar popularidade como linguagem de
programao, ser interessante ver quais dessas tcnicas se tornar bem-sucedida.
 'H, --------------------------------- ,--

CAPTULO 1: INTRODUO 29

Outra maneira pela qual as pessoas vern a UML a variao entre utiliz-la para
modelagem conceitua! e para a modelagem de software. A maioria das pessoas est fami
liarizada com o uso da UML para modelagem de software. Nessa perspectiva de softwa
re, os elementos da UML so mapeados diretamente nos elementos de um sistema de
software. Conforme veremos, o mapeamento no consagrado, mas quando usamos a
UML, estamos falando a respeito de elementos de software.
Na perspectiva conceituai, a UML representa uma descrio dos conceitos de um
domnio de estudo. Aqui, no estamos falando a respeito de elementos de software, tanto
quanto estamos construindo um vocabulrio para falarmos sobre um domnio em particular.
No existem regras rgidas e diretas sobre perspectiva; conforme se verifica, existe
uma gama de utilizao muito grande. Algumas ferramentas transformam automatica
mente cdigo-fonte em diagramas UML, tratando a UML como um modo de visualiza
o alternativo do cdigo-fonte. Isso se parece muito com uma perspectiva de software.
Se voc usar diagramas UML para tentar entender os vrios significados do termo fundo
de bens com vrios contadores, voc estar com uma disposio de esprito muito mais
conceituai.
Nas edies anteriores deste livro, eu dividi a perspectiva de software em especifica
o (interface) e implementao. Na prtica, descobri que era muito difcil traar uma
linha precisa entre as duas; portanto, achei que no era mais interessante fazer essa dis
tino. Entretanto, em meus diagramas, estou sempre propenso a enfatizar interfaces,
em vez de implementao.
Essas diferentes maneiras de usar a UML levam a muitos argumentos sobre o que Ii
significam os diagramas UML e qual sua relao com a realidade. Em particular, isso
afeta o relacionamento entre a UML e o cdigo-fonte. Algumas pessoas sustentam que a l
UML deve ser utilizada para criar um projeto que seja independente da linguagem de
programao usada para a implementao. Outras acreditam que o projeto independen II
i
te de linguagem como reunir palavras aparentemente contraditrias, com forte nfase
na contradio. .
'.
Outra diferena nos pontos de vista quanto a essncia da UML. Eu acho que a
maioria dos usurios da UML, particularmente os profissionais que fazem esboos, v a
.. r,
essncia da UML como sendo os diagramas. Entretanto, os criadores da UML vern os '
diagramas como secundrios; a essncia da UML o metamodelo. Os diagramas so simples
mente uma apresentao do metamodelo. Essa viso tambm faz sentido para os profissionais
que fazem projetos UML e para os usurios de UML como linguagem de programao.
Ento, sempre que voc ler algo que envolva a UML, importante entender o
ponto de vista do autor. Somente ento voc poder entender os argumentos freqente
mente ferozes que a UML estimula.
Dito isso, preciso tornar claras minhas preferncias. Quase sempre utilizo a UML
para fazer esboos. Acho os esboos UML teis para desenvolvimento e engenharia re
versa, tanto na perspectiva conceitua! como na de software.
No sou adepto dos projetos de desenvolvimento detalhados; acredito que, muito
difcil faz-los bem feitos, e eles retardam o trabalho de desenvolvimento. E razovel
fazer projetos em nvel de interfaces de subsistema, mas mesmo assim, voc deve esperar
alteraes nessas interfaces, a medida que os desenvolvedores implementarem as intera
es nelas. O valor dos projetos de engenharia reversa dependente do funcionamento
da ferramenta. Se ela for usada como um navegador dinmico, pode ser muito til; se ela
'
gerar um documento grande, estar apenas causando devastao.
Como linguagem de programao, eu vejo a UML como uma tima idia, mas
duvido que tenha uso significativo. No estou convencido de que as formas grficas

)
.,.,-'""""

,
.
.. .. .

, ",
..
.

, '

. , . ,'

. , . . .

. . ' ..

. . :.-
'

,' .
' '

.;, ..... :.
:'. ,. .

. . ,.. .
 30 UML ESSENCIAL

sejam mais produtivas do que as textuais para a maioria das tarefas de programao e,
mesmo que sejam, muito difcil que uma linguagem seja amplamente aceita.
Como resultado de minhas preferncias, este livro focaliza muito mais o uso da
UML para fazer esboos. Felizmente, isso faz sentido para um guia breve. Em um livro
deste tamanho, no posso fazer justia UML em seus outros modos, mas um livro
assim uma boa introduo para outros que o fazem. Portanto, se voc estiver interessa
do nos outros modos da UML, sugiro que trate este livro como uma introduo e con
sulte outros quando precisar. Se voc estiver interessado apenas em esboos, este livro
pode ser tudo que voc precisa .

............... ,--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
COMO CHEGAMOS UML

Vou admitir que sou aficionado por histria. Minha concepo predileta de leitura leve
um bom livro de histria. Mas tambm sei que essa no a idia de diverso de todo
mundo. Falo sobre histria aqui porque acho que, de muitas formas, difcil compreen
der onde a UML est, sem entender a histria de como ela chegou at aqui.
Na dcada de oitenta, os objetos comearam a sair dos laboratrios de pesquisa
e a dar seus primeiros passos em direo ao mundo "real". Smalltalk estabilizou-se
em uma plataforma confivel e surgiu a linguagem C++. Naquela poca, vrias pes
soas comearam a pensar a respeito das linguagens grficas de projeto orientadas
a objetos. -
Os livros essenciais sobre linguagens grficas de modelagem orientadas a obje
tos surgiram entre 1988 e 1992. Os principais profissionais incluam Grady Booch
[Booch, OOAD]; Peter Coad [Coad, OOA], [Coad, OOD]; Ivar Jacobson (Objec
tory) [Jacobson, OOSE); Jim Odell [Odell]; Jim Rumbaugh (OMT) [Rumbaugh,
idias], [Rumbaugh, OMT]; Sally Shlaer e Steve Mellor [Shlaer e Steve Mellor, da
dos], [Shlaer e Steve Mellor, estados]; e Rebecca Wirfs-Brock (Responsibility Driven
Design) [Wirfs-Brock].
Cada um desses autores estava, ento, liderando informalmente um grupo de
profissionais que gostavam daquelas idias. Todos esses mtodos eram muito pareci
dos, apesar de conterem vrias pequenas diferenas entre si. Os mesmos conceitos
bsicos apareciam em muitas notaes diferentes, o que causava confuso para os
meus clientes.
Durante aquela poca agitada, qualquer conversa sobre padronizao era ignorada .
Uma equipe do OMG tentou analisar uma padronizao, mas recebeu uma carta aberta

de protesto de todos os metodologistas importantes. (Isso me lembra uma velha piada:
Qual a diferena entre um metodologista e um terrorista? Resposta: com um terrorista
voc pode negociar.)

O evento cataclsmico que iniciou a UML se deu quando Jim Rumbaugh deixou a
General Electric e se uniu a Grady Brooch, da Rational (agora pertencente IBM). A

aliana entre Booch e Rumbaugh foi vista desde o incio como aquela que poderia obter
uma massa crtica da fatia de mercado. Grady e Jim proclamaram que "a guerra de mto
dos acabou - ns vencemos"-, declarando basicamente que eles iriam alcanar a padro
nizao " maneira da Microsoft". Vrios outros metodologistas sugeriram formar uma

Coalizo Anti-Booch.
Para a conferncia de OOPSLA 95, Grady e Jim haviam preparado a sua primeira
descrio pblica de seu mtodo unificado: a verso 0.8 da documentao do Mtodo
 CAPfTULO 1: INTRODUO 31

Unificado. Mais importante ainda, eles anunciaram que a Rational Software comprara a
Objectory e que, portanto, Ivar Jacobson iria unir-se equipe. A Rational fez uma festa
para comemorar o lanamento do rascunho 0.8, a qual foi muito concorrida. (O desta
que da festa foi a primeira apario pblica de Jim Rumbaugh cantando; todos espera
mos que tambm tenha sido a ltima.)
O ano seguinte viu emergir um processo mais aberto. O OMG, que de modo geral
tinha ficado parte, desempenhava agora um papel ativo. A Rational teve que incorpo
rar as idias de Ivar e tambm dispender algum tempo com outros parceiros. O mais
significativo foi que o OMG decidiu desempenhar um papel importante.
Neste ponto, importante compreender porque o OMG se envolveu. Os metodo
logistas, assim como os autores, gostam de pensar que eles so importantes, mas eu no
acho que os gritos dos autores de livros sejam ouvidos pelo OMG. O que fez o OMG se
envolver foram os gritos dos fornecedores de ferramentas, todos os quais estavam com
medo de que um padro controlado pela Rational desse uma vantagem competitiva
desleal essa empresa. Como resultado, os fornecedores incitaram o OMG a fazer algo a
i .
respeito, sob a bandeira da interoperabilidade da ferramenta CASE. Essa bandeira era
imporrante, pois o OMG estava totalmente voltado interoperabilidade. A idia era
criar uma UML que permitisse s ferramentas CASE trocar modelos livremente.
Mary Loomis e Jim Odell assumiram a liderana inicial do trabalho. Odell deixou
claro que estava preparado para desistir da sua metodologia em favor de um padro, mas
ele no queria um padro imposto pela Rational. Em janeiro de 1997, vrias organiza
es submeteram propostas para um padro de mtodos a fim de facilitar a troca de
modelos. A Rational colaborou com diversas outras organizaes e lanou a verso 1.0
da documentao UML como sua proposta, a primeira criatura a responder pelo nome
de Unified Modeling Language.
Seguiu-se, ento, um pequeno perodo de quebra de brao, enquanto vrias pro
postas eram unificadas. O OMG adotou a verso 1.1 resultante como um padro oficial
do OMG. Posteriormente, foram feitas algumas revises. A reviso 1.2 foi somente para
melhorar as aparncias, mas a 1.3 foi mais significativa. A reviso 1.4 acrescentou vrios . '
'
conceitos detalhados, relativos a componentes e a perfis. A reviso 1.5 adicionou semn ''
I
tica de ao. ',

Quando as pessoas falam sobre a UML, elas creditam principalmente a Grady

Booch, Ivar Jacobson e Jim Rumbaugh como seus criadores. Geralmente, eles so cha
mados de "os trs amigos", embora os piadistas gostem de omitir a primeira slaba da
segunda palavra. Embora eles sejam os mais reconhecidos em relao UML, acho um
tanto desleal dar a eles o crdito principal. A notao UML foi concebida pela primeira
vez no mtodo unificado de Booch/Rumbaugh. Desde ento, grande parte do trabalho
tem sido liderado pelos comits do OMG. Durante esses estgios posteriores, Jim Rum
baugh foi o nico dos trs a ter se comprometido de forma intensa. Eu acho que so esses
'
membros do comir do OMG relativo a UML que merecem o crdito principal por ela . '

...............
- -----------------------~------------
NOTAOES E METAMODELOS

No seu estado atual, a UML define uma notao e um metamodelo. A notao o

material grfico que voc v nos modelos; ela a sintaxe grfica da linguagem de mode
lagem. Por exemplo, a notao de diagrama de classes define como so representados os
itens e conceitos, como classe, associao e multiplicidade.

--~.)

. ' .
:, ...

-~ ..

. '

.
.: ".! .

.
:~;-~-. _: .
 32 UML ESSENCIAL

Certamente, isso leva questo sobre o que qt1eremos dizer exatamente com uma
associao ou multiplicidade ou mesmo uma classe. O uso comum sugere algumas defi
nies informais, mas algumas pessoas querem mais rigor.
A idia de linguagens rigorosas de especificao e de projeto prevalece mais no
campo dos mtodos formais. Em tais. tcnicas, projetos e especificaes so representa
dos usando alguns derivativos do clculo de predicados. Tais definies so matematica
mente rigorosas, no permitindo ambigidade. Entretanto, o valor dessas definies no
de forma alguma universal. Mesmo que voc possa provar que um programa satisfaz
uma especificao matemtica, no h maneira de provar que a especificao matemti
ca satisfaa realmente os requisitos reais do sistema.
A maioria das linguagens grficas de modelagem tem muito pouco rigor; suas no
taes apelam para a intuio, em vez de para uma definio formal. Em geral, isso
parece no ter causado muito prejuzo. Essas metodologias podem ser informais, mas
muitas pessoas ainda as consideram teis - e a utilidade que interessa.
No entanto, os metodologistas esto procurando maneiras de melhorar o rigor das
metodologias, sem sacrificar sua utilidade. Uma maneira de fazer isso definir um meta
modelo: um diagrama, geralmente um diagrama de classes, que define os conceitos da
linguagem.
A Figura 1.1 uma pequena parte do metamodelo UML que mostra o relaciona
mento entre as caractersticas. (Este segmento aparece a para dar uma idia do que so
os metamodelos. No vou nem tentar explic-lo.)
Quanto o metamodelo afeta um usurio da notao de modelagem? A resposta
depende principalmente do modo de utilizao. Um profissional que trabalhe com esbo
os normalmente no se preocupa muito; outro que trabalhe com projetos deve se preo
cupar bem mais. Isso fundamentalmente importante para aqueles que utilizam a UML
como linguagem de programao, pois ela define a sintaxe abstrata dessa linguagem.

Caracterstica

/\

Caracterstica Caracterstica
estrutural comportamental

6 0. 1

{ordered} *
Parmetro

FIGURA 1.1 Uma pequena parte do metamodelo UML.

.

:
CAPTULO 1: INTRODUO 33

Muitas das pessoas que esto envolvidas como desenvolvimento em andamento da

UML esto interessadas principalmente no metamodelo, particularmente porque isso
importante para a utilizao da UML e de uma linguagem de programao. Os proble

mas de notao freqentemente ficam em segundo plano, o que importante lembrar,
se voc tentar se familiarizar com os documentos padres propriamente ditos.
'
A medida que voc se aprofunda na utilizao mais ,
detalhada da UML, percebe
que precisa de muito mais do que a notao grfica. E por isso que as ferramentas de
UML so to complexas.
No sou muito rigoroso neste livro. Eu prefiro os camihos dos mtodos tradicio
nais e, de modo geral, apelo para a intuio do leitor. Isso natural para um livro peque
no como este, escrito por um autor principalmente inclinado a utilizao de esboos. Se
voc quiser um maior rigor, ento deve ler livros mais detalhados.

DIAGRAMAS UML

A UML 2 descreve 13 ti pos de diagramas oficiais, listados na Tabela 1.1 e classificados

conforme indicado na Figura 1.2. Embora esses tipos de diagrama sejam a maneira como
muitas pessoas encaram a UML e como eu organizei este livro, os autores da UML no
vem os diagramas como a parte central da UML. Como resultado, os tipos de diagrama
no so particularmente rgidos. Freqentemente, voc pode utilizar legalmente elemen
'
tos de um tipo de diagrama em outro diagrama. O padro UML indica que certos ele
mentos normalmente so desenhados em determinados tipos de diagrama, mas isso no \
, I
e uma regra.
'
'

: f
,_

' I
'
'
'i,
! !'
TABELA 1.1 Tipos de diagrama oficiais da UML : :

Captulos
Diagrama do livro Objetivo Linhagem ,,

Atividades 11 Comportamento procedimental e paralelo Na UML 1 '

'
Classes 3,5 Classe, caractersticas e relacionamentos Na UML 1
Comunicao 12 Interao entre objetos; nfase nas ligaes Diagrama de
colaborao da UML 1
""
Componentes 14 Estrutura e conexo de componentes Na UML 1
Estruturas compostas 13 Decomposio de uma classe em tempo Novidade da UML 2
de execuo
Distribuio 8 Distribuio de artefatos nos ns Na UML 1
Viso geral da 16 Mistura de diagrama de seqncia e de Novidade da UML 2
interao atividades
Objetos 6 Exemplo de configuraes de instncias Extra-oficialmente
na UML 1
Pacotes 7 Estrutura hierrquica em tempo de compilao Extra-oficialmente
na UML 1
Seqncia 4 Interao entre objetos; nfase na seqncia Na UML 1
Mquinas de estado 10 Como os eventos alteram um objeto no Na UML 1
decorrer de sua vida
Sincronismo 17 Interao entre objetos; nfase no sincronismo Novidade da UML 2
Casos de uso 9 Como os usurios interagem com um sistema Na UML 1

..
,., , ,_,.V ,J

. . -' .

_- -_._ ,.
 ... . -. - - .,

34 UML' ESSENCIAL.

Diagrama de
classes

Diagrama de
componentes

Diagrama de Diagrama de
estrutura < estruturas
compostas
Diagrama de
instalao
..
Diagrama de
objetos
Diagrama <~ Diagrama de
f
..
~-
pacotes {-.
,.

. ..
E
~
~-
[

Diagrama de f~-
atividades f~:
f,
~:
~:
"~~.
t.\ .
?;

r-~;.
Diagrama de ~~.
s.K.'
casos de uso r:
i:
,

... I~
t.
-\
t'i_:
t
t
Diagrama de K Diag_ramade f~:
comportamento maquina
de estados . .!~
$

_ Diagrama de
seqncia ,(,~:
:(
t~

i
}:
.....
e-;
;.:
_ Diagrama de ~...
;.
~
comunicao ~.:.

- Diagrama de k......,...
interaes
Diagrama de viso
w

- geral da interao

._ Diagrama de
sincronizao

FIGURA 1.2 Classificao dos tipos de diagrama da UML .

O QUE UML VLIDA?

.....

A primeira vista, essa deve ser uma pergunta simples de responder: UML vlida o que
definido como bem-formado na especificao. Na prtica, entretanto, a resposta um
pouco mais complicada.

~
 CAPTULO 1: lN'J'RODUO 35

Uma parte importante dessa questo se a UML possui regras descritivas ou pres
critivas. Uma linguagem com regras prescritivas controlada por um organismo oficial
que diz o que ou no vlido na linguagem e qual significado voc d s declaraes
nessa linguagem. Uma linguagem com regras descritivas aquela na qual voc enten
de suas regras examinando como as pessoas utilizam a linguagem na prtica. As
linguagens de programao tendem a ter regras prescritivas estabelecidas por um
cornit formador de padres ou por um fornecedor dominante, enquanto as lingua
gens naturais, como o ingls, tendem a ter regras descritivas, cujo significado esta
belecido por conveno.
A UML uma linguagem bastante precisa; portanto, voc pode esperar que ela
tenha regras prescririvas, Mas a UML reqenrementc considerada como sendo o equi
valente de software aos projetos em outras disciplinas da engenharia, e esses projetos no
so notaes prescririvas. Nenhum cornit diz quais so os smbolos vlidos em um
desenho estrutural de engenharia; a notao tem sido aceita por conveno, de forma
semelhante a uma linguagem natural. Simplesmente ter um organismo padronizador
tambm no resolve, pois as pessoas do setor podem no seguir todos os padres defini
dos por ele; basta perguntar aos franceses sobre a Acadmie Franaise. Alm disso, a
UML to complexa que o padro freqentemente aberto a mltiplas interpretaes.
Mesmo os lderes da UML que revisaram este livro discordariam quanto interpretao
do padro UML.
Essa questo importante tanto para mim, que estou escrevendo este livro,
quanto para voc, que est usando a UML. Se voc quiser compreender um diagra
ma UML, importante perceber que entender o padro UML no tudo. As pes
soas adotam convenes, amplamente na indstria e dentro de um projeto particu
j
lar. Como resultado, embora o padro possa ser a principal fonte de informao
sobre a UML, ele no pode ser o nico.
Minha postura a de que, para a maioria das pessoas, a UML possui regras descri ' II
'

tivas. O padro UML a maior influncia sobre o significado da UML, mas no o ' l!
i
nico. Acho que isso se tornar particularmente verdade com a UML 2, que apresenta I
.
algumas convenes de notao que entram em conflito com a definio da UML 1 ou i
com a utilizao convencional da UML, assim como acrescenta ainda mais complexida ' [.

de UML. Neste livro, portanto, estou tentando resumir a UML conforme eu a
percebo: com os padres e com a utilizao convencional. Quando eu tiver que fazer
uma distino neste livro, usarei o termo uso convencional para indicar algo que
no est no padro, mas que creio ser amplamente usado. Para algo que esteja de
acordo com o padro, usarei os termos padro ou normativo. (Normativo o termo
que os profissionais que trabalham com padres utilizam para indicar uma declara
o que voc deve obedecer para ser vlida no padro. Assim, UML no-normativa
uma maneira elegante de dizer que algo rigorosamente invlido, de acordo com o
padro UML.) '

Quando voc estiver examinando um diagrama UML, deve se lembrar de que

um princpio geral na UML que qualquer informao pode ser suprimida de um
diagrama em particular. Essa supresso pode ocorrer geralmente - ocultar todos os
atributos - ou especificamente - no exibir essas trs classes. Em um diagrama,
portanto, voc nunca pode inferir algo por sua ausncia. Se estiver faltando uma
multiplicidade, voc no pode inferir qual valor ela poderia ter. Mesmo que o meta
modelo lJML tenha um padro estabelecido, como [ l] para atributos, se voc no
vir a informao no diagrama, isso pode ser porgue se trata do padro estabelecido
ou porque ele foi suprimido .

..,..~ ... -.I' .

". ' .

.. '.

,.,. .:
- .-_,,, :
'. . . ":" .
"";' .
. ;: ...
 36 UML ESSENCIAL

Dito isso, existem algumas convenes gerais, como as propriedades que pos
. suem vrios valores como conjuntos. Vou apontar essas convenes padronizadas no
texto. ,
E importante no colocar muita nfase na obteno
,
de UML vlida, caso voc seja
um profissional que faz esboos ou esquemas. E mais importante ter um bom projeto
para seu sistema; e eu preferiria ter um bom projeto com UML invlida, ao invs de uma
UML vlida, mas com um projeto deficiente. Obviamente, bom e vlido melhor, mas
mais interessante dispender sua energia, na obteno de um bom projeto do que se
preocupar com os mistrios da UML. (E claro que voc precisa utilizar UML vlida
como linguagem de programao, seno seu programa no funcionar correramentel)

O SIGNIFICADO DE UML

Um dos problemas difceis sobre a UML que, embora a especificao descreva com
bastante detalhe o que UML bem-formada, ela no tem muito a dizer a respeito do que
significa UML fora do mundo refinado dos metamodelos UML. No existe nenhuma
definio formal sobre como a UML mapeada para qualquer linguagem de programa
o especfica. Voc no pode examinar um diagrama UML e dizer exatamente como
seria o cdigo equivalente. Entretanto, voc pode ter uma idia aproximada de como
ficaria o cdigo. Na prtica, isso suficiente para ser til. As equipes de desenvolvimento
freqentemente estabelecem suas convenes locais para isso e voc precisar se familia
rizar com aquelas que estejam sendo usadas.

- ,
UML NAO E SUFICIENTE

Embora a UML fornea um conjunto considervel de diversos diagramas que ajudam a

definir uma aplicao, de modo algum uma lista completa de todos os diagramas teis
que voc poderia querer usar. Em muitos lugares, diferentes diagramas podem ser teis,
e voc no deve hesitar em usar um diagrama que no seja feito com UML, se nenhum
diagrama da UML atender seu propsito.
A Figura 1.3, um diagrama de fluxo de tela, mostra as vrias telas de uma interface
com o usurio e como voc se move entre elas. Eu tenho visto e utilizado esses diagramas
de fluxo de tela h muitos anos. Nunca vi mais do que uma definio muito grosseira do
que eles significam; no h nada como isso na UML; apesar disso, acho que so diagra-
. , .
mas muito uteis.
A Tabela 1.2 mostra um outro diagrama favorito: a tabela de deciso. As tabelas de
deciso so uma boa maneira de mostrar condies lgicas complicadas. Voc pode fazer

isso com um diagrama de atividades, mas quando vai alm dos casos mais simples, a
tabela mais compacta e clara. Novamente, existem muitas formas de tabelas de deciso.
A Tabela 1.2 divide-se em duas sees: as condies esto acima da linha dupla e as
conseqncias esto abaixo dela. Cada coluna mostra como uma combinao particular
de condies leva a um conjunto especfico de seqncias.

Voc encontr~r vrios tipos dessas coisas em vrios livros. No hesite em experi
mentar tcnicas que paream apropriadas, para seu projeto. Se elas funcionarem bem,
utilize-as. Caso contrrio, descarte-as. (E claro que esse mesmo conselho vale para os
diagramas UML.)
 CAPTULO 1: INTRODUO 37
'

Bem-vindos Visitantes

nao- . -
navegaao- _
normativo'
.. ,, -_' -': :,- ...

AlteraesRecentes Localizar Pgina

'

. .
enviar pesquisa

para pginas alteradas recentemente

AlgumaPginadoWiki

tela
boto de
salvamento

'I
Passeio Virtual Pgina de Edio


FIGURA 1.3 Um diagrama informal de fluxo de tela para parte do hipertexto Wiki (http://c2.com/cgi/wiki). I f
j

'
I
I

I
; ~
f
TABELA 1.2 Uma tabela de deciso
.
!
. .'
~
'
. .
Cliente de 1 classe X X y y N N .

.
Ordem de prioridade y N y N y N . il
~
Pedido internacional y y N N N N

Taxa $150 $100 $70 $50 $80 $60

Relatrio de alerta
' '

'

-.------------------------------------
ONDECOMEAR COM A UML

Ningum, nem mesmo seus criadores, entende ou utiliza tudo que h na UML. A maio
ria das pessoas utiliza um pequeno subconjunto da UML e trabalha com isso. Voc precisa
encontrar o subconjunto da UML que funcione para seu caso e para o de seus colegas.
Se voc estiver apenas comeando, sugiro que se concentre primeiro nas formas
bsicas de diagramas de classes e de diagramas de seqncia. Esses so os tipos de diagra-
. . . , .
mas mais comuns e, creio eu, os mais ureis.
Quando voc tiver dominado esses diagramas, poder comear a usar alguma nota
o de diagrama de classes mais avanada e dar uma olhada nos outros tipos de diagra-

.. . )
. .

. .
 38 UML ESSENCIAL

mas. Faa experincias com os diagramas e veja quo teis eles so para voc. No tenha
medo de eliminar tudo que no parea til para seu trabalho.

ONDE ENCONTRAR
-
MAIS INFORMAOES

Este livro no. uma referncia completa e definitiva para UML, muito menos para
anlise e projeto orientados a objetos. H muito material publicado e muitas coisas que
'
valem a pena ser lidas. A medida que eu discutir os tpicos individuais, tambm mencio-
narei outros livros aos quais voc deve recorrer para obter informaes mais aprofunda
das. Aqui esto indicados alguns livros gerais sobre a UML e sobre o projeto orientado a
objetos.
Assim como em todas as recomendaes de livros, talvez voc precise verificar para
qual verso da UML eles foram escritos. Em junho de 2003, nenhum livro publicado
usava UML 2.0, o que no surpresa, pois o padro acabava de ser lanado. Os livros
que sugiro so muito bons, mas no posso dizer quando eles sero atualizados, se que
sero utilizadas, para o padro UML 2.
Se voc iniciante na rea de objetos, recomendo o meu livro introdutrio favori
to: [Larman]. A forte estratgia do autor direcionada responsabilidade para projetos
vale a pena ser seguida.
Para um texto conclusivo sobre a UML, voc deve ver os documentos do padro
oficial; mas, lembre-se de que eles so escritos para metodologistas que esto de acordo,
na privacidade de seus prprios cubculos. Para uma verso muito mais digervel do
padro, d uma olhada em [Rumbaugh, UML Reference].
Para informaes mais detalhadas sobre projeto orientado a objetos, voc aprende
r muito com [Martin].
Sugiro tambm que voc leia livros sobre padres para material que o levar alm
. do conhecimento bsico. Agora que a guerra de mtodos acabou, nos padres de projeto
(pgina 46) que aparece o material mais interessante sobre anlise e projeto .

Captulo

rocesso de Desenvolvimento

Conforme j mencionei, a UML originou-se a partir de diversas metodologias de

anlise e projeto orientados a objetos. At certo ponto, todos eles misturaram uma lin
guagem grfica de modelagem com um processo que descrevia como proceder no desen
volvimento
,
de software.
E interessante notar que, assim que a UML foi concebida, os vrios participantes
de sua formao descobriram que, embora pudessem concordar com uma linguagem de
modelagem, quase certamente no concordariam com um processo. Como resultado,
eles concordaram em deixar qualquer acordo sobre o processo para depois e restringir a
UML a uma linguagem de modelagem. i

'

O ttulo deste livro UML Essencial; portanto, eu poderia seguramente ignorar o

{
processo. Entretanto, no acredito que as tcnicas de modelagem tenham algum sentido
sem que se saiba como elas se encaixam no processo. A maneira como voc usa a UML
'
f '

depende muito do estilo de processo utilizado. .

'
~
'

Como resultado, acho que importante falar primeiro sobre processo, para que
voc possa ver o contexto da utilizao da UML. No vou entrar em muitos detalhes

sobre qualquer processo especfico; quero simplesmente fornecer informaes suficien
tes sobre esse contexto e indicar onde encontrar mais informaes sobre isso. '
Quando as pessoas discutem a UML, freqentemente voc as ouve falar a respeito
do RUP (Rational Unified Process). O RUP um processo - ou, mais rigorosamente,
uma estrutura de processo - que voc pode utilizar com a UML. Mas, a no ser pelo
envolvimento comum de vrias pessoas da Rational e pelo nome "unified" (unificado),
ele no tem nenhum relacionamento especial com a UML. A UML pode ser usada com
qualquer processo. O RUP uma estratgia popular e ser discutido mais adiante.
:,' .

. . ..
f .

PROCESSOS ITERATIVO E EM CASCATA

Um dos debates mais intensos sobre processo aquele entre os estilos em cascata e itera
tivo. Os termos so freqentemente empregados de forma errada, particularmente por
que o processo iterativo visto como elegante, enquanto que o processo em cascata
parece vestir cala xadrez. Como resultado, muitos projetos dizem ser iterativos, mas na
verdade so em cascata.
A diferena essencial entre os dois o modo como voc subdivide um projeto em
segmentos menores. Se voc tiver um projeto que acha que levar um ano, poucas pes
soas se sentiro vontade para dizer equipe que v trabalhar por um ano e volte quan-

. '

. '<

. -:-
--
.,-,'
._,: . ,

. . ' . .

. -- .
'

.. :- ..
 .,. .

40 UML ESSENCIAL

do o trabalho estiver pronto. Alguma interrupo necessria, para que as pessoas pos
sam encarar o problema e controlar o andamento.
O estilo em cascata subdivide um projeto com base nas atividades. Para construir
software, voc precisa realizar certas atividades: anlise dos requisitos, projeto, codifica
o e teste. Assim, nosso projeto de um ano poderia ter uma fase de anlise de dois
meses, seguida de uma fase de projeto de quatro meses, aps a qual viria uma fase de
codificao de trs meses, seguida de uma fase de teste de mais trs meses.
O estilo iterativo subdivide urn projeto em subconjuntos de funcionalidade.
Voc poderia pegar um ano e dividi-lo em iteraes de trs meses. Na primeira itera
o, voc pegaria um quarto dos requisitos e faria o ciclo de vida do software comple
to para esse quarto: anlise, projeto, cdigo e teste. No final da primeira iterao,
voc teria um sistema que faria um quarto da funcionalidade necessria. Ento, voc
faria uma segunda iterao tal que,, no final de seis meses, tivesse um sistema que
fizesse metade da funcionalidade. E claro que o exposto uma descrio simplifica-
da, mas a essncia da diferena. Na prtica, evidentemente, vazam algumas impu
rezas no processo.
No desenvolvimento em cascata, normalmente existe alguma espcie de transfe
rncia formal entre cada fase, mas freqentemente existem refluxos. Durante a codifica
o, pode surgir algo que o faa rever a anlise e o projeto. Voc certamente, no deve
supor que todo o projeto esteja concludo, quando a codificao comea. E inevitvel
que as decises de anlise e projeto tenham de ser revistas nas fases posteriores. Entretan
to, esses refluxos so excees e devem ser minimizados o mximo possvel.
No caso do estilo iterativo, voc normalmente v alguma forma de atividade explo
ratria, antes que as iteraes reais comecem. No mnimo, isso fornecer uma viso de
'
alto nvel dos requisitos: pelo menos o suficiente para subdividi-los nas iteraes que se '
I'
s
seguiro. Algumas decises de projeto de alto nvel tambm podem ocorrer durante a '

explorao. Por outro lado, embora cada iterao deva gerar software integrado pronto i.
''; .
para a produo, freqentemente ela no chega a esse ponto e precisa de um perodo de I

estabilizao para eliminar os ltimos erros. Alm disso, algumas atividades, como o ';
~

treinamento dos usurios, so deixadas para o final. r
Voc pode no colocar o sistema em produo ao final de cada iterao, mas ele '
'
''
deve ter qualidade de produo. Freqenternente, entretanto, voc pode colocar o siste
'
ma em produo em intervalos regulares; isso bom, porque voc avalia o sistema ante

cipadamente e obtm um retorno de melhor qualidade. Nessa situao, muitas vezes

voc ouve falar de um projeto com mltiplas verses, cada uma das quais subdividida
, . . ,...,
em varias 1teraoes.
O desenvolvimento iterativo tem aparecido com muitos nomes: incremental, espi
ral, evolutivo e jacuzzi, por exemplo. Vrias pessoas fazem distines entre eles, mas no
h um acordo generalizado a respeito, nem so to importantes, comparados dicoto
mia do processo iterativo/em cascata.
'
.
Voc pode ter estratgias hbridas. [McConnell] descreve o ciclo de vida da entrega
' por etapas, por meio da qual a anlise e o projeto de alto nvel so realizados primeiro,
,.
no estilo em cascata, e depois a codificao e o reste so divididos em iteraes. Tal
projeto poderia ter quatro meses de anlise e projeto, seguidos de quatro construes
iterativas do sistema, de dois meses cada uma. .1 ..

A maioria dos autores envolvidos com processos de software, especialmente da comu ..

,,..
nidade orientada a objetos, no gosta da estratgia em cascata. Dos muitos motivos
para isso, o mais importante que, com o processo em ,
cascata, muito difcil dizer '

se o projeto est realmente progredindo a contento. E fcil cantar vitria nas primei- . '.
.
'
 CAPTULO 2: PROCESSO DE DESENVOLVIMENTO 41

ras fases e ocultar um deslize no planejamento. Normalmente, a nica maneira de
saber se voc est no caminho certo produzir software integrado testado. Fazendo
isso repetidamente, um estilo iterativo fornece a voc um alerta melhor, caso algo esteja .

indo mal.
Somente por esse motivo, recomendo veementemente que os projetos no utilizem
uma estratgia em cascata pura. Voc deve usar pelo menos a entrega por etapas, se no
, . . . .
usar uma tecnica iteratrva mais pura.
H muito tempo a comunidade orientada a objetos a favor do desenvolvimento

iterativo e seguro dizer que todos os que esto envolvidos na construo da UML so a
favor de pelo menos alguma forma de desenvolvimento iterativo. Entretanto, minha
percepo da prtica do setor indica que o desenvolvimento em cascata ainda a estrat
gia mais comum. Um motivo para isso o que eu refiro como desenvolvimento pseudo
i terativo: as pessoas dizem que esto fazendo desenvolvimento iterativo, mas na verdade
esto usando o processo em cascata. Os sintomas comuns disso so:
"Estamos fazendo uma iterao de anlise seguida de duas iteraes de projeto ... "
"O cdigo dessa iterao est repleto de erros, mas vamos limp-lo no final."
,.,.
E particularmente importante que cada iterao produza cdigo integrado testado,
que seja o mais prximo possvel da qualidade de produo. O teste e a integrao so as
atividades mais difceis de estimar; portanto, importante no ter uma atividade aberta
como essa no final do projeto. O teste deve ser tal que qualquer iterao que no esteja

programada para ser lanada possa s-lo, sem um trabalho substancial extra de desenvol- : i
l
'
vimento.
Uma tcnica comum no caso das iteraes usar quadro de tempo. Isso obriga
uma iterao a ocorrer em um perodo de tempo fixo. Se voc achar que no vai conse
; {
. i
guir fazer tudo o que pretendia durante uma iterao, deve deslocar alguma funcionali ; !
i ~
' r
': ..
dade dela; voc no deve deslocar a data da iterao. A maioria dos projetos que utilizam !
:
.
:

desenvolvimento iterativo usam o mesmo perodo de iterao por todo o projeto; desse
modo, voc consegue um ritmo de construes regular.
Gosto do quadro de tempo, pois as pessoas normalmente tm dificuldade em des : r

locar funcionalidade. Praticando a funo de deslocamento de funcionalidade regular

mente, elas ficam em uma melhor posio para fazer uma escolha inteligente, em um
grande lanamento, entre deslocar uma data e deslocar uma funo. O deslocamento de
funes durante as iteraes tambm eficaz para ajudar as pessoas a aprender quais so
as prioridades reais dos requisitos.
Uma das preocupaes mais comuns a respeito do desenvolvimento iterativo a
questo de refazer o trabalho. O desenvolvimento iterativo supe explicitamente que
voc vai refazer o trabalho e excluir o cdigo j existente, durante as iteraes posteriores
de um projeto. Em muitos domnios, como na manufatura, refazer o trabalho visto
como desperdcio de tempo. Mas o software no como a manufatura; como resultado,
freqentemente mais eficaz refazer um cdigo j existente do que corrigir um cdigo
mal projetado. Diversas prticas tcnicas podem ajudar muito a refazer o trabalho de
forma mais eficiente.
Testes de regresso automatizados ajudam, permitindo que voc detecte rapida
mente quaisquer defeitos que possam ter sido introduzidos na alterao de algo. A
famlia xUnit de estruturas de teste uma ferramenta particularmente valiosa para a
construo de testes de unidade automatizados. Comeando corn o endereo da
]Unit original, gttp://junit.org, agora existem portas para praticamente todas as
 I
~:

f
i:.
f
t
f
,:\:.
i,:

t
;..
""
ri
42 UML ESSENCIAL F.

l.e:
-<
f,.

i::
fs,:.

linguagens imaginveis (veja o endereo http://www ..xprogramming.com/

software.htm). Uma boa regra geral a de que o tamanho do cdigo de sua ..
l..
,t
,
unidade em teste deve ser aproximadamente igual ao tamanho do seu cdigo de . ~:
~:
'
produo.
Refacto1"ing uma tcnica disciplinada para alterao de software j existente [Fow ..;

~.::
ler, refactoring]. O refactoring trabalha usando uma srie de pequenas transforma (

es na base de cdigo, que preservam o comportamento. Muitas dessas transforma :s;

t.
..;.~.
es podem ser automatizadas (veja o endereo http://www.refactoring.com). E1.
,,
r,

:s:'Y'
A integrao contnua mantm uma equipe em sincronismo para evitar ciclos :

de integrao complicados [Fowler e Foemmel]. No centro disso reside um pro

cesso de construo totalmente automatizado que pode ser disparado automati
camente, quando qualquer membro da equipe verifica o cdigo na base de cdi
go. Espera-se que os desenvolvedores faam verificaes diariamente; portanto,
as construes automatizadas so feitas muitas vezes por dia. O processo de
construo inclui executar um grande grupo de testes de regresso automatiza
dos, tal que quaisquer discrepncias sejam capturadas rapidamente, e que pos
sam ser corrigidas facilmente.
Todas essas prticas tcnicas foram popularizadas recentemente pela Extreme Pro
gramming [Beck], embora j tenham sido usadas anteriormente e possam (e devam) ser
;
utilizadas esteja voc usando ou no XP ou outro processo gil.
a;.

PLANEJAMENTOS PREDITIVO E ADAPTATIVO

Um motivo pelo qual o processo em cascata resiste o desejo de previsibilidade no

desenvolvimento de software. Nada mais frustrante do que no ter uma idia clara
do quanto custar desenvolver algum software e quanto tempo demorar para cons
tru-lo.
Uma estratgia preditiva procura fazer o trabalho antecipadamente no projeto, a
fim de gerar um maior entendimento do que precisa ser feito posteriormente. Dessa
maneira, voc pode chegar a um ponto onde a ltima parte do projeto pode ser estimada
com um grau de preciso razovel. No planejamento preditivo, um projeto tem dois
.. estgios. O primeiro estgio sugere planos e difcil de prever, mas o segundo estgio
muito mais previsvel, pois os planos esto estabelecidos. .
Isso no necessariamente um negcio preto-no-branco. A medida que o projeto

prossegue, voc obtm gradualmente muito mais previsibilidade. Mesmo quando voc
tem um plano preditivo, as coisas podem dar errado. Voc simplesmente espera que os
desvios se tornem menos significativos, quando um plano slido estiver estabelecido.
Entretanto, h uma discusso considervel sobre se muitos projetos de software
podem ser previsveis. No centro dessa questo est a anlise de requisitos. Uma das
nicas fontes de complexidade nos projetos de software a dificuldade de entender os
requisitos de um sistema de software. A maioria dos projetos de software passa por uma
revoluo de requisitos significativa: alteraes nos requisitos nos estgios posteriores do

projeto. Essas alteraes arruinam as bases de um plano preditivo. Voc pode combater
essas alteraes congelando os requisitos antecipadamente e no permitindo mudanas,
mas isso acarreta o risco de distribuir um sistema que no atende mais s necessidades de
~ .
seus usuarios.
 CAPTULO 2: PROCESSO DE DESENVOLVIMENTO 43

Esse problema leva a duas reaes muito diferentes. Um caminho elaborar me
lhor o processo de especificao dos requisitos em si. Dessa maneira, voc pode obter um

conjunto de requisitos mais preciso, o que reduzir a revoluo.
Outra escola sustenta que a revoluo de requisitos inevitvel, que para muitos proje
tos difcil demais estabilizar os requisitos suficientemente para utilizar um plano preditivo.
Isso pode ser devido tremenda dificuldade de imaginar o que o software pode fazer ou

porque as condies do mercado impem alteraes imprevisveis. Essa escola de pensamen

to defende o planejamento adaptativo, no qual a previsibilidade vista como uma iluso. Em

vez de nos_ enganarmos com uma previsibilidade ilusria, devemos encarar a realidade da

alterao constante e utilizar uma estratgia de planejamento que trata a alterao como uma

constante em um projeto de software. Essa alterao controlada para que o projeto gere o
melhor software possvel; mas, embora o projeto seja controlvel, ele no previsvel.
A diferena entre um projeto preditivo e um projeto adaptativo aparece nas muitas
maneiras pelas quais as pessoas falam a respeito de como o projeto est se desenvolvendo.
Quando as pessoas falam que um projeto vai bem, porque est de acordo com o planeja
do, essa uma forma preditiva de pensar. Voc no pode dizer "de acordo com o plane
jado" em um ambiente adaptativo, pois o plano est sempre mudando. Isso no significa
que os projetos adaptativos no tm planejamento; normalmente eles tm, e muito, mas
o plano tratado como uma linha de base para avaliar as conseqncias da alterao, em
vez de trat-lo como uma previso do futuro.
Em um plano preditivo, voc pode fechar um contrato a preo fixo e abrangncia
fixa. Tal contrato diz exatamente o que deve ser construdo, quanto custar e quando
'
. :
ser entregue. Tal determinao no possvel em um plano adaptativo. Voc pode fixar -
.,

. '.:.i
um oramento e um tempo para entrega, mas no pode estabelecer a funcionalidade que : {

ser entregue. Um contrato adaptativo pressupe que os usurios iro colaborar com a
equipe de desenvolvimento para reavaliar regularmente a funcionalidade que precisa ser .. ..

construda e cancelar o projeto, caso o progresso acabe sendo lento demais. Desse modo,
um processo de planejamento adaptativo pode ter preo fixo e abrangncia varivel.
Naturalmente, a estratgia adaptativa menos desejvel, pois qualquer pessoa pre
feriria previsibilidade em um projeto de software. No entanto, a previsibilidade depende
de um conjunto de requisitos preciso, exato e estvel. Se voc no puder estabilizar seus
requisitos, o plano preditivo no ter uma boa base e sero altas as chances de que o
projeto saia do curso. Isso leva a duas recomendaes importantes.
1. No faa um plano preditivo at ter requisitos precisos e exatos e at estar con
fiante de que eles no mudaro significativamente.
2. Se voc no puder obter requisitos precisos, exatos e estveis, utilize um estilo de
planejamento adaptativo.
A previsibilidade e a adaptabilidade estabelecem a escolha do ciclo de vida. Um
plano adaptativo exige absolutamente um processo iterativo. O planejamento preditivo
pode ser feito de qualquer uma das maneiras, embora seja mais fcil ver como ele funcio
na com uma estratgia de distribuio em cascata ou em estgios.

---- I

PROCESSOS AGEIS
.,,
Nos ltimos anos, rem havido muito interesse nos processos geis de software. Agil um
termo abrangente que compreende muitos processos que compartilham um conjunto

.. ------
 44 UML ESSENCIAL

comum de valores e de princpios, conforme definido pelo Manifesto of Agile Software

Development (http://agileManifesto.org). Exemplos desses processos so Extreme Pro
gramming (XP), Scrum, FDD (Feature Driven Development), Crystal e DSDM (Dy
namic Systems Development Method).
Nos termos de nossa discusso, os processos geis so fortemente adaptativos
por natureza. Eles tambm so processos muito voltados s pessoas. As estratgias
geis presumem que o fator mais importante no sucesso de um projeto a qualidade
das pessoas que esto envolvidas nele e o quo bem elas trabalham juntas, em termos
humanos. Os processos e as ferramentas que elas utilizam so estritamente efeitos de
segunda ordem.
As metodologias geis tendem a utilizar iteraes curtas e com quadro de tempo
estabelecido, freqentemente de um ms ou menos. Como no associam muito peso aos
documentos, as estratgias geis desprezam o uso da UML no projeto. A maioria utiliza
a UML no modo de esboo, com alguns defendendo seu uso como linguagem de pro-
,..
gramaao.
Os processos geis tendem a ter pouca formalidade. Um processo muito formal ou
pesado tem muitos documentos e pontos de controle durante o projeto. Os processos
geis consideram que a formalidade torna mais difcil fazer alteraes e vo contra a
natureza das pessoas talentosas.
...
Como resultado, os processos geis so freqentemente
caracterizados como leves. E importante perceber que a falta de formalidade uma con-
. ' + seqncia da adaptabilidade e da orientao das pessoas, em vez de ser uma propriedade
... fundamental .

RATIONAL UNIFIED PROCESS

Embora o RUP (Rational Unified Process) seja independente da UML, freqentemente

os dois so mencionados juntos. Assim, acho que interessante dizer algumas coisas a
respeito dele.
Embora o RUP seja chamado de processo, na verdade trata-se de uma estrutura de
processo, fornecendo um vocabulrio e uma vaga estrutura para falar sobre processos.
Quando voc usa o RUP, a primeira coisa que precisa fazer escolher um caso de desen
volvimento: o processo que voc vai utilizar no projeto. Os casos de desenvolvimento
podem variar bastante; portanto, no ache que seu caso de desenvolvimento ser pareci

do com algum outro. A escolha de um caso de desenvolvimento exige algum que esteja
antecipadamente familiarizado com o RUP: algum que possa personalizar o RUP para

as necessidades de um projeto em particular. Como alternativa, existe um conjunto cres
cente de casos de desenvolvimento empacotados, para dar partida.

Qualquer que seja o caso de desenvolvimento, o RUP basicamente um processo
iterativo. Um estilo em cascata no compatvel com a filosofia do RUP, embora, infeliz
mente, no seja incomum encontrar projetos que utilizam um processo de estilo em
casca ta e se fan tasi am de RUP.
Todos os projetos RUP devem seguir quatro fases.

l. A concepo faz uma avaliao inicial de um projeto. Normalmente, na con
cepo, voc decide se vai comprometer fundos pata realizar uma fase de
elaborao.
2. A elaborao identifica os casos de uso .principais do projeto e elabora o software
em iteraes para reorganizar a arquitetura do sistema. Ao final da elaborao,
 -------- ---- - - ...

CAPTULO 2: PROCESSO DE DESENVOLVIMENTO 45

-

voc deve ter uma boa idia dos requisitos e um esqueleto funcionaldo sistema,
que atue como semente de desenvolvimento. Em particular, voc deve ter en
contrado e resolvido os principais riscos do projeto.

3. A construo continua o processo, desenvolvendo funcionalidade suficiente para

o lanamento.
4. A transio inclui vrias atividades de ltimo estgio que voc no faz de forma
iterativa. Isso pode incluir a distribuio para o centro de dados, treinamento
dos usurios e coisas parecidas.

H muita impreciso entre as fases, especialmente entre a elaborao e a constru

o. Para alguns, a mudana para a construo o ponto em que voc pode passar para
um modo de planejamento preditivo. Para outros, ela apenas indica o ponto em que
voc tem uma viso ampla dos requisitos e uma arqu.itetura que voc acha que vai durar
pelo resto do projeto .
...
As vezes, o RUP referido como UP (Unified Process - processo unificado).
Isso feito normalmente por organizaes que desejam utilizar a terminologia e o
estilo global do RUP, sem usar os produtos licenciados da Rational Software. Voc
pode considerar o RUP como o produto da Rational baseado no UP ou pode consi
derar o RUP e o UP como idnticos. Seja l como for, voc encontrar pessoas que
concordam com sua idia.

.,
~

COMO ADEQUAR UM PROCESSO A UM PROJETO ,

;

1 ' '
J. '

Os projetos de software diferem muito uns dos outros. A maneira de proceder em um

!

desenvolvimento de software depende de muitos fatores: do tipo de sistema que est

sendo construdo, da tecnologia utilizada, do tamanho e da distribuio da equipe, da
natureza dos riscos, das consequncias de um fracasso, dos estilos de trabalho da equipe
e da cultura da organizao. Como resultado, voc nunca deve esperar que haja um
processo nico que funcione para todos os projetos.
Conseqentemente, voc sempre tem de adaptar um processo, de acordo com seu
ambiente particular. Uma das primeiras coisas que voc precisa fazer examinar seu
projeto e considerar quais processos parecem mais prximos ao desejado. Isso deve for
necer a voc uma lista de processos a considerar.
Voc deve considerar ento quais adaptaes precisa fazer para adequ-las ao seu
projeto. Voc precisa ser muito cuidadoso com isso. Muitos processos so difceis de
avaliar completamente, at que voc tenha trabalhado com eles. Nesses casos, fre
qentemente interessante utilizar um processo j pronto para fazer algumas itera
es, at voc saber como ele funciona. Ento, voc pode comear a modificar o
processo. Se voc estiver mais familiarizado com o funcionamento do processo des
de o incio, poder modific-lo j a partir desse ponto. Lembre-se de que normal
mente mais fcil comear com pouco e acrescentar itens do que comear com
muitas coisas e jog-las fora.
Por mais confiante que voc esteja com seu processo, fundamental aprender
medida que avana. Na verdade, uma das maiores vantagens do desenvolvimento itera
tivo que ele suporta melhorias freqentes no processo.
Ao final de cada iterao, realize uma retrospectiva de iterao, na qual a equipe se
rene para para considerar como as coisas correram e como elas podem ser aprimoradas.
 ~

46 UML ESSENCIAL
,,

Padres
A UML diz como expressar um projeto orientado a objetos. Ao contrrio, os pa
dres focam os resultados do processo: eles oferecem exemplos de projetos.
Muitas pessoas comentam que os projetos tm problemas porque as pessoas envol
vidas no estavam inteiradas de projetos bem conhecidos de pessoas mais experientes. Os
padres descrevem maneiras comuns de fazer as coisas e so coletados por pessoas que
identificam temas repetitivos em projetos. Essas pessoas examinam cada tema e o descre
vem de modo que outras pessoas possam ler o padro e ver como aplic-lo.
Vamos ver um exemplo. Digamos que voc tenha alguns objetos sendo execu
tados em um processo na sua mquina de trabalho e que eles precisam se comunicar
_ com outros objetos sendo executados em outro processo. Talvez, esse processo tam
bm esteja em sua rea de trabalho; talvez esteja em outro lugar. Voc no quer que
os objetos do seu sistema tenham que se preocupar em encontrar outros objetos na
rede ou executar chamadas de procedimentos remotos.
O que voc pode fazer criar um objeto proxy para o objeto remoto, dentro de
seu processo local. O proxy tem a mesma interface que o objeto remoto. Os seus
objetos locais se se comunicam com o proxy, utilizando envios normais de mensa
gens internas de processo. O proxy, ento, responsvel por passar todas as mensa
gens para o objeto real, onde ele estiver.
,. Os proxies so uma tcnica comum, utilizada em redes e em outros sistemas.
...
Profissionais tm muita experincia no uso de proxies, sabem como podem ser utili
zados, quais vantagens podem trazer, suas limitaes e como implement-los. Livros
de metodologia como este no discutem esse conhecimento; eles discutem apenas
como voc pode diagramar um proxy, que, apesar de ser til, no o tanto quanto a
discusso sobre a experincia envolvendo proxies.
No incio dos anos 90, algumas pessoas comearam a captar essas experincias.
Elas formaram uma comunidade interessada em escrever padres. Essas pessoas pa
trocinam conferncias e tm produzido vrios livros.
O livro mais famoso sobre padres que surgiu desse grupo foi o livro [Gangue
dos Quatro], que discute em detalhes 23 padres de projeto. Se voc quiser saber
sobre proxies, esse livro desenvolve o assunto em dez pginas, dando detalhes sobre
como os objetos funcionam em conjunto, benefcios e limitaes do padro, varia
es comuns e dicas de implementao .

Um padro muito mais do que um modelo. Um padro tambm deve incluir a

razo pela qual ele o que . Freqentemente diz-se que um padro uma soluo para
um problema. Um padro deve identificar o problema claramente, explicar porque ele
resolve o problema e tambm explicar em quais circunstncias ele funciona ou no.

Os padres so importantes porque so o prximo estgio alm da compreenso
do bsico de uma linguagem ou de uma tcnica de modelagem. Os padres fornecem
uma srie de solues e tambm mostram o que faz um bom modelo e como voc deve
proceder para construir um modelo. Eles ensinam por meio de exemplos .
Quando comecei, eu me perguntava por que tinha de inventar as coisas a par
tir do nada. Por qu eu no possua manuais para me mostrar como fazer coisas comuns?

A comunidade envolvida com padres est tentando elaborar esses manuais .
Existem, agora, muitos livros sobre padres no mercado e sua qualidade varia bas
tante. Meus prediletos so [Gangue dos Quatro], [POSAI], [POSA2], [Core J2EE Pat
terns], [Pont] e, modstia a parte, [Fowler, AP] e [Fowler, P of EAA]. Voc tambm pode
dar uma olhada na homepage sobre padres: http://www.hillsite.net/ patterns.
 CAPfTULO 2: PROCESSO DE DESENVOLVIMENTO 47

Duas horas suficiente, caso suas iteraes sejam curtas. Uma boa maneira de realizar
isso fazer uma lista com trs categorias:

l. Manter: coisas que funcionaram bem, as quais voc quer que continuem a fun-


cionar assim.
2. Problemas: reas que no esto funcionando bem.

3. Tentativa: alteraes em seu processo para aprimor-lo.

Voc pode comear cada retrospectiva de iterao aps a primeira, examinando os
itens da sesso anterior e vendo como as coisas mudaram. No se esquea da lista de
coisas a manter; importante controlar o que est funcionando. Se voc no fizer isso,
poder perder a perspectiva do projeto e, possivelmente, parar de prestar ateno nas
prticas de sucesso.
Ao final de um projeto ou de um lanamento importante, talvez voc queira con
siderar uma retrospectiva de projeto mais formal, que durar dois dias; veja o endereo
http://www.retrospectives.com/ e [Kerth], para obter mais detalhes. Uma de minhas
maiores irritaes a respeito de como as organizaes constantemente deixam de aprender
a partir de suas prprias experincias e acabam cometendo erros dispendiosos repetida
mente.

i~r-----------------------------------
,..._;:.
,:

.,f COMO ENCAIXAR A UML EM UM PROCESSO . '

.,
I
!:
o
'!
~

Ao examinar as linguagens grficas de modelagem, as pessoas normalmente as conside '

.
i
~
,f ' .
ram no contexto de um processo em cascata. Um processo em cascata normalmente .
.
~,
::-
~

possui documentos que atuam como transferncias entre as fases de anlise, projeto e
i.:

codificao. Os modelos grficos freqentemente podem formar uma parte importante

desses documentos. Na verdade, muitas das metodologias estruturadas dos anos 70 e 80
falam muito sobre modelos de anlise e projeto como esse.
Utilizando ou no uma estratgia em cascata, voc ainda executa as atividades de
anlise, projeto, codificao e teste. Voc pode executar um projeto iterativo com itera
es de uma semana, com cada semana sendo uma mini-cascata.
Usar a UML no implica necessariamente no desenvolvimento de documentos ou na
alimentao de uma ferramenta CASE complexa. Muitas pessoas desenham diagramas UML
em quadros brancos, somente durante uma reunio, para ajudar a transmitir as suas idias.

? __ ,,__ _
f
~i:-ANLISE DE REQUISITOS
.~

A atividade de anlise de requisitos procura descobrir o que os usurios e clientes de

um produto de software querem que o sistema faa. Vrias tcnicas de UML so
' . .
uteis aqui:
Casos de uso, que descrevem como as pessoas interagem com o sistema.
Um diagrama de classes desenhado a partir da perspectiva conceituai, o qual
pode ser uma boa maneira de construir um vocabulrio rigoroso do domnio.
Um diagrama de atividades, o qual pode exibir o fluxo de trabalho da organiza
o, mostrando como o software e as atividades humanas interagem. Um diagra-
 -
-
48 UML ESSENCIAL
,':.

ma de atividades pode mostrar o contexto dos casos de uso e tambm os deta

lhes sobre como um caso de uso complicado funciona. ~.
:-
f:

Um diagrama de estados, o qual pode ser til, caso um conceito tenha um ciclo r
:
de vida interessante, com vrios estados e eventos que mudam esses estados. ~
r
:

r:: .
Ao trabalhar na anlise de requisitos, lembre-se de que o mais importante a co
:;.
municao com seus usurios e clientes. Normalmente, eles no so profissionais de f}:
v-
-::.

software e no estaro familiarizados com a UML ou qualquer outra tcnica. Mesmo -

s:
~:

{-
f
assim, eu tive sucesso ein usar essas tcnicas com pessoal no-tcnico. Para fazer isso, r
f1>:
~'::
~-:-

lembre-se de que importante manter a notao em um mnimo. No introduza nada r.

f_:.
que seja especfico da implementao de software. :-,
f,-,:.
Esteja preparado para violar as regras da UML a qualquer momento, caso isso o ~-
-
r
e,,

ajude a se comunicar melhor. O maior risco ao utilizar a UML na anlise desenhar ;;_.:
"If
~~~
lb
diagramas que os especialistas do domnio no entendem completamente. Um diagrama ,_,..".
il'
t;
':..
.:.

que no entendido pelas pessoas que conhecem o domnio simplesmente intil; ele
l
.
.

apenas desenvolve um falso sentido de confiana para a equipe de desenvolvimento. f

.r
f

Projeto
I ~~.

~/{i::
Y
:

&:
;~.
t
t;.
~-
"'"
Quando voc est fazendo um projeto, pode ter diagramas mais tcnicos. Voc pode ~~~

~~,,

... ~;:
utilizar mais notao e ser mais preciso a respeito dela. Algumas tcnicas teis so:
'.}
t
Diagramas de classes a partir de uma perspectiva de software. Eles mostram as ...~: .
~
:=v.
classes presentes no software e como elas se relacionam. ~ '.
,..
j,
~
Diagramas de seqncia para cenrios comuns. Uma estratgia valiosa escolher os ~i;f'..'
~:.

cenrios mais importantes e interessantes dos casos de uso e utilizar cartes CRC ou iF.
,; '
r:

diagramas de seqncia para descobrir o que acontece no software.

Diagramas de pacotes para mostrar a organizao em larga escala do software. ;\; ..
;:,
,,:.
t;..
..1.~,...

Diagramas de estados para classes com histricos de vida complexos. ~-..

~,

J}:
:.,
Diagramas de distribuio para mostrar o layout fsico do software. if.
*.'
r
:,. ~

.~;:,: '
Muitas dessas mesmas tcnicas podem ser usadas para documentar o sojiioare, quando
\.'.'
... ele j tiver sido codificado. Isso pode ajudar s pessoas a se orientar no software, caso elas ., .:

,i~~:
~-
-
tenham que rrabalhar nele e no estejam familiarizadas com o cdigo. ;'~:
v,

...
.,! ..
~::- .
,y~.
~
Com um ciclo de vida em cascata, voc faria esses diagramas e essas atividades ~,:
;.:,
'.v.;,,

como parte das fases. Os documentos de final de fase normalmente incluem os diagra
mas UML apropriados para essa atividade. Um estilo em cascata normalmente implica l ~-..
',:
.:~
{f:.
que a UML seja usada como projeto. s-
,.:.~

Em um estilo iterativo, os diagramas UML podem ser utilizados como um projeto

ou como um esboo. No caso de um projeto, os diagramas de anlise normalmente sero
construdos na iterao anterior quela que cria a funcionalidade. A iterao no comea
do nada; em vez disso, ela modifica o texto dos documentos existente, destacando as
alteraes na nova iterao.
Os desenhos de projeto so normalmente feitos antecipadamente na iterao e
podem ser feitos em partes para diferentes funcionalidades destinadas iterao. Nova
mente, uma iterao implica em fazer alteraes em um modelo j existente, em vez de
criar um novo modelo a cada vez.
 CAPTULO 2: PROCESSO DE ESENVOLVIMENTO 49

Usar a UML no modo de esboo implica em um processo mais fluido. Uma estra
tgia passar uns dois dias, no incio de uma iterao, esboando o projeto para essa
iterao. Voc tambm pode fazer sesses curtas de projeto em qualquer ponto durante a
iterao, fazendo uma rpida reunio de meia hora, sempre que um desenvolvedor co
.

mear a atacar uma funo complicada.

No modo de projeto, voc espera que a implementao do cdigo acompanhe os

diagramas. Uma alterao no projeto um desvio que precisa de reviso por parte dos
projetistas que o elaboraram. Normalmente, um esboo tratado mais como um corte

de caminho no projeto. Se, durante a codificao, as pessoas acharem que o esboo no

est exatamente correto, elas devem se sentir livres para alterar o projeto. Os implemen

tadores precisam utilizar seu julgamento para identificar se a alterao precisa de uma
discusso mais ampla para entenderem todas as ramificaes.
Uma de minhas preocupaes com os projetos que, mesmo para um bom
projetista, muito mais difcil faz-los corretamente. Freqentemente, verifico que
meus prprios projetos no sobrevivem intactos ao contato com uma codificao.
Ainda considero meus esboos UML teis, mas no creio que eles possam ser trata
dos como absolutos.
Nos dois modos, faz sentido explorar vrias alternativas de projeto. Normalmente
melhor explorar alternativas no modo de esboo, para que voc possa gerar e alterar as
alternativas rapidamente. Quando voc escolher um projeto para executar, pode usar
esse esboo ou detalh-lo em uma planta de projeto.
''
'
'
'.'
Documentao
I
'''
Quando voc tiver construdo o software, poder utilizar a UML_ para ajud-lo a docu
mentar o que foi feito. Para isso, acho os diagramas UML teis para se obter um enten
dimento global de um sistema. Ao se fazer isso, no entanto, devo enfatizar que no
acredito na produo de diagramas detalhados do sistema inteiro. Para citar Cunningham
[Cunningham]:

Memorandos bem escritos e cuidadosamente selecionados podem facilmente substituir

uma documentao de projeto abrangente tradicional. Esta ltima raramente brilha,
exceto em pontos isolados. Eleve esses pontos ... e esquea o resto. (p. 384)

Acredito que uma documentao detalhada deva ser gerada a partir do cdigo -
como, por exemplo, JavaDoc. Voc deve escrever documentao adicional para salientar
conceitos importantes. Pense neles como sendo um primeiro passo para o leitor, antes
que ele entre nos detalhes do cdigo. Gosto de estrutur-los como textos curtos o sufi
ciente para serem lidos enquanto tomo um caf, utilizando diagramas UML para ajudar
a ilustrar a discusso. Eu prefiro os diagramas como esboos que destacam as partes mais
importantes do sistema. Obviamente, o escritor do documento precisa decidir o que im
portante e o que no , mas ele est muito melhor equipado do que o leitor para fazer isso.
Um diagrama de pacotes um bom mapa lgico do sistema. Esse diagrama me
ajuda a compreender as partes lgicas do sistema, ver as dependncias e mant-las sob
controle. Um diagrama de distribuio (veja o Captulo 8), que mostra a viso fsica de
alto nvel, tambm pode se mostrar til neste estgio.
Dentro de cada pacote, gosto de ver um diagrama de classes. No mostro todas as
operaes em cada classe. Mostro apenas as caracrcrsricas importantes que me ajudam a
 ~~---
.>

50 UML ESSENCIAL

entender o que existe l dentro. Esse diagrama de classes funciona como um sumrio
grfico.
O diagrama de classes deve ser suportado por diversos diagramas de interao, que
mostrem as interaes mais importantes no sistema. Novamente, a seletividade impor
tante aqui; lembre-se de que, nesse tipo de documento, a abrangncia inimiga da com
preensibilidade.
Se uma classe tem um comportamento de ciclo de vida complexo, eu desenho um
diagrama de mquina de estados (veja o Captulo 1 O) para descrev-lo. Fao isso somen
te se o comportamento for suficientemente complexo, o que no acontece com muita
freq ncia.
Incluirei, freqentemente, algum cdigo importante, escrito em um estilo erudito
de programao. Se um algoritmo particularmente complexo estiver envolvido, eu con
sidero a utilizao de um diagrama de atividades (veja o Captulo 11), mas somente se
ele proporcionar maior compreenso do que o prprio cdigo.
Se encontro conceitos que vm aparecendo repetidamente, uso padres (pgina
27) para captar as idias bsicas.
Um ds itens mais importantes a ser documentado so as alternativas de projeto
que voc no adotou e o por que no as tomou. Essa , freqentemente, a documentao
externa mais til, porm mais esquecida, que voc pode fornecer.

o;.
Como Entender o Cdigo Legado

A UML pode ajud-lo a entender um emaranhado de cdigos desconhecidos, de duas

maneiras. A construo de um esboo dos fatos principais pode funcionar como um
mecanismo grfico de anotaes, que o ajuda a capturar informaes importantes,
medida que voc as aprende. Os esboos das classes principais de um pacote e suas
interaes mais importantes podem ajudar a esclarecer o que est acontecendo.
Com ferramentas modernas, voc pode gerar informaes detalhadas para as par
tes fundamentais de um sistema. No utilize essas ferramentas para gerar grandes relat
rios em papel; em vez disso, utilize-as para sondar reas importantes, quando voc estiver
explorando o cdigo em si. Um recurso particularmente interessante a gerao de um
diagrama de seqncia para ver como os vrios objetos colaboram no tratamento de um
mtodo complexo.
~

COMO ESCOLHER UM PROCESSO DE DESENVOLVIMENTO

Sou francamente favorvel aos processos de desenvolvimento iterativo. Conforme j

mecionei neste livro, voc deve utilizar desenvolvimento iterativo somente em projetos

em que queira ter sucesso.
Talvez isso no seja muito srio, mas medida que fico mais velho, me torno mais
agressivo quanto utilizao de desenvolvimento iterativo. Bem-feita, trata-se de uma
tcnica fundamental, que voc pode usar para expor cedo os riscos e para obter um
melhor controle sobre o desenvolvimento. Isso no o mesmo que no ter nenhum

gerenciamento, embora, para ser justo, devo salientar que algumas pessoas o tenham
utilizado dessa maneira. O desenvolvimento iterativo precisa ser bem planejado, mas
um enfoque slido e todo livro sobre desenvolvimento orientado a objetos estimula a sua
utilizao - por boas razes.
 CAPTULO 2: PROCESSO DE DESENVOLVIMENTO 51

Voc no deve ficar surpreso em ouvir que, co~o um dos autores do Manifesto for
Agile Software Development, sou f ardoroso das estratgias geis. Tambm tive muitas

experincias positivas com a Extreme Programming e voc certamente deve levar suas
' . . ., .
praticas muito a serio.

............~--------------------~-----------------------------------------------

ONDE ENCONTRAR MAIS INFORMAES

'

Livros sobre processo de software sempre foram comuns e o surgimento do desenvolvi

mento gil de software levou a muitas novas pub.licaes. De modo geral, meu livro
predileto sobre processos em geral o [McConnell]. Ele fornece uma cobertura ampla e
prtica de muitos dos problemas envolvidos no desenvolvimento de software e uma lon
ga lista de prticas teis.
Da comunidade que trabalha com desenvolvimento gil de software, [Cockburn,
agile] e [Highsmith] fornecem uma boa viso geral. Para boas orientaes sobre. a aplica
o da UML num processo de maneira gil, veja [Ambler].
Uma das metodologias geis mais populares a Extreme Programming (XP),
na qual voc pode se aprofundar por intermdio de pginas da Web como http://
xprogramming.com e http:.//www.extremeprogramming.org. A XP gerou muitos li
vros e esse o motivo pelo qual eu agora me refiro a ela como metodologia anteriormen
te leve. O ponto de partida usual [Beck]. !
'
Embora seja escrito para XP, [Beck e Fowler] fornece mais detalhes sobre o plane '
.;

'1
...

jamento de um projeto iterativo. Grande parte disso tambm abordada por outros ';:
..

f . .
livros sobre XP, mas se voc estiver interessado apenas no aspecto do planejamento, essa .
. I
I'

:
seria uma boa escolha.
...
;

Para obter mais informaes sobre o Rational Unified Process, minha introduo
predileta [Kruchten].

,'

------ - ------- -
 i:;.- ,...
/

..
,.........---
!
;
i:..
~'.
f
r:.
e.<,
i'
.g.
.:.:
.:,';
!"
,:.
(
i,.
lif,1
ff:
y;.

Captulo 3 ,.
,r
:.
-i-.

-,::
,,
.,

f
i.:
a
f.;~-;

iagramas de Classes: t.,:

~
<
~
~-
~

Os Elementos Bsicos i
r~
~

i
-
f.~,.
rN
~

f
:.:
'f:

f.:I

~i..
'-'
:''
),
.,;i_....
/:

Se algum chegar perto de voc em um beco escuro e disser: "Psiu, quer ver um ~,'
,. ne
diagrama UML?", esse provavelmente seria um diagrama de classes. A maioria dos dia ;<\
~-
:,
...
gramas UML que vejo composta por diagramas de classes. t:
O diagrama de classes no apenas amplamente usado, mas tambm est sujeito .. '
.;
~!':.

maior variao de conceitos de modelagem. Embora os elementos bsicos sejam necess

'1,
,.,-,
...
i-.,
ite
'
'. :. .
rios para todo mundo, os conceitos avanados so utilizados com menos freqncia. .. ,(
~-~s,......
Portanto, dividi a minha exposio sobre diagramas de classes em duas partes: a bsica h
.......
..
!.'.
(este captulo) e a avanada (Captulo 5). f:=.
...
Um diagrama de classes descreve os tipos de objetos presentes no sistema e os ~;:.
'1,1

t.:..
:,.
vrios tipos de relacionamentos estticos existentes entre eles. Os diagramas de clas ,', .
,. '
,,
':-,
'~l ..'' .
ses tambm mostram as propriedades e as operaes de uma classe e as restries que
se aplicam maneira como os objetos esto conectados. A UML utiliza a palavra
caracterstica como um termo geral que cobre as propriedades e operaes de uma ,,
'. .
,\.

classe. s: .,:=r\
1:

A Figura 3.1 mostra urnmodelo de classes simples que no surpreenderia ningum

. que j tivesse trabalhado com processamento de pedidos. As caixas do diagrama so.
classes, as quais esto divididas em trs compartimentos: o nome da classe (em negrito),
seus atributos e suas operaes. A Figura 3 .1 tambm mostra dois tipos de relacionamen FIGU
tos entre as classes: associaes e generalizaes .

Propriedades

As propriedades representam as caractersticas estruturais de uma classe. Como uma

primeira aproximao, voc pode considerar as propriedades como correspondentes aos
campos de uma classe. A realidade bem mais complicada, conforme veremos, mas essa
uma considerao razovel, para comear.
As propriedades so um conceito simples, mas elas aparecem em duas notaes
bastante distintas: atributos e associaes. Embora elas paream bastante diferentes em
'
um diagrama, na realidade elas so a mesma coisa.

Atributos

A notao de atributo descreve uma propriedade como uma linha de texto dentro da
caixa de classe em si. A forma completa de um atributo :
 CAPTULO 3: DIAGRAMAS DE CLASSES: S ELEMENTOS BSICOS 53

Pedido multiplicidade

datadeRecebi mento: Cliente

Date[0 .. 1]
Pr-pago: Boolean[1] 1--*---------1 .....;;~ nome [1]
nmero: String [1] endereo [0.. 1]
preo: Money
. ,..., obterClassedeCrdito(): String
expedir() cssocrcco
encerrar() A
restrio
1
''
' \
\ classe

general i zao
'' I
'

{sePedido.cliente.obterClassedeCrdito "\
"ruim", ento Pedido.Pr-pago deve
ser "Verdadeiro"}
1m nome do papel

.ia- atributos Cliente Corporatlvo Cliente Pessoal

.. nomedeContato N me rod oCartodeC rdito

' :

itensdelinha operaes
classedeCrdito
'V * {ordered}
I
sa- limitedeCrdito

na,
Linha de Pedido fatu raM ensal (Integer)
rea aviso()
quantidade: Integer {obterClassedeCrdito() == "ruim"}
os preo: Money
*
as '!
:j

'

ue * navegvel rep. de vendas 'V 0.. 1 ,.

!
'j

'
'

rra ~

na Funcionrio
1 \V

.ao - Produto
o),
en- FIGURA 3.1 Um diagrama de classes simples.

visibilidade nome: tipo multiplicidade= valor-por-omisso {lista de propriedades}

Um exemplo disso aparece a seguir:

na - nome: String [l] = "Sem ttulo" { readOnly}
LOS
Somente o nome necessrio.
ssa
Esse marcador de visibilidade indica se o atributo pblico ( +) ou privado (-);

>es vamos discutir outras visibilidades na pgina 92 .

.m
O nome do atributo - como a classe se refere ao atributo - corresponde aproxi
madamente ao nome de um campo em uma linguagem de programao.

O tipo do atributo indica uma restrio sobre o tipo de objeto que pode ser
colocado no atributo. Voc pode considerar isso como o tipo de um campo em
uma linguagem de programao.
da
Vou explicar a multiplicidade na pgina 5_4.

. ........ _...... _
 -

":t"
,..
!~:,'
:'-

.-ti,{.
54 UML ESSENCIAL
-
r
,r..
>.:
,.,~
~-
. - 'H
-:l .

.:'
~;.<
O valor-por-omisso o valor do objeto novo criado, caso o atributo no seja '
',\.
o.
l~.
''(~:
especificado durante a criao. ,,

~,:,.,

O item { lista de propriedades} permite que voc indique propriedades adi

cionais para o atributo. No exemplo, usei { readnly} para indicar que os clien
tes no podem modificar a propriedade. Se isso estiver ausente, voc normal
mente pode supor que o atributo modificvel. Vou descrever outras proprieda
des medida que prosseguirmos.

Associaes

A outra maneira de anotar uma propriedade como uma associao. Praticamente as

mesmas informaes que voc pode exibir em um atributo aparecem em uma associao.
As Figuras 3.2 e 3.3 mostram as mesmas propriedades representadas nas duas notaes
diferentes.
Uma associao uma linha cheia entre duas classes, direcionada da classe de ori
gem para a classe de destino. O nome da propriedade fica no destino final da associao,
junto com sua multiplicidade. O destino final da associao vincula classe que o tipo
da propriedade.
Embora grande parte das mesmas informaes aparea nas duas notaes, alguns
itens so diferentes. Em particular, as associaes podem mostrar multiplicidades nas
o;.

duas extremidades da linha.

Com duas notaes para a mesma coisa, a pergunta bvia : por qu voc deve usar
r-

uma ou a outra? Em geral, eu tendo a utilizar atributos para coisas pequenas, como datas
ou valores booleanos -. normalmente, tipos de valor (pgina 73) - e associaes para
classes mais significativas, como clientes e pedidos. Eu tambm tendo a preferir o uso de
caixas para aquelas classes que so significativas para o diagrama, o que leva ao uso de
associaes, e atributos para coisas menos importantes desse diagrama. A escolha est
muito mais relacionada nfase do que a qualquer significado. subjacente.

MULTIPLICIDADE

A multiplicidade de uma propriedade uma indicao de quantos objetos podem preen

cher a propriedade. As multiplicidades que voc ver mais comumente so:

I (Um pedido deve ter exatamente um cliente.)

0.. 1 (Um cliente corporativo pode ter ou no um nico representante de vendas.)
* (Um cliente no precisa fazer um Pedido e no existe nenhum limite superior
para o nmero de Pedidos que um Cliente pode fazer - zero ou mais pedidos.)

Pedido

+ datadeRecebimento: Date[O.. 1] I
+ Pr-pago: Boolean[1]
+ itensdelinha: LinhadePedido[*] {ordered}

FIGURA 3.2 Mostrando as propriedades de um pedido como atributos.

 ~~~~--~-----------------------------=~~

CAPTULO 3: DIAGRAMAS DE CLASSES: S ELEMENTOS SlCOS 55 .

0.. 1 + prePago
Date ~
* Pedido ~ Boolean

+ datade Recebimento .. 1
...
' ~;~:
~
. . ... .. 1

origem
destino
,
. ,.,
::: ..
...
itensde Lin ha
-,., , * 't' {ordered}

Linha de
Pedido

FIGURA 3.3 Mostrando as propriedades de urn pedido como associaes.

Geralmente, as multiplicidades so definidas com um limite inferior e um limite supe

rior, como 2.. 4 para jogadores de canastra. O limite inferior pode ser qualquer nmero posi
tivo ou zero; o limite superior qualquer nmero positivo ou * (para ilimitado). Se os limites
inferior e superior forem os mesmos, voc pode usar um nico nmero; assim, 1 equivalen
te a 1 .. 1. Como se trata de um caso comum,* a abreviatura de O.. *.
Nos atributos, voc encontra vrios termos que se referem multiplicidade.
Opcional significa um limite inferior igual a O.
Obrigatrio significa um limite inferior igual a 1 ou possivelmente mais.
..
Valor nico significa um limite superior igual a 1.
,.
"
,;
,'

Valores mltiplos significa um limite superior maior que 1: normalmente, ",

Se eu tiver uma propriedade de valores mltiplos, prefiro utilizar uma forma plural
para seu nome. .
Caso no sejam especificados, os elementos em uma multiplicidade de valores ml
tiplos formam um conjunto; portanto, se voc solicitar os pedidos de um cliente, eles
no voltaro em qualquer ordem. Se a ordem dos pedidos na associao for significativa,
voc precisar adicionar {ordered} na ponta da associao. Se voc quiser permitir a
existncia de duplicatas, adicione { non unique}. {Se voc quiser mostrar o padro expli
citamente, pode usar {unordered} e {unique}.) Voc tambm poder ver nomes orien
tados coleo, como {bag} para no-ordenado e no-exclusivo.
A UML 1 permitia multiplicidades descontnuas, como 2, 4 (significando 2 ou 4,
como nos carros, no tempo em que no havia minivans). As multiplicidades descontnu
as no eram muito comuns e a UML 2 as eliminou.
A multiplicidade padro de um atributo [l.]. Embora isso seja verdade no meta
modelo, voc no pode sup_.or que um atributo em um diagrama que no possui multi- .

plicidade tenha um valor igual a [ 1], pois o diagrama pode estar suprimindo a informa-
o de multiplicidade. Como resultado, eu prefiro indicar explicitamente uma multipli- .
cidade [ 1], se isso for importante.

1:----------------------------------------
.~,:,,

{ INTERPRETAO DE.PROPRIEDADES EM PROGRAMAS

Assim como acontece com tudo na UML, no existe uma maneira nica de interpretar
propriedades no cdigo. A representao de software mais comum a de um campo ou
 56 UML ESSENCIAL

de uma propriedade em sua linguagem de programao. Assim, a classe Linha de Pedido

da Figura 3.1 correspondesse a algo como o seguinte em Java:

public class LinhadePedido ...

private int quantidade;
private Dinheiro preo;
private Pedido pedido;
private Produto produto;

Em uma linguagem como C#, que possui propriedades, ela corresponderia a:

public class LinhadePedido ...
private int quantidade;
private Dinheiro Preo;
private Pedido Pedido;
private Produto Produto;

Note que um atributo normalmente corresponde s propriedades pblicas em uma

linguagem que suporta propriedades, mas a campos privados, em um linguagem que
no suporta. Em uma linguagem sem propriedades, voc poder ver os campos expostos
por intermdio de mtodos acessores (de leitura e modificao). Um atributo somente
. ),
'
de leitura no ter nenhum mtodo de modificao (com campos) nem ao de conjun
e;.
to (para propriedades). Note que, se voc no der um nome para uma propriedade,
comum utilizar o nome da classe de destino.
~
A utilizao de campos privados uma interpretao muito focada na implemen
tao do diagrama. Em vez disso, uma interpretao mais voltada interface poderia se
concentrar nos mtodos de leitura, em vez de usar os dados subjacentes. Neste caso, podera
mos ver os atributos da Linha de Pedido correspondendo aos seguintes mtodos:

public class LinhadePedido ...

private int quantidade; .
r,

private Produto produto;

public i nt obterQuantidade () {
return quantidade;
}
. public void conf igurarQuantidade ( int quantidade) {
this.quantidade= quantidade;

}
public Dinheiro obter Preo () {
return produto.obterPreo() .multiply(quantidade);

}

. Nesse caso, no existe nenhum campo de dados para preo; em vez disso, ele um

valor calculado. Mas, no que diz respeito aos clientes da classe Linha de Pedido, ele
igual a um campo. Os clientes no conseguem diferenciar o que um campo e o que

calculado. Essa ocultao de informaes a essncia do encapsulamento .
Se um atributo tem valores mltiplos, isso significa que os dados envolvidos so
uma coleo. Assim, uma classe Pedido faria referncia a unia coleo de Linhas de
Pedido. Como essa multiplicidade ordenada, essa coleo deve ser ordenada (como um
elemento List em Java ou um elemento IList em .NET). Se a coleo no ordenada,
 CAPTULO 3: DIAGRAMAS DE CLASSES: S ELEMENTOS BSICOS 57

rigorosamente ela no deveria ter nenhuma ordem significativa e, assim, ser implemen

tada como urn conjunto, mas a maioria das pessoas implementa atributos no-ordena
dos tambm como listas. Alguns utilizam arrays, mas a UML requer um limite superior

ilimitado; portanto, eu quase sempre utilizo uma coleo como estrutura de dados.
As propriedades de valores mltiplos produzem um tipo diferente de interface para
propriedades de valor nico (em Java):

class Pedido {
private Set itensdeLinha = new HashSet();

public Set obterltensdeLinha () {

return Colees.unmodifiableSet(itensdeLinha);
}
public void adicionaritemdeLinha(ItemdoPedido arg) {
i tens de Linha. add (arg) ;
}
public void removeritemdeLinha ( IterndoPedido arg) {
itensdeLinha.remove(arg);
}

Na maioria dos casos, voc no faz atribuio a uma propriedade de valores mlti
plos; ein vez disso, voc atualiza com os mtodos add e remove. Para controlar sua pro
priedade Itens de Linha, o pedido deve controlar a participao como membro dessa
coleo; como resultado, ele no deve passar a coleo vazia. Neste caso, eu usei um proxy
de proteo para fornecer um wrapper somente de leitura para a coleo. Voc tambm
pode fornecer um iterador no-atualizvel ou fazer uma cpia. Os clientes podem modi f '
ficar os objetos membro, mas no devem alterar diretamente a coleo em si.
Como os atributos de valores mltiplos implicam em colees, voc quase nunca
v classes de coleo em um diagrama de classes. Voc os exibiria somente em diagramas
de implementao de nvel muito baixo, das prprias colees.
Voc deve evitar classes que no so outra coisa a no ser uma coleo de campos e
seus mtodos acessores. O projeto orientado a objetos tem como tema o fornecimento
de objetos que tm um comportamento rico; portanto, eles no devem estar simples
mente fornecendo dados para outros objetos. Se voc estiver fazendo chamadas repetidas
a dados utilizando acessores, esse um sinal de que algum comportamento deve ser
movido para o objeto que possui os dados.
Esses exemplos tambm reforam o fato de que no existe uma correspondncia
rgida e direta entre a UML e cdigo, apesar de haver uma semelhana. Dentro de uma
equipe de projeto, as convenes levaro a uma correspondncia mais prxima.
Se uma propriedade implementada como um campo ou como um valor calcula
do, isso representa algo que um objeto sempre pode fornecer. Voc no deve usar uma
propriedade para modelar um relacionamento transitrio, como um objeto que passa
do como parmetro durante uma chamada de mtodo e utilizado apenas dentro dos
limites dessa interao.

----
ASSOCIAES BIDIRECIONAIS

As associaes que vimos at aqui so chamadas de unidirecionais. Outro tipo comum

de associao a bidirecional, como mostra a Fgura 3.4.

/
.-------
 58 UML ESSENCIAL

Pessoa IE_: ~ Carro

FIGURA 3.4 Uma associao bidirecional.

Uma associao bidirecional um par de propriedades inversamente vinculadas. A

classe Carro tem a propriedade proprietrio: Pessoa [ 1) e a classe Pessoa tem uma pro
priedade carros: Carro [ *]. (Observe como chamei a propriedade de "carros", na forma
plural do tipo da propriedade, uma conveno comum, mas no norrnariva.)
O vnculo inverso entre elas significa que, se voc seguir as duas propriedades,
dever retornar a um conjunto que contm seu ponto de partida. Por exemplo, se eu comear
com um MG Midget particular, encontrar seu proprietrio e depois ver os carros de seu
proprietrio, esse conjunto dever conter o Midget a partir do qual comecei.
Como uma alternativa denominao de uma associao por meio de uma proprieda
de, muitas pessoas, particularmente se tiverem experincia em modelagem de dados,
gostam de rotular uma associao utilizando um verbo (Figura 3.5) para que o relaciona
mento possa ser usado em uma frase. Isso vlido e voc pode adicionar uma seta na
associao para evitar ambiguidade. A maioria dos modeladores de objeto prefere usar
um nome de propriedade, pois isso corresponde melhor s responsabilidades e operaes.
,, Algumas pessoas nomeiam cada associao de alguma maneira. Eu prefiro nomear
~ uma associao somente quando isso melhorar o entendimento. J vi muitas associaes
com nomes tais como "tern" ou "est relacionado a".
~ Na Figura 3.4, a natureza bidirecional da associao fica evidente pelas setas de
navegabilidade nas duas extremidades da associao. A Figura 3.5 no tem setas; a UML
permite usar essa forma para indicar uma associao bidirecional ou quando voc no
est mostrando navegabilidade. Minha preferncia usar a seta de duas pontas da Figura
3.4, quando voc quer tornar claro que tem uma associao bidirecional.
Freqentemente um pouco complicado implementar uma associao bidirecio
nal em uma linguagem de programao, pois voc precisa certificar-se de que as duas
propriedades se mantenham sincronizadas. Usando C#, utilizo um cdigo nestes moldes
para implementar uma associao bidirecional:

class Carro ...

. public Pessoa Proprietrio {
get { return _proprietrio;}
set {

if (_proprietrio != .null) _proprietro.amigoCarros(} .Remove(this);
_proprietrio= valor;
if (_proprietrio != null) _proprietrio.arnigoCarros{) .Add(this);
}
}
private Pessoa_proprietrio;

Possui ~
Pessoa Carro
0.. 1 *
FIGURA 3.5 Usando um verbo para nomear uma associao.

-,
-,
'
'.~:}~tf~.:~
 CAPTULO 3: DIAGRAMAS DE CLASSES: Os ELEMENTOS ASICOS 59

class Pessoa ...
public IList Carros {
get {return ArrayList.ReadOnly( carros);}

}
public void AddCarro (Carro arg) {
arg.Proprietrio =this;
}
private IList carros~ new ArrayList();
internal IList AmigoCarros () {

//s deve ser usado por Carro.Proprietrio
return carros; ...

O principal permitir que um lado da associao - um lado de valor nico, se

possvel - controle o relacionamento. Para que isso funcione, o lado escravo (Pessoa)
precisa deixar vazar o encapsulamento de seus dados para o lado mestre. Isso acrescenta
um mtodo inoportuno na classe escrava, que realmente no deveria estar l, a no ser
que a linguagem tenha um controle de acesso refinado. Eu usei aqui a conveno de
atribuio de nomes amigo" como uma aprovao da linguagem C++, onde o mtodo
de modificao do mestre seria mesmo um amigo (friend). Assim como grande parte do .

cdigo de propriedade, esse material bastante padronizado, que o motivo pelo qual
muitas pessoas preferem utilizar alguma forma de gerao de cdigo para produzi-lo. .
'

Em modelos conceituais, a navegabilidade no uma questo importante; portan

to, no mostro quaisquer setas de navegabilidade nesses modelos.
'i
+ ' .

OPERAES
'%~

Operaes so as aes que uma classe sabe realizar. As operaes correspondem clara
mente aos mtodos presentes em uma classe. Normalmente, voc no mostra as opera
es que simplesmente manipulam propriedades, porque elas podem ser, na maioria das
vezes, inferidas.
A sintaxe completa da UML para as operaes
visibilidade nome (lista-de-parmetros): tipo-de-retorno {lista-de-propriedades}
O marcador visibilidade pblico (+) ou privado (-); outros na pgina 92.
O nome uma seqncia de caracteres.
A lista-de-parmetros a lista de parmetros da operao.
O tipo-de-retorno o tipo do valor retornado, se houver um.
A lista-de-propriedades indica os valores de propriedade que se aplicam
operao dada.
Os parmetros da lista de parmetros so anotados de maneira semelhante aos
atributos. A forma :
direo nome: tipo - valor-por-omisso
 ,('I'

'

>.
~

.~

60 UML ESSENCIAL t-. ..

~\

(:
'116i
.:.
-
f
..;f
, .
O nome, o tipo e o valor-por-omisso so iguais aos dos atributos. ...,.

A direo indica se o parmetro de entrada (in), sada (out) ou ambos (inout).

,_.. ..
i~::
Se nenhuma direo for mostrada, assume-se que ela seja in. ....;/.,.
,.

Um exemplo de operao de uma conta poderia ser:

+ saldoErn (data: Date): Dinheiro
Nos modelos conceituais, voc no deve usar operaes para especificar a interface
de uma classe. Em vez disso, utilize-as para indicar as responsabilidades principais de
cada classe, empregando, talvez, algumas palavras para resumir responsabilidades no es
tilo CRC (pgina 77).
Geralmente, considero til fazer distino entre as operaes que alteram o estado
do sistema daquelas que no alteram. A UML define uma consulta como uma operao
que obtm um valor de uma classe, sem mudar o estado do sistema - em outras palavras,
sem efeitos colaterais. Voc pode marcar tal operao com a palavra de propriedade {query}.
Refiro-me s operaes que alteram o estado como modificadores, tambm chamadas
de comandos.
Rigorosamente falando, a diferena entre consulta e modificadores se elas alte
ram o estado observvel [Meyer]. O estado observvel o que pode ser percebido do
exterior. Uma operao que atualiza uma memria cache alteraria o estado interno, mas
no teria nenhum efeito observvel no exterior.
. Considero til destacar as consultas, pois voc pode mudar a ordem de execu
o delas e no alterar o comportamento do sistema. Uma conveno comum
tentar escrever operaes de modo que os modificadores no retornem nenhum va
e
lor; desse modo, voc pode contar com o fato de que as operaes que retornam
valores so consultas. ,
[Meyer] se refere a isso como o princpio da separao Co-
mando-Consulta. As vezes difcil fazer isso o tempo todo, mas voc deve faz-lo o
mximo que puder.
Outros termos que voc s vezes encontra so mtodos de leitura e mtodos de
modificao. Um mtodo de leitura retorna um valor de um campo (e no faz mais
nada). Um mtodo de modificao coloca um valor em um campo (e no faz mais
nada). Do lado externo, um cliente no deve ser capaz de dizer se uma consulta um
mtodo de leitura ou se um modificador um mtodo de modificao. O conhecimento
dos mtodos de leitura e de modificao completamente interno classe.
Outra distino entre operao e mtodo. Uma operao algo que chamado

em um objeto (a declarao de procedimento), enquanto um mtodo o corpo de um

N
procedimento. Os dois so diferentes quando voc tem polimorfismo. Se voc tem um
supertipo com trs subtipos, cada um dos quais sobrepondo a operao obterPreo do
supertipo, ento tem uma operao e quatro mtodos que a implementam.
As pessoas usam, normalmente, operao e mtodo como sinnimos, mas existem
ocasies em que til ser preciso sobre a diferena.

-
-
GENERALIZAAO

Um exemplo tpico de generalizao o que envolve clientes e pessoas fsicas e jurdicas
de uma empresa. Elas tm diferenas mas tambm muitas semelhanas. As semelhanas
podem ser colocadas em uma classe geral Cliente (o supertipo), com Cliente Pessoa
Fsica e Cliente Pessoa Jurdica como subtipos.
 CAPTULO 3: DIAGRAMAS DE CLASSES: Os ELEMENTOS BAsrcos 61

Esse fenmeno tambm est sujeito a vrias interpretaes em diferentes perspecti

vas da modelagem. Conceitualmente, podemos dizer que Cliente Pessoa Jurdica um

subtipo de Cliente, se todas as instncias de Cliente Pessoa Jurdica tambm o so, por

definio, instncias de Cliente. Um Cliente Pessoa Jurdica , ento, um tipo especial

de Cliente. A idia principal a de que tudo que dissermos sobre um Cliente - associa
es, atributos, operaes - tambm verdadeiro para um Cliente Pessoa Jurdica.

Em uma perspectiva de software, a interpretao bvia a herana: o Cliente Pessoa
Jurdica urna subclasse de Cliente. Nas principais linguagens orientadas a objetos, a
subclasse herda todos os recursos da superclasse e pode sobrepor todos os mtodos da

superclasse.
Um princpio importante para utilizar a herana eficientemente a capacidade de
substituio. Eu devo ser capaz de substituir um Cliente Pessoa Jurdica dentro de qual
quer cdigo que exija um Cliente e tudo deve funcionar bem. Basicamente, isso significa
que, se voc escrever um cdigo supondo que tem um Cliente, ento pode usar livre
mente qualquer subtipo de Cliente. O Cliente Pessoa Jurdica pode responder a certos
comandos diferentemente de outro Cliente {usando polimorfismo), mas o chamador
no precisa se preocupar com a diferena. (Para mais informaes sobre isso, veja o
Princpio da Substituio de Liskov (LSP), em [Martin].)
Embora a herana seja um mecanismo poderoso, ela traz muita bagagem que nem
sempre necessria para se obter a capacidade de substituio. Um bom exemplo disso
o que acontecia nos primrdios da linguagem Java, quando muitas pessoas no gostavam .

da implementao da classe interna Vector e queriam substitu-la por algo mais leve.
Entretanto, a nica maneira pela qual elas podiam produzir uma classe que fosse substi
tuvel por Vector era por meio de sua subtipagem e isso significava herdar muitos dados
.f

e comportamento indesejados. '

'
;
,( ' '

'
Muitos outros mecanismos podem ser usados para fornecer classes substituveis.
Como resultado, muitas pessoas gostam de fazer distino entre subtipagem (ou herana
de interface) e subclassificao (ou herana de implementao). Uma classe um subti
po se ela substituvel por seu supertipo, utilize herana ou no. A subclassificao
usada corno sinnimo de herana regular.
Existem muitos outros mecanismos que permitem ter subtipos sem subclasses. Exem
plos disso so a implementao de uma interface (pgina 69) e muitos dos padres de
projeto [Gangue dos Quatro].

------ "
NOTAS E CO MENT ARIOS

Notas so comentrios nos diagramas. As notas podem ser isoladas ou vinculadas, com
uma linha tracejada, aos elementos que esto sendo comentados (Figura 3.6). Elas po
dem aparecer em qualquer tipo de diagrama.

Carro
.,,..
Inclui picapes e "' .,, ,. " .,,..
camionetes VANs,
mas no motocicletas

FIGURA 3.6 Uma nota usada como comentrio sobre um ou mais elementos do diagrama.
 '. ,...

62 UML ESSENCIAL

'
As vezes, a linha tracejada pode ser incmoda, pois voc no pode localizar exata-
mente onde essa linha termina. Assim, uma conveno comum colocar um pequeno
.....

crculo aberto no final da linha. As vezes, til ter um comentrio em linha em um

elemento do diagrama. Voc pode fazer isso prefixando o texto com dois traos: - - .

...
DEPENDENCIA

Uma dependncia entre dois elementos existe se mudanas na definio de um elemento )

(o fornecedor) podem causar mudanas ao outro (o cliente). Nas classes, as dependn- ,;
cas existem por vrias razes: uma classe envia uma mensagem para outra; uma classe
tem outra como parte de seus dados; uma classe menciona uma outra como um parme
tro de uma operao. Se uma classe muda a sua interface, qualquer mensagem enviada
para essa classe pode no ser mais vlida.
'
A medida que os sistemas de computador crescem, voc precisa se preocupar cada
vez mais com o controle das dependncias. Se as dependncias sarem de controle, cada
alterao em um sistema ter um amplo efeito de propagao medida que mais coisas
tiverem que mudar. Quanto maior a propagao, mais difcil a alterao de qualquer coisa.
A UML permite representar dependncias entre todos os tipos de elementos. Voc _;
usa dependncias quando quer mostrar como as mudanas em um elemento poderiam ::..,

alterar outros elementos.

.;. A Figura 3.7 mostra algumas dependncias que voc poderia encontrar em um
aplicativo de mtiplas camadas. A classe Plano de Benefcios - uma interface com o '.'
usurio ou classe de apresentao - dependente da classe Funcionrios: um objeto do :f
(
domnio que captura o comportamento essencial do sistema - neste caso, regras do '.;
negcio. Isso significa que, se a classe Funcionrio mudar sua interface, a classe Plano de -~
Benefcios talvez tenha que mudar.
O importante aqui que a dependncia apenas em uma direo e vai da classe de
apresentao para a classe do domnio. Desse modo, sabemos que podemos alterar livre
mente a classe Plano de Benefcios sem que essas alteraes tenham qualquer efeito sobre j1
a classe Funcionrios ou outros objetos do domnio. Descobri que uma separao rigo
rosa entre a apresentao e a lgica do domnio, com a apresentao dependendo do
domnio, mas no o contrrio, tem sido uma regra valiosa a ser seguida. _::
Um segundo detalhe notvel nesse diagrama que no existe nenhuma dependn- 1
- eia direta da classe Plano de Benefcios para as duas classes Entrada de Dados. Se essas '
classes mudarem, a classe Funcionarios talvez tenha que mudar. Mas se a alterao for

cliente fornecedor
Entrada de Dados
I
de Funcionrios
I
I
I
I
Janela de I

Benefcios ---------- Funcionrio - - -1

I
I
I
I
I
I Entrada de Dados
dependncia de Benefcios

FIGURA 3.7 Exemplos de dependncias.

 CAPTULO 3: DIAGRAMAS DE CLASSES: S ELEMENTOS BSICOS 63

apenas na implementao da classe Funcionrio e no em sua interface, a alterao vai
,
parar ai.
A UML tem muitas variedades de dependncia, cada uma com semntica e pala

vras-chave particulares. A dependncia bsica que destaquei aqui a que considero mais
til e normalmente a utilizo sem palavras-chave. Para adicionar mais detalhes, voc pode
acrescentar uma palavra-chave apropriada (Tabela 3.1).
A dependncia bsica no um relacionamento transitivo. Um exemplo de relacio
namento transitivo o relacionamento "barba maior". Se Jim tem barba maior do que

Grady e Grady tem barba maior do que Ivar, podemos deduzir que Jim tem barba maior

do que Ivar. Alguns tipos de dependncias, como a substituta, so transitivas, mas na
'
maioria dos casos existe uma diferena significativa entre as dependncias diretas e indi
retas, como se v na Figura 3. 7.
Muitos relacionamentos da UML implicam em uma dependncia. A associao
navegvel de Pedido para Cliente, na Figura 3.1, significa que o Pedido dependente do
Cliente. Uma subclasse dependente de sua superclasse, mas no o contrrio.
Sua regra geral deve ser minimizar as dependncias, particularmente quando elas
atravessam grandes reas de um sistema. Em particular, voc deve tomar cuidado com os
ciclos, pois eles podem levar a um ciclo de alteraes. No sou muito exigente quanto a
isso. No ligo para dependncias mtuas entre classes fortemente relacionadas, mas ten
to eliminar ciclos em um nvel mais amplo, particularmente entre pacotes.
Tentar mostrar todas as dependncias em um diagrama de classes uma perda de
tempo; existem muitas e elas mudam demais. Seja seletivo e mostre dependncias so
mente quando elas forem diretamente relevantes para o assunto especfico que voc quer
transmitir. Para entender e controlar dependncias, melhor utiliz-las com diagramas I
}
de pacotes (pgina 96). f '

O caso mais comum em que utilizo dependncias com classes ao ilustrar um

relacionamento transitrio, como quando um objeto passado para outro como par
metro. Voc pode ver isso usado com as palavras-chave par amet er, Loca l e glo
bal. Voc tambm pode ver essas palavras-chave em associaes nos modelos da UMI.J 1,

TABELA 3.1 Palavras-chave de dependncia selecionadas

Palavra-chave Sign ifcad o
call A origem chama uma operao no destino.
create A origem cria instncias do destino.
derive A origem derivada do destino.
instantiate A origem uma instncia do destino. (Note que, se a origem uma classe,
a prpria classe uma instncia de classe da classe; isto , a classe de
destino uma metaclasse.)
permit O destino permite que a origem acesse seus recursos privados.
realize A origem uma implementao de uma especificao ou Interface ~lefinida
pelo destino (pgina 80).
refine O refinamento indica um relacionamento entre diferentes nveis semnti
cos; por exemplo, a origem poderia ser uma classe de projeto e o destino, a
classe de anlise correspondente.
substitute A origem substituvel pelo destino (pgina 61 ).
trace Usada para controlar coisas como requisitos de classes ou como altera
es em um modelo se vinculam a alteraes em outro lugar.
<<us e A origem exige o destino para sua implementao.
 . ,

64 UML ESSENCIAL

no caso em que elas indicam vnculos transitrios e no propriedades. Essas palavre

chave no fazem parte da UML 2.
As dependncias podem ser determinadas examinando-se o cdigo; portanto, ff
ramentas so ideais para se fazer anlise de dependncia. Conseguir uma ferramenta pa
fazer engenharia reversa nos relacionamentos de dependncia a maneira mais til,
utilizar essa parte da UML.

------ -
REGRAS DE RESTRIAO

Grande parte do que voc faz quando desenha diagramas de classes indicar restrii
A Figura 3.1 indica que um Pedido pode ser feito apenas por um nico Cliente.
diagrama tambm implica que cada Item de Linha considerado separadamente: 1
Pedido, voc diz "40 elementos de )anela marrons, 40 elementos de janela azuis el
elementos de janela vermelhos" e no cc 120 coisas". Alm disso, o diagrama diz 'l
Cliente Pessoa Jurdica tem limite de crdito, mas Cliente Pessoa Fsica, no .
.fu construes bsicas de associao, atributo e generalizao fazem muito para espec
ficar restries importantes, mas elas no conseguem indicar todas as restries. Essas rest:
es ainda precisam ser capturadas; o diagrama de classes um bom lugar para faz-b
A UML permite que voc use qualquer coisa para descrever restries. A ni
. ' f . regra que voc as coloque entre chaves ({}). Voc pode utilizar linguagem natural, un
... linguagem de programao ou a linguagem formal de restries de objetos de Ulv
(OCL- Object Constraint Language) [Warmer e Kleppe], que baseada no clculo,
predicados. O uso de uma notao formal evita o risco de uma interpretao errn
devido a uma linguagem natural ambgua. No entanto, ela introduz o risco de interpr
rao errnea devida ao fato de os escritores e leitores no entenderem realmente a OC
Portanto, a no ser que voc tenha leitores que se sintam vontade com o clculo
predicados, sugiro utilizar linguagem natural.
Opcionalmente, voc pode nomear uma restrio colocando o primeiro nome, segui:
de dois-pontos; por exemplo, {proibir incesto: marido e esposa no devem ser irmos}.

Projeto por Contrato (Design by. Contract)

Projeto por Contrato uma tcnica de projeto desenvolvida por Bertrand Meyer
[Meyer]. A tcnica uma caracterstica central da linguagem Eiffel desenvolvida por
ele. Entretanto, o projeto por contrato no especfico da linguagem Eiffel; uma
tcnica valiosa que pode ser utilizada com qualquer linguagem de programao.
No corao do Projeto por Contrato est a assero. Uma assero uma
declarao booleana que nunca deve ser falsa e, portanto, s ser falsa devido a um
erro. Normalmente, as asseres so verificadas apenas durante a depurao e no
~
so verificadas durante a execuo em produo. De fato, um programa no deve
supor que as asseres esto sendo verificadas.
O Projeto por Contrato usa trs tipos particulares de asseres: ps-condies.i
pr-condies e invariantes. As pr-condies e ps-condies se aplicam s opera-
es. Uma ps-condio uma declarao de como o mundo deve parecer depois da
execuo de uma operao. Por exemplo, se definirmos a operao "raiz quadrada")
de um nmero, a ps-condio assumiria a forma entrada : : : resultado * resultado,
 CAPTULO 3: DIAGRAMAS DE CLASSES: S ELEMENTOS BSICOS 65

as- onde resultado a sada e entrada o valor de entrada. A ps-condio uma forma
til de dizer o que fazemos, sem dizer como o fazemos - em outras palavras, a
~r- maneira de separar a interface da implementao. '

tra Uma pr-condio uma declarao de como esperamos que o mundo seja
de antes de executarmos uma operao. Poderamos definir uma pr-condio para a ope
rao "raiz quadrada" igual a entrada > =O.Tal pr-condio diz que um erro executar
"raiz quadrada" de um nmero negativo e que as conseqncias disso so indefinidas.
- Em um primeiro instante, isso parece ser uma m idia, pois deveramos colo
car alguma verificao em algum lugar, para assegurar que a "raiz quadrada" seja

executada adequadamente. A pergunta importante : quem responsvel por fazer isso?

!S.
A pr-condio torna explcito que o chamador responsvel pela verificao.

o Sem essa declarao de responsabilidades explcita, podemos obter pouca verificao

10
(pois as duas partes presumem que a outra responsvel) ou verificao demais (as
io duas partes verificam). Verificao demais no bom, pois ela leva a muito cdigo
de verificao duplicado, o que pode aumentar significativamente a complexidade
de un-i programa. Ser explcito a respeito de quem responsvel ajuda a reduzir a
:i-
complexidade. O perigo do chamador esquecer de verificar reduzido pelo fato de

1-
que as asseres so normalmente verificadas durante a depurao e durante os testes.
) . A partir dessas definies de pr-condio e ps-condio, podemos ter uma forte
:a definio do termo exceo. Uma exceo ocorre quando uma operao executada com
ta
sua pr-condio satisfeita, apesar de no poder retornar com sua ps-condio satisfeita.
L Uma invariante uma assero a respeito de uma classe. Por exemplo, uma
le classe Conta pode ter uma invariante que diz que saldo = = sum(entradas.valor()). A f
'
'
:a invariante "sempre" verdadeira para todas as instncias da classe. Aqui, "sempre" 'i
: ,f . . .
:,._
..,
significa "quando o objeto estiver disponvel para ter uma operao executada nele". I

_,.
Basicamente, isso significa que a invariante acrescentada s pr-condies e
.e s ps-condies associadas a todas as operaes pblicas de determinada classe. A
invariante pode se tornar falsa durante a execuo de um mtodo, mas deve voltar a
o ser verdadeira no momento em que outro objeto puder fazer algo no receptor.
As asseres podem desempenhar um papel nico na subclassificao. Um dos
perigos da herana que voc pode redefinir as operaes de uma subclasse, tornan
do-a inconsistente com as operaes da superclasse. As asseres reduzem as chances
de se fazer isso. As invariantes e as ps-condies de uma classe devem ser aplicadas
a todas as subclasses. As subclasses podem optar por fortalecer essas asseres, mas
..
no podem enfraquec-las. A pr-condio, por outro lado, no pode ser fortaleci
da, mas.....
pode ser enfraquecida .
A primeira vista, isso parece estranho, mas importante para permitir ligao
dinmica. Voc sempre deve ser capaz de tratar um objeto de subclasse como se ele
fosse uma instncia da superclasse (pelo princpio da capacidade de substituio). Se
uma subclasse fortalecesse sua pr-condio, ento uma operao de superclasse po
deria falhar quando aplicada subclasse.

-----
QUANDO UTILIZAR DIAGRAMAS DE CLASSES
Os diagramas de classes so a espinha dorsal da UML; portanto, voc ir utiliz-los o
tempo todo. Este captulo aborda os conceitos bsicos; o Captulo 5 discutir muitos dos
conceitos avanados.
 I
.,


1
..
~

1
66 UML ESSENCIAL I

O problema com os diagramas de classes que eles so to ricos que podem ser
complexos demais para usar. Aqui esto algumas dicas.
No tente utilizar todas as notaes de que voc dispe. Comece com o material
simples deste captulo: classes, associaes, atributos, generalizao e restries.
Introduza as outras notaes do Captulo 5 somente quando voc necessit-las.
Considero os diagramas de classes conceituais muito teis na explorao da lingua
gem de negcio. Para que isso funcione, voc precisa trabalhar arduamente para
manter o softwarefora da discusso e manter a notao muito simples.
No desenhe modelos para tudo; em vez disso, concentre-se nas reas princi
pais. melhor ter poucos diagramas que voc utiliza e os mantm atualizados
do que ter muitos modelos esquecidos e obsoletos.
O maior perigo com os diagramas de classes que voc pode focalizar exclusiva
mente a estrutura e ignorar o comportamento. Portanto, ao desenhar diagramas de clas
ses para entender software, sempre faa-os em conjunto com alguma forma de tcnica
comportamental. Se voc estiver indo bem, vai ficar trocando entre as tcnicas freqen
temente.

----
ONDE ENCONTRAR MAIS INFORMAOES
.....

.~

...
Todos os livros sobre UML que mencionei no Captulo 1 abordam mais detalhadamente
os diagramas de classes. O gerenciamento de dependncias uma caracterstica funda
mental de projetos maiores. O melhor livro sobre esse assunto [Martin].

-..... -- -. - -


Captulo 4

iagramas de Seqncia

Os diagramas de interao descrevem como grupos de objetos colaboram em al

gum comportamento. A UML define vrias formas de diagrama de interao, das quais
a mais comum o diagrama de seqncia.
Normalmente, um diagrama de sequncia captura o comportamento de um nico
cenrio. O diagrama mostra vrios exemplos de objetos e mensagens que so passadas
entre esses objetos dentro de um caso de uso.
Para comear a discusso, considerarei um cenrio simples. Temos um pedido e
vamos executar um comando sobre ele para calcular seu preo. Para fazer isso, o pedido
precisa examinar todos os itens de linha nele presentes e determinar seus preos, os quais
so baseados nas regras de composio de preos dos produtos da linha do pedido. Ten
do feito isso para todos os itens de linha, o pedido precisa ento calcular um desconto


,f ' .
global, que baseado nas regras vinculadas ao cliente.
A Figura 4.1 um diagrama de seqncia que mostra uma implementao desse
cenrio. Os diagramas de seqncia mostram a interao, exibindo cada participante
com uma linha de vida, que corre verticalmente na pgina, e a ordem das mensagens,
lendo a pgina de. cima para baixo.
Uma das coisas interessantes a respeito de um diagrama de sequncia que quase
no preciso explicar a notao. Voc pode ver que uma instncia do pedido envia
mensagens obterQuantidade e obter Produto para a linha do pedido. Voc tambm pode
ver como mostramos o pedido chamando um mtodo dele mesmo e como esse mtodo
envia obter Inf ormaodeDesconto para uma instncia de cliente.
O diagrama, entretanto, no mostra tudo muito bem. A sequncia de .mensagens
obterQuantidade,obterProduto,obterDetalhesdoPreoecalcularinformaodeDesconto
precisa ser feita para cada linha de pedido no pedido, enquanto calcularDesconto
chamado apenas uma vez. Voc no pode saber isso a partir desse diagrama, embora
apresentemos. mais alguma notao para tratar disso, posteriormente.
A maior parte das vezes, voc pode considerar os participantes de um diagrama de
interao como objetos, conforme eles eram, na realidade, na UML 1. Mas, na UML 2,
seus papis so muito mais complicados e, explicar isso completamente est fora dos
objetivos deste livro. Assim, uso o termo participantes, uma palavra que no utilizada
formalmenre na especificao da UML. Na UML l, os participantes eram objetos e,
assim, seus nomes eram sublinhados; mas, na UML 2, eles devem ser mostrados sem o
sublinhado, conforme fizemos aqui.
Nesses diagramas, dei nome aos participantes utilizando o estilo urnPedido. Isso
funciona bem ria maior parte das vezes. Uma sintaxe mais completa nome : Classe,

. .--
--------- ~~

68 UML ESSENCIAL

um Pedido uma Linha umProduto umCliente

de Pedido

calcularPreo
obterQuantidade
I I
I

participante linha de vida

obterProduto I I
mensagem
recebida I L------------
umProduto I
ativao
I
obterDetalhesdoPreo
I .
. retorno
I I
I I I
I
I
--I I
calcularPreoBase autochamada
1. I I
I I mensagem
I
calcularDescontos I obte ri ntorrnao- I I
...... I I de D~~conto
I
I I
. J,
.. I I I
I I I I
FIGURA 4.1 Um diagrama de seqncia para controle centralizado.

onde o nome e a classe so opcionais, mas voc deve manter os dois-pontos, se usar a { <

classe. (A Figura 4.4, mostrada na pgina 58, usa esse estilo.)

Cada linha de vida tem uma barra de ativao que mostra quando o participante:
est ativo na interao. Isso corresponde aos mtodos de um dos participantes entrando] 1

na pilha. As barras de ativao so opcionais na UML, mas as considero extremamente]

valiosas no esclarecimento do comportamento. A nica exceo ao explorar um projeto]
durante uma sesso de projeto, pois elas so incmodas de desenhar em quadros brancos. "
.. Freqentemente, a atribuio de nomes til para correlacionar participantes no} ~

diagrama. A chamada obter Produto aparece retornando umProduto, o qual tem o mesmo
nome e, portanto, o mesmo participante, que o objeto umProduto para o qual a chama-j 'li

da de obterDetalhesdoPreo enviada. Note que usei uma seta de retorno apenas par;1:~
essa chamada; fiz isso para mostrar a correspondncia. Algumas pessoas utilizam retoo]
nos para todas as chamadas, mas prefiro us-los somente onde eles acrescentam informa-},
es: caso contrrio, eles apenas congestionam o diagrama. Mesmo nesse caso, voe~'.
provavelmente poderia omitir o retorno, sem confundir seu leitor. ~.
A primeira mensagem no tem um participante que a enviou, pois ela provenien
te de uma fonte indeterminada. Ela chamada de mensagem recebida.
Para outra abordagem desse cenrio, d uma olhada na Figura 4.2. O problem: 1~

'
bsico ainda o mesmo, mas a maneira como os participantes colaboram para imple-;
ment-lo muito diferente. O Pedido pede para que cada Linha de Pedido calcule se~t
prprio Preo. A prpria Linha de Pedido transmite o clculo para o Produto; observ9
como mostramos a passagem de um parmetro. Analogamente, para calcular o deseen]
 CAPTULO 4: DIAGRAMAS DE 5EQNCIA 69

um Pedido uma Linha de um Produto umCliente

Pedido

calcularPreo .,. ,.,. :,. parmetro

.~: "
.. '

calcu IarP reo 1. obterPreo(quantidaci~: I I

~nmero)
I
I

I obterVa]orComDesconto(um Pedido) I
I obte rValorBase I
I I ,. retorno

I ::.
.:.:: 1.
.:
I
- - - - - - - - - - - - i- - vl;rCo~-D-e~~onto -1- - - - - - - - - - - - - I
FIGURA 4.2 Um diagrama de seqncia para controle distribudo.

to, o Pedido chama um mtodo do Cliente. Como ele precisa de informaes do Pedido
para fazer isso, o Cliente faz uma chamada reentrante (obterValorBase) no Pedido para
ob ter os dados.
O primeiro detalhe a ser notado a respeito desses dois diagramas a clareza com
,f ' .
que o diagrama de sequncia indica as diferenas" na interao dos participantes. Essa a
grande vantagem dos diagramas de interao. Eles no so bons para mostrar detalhes
dos algoritmos, como laos e comportamento condicional, mas torn.am as chamadas
entre os participantes cristalinas e. fornecem uma viso excepcional a respeito de quais
participantes esto realizando quais processamentos.
O segundo detalhe a ser notado a clara diferena nos estilos entre as duas intera
es. A Figura 4.1 um controle centralizado, com um nico participante realizando
todo o processamento e com os outros participantes l para fornecer dados. A Figura 4.2
utiliza controle 'distribudo, no qual o processamento dividido entre muitos partici
pantes, cada um executando um pequeno trecho do algoritmo.
Os dois estilos tm suas foras e suas. fraquezas. A maioria das pessoas, particular
mente aquelas iniciantes na tecnologia de objetos, est mais acostumada com o controle
centralizado. De muitas formas, ele mais simples, pois todo o processamento feito em
um s lugar; em comparao, no controle distribudo, voc tem a sensao de correr
atrs dos objetos, tentando encontrar o programa.
Apesar disso, os fanticos por objetos como eu do forte preferncia ao controle
distribudo. Um dos principais objetivos de um bom projeto localizar os efeitos de
alteraes. Os dados e o comportamento que acessam esses dados freqentemente mu
dam juntos. Portanto, colocar os dados e o comportamento que os utiliza juntos em um
nico. local a primeira regra do projeto orientado a objetos.
Alm disso, com o controle distribudo, voc gera mais oportunidades para
usar polimorfismo, em vez de utilizar lgica condicional. Se os algoritmos da corn
posio de preos do produto so diferentes para tipos de produto diversos, o meca
nismo de controle distribudo nos permite usar subclasses do produto para tratar
dessas variaes.

...... ---
- .. ---------,...... ..
,.,.,._
.r
~

70 UML ESSENCIAL

Em geral, o estilo orientado a objetos utiliza muitos objetos pequenos com muitos
mtodos pequenos que nos fornecem muitos pontos de ligao para sobreposio e va
riao. Esse estilo muito confuso para as pessoas acostumadas com procedimentos
longos; na verdade, essa mudana o corao da mudana de paradigma da orientao
a objetos. Isso algo muito difcil de ensinar. Parece que a nica maneira de realmente
entender isso trabalhar por algum tempo em um ambiente orientado a objetos, com
controle fortemente distribudo. Muitas. pessoas relatam que, repentinamente, excla
mam "aha!", quando o estilo faz sentido. Nesse ponto, o crebro delas foi religado e elas
comeam a achar que o controle descentralizado mesmo mais fcil.

COMO CRIAR E EXCLUIR PARTICIPANTES

Os diagramas de seqncia exibem alguma notao extra para criar e excluir participan
tes (Figura 4.3). Para criar um participante, voc desenha a seta da mensagem direta
mente para a caixa do participante. Um nome para a mensagem opcional aqui, caso
voc esteja usando um construtor, mas normalmente a identifico com "nova", de qual
quer forma. Se o participante faz algo imediatamente, quando criado, como executar o
comando de consulta, voc inicia uma ativao logo aps a caixa do participante.
A excluso de um participante indicada por um X grande. Uma seta de mensa
'.
gem chegando ao X indica um participante explicitamente excluindo outro; um X no
o;. final de uma linha de vida mostra um participante excluindo a si mesmo.

um Tratador

banco de dados
de consulta

nova I um Comando de
Consulta

nova
III
I uma Instruo de
Banco de Dados
. ,..,
crrcoo
executar

excluso a
------------ partir de
resultados outro objeto

extrair resultados

fechar

- - ~~Citad~; - )1<:
auto-excluso

FIGURA 4.3 Criao e excluso de participantes.

 CAPTULO 4: DIAGRAMAS DE SEQNCIA 71

Em um ambiente de coleta de lixo, voc no exclui objetos diretamente, mas ainda

assim interessante usar o X para indicar quando um objeto no mais necessrio e est

pronto para ser coletado. Isso tambm apropriado para operaes de fechamento, indi
cando que o objeto no pode mais ser utilizado.

...............----------------------------~------------------------------------------~

:-.~

'.;
ft::' .

\ LAOS, CONDICIONAIS, ETC.

'

Um problema comum dos diagramas de seqncia como mostrar laos (loops) e com

portamento condicional. O primeiro detalhe a apontar que os diagramas de seqncia
no servem muito bem para isso. Se voc quiser mostrar estruturas de controle como
essas, melhor utilizar um diagrama de atividades ou, na verdade, o prprio cdigo.
Trate os diagramas de seqncia como uma visualizao de como os objetos interagem,
em vez de trat-los como urna maneira de modelar lgica de controle.
Dito isso, aqui est a notao a ser usada. Os laos e as condicionais usam quadros
de interao, que so maneiras de demarcar uma parte de um diagrama de seqncia. A
'
Figura 4.4 mostra um algoritmo simples baseado no pseudo-cdigo a seguir:

procedure despachar
foreach (iternelinha)
if (produto.valor> $10K)
cuidadoso.despachar
else
regular.despachar
end if
enf for
if (precisaConfirmao) mensageiro.confirmar
end procedure

Em geral, os quadros consistem em alguma regio de um diagrama de seqn

cia que dividida em um ou mais fragmentos. Cada quadro tem um operador e cada
fragmento pode ter uma sentinela. (A Tabela 4.1 lista os operadores comuns para
quadros de interao.) Para mostrar um lao, voc utiliza o operando loop com um
nico fragmento e coloca a base da iterao na sentinela. Para lgica condicional,
voc pode usar um operador alt e colocar uma condio em cada fragmento. So
mente o fragmento cuja sentinela verdadeira ser executado. Se voc tiver apenas
uma regio, existe um operador opt.
Os quadros de interao so novos na UML 2. Como resultado, voc pode ver
diagramas preparados antes da existncia da UML 2 e que usam uma estratgia dife
rente. Alm disso, algumas pessoas no gostam dos quadros e preferem alguma das
convenes mais antigas. A Figura 4.5 mostra algumas dessas otimizaes extra
oficiais.
A UML 1 utilizava marcadores de iterao e sentinelas. Um marcador de iterao
um asterisco (*) adicionado ao nome da mensagem. Voc pode adicionar algum texto
entre colchetes, para indicar a base da iterao. As sentinelas so expresses condicionais
colocadas entre colchetes e indicam que a mensagem enviada somente se a sentinela
verdadeira. Embora essas notaes tenham sido eliminadas dos diagramas de seqncia
na UML 2, elas ainda so vlidas nos diagramas de comunicao.

_____ _,;.. ,,

-
 ff- ..
..
.,.

72 UML ESSENCIAL

:Pedido cuidadoso: regular: :Mensageiro

Distribuidor Distribuidor

despachar
I ;)1
I I
loop [para cada item de linha]
I
I I I
quadro I
opercdor :.. . 1.-. :.I alt [valor > $10.000] I I
despachar
).,F
~
I I I
.... I I
~ - - - - - - - - - ~ . . - - - - - - - -1- - - - - - _._ - 1 - - -
[else]"
I
I I I
despachar I I
I >.
sentinela
I ..._ I
I-
I I

opt [precisaConfirmao] confirmar
J
.,..
' ,

~
I I .._

FIGURA 4.4 Quadros de interao.

Embora os marcadores de iterao e as sentinelas possam ajudar, eles tm suas

fraquezas. As sentinelas no conseguem indicar que um conjunto delas mutuamente
exclusivo, como as duas da Figura 4.5. As duas notaes s funcionam com um envio de

TABELA 4.1 Operadores comuns para quadros de interao

Operador Significado

. alt Mltiplos fragmentos alternativos; somente aquele cuja condio for verdadeira ser
' executado (Figura 4.4).
' opt Opcional; o fragmento executado somente se a condio fornecida for verdadei

ra. Equivalente a um alt, com apenas um caminho (Figura 4.4) .
par Paralelo; cada fragmento executado em paralelo.
loop Lao; o fragmento pode ser executado vrias vezes e a sentinela indica a base da
iterao (Figura 4.4).
.
region Regio crtica; o fragmento pode ter apenas uma linha de execuo ativa por vez.
neg Negativo; o fragmento mostra uma interao invlida.
ref Referncia; refere-se a uma interao definida em outro diagrama. O quadro de

senhado de forma a abordar as linhas de vida envolvidas na interao. Voc pode
definir parmetros e um valor de retorno.
sd Diagrama de seqncia; usado para circundar um diagrama de seqncia lnteiro,
se voc quiser.

= "
-- z
 CAPfTULO 4: IAGRA!\1AS DE 5EQNCIA 73

um Pedido cuidadoso: regular:

Distribuidor :Mensageiro
Distribuidor

despachar I marcador de iterao I I

" '"
. l. : :. . :. pseudo-mensagem
I I

I.

* [para cada item . 'l I I
,..,
nao- de linha] mensagem
normativo [valor > $10.000] I assncrona (UML 1.4
e posteriores)
I I
despachar
1 :. ' . " II
mensagem
assncrona (UML I

identificao 1.3 e anteriores)

do pedido I
(else]
despachar!
~~

n da linha
.I :'
" I
alternativa
~ I
identificao I
sentinela
I girino
de dados
da entrega I
I I I
[precisa Conti rmao] confirmar

I I I
I I I
I I I I
f ' '
FIGURA 4.5 Convenes mais antigas para lgica de controle.

mensagem e no funcionam bem quando vrias mensagens provenientes de uma nica

ativao esto dentro do mesmo lao ou bloco condicional.
Para contornar este ltimo problema, uma conveno extra-oficial que se tornou
popular usar uma pseudo-mensagem, com a condio de lao ou a sentinela em uma
variao da notao de autochamada. Na Figura 4.5, mostrei isso sem uma seta de men
sagem; algumas pessoas incluem uma seta de mensagem, mas omiti-la ajuda a reforar
que essa no uma chamada real. Alguns tambm gostam de sombrear a barra de ativa
o da pseudo-mensagem. Se voc tem comportamento alterador, pode mostr-lo com
um marcador alternativo entre as ativaes.
Embora eu considere as ativaes muito teis, elas no acrescentam muito no caso
do mtodo despachar, por intermdio do qual voc envia uma mensagem e nada mais
acontece dentro da ativao do receptor. Uma conveno comum, que mostrei na Figura
4.5) suprimir a ativao para essas chamadas simples.
O padro UML no tem nenhum dispositivo grfico para mostrar a passagem de
dados; em vez disso, ela mostrada por meio de parmetros no nome da mensagem e de
setas de retorno. Em muitos mtodos, existem girinos de dados para indicar o movi
mento dos dados, e muitas pessoas ainda gostam de utiliz-los com a UML.
No todo, embora vrios esquemas possam acrescentar notao para lgica condi
cional a diagramas de seqncia, no acho que eles funcionem melhor do que o cdigo
ou, pelo menos, do que o pseudo-cdigo. Em particular, considero os quadros de intera
o muito pesados, ocultando o objetivo principal do diagrama; portanto, prefiro as
pseudo-mensagens.
 74 UML ESSENCIAL

CHAMADAS SNCRONAS E ASSNCRONAS

Se voc estiver excepcionalmente alerta, ter notado que as pontas das setas dos ltimos
dois diagramas so diferentes das dos anteriores. Essa pequena diferena muito impor
tante na UML 2. Na UML 2, as pontas de seta preenchidas mostram uma mensagem
sncrona, enquanto as pontas de seta tipo "p de galinha'' mostram uma mensagem as-
,
sincrona.
Se um chamador enviar uma mensagem sncrona, ele deve esperar at que ela
seja concluda, tal como a chamada a uma sub-rotina. Se um chamador envia uma
mensagem assncrona, ele pode continuar o processamento e no precisa esperar
por uma resposta. Voc v chamadas assncronas em aplicativos de mltiplas linhas
de execuo e em middleware* orientado por mensagens. A falta de sincronizao
fornece melhor correspondncia e reduz o acoplamento temporal, mas mais difcil
de depurar.
A diferena na ponta da seta muito sutil; na verdade, sutil demais. Ela tambm
foi uma mudana na UML 1.4, incompatvel com as verses anteriores, nas quais urna
mensagem assncrona era mostrada com a seta tipo "meio p de galinha", como na Figu
ra 4.5.
Acho que essa distino na ponta da seta sutil demais. Se voc quiser destacar
mensagens assncronas, recomendo utilizar a ponta de seta tipo "meio p de galinha"
. . .+
o;.
obsoleta, que chama muito mais ateno para uma distino importante. Se voc estiver
lendo um diagrama de sequncia, cuidado ao fazer suposies a respeito do sincronismo
a partir das pontas de seta, a no ser que tenha certeza de que o autor est fazendo a
distino intencionalmente.

QUANDO UTILIZAR DIAGRAMAS DE SEQNCIA

Voc deve utilizar diagramas de seqncia quando quiser observar o comportamento de '.9
vrios objetos dentro de um nico caso de uso. Os diagramas de seqncia so bons para .J
mostrar as colaboraes entre os objetos, mas no so to bons para uma definio pre- _;j
cisa do com portamento. :,
w
Se voc quiser observar o comportamento de um nico objeto em muitos casos de :
.
uso, utilize um diagrama de estados (veja o Captulo 1 O). Se quiser observar o compor- ;
tamento em muitos casos de uso ou em muitas linhas de execuo, considere um diagra- j
ma de atividades (veja Captulo 11). ."
Se voc quiser explorar mltiplas interaes alternativas rapidamente, talvez seja ~

melhor usar cartes CRC, pois isso evita desenhar e apagar muitas vezes. Freqenrernen- 1
te til ter uma sesso de carto CRC para explorar alternativas de projeto e depois ;
utilizar diagramas de seqncia para capturar todas as interaes a que voc queira fazer \
referncia posteriormente.
Outras formas teis de diagramas de interao so os diagramas de comunicao, j
para mostrar conexes, e os diagramas de temporizao, para mostrar restries de tem- :

. ,.,
por1zaao.

* N. de R.T.: Middleware a camada de software entre os aplicativos e a rede.

 ~~~~~~----------------------------------------------------~

CAPTULO 4: DIAGRAMAS DE SEQNCIA 75

Cartes CRC

Uma das tcnicas mais valiosas para propor um bom projeto orientado a objetos
explorar as interaes dos objetos, pois isso enfoca o comportamento, em vez dos
dados. Os diagramas CRC (Class-Responsibility-Collaboration - Classe-Responsa

bilidade-Colaborao), inventados por Ward Cunningham no final dos anos 80,
tm resistido ao teste do tempo como uma maneira altamente eficiente para se fazer
isso (Figura 4.6). Embora no faam parte da UML, eles representam uma tcnica

muito popular entre os projetistas de objeto experientes.

Para usar cartes CRC, voc e seus colegas devem se reunir em torno de uma

mesa. Peguem diversos cenrios e representem-nos com os cartes, escolhendo-os

aleatoriamente, quando eles estiverem ativos, movendo-os para sugerir o modo como
eles enviam mensagens uns para os outros, e fazendo-os circular. Essa tcnica quase
impossvel de descrever em um livro, apesar de ser facilmente demonstrada; a me
lhor maneira de aprend-la pedir para algum que j a tenha utilizado para mostrar
a voce."

nome da classe
co laborao
responsabi I i dad e

I ' Pedido

Verificar se os itens esto em estoque

..

Linha de Pedido
...

Determinar o preo Cliente

Verificar se o pagamento vlido

Despachar para o endereo de entrega

'

FIGURA 4.6 Um exemplo de carto CRC.

Uma parte importante do modo de pensar com relao aos cartes CRC a
identificao de responsabilidades. Uma responsabilidade uma frase curta que
rsume algo que um objeto deve fazer: uma ao que o objeto executa, algum conhe
cimento que o objeto conserva ou algumas decises importantes que o objeto toma.
A idia que voc deve ser capaz de pegar qualquer classe e resumi-la com algumas
responsabilidades. Fazer isso pode ajud-lo a pensar mais claramente a respeito do
projeto de suas classes.
O segundo C refere-se aos colaboradores: as outras classes com as quais essa
classe precisa trabalhar. Isso d uma idia dos vnculos entre as classes - ainda em um
nvel alto.
Um dos maiores benefcios dos cartes CRC que eles estimulam animadas
discusses entre os desenvolvedores. Quando voc estiver trabalhando com um caso
de uso para ver como as classes o implementaro, os diagramas de interao deste
captulo podero ser demorados de desenhar. Normalmente, voc precisa considerar
alternativas e com os diagramas, perde-se muito tempo desenhando-as e apagando-as.
 ~~-
.>

76 UMI-' ESSENCIAL

Com os cartes CRC, voc modela a interao escolhendo-os e movendo-os. Isso

permite que se considere rapidamente diversas alternativas.
medida que faz isso, voc forma idias sobre as responsabilidades e as escreve
~

nos cartes. E importante pensar sobre as responsabilidades, porque isso desvia voc
da noo de classes como simples portadores de dados e facilita aos membros da equipe
compreenderem o comportamento de cada classe em um nvel mais elevado. Uma
responsabilidade pode corresponder a uma operao, a um atributo ou (mais prova
velmente) a um aglomerado indeterminado de atributos e operaes.
Um erro comum que vejo as pessoas cometerem gerar longas listas de respon
sabilidades de baixo nvel. Fazendo isso perde-se o rumo. As responsabilidades de
vem caber facilmente em um carto. Voc deve questionar se a classe deve ser dividi
da ou se as responsabilidades seriam mais bem formuladas se englobadas em declara
es de nvel mais alto.
Muitas pessoas salientam a importncia de desempenhar papis; cada pessoa
de uma equipe desempenha o papel de uma ou mais classes. Nunca vi Ward Cun
ningham fazer isso, e acho que desempenhar papis atrapalha.
J foram escritos livros sobre CRC, mas verifiquei que eles nunca chegam real
mente ao centro da tcnica. O trabalho original sobre CRC, escrito com Kent Beck,
[Beck e Cunnigham]. Para aprender mais sobre cartes CRC e sobre responsabili
dades no projeto, d uma olhada em [Wirfs-Brock] .


Isso
Captulo 5
'
.eve
I\
'oce

Llpe
'ma iagramas de Classes:
rva-
Conceitos Avanados
on

de

.di-
.ra-

iO a Os conceitos descritos no Captulo 3 correspondem s notaes-chave nos diagra

1n- mas de classes. Esses conceitos so os primeiros com os quais voc deve familiarizar-se e
compreender, porque eles abrangero 90o/o do seu trabalho na construo de diagramas
al de classes.
ck, A tcnica do diagrama de classes, entretanto, promoveu a criao de dezenas de
ili- notaes de conceitos adicionais. Na realidade, no as utilizo o tempo todo, mas elas so
teis, quando apropriadas. Eu as discutirei uma de cada vez e salientarei alguns dos
aspectos de suas utilizaes.
Voc provavelmente considerar este captulo um pouco pesado. A boa nova que,
durante sua primeira passada por este livro, voc pode seguramente pular este captulo e
retom-lo mais tarde .

...............-----------------------------~-------------------------------------------
PALAVRAS-CHAVE

Um dos desafios de uma linguagem grfica que voc precisa lembrar do significado dos
smbolos. Existindo muitos deles, os usurios acham muito difcil lembrar o que todos
os smbolos significam. Assim, a UML freqentemente tenta reduzir o nmero de sm
bolos e, em seu lugar, utilizar palavras-chave. Se voc verificar que precisa de uma cons
truo de modelagem que no est na UML, mas que semelhante a algo que est,
utilize o smbolo da construo UML existente, mas marque-o com uma palavra-chave ..
para mostrar que algo diferente.
Um exemplo disso a interface. Uma interface da UML (pgina 69) uma classe
que possui apenas operaes pblicas, sem nenhum corpo de mtodo. Isso corresponde
s interfaces da linguagem Java, COM (Component Object Module) e CORBA. Como
se trata de um tipo especial de classe, ela mostrada usando-se o cone de classe com a
palavra-chave i nt erf ace.
Normalmente, as palavras-chave so mostradas como texto entre os caracteres e.
Como uma alternativa a palavras-chave, voc pode usar cones especiais, rnas ento ter
o problema de todo mundo ter que lembrar o que eles significam.
Algumas palavras-chave aparecem entre chaves, tais como {abstract}. Nunca fica
realmente claro o que deve, tecnicamente, estar entre os caracteres e e o que deve estar
entre chaves. Felizmente, se voc errar, apenas os perfeccionistas da UML notaro - ou
-
se preocuparao.
Algumas palavras-chave so to comuns que freqentemente so abreviadas: in
terface muitas vezes abreviada como I e {abstract}, como {A}. Tais abreviaes so

-------
--~ ... ,-
 /

78 UML ESSENCIAL

muito teis, particularmente em quadros brancos, mas no so padro; portanto, se voc

utiliz-las, certifique-se de encontrar um lugar para esclarecer o que elas significam.
Na UML l, os caracteres e eram usados principalmente para esteretipos. Na
UML 2, os esteretipos so definidos muito rigidamente e descrever o que e o que no
um esteretipo est fora dos objetivos deste livro. No entanto, por causa da UML l,
muitas pessoas usam o termo esteretipo com o mesmo significado de palavra-chave,
embora isso no seja mais correto.
Os esteretipos so usados como parte dos perfis. Um perfil (profile) pega uma parte da
UML e a estende com um grupo coerente de esteretipos para um propsito especfico,
como a modelagem de negcio. A semntica completa dos perfis est fora dos objetivos
deste livro. A no ser que voc,,.
esteja em um projeto srio de metamodelo, improvvel
que precise criar um perfil. E mais provvel que voc utilize um j criado para um prop-
sito de modelagem especfico, mas felizmente o uso de um perfil no exige o conheci
mento de todos os detalhes sobre como eles so vinculados ao metamodelo.

RESPONSABILIDADES

Freqentemente, til mostrar as responsabilidades (pgina 75) de uma classe em um

diagrama de classes. A melhor maneira de mostr-las como frases de comentrio
em seu prprio compartimento na classe (Figura 5 .1). Se quiser, voc pode dar um
,";,
nome ao compartimento, mas eu normalmente no fao isso, pois raramente existi
...
r alguma confuso.

---- -
OPERAOES E ATRIBUTOS ESTA TICOS
,

A UML se refere a uma operao ou a um atributo que se aplica a uma classe, em vez de
a uma instncia, como esttica. Isso equivale aos membros estticos em linguagens ba
seadas em C. As propriedades estticas so sublinhadas em um diagrama de classes (veja
Figura 5.2).

Visa o
Modelo
Responsabilidades 1 3
-- mostra informaes -- lgica do domnio
sobre o modelo

Controlador de Entrada

-- trata dos eventos de entrada

FIGURA 5.1 Mostrando responsabilidades em um diagrama de classes.

-
 CAPTULO 5: DIAGRAMAS DE CLASSES: CONCEITOS AVANADOS 79

Pedido

, : obterNmero
escopo de obterPrximoNovoNmero '. :: " ..., .
instncia : ' =:" ::: ::: , "
.........
.
,.
tt' :; .: .r; , '
estatico

FIGURA 5.2 Notao de propriedade esttica.

...:~
,,
'
----......----------------------------------
? AGREGAO E COMPOSIO
.,,
.. ,'

.:::
!, '
.,,
Uma das fontes de confuso mais freqentes na UML a agregao e a composio. E
fcil explic-las superficialmente: agregao o relacionamento "parte de". como dizer
que um carro tem um motor e rodas como suas partes. Isso soa bem, mas o difcil
considerar qual a diferena entre agregao e associao.
Antes do surgimento da UML, as pessoas eram, geralmente, muito vagas a respeito
do que era agregao e do que era associao. Vagas ou no, elas sempre eram inconsis
tentes com as idias dos outros. Como resultado, muitos projetistas consideram a agre
gao importante, embora por razes diferentes. Ento, a UML incluiu a agregao
(Figura 5.3), mas com quase nenhuma semntica. Como Jim Rumbaugh diz: "Pense
nisto como um placebo de modelagem" [Rumbaugh, UML Reference J.
Assim como para a agregao, a UML tem a propriedade mais definida da compo
sio. Na Figura 5.4, uma instncia de Ponto pode fazer parte de um polgono ou pode
ser o centro de um crculo, mas no pode ser ambos. A regra geral que, embora uma classe
possa ser um componente de muitas outras classes, toda instncia deve ser um componente
de apenas um proprietrio. O diagrama de classes pode mostrar vrias classes de proprietrios
em potencial, mas toda instncia tem apenas um nico objeto como seu proprietrio.
Voc notar que no mostro as multiplicidades inversas na Figura 5.4. Na maioria
dos casos> como aqui, 0 .. 1. Seu nico outro valor possvel 1, para casos em que a
classe de componentes projetada de modo a poder ter apenas uma outra classe como
. ' .
sua propr1etar1a.
A regra do "no compartilhamento" a chave da composio. Outra suposio a
de que, se voc excluir o polgono, isso deve garantir automaticamente que todos os
Pontos a ele pertencentes tambm sejam excludos.

membros
Clube o ~
Pessoa
* *
FIGURA 5.3 Agregao.

{ordered} centro
Polgono Ponto Crculo
3.. * 1

FIGURA 5.4 Composio.

 80 UML ESSENCIAL

A composio urna boa maneira de mostrar propriedades que tm valor, propr

dades para objetos de valor (pgina 84) ou propriedades que tm uma participao com
membro forte e um tanto exclusiva de outros componentes especficos. A agregao
estritamente sem significado; como resultado, recomendo que voc a ignore em s
diagramas. Se voc a encontrar nos diagramas de outras pessoas, precisar ir mais a f
do para descobrir o que elas querem dizer como isso. Diferentes autores e equipe
utilizam para propsitos muito distintos.

---------------------------------
PROPRIEDADES DERIVADAS
As propriedades derivadas podem ser calculadas com base em outros valores. Qua
pensamos a respeito de um intervalo de datas (Figura 5.5), podemos considerar
propriedades: a data de incio, a data de trmino e o nmero de dias no perodo. E
valores so vinculados; portanto, podemos pensar na durao como sendo derivada
outros dois valores.
Na perspectiva do software, a derivao pode ser interpretada de duas man
diferentes. Voc pode usar derivao para indicar a diferena entre um valor calcula
um valor armazenado. Nesse caso, interpretaramos a Figura 5.5 como indica
que o incio e o trmino so armazenados, mas qtie a durao calculada. Em
esse seja um uso comum, no gosto muito dele, pois ele revela muito dos det
internos de IntervalodeDatas .
Meu modo de pensar preferido que ela indica uma restrio entre valores. N
caso, estamos dizendo que a restrio entre os trs valores vlida; no entanto,
importante qual deles calculado. Nesse caso, a escolha do atributo a ser marcado
derivado arbitrria e rigorosamente desnecessria, mas til para ajudar a lembr
pessoas sobre a restrio. Essa utilizao tambm faz sentido nos diagramas concei
A derivao tambm pode ser aplicada em propriedades, usando-se nota
associao. Nesse caso, voc simplesmente marca o nome com uma barra normal(

__.,__----------------------------
INTERFACES E CLASSES ABSTRATAS
Uma classe abstrata uma classe que no pode ser instanciada diretamente. E
disso, voc instancia uma instncia de uma subclasse. Normalmente, uma classe a
tem uma ou mais operaes abstratas. Uma operao abstrata no tem nenhum

plementao; ela uma declarao pura para que os clientes possam se ligar classe ab
A maneira mais comum de indicar uma classe ou operao abstrata na U
colocar o nome em itlico. Voc tambm pode tornar propriedades abstratas indicand

Intervalo de Datas ........

{durao = incio trmino}
atributo incio: Date ~

derivado trmino: Date

/durao: Integer '

FIGURA 5.5 Atributo derivado em um perodo de tempo.

 CAPTULO 5: DIAGRAMAS DE CLASSES: CONCEITOS AVANADOS 81

propriedade abstrata ou mtodos de acesso. As palavras em itlico so chatas de escrever
em um quadro branco; portanto, voc pode usar o rtulo: {abstract}.
Uma interface uma classe que no tem nenhuma implementao; isto , todas as

suas propriedades so abstratas. As interfaces correspondem diretamente s interfaces

das linguagens C# e Java e so um dialeto comum em outras linguagens ripadas. Voc
identifica uma interface com a palavra-chave interface.

As classes tm dois tipos de relacionamentos com as interfaces: fornecimento e

exigncia. Uma classe fornece uma interface se ela substituvel pela interface. Em Java
e em .NET, uma classe pode fazer isso implementando a interface ou implementando
um subtipo da interface. Em C++, voc cria uma subclasse da classe que a interface.
Uma classe exige uma interface se precisa de uma instncia dessa interface para

funcionar. Basicamente, isso significa ter uma dependncia da interface.

A Figura 5.6 mostra esses relacionamentos em ao, baseados em algumas classes de
coleo da linguagem Java. Eu poderia escrever uma classe Pedido que tivesse uma lista de
itens de linha. Como estou usando uma lista, a classe Pedido dependente da interface List.
Vamos supor que ela use os mtodos equals, add e get. Quando os objetos se conectarem, a
classe Pedido usar na verdade uma instncia de ArrayList, mas no precisar saber disso
para utilizar esses trs mtodos, pois todos eles fazem parte da interface List.
O prprio ArrayList uma subclasse da classe AbstractList. AbstractList forne
ce parte da implementao (mas no toda) do comportamento de Lista. Em particular, o

interface
Collection
interface +
equals
add

/\
classe abstrata

interface Abstract List

Pedido
--,
List
"" ------ -
i---------- -- --
~
equal
Itens deLlnha [*] get
get
add

Dependncia
/,
implementao
(exige a interface) (fornece a mtodo
abstrato
interface)

Array list

get
add

sobreposio
FIGURA 5.6 Um exemplo de interfaces e de uma classe abstrata na linguagem Java.

,-...

 ........
""'
82 UML ESSENCIAL

mtodo get abstrato. Como resultado, ArrayList implementa o mtodo get, mas
tambm sobrepe algumas das outras operaes em AbstractList. Neste caso, ele tambm
sobrepe o mtodo add, mas fica feliz em herdar a implementao do mtodo equals.
Por qu no evitar isso simplesmente e fazer Pedido usar ArrayList diretamente?
Utilizando a interface, tenho a vantagem de tornar mais fcil alterar implementaes
posteriormente, se for necessrio. Outra implementao pode fornecer melhorias de de-
sempenho, alguns recursos de interao de banco de dados ou outros benefcios. Progra
mando com interfaces, em vez da implementao direta, no tenho que alterar todo o
cdigo, caso precise de uma implementao diferente de List. Voc sempre deve tentar
programar com uma interface como essa; use sempre o tipo mais geral que puder.
Tambm devo chamar a ateno para uma situao pragmtica nisso. Quando os
programadores utilizam uma coleo como essa, eles normalmente iniciam a coleo
com uma declarao, como a seguinte:
private List itensdeLinha = new ArrayList()
Note que, rigorosamente, isso introduz uma dependncia de Pedido para o ArrayList
concreto. Teoricamente, isso um problema, mas na prtica as pessoas no se preocu
pam com ele. Como o tipo de i tensdeLinha declarado como List, nenhuma outra
parte da classe Pedido dependente de ArrayList. Se alterarmos a implementao, have
r apenas
,
essa nica linha de cdigo de inicializao com a qual precisamos nos preocu-
par. E bastante comum fazer referncia a uma classe concreta uma vez, durante a criao,
mas posteriormente, utilizar apenas a interface.
A notao completa da Figura 5.6 uma maneira de indicar interfaces. A Figura
5.7 mostra uma notao mais compacta. O fato de que ArrayList implementa List e
Collection mostrado fora dele por meio de cones de crculos, freqenternenre referi
dos como pirulitos. O fato de que Pedido exige uma interface List mostrado pelo
cone de soquete. A conexo bastante evidente.
A UML tem usado a notao de pirulito h algum tempo, mas a notao de saque
te nova na UML 2. (Acho que essa minha adio de notao avorira.) Voc provavel
mente ver diagramas mais antigos usando o estilo da Figura 5.8, onde uma dependn
cia resiste notao de soquete.

List
Pedido
ArrayList

Itens de Linha [*]

Collection '-'
FIGURA 5.7 Notao de bola e de soquete .

Pedido Lista
ArrayList
Itens de Linha [*]

Coleo '--"
FIGURA 5.8 Dependncias mais antigas com pirulitos .

-
. ---- -~
 CAPTULO 5: DIAGRAMAS DE CLASSES: CONCEITOS AVANADOS 83

Toda classe uma mistura de interface e implementao. Portanto, freqentemen

te podemos ver um objeto utilizado atravs da interface de uma de suas superclasses.

Rigorosamente falando, no seria vlido usar a notao de pirulito para uma superclasse,
pois a superclasse uma classe e no uma interface pura. Mas, em nome da clareza, eu
violo essas regras.
Assim como acontece nos diagramas de classes, as pessoas tm considerado os piru '

lires teis em outros contextos. Um dos problemas perenes dos diagramas de interao
que eles no fornecem uma visualizao muito boa de comportamento polimrfico.
Embora no seja de utilizao obrigatria, voc pode indicar isso de acordo com a Figura 5.9.

Aqui, podemos ver que, embora tenhamos uma instncia de Vendedor, que usada

como tal pela Calculadora de Bnus, o objeto Perodo de Pagamento utiliza o Vendedor
somente por intermdio de sua interface Funcionrio. (Voc pode fazer o mesmo truque
com diagramas de comunicao.)

READ-ONLY E FROZEN

Na pgina 54, descrevi a palavra-chave {readnl y}. Voc usa essa palavra-chave para
identificar uma propriedade que s pode ser ]ida pelos clientes e que no pode ser atua
lizada. Semelhante, embora diferente, a palavra-chave {frozen} da UML 1. Uma pro
priedade frozen (congelada) se no pode ser mudada durante o tempo de vida de um
objeto; tais propriedades so freqentemente chamadas de imutveis. Embora tenha
sido retirado da UML 2, {frozen} um conceito muito til; portanto, eu continuaria a
f

, '
Bruce: Vendedor maro: Perodo
um cenar10
de Pagamento

avaliar

uma Calculadora
I I
de Bnus
I I
estabelecer valor
do bnus
I I
mensagem atraves
, I
I da interface
I
adicionarNalistadePagamento (Bruce) I
I .
i--~~~~~~~~I~ calcularFolhadePagamento
calcular
Pagamento

- funcionrio
nao-
' normativo'
.: ,.i=: -~
I
I
. . e ,.. '

I
I I
FIGURA 5.9 Usando um pirulito para mostrar polimorfismo em um diagrama de seqncia.

, .. -
'

'

....
84 UML ESSENCIAL

utiliz-lo. Assim como voc pode marcar propriedades individuais como .frozen, tambm
pode aplicar a palavra-chave a uma classe para indicar que todas as propriedades de todas
as instncias esto congeladas. (Ouvi dizer que o conceito de congelamento poder ser
reintegrado em breve.)

OBJETOS DE REFERENCIA E OBJETOS DE VALOR

Uma das coisas comumente ditas a respeito dos objetos que eles tm identidade. Isso
verdade, mas no to simples assim. Na prtica, voc verifica que a identidade impor
tante para objetos de referncia, mas nem tanto para objetos de valor.
Os objetos de referncia so coisas como um Cliente. Aqui, a identidade muito
importante, pois voc normalmente s quer um objeto de software para designar um
cliente no mundo real. Qualquer objeto que faa referncia a um objeto Cliente far isso
por intermdio de uma referncia ou ponteiro. Todos os objetos que fazem referncia a
esse Cliente faro referncia ao mesmo objeto de software. Desse modo, as alteraes em
um Cliente estaro disponveis para todos os usurios do Cliente.
Se voc tem duas referncias para um Cliente e quer ver se elas so as mesmas,
normalmente voc compara suas identidades. As cpias podem ser proibidas; se elas
forem permitidas, tendero a ser feitas raramente, talvez para propsitos de arquivamen
to ou para duplicao atravs de uma rede. Se forem feitas cpias, voc precisar escolher
como vai sincronizar as alteraes.
Os objetos de valor so coisas como Date. Freqentemente, voc tem vrios obje
tos de valor representando o mesmo objeto no mundo real. Por exemplo, normal ter
centenas de objetos que designam l-Jan-04. Todos eles so cpias intercambiveis. No
vas datas so criadas e destrudas freqentemente.
Se voc tem duas datas e quer ver se elas so as mesmas, no examine as suas
identidades, mas sim os valores que representam. Isso normalmente significa que voc
precisa escrever um operador de teste de igualdade, o qual, para datas, faria um teste do
ano, do ms e do dia - ou qualquer que seja a representao interna. Cada objeto que faz
referncia a l-Jan-04 normalmente possui seu prprio objeto dedicado, mas voc tam
bm pode compartilhar datas.
Os objetos de valor devem ser imutveis; em outras palavras, voc no deve poder
pegar um objeto de data 1-Jan-04 e mudar o mesmo objeto de data para 2-Jan-04. Em
vez disso, voc deve criar um novo objeto 2-Jan-04 e us-lo. O motivo que, se a data
fosse compartilhada, voc atualizaria a data de um outro objeto de uma maneira impre
visvel, um problema conhecido como bug de nome alternativo (aliasing).
Antigamente, a diferena entre objetos de referncia e objetos de valor era mais clara.
Os objetos de valor eram os valores internos do sistema de tipos. Agora, voc pode estender o
sistema de tipos com suas prprias classes; portanto, esse problema exige mais reflexo.
A UML utiliza a noo de tipo de dados, que mostrada como uma palavra
chave no smbolo de classe. Rigorosamente falando, o tipo de dados no o mesmo
que objeto de valor, pois os tipos de dados no podem ter identidade. Os objetos de
valor podem ter uma identidade, mas no a utilizam para comparaes de igualda
de. Em Java, as primitivas seriam tipos de dados, mas as datas no seriam, embora
elas sejam objetos de valor.
Se importante destac-las, eu uso composio ao associar com um objeto de
valor. Voc tambm pode utilizar uma palavra-chave em um tipo de valor; as convencia-
. . -
nais comuns que veJo sao value e struct.
 CAPTULO 5: DIAGRAMAS DE CLASSES: CONCEITOS AVANADOS 85

............... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

ASSOCIAES QUALIFICADAS

Associao qualificada o equivalente da UML para um conceito de programao co

nhecido como arrays associativos, mapeamentos, hashing e dicionrios. A Figura 5.10
mostra uma maneira de usar um qualificador para representar a associao entre as clas

ses Pedido e Linha de Pedido. O qualificador diz que, em conexo com um Pedido, pode
haver uma Linha de Pedido para cada instncia de Produto.
Da perspectiva do software, essa associao qualificada implicaria em uma interface
de acordo com a seguinte:

class Pedido ...
public LinhadePedido obteritemdeLinha(Produto umProduto);
public void adicionaritemdeLinha(Nmero quantidade, Produto paraProduto);
Assim, todo acesso a determinada Linha de Pedido exige um Produto como argu
mento, sugerindo uma implementao que use uma chave e uma estrutura de dados de
valor. ,
E comum as pessoas ficarem confusas quanto s multiplicidades de uma associao
qualificada. Na Figura 5.1 O, um Pedido pode ter muitos Itens de Linha, mas a multipli
cidade da associao qualificada a multiplicidade no contexto do qualificador. Assim, o
diagrama diz que um Pedido tem 0 .. 1 Itens de Linha por Produto. Uma multiplicidade
igual a 1 indicaria que Pedido deveria ter um Item de Linha por instncia de Produto.
Um " indicaria que voc teria vrios Itens de Linha por Produto mas o acesso aos Itens de
Linha seria indexado por Produto.
Na modelagem conceituai, eu uso a construo de qualificador somente para mos
trar restries de acordo com "uma Linha de Pedido por Produto no Pedido".

-
CLASSIFICAAO
-
E GENERALIZAAO

Ouo, com freqncia, pessoas falarem sobre subtipagem como o relacionamento um.
Peo que voc tome cuidado com essa maneira de pensar. O problema que a expresso
um pode significar coisas diferentes.
Considere as frases a seguir.
1. Shep um Border Collie.
2. Um Border Collie um Cachorro.
3. Cachorros so Animais.
4. Border Collie uma Raa.
5. Cachorro uma Espcie.

Linha de Pedido
0.. 1
Produto quantidade:Nmero
Pedido -
item de linha

FIGURA 5.1 O Associao qualificada.

 86 . UML ESSENCIAL

Agora, tente combinar as frases. Se eu combino as frases 1 e 2, tenho "Shep

Cachorro"; as frases 2 e 3 juntas do "Border Collies so Animais". A frase l mais
mais a 3 resulta em "Shep um Animal". At aqui, tudo bem. Agora, tente as frase
4: "Shep uma Raa". A combinao das frases 2 e 5 "Um Border Collie uma E
cie". Estas no esto corretas.
Por que posso combinar algumas destas frases e outras no? A razo que algu
so classificaes - o objeto Shep uma instncia do tipo Border Collie+. e alguma
generalizaes - o tipo Border Collie um subtipo do tipo Cachorro. A generaliza
transitiva; a classificao, no. Posso combinar a classificao seguida de uma gei1era
~ ~ ' .
ao, mas nao o contrario.
Fao questo de mostrar isso para que voc desconfie do um. Utiliz-lo pode
a um uso inadequado da subclassif1cao e confuso de responsabilidades. Teste
lhores de subtipagem nesse caso seriam as frases "Cachorros so tipos de Anim
"Toda instncia de um Border Collie uma instncia de Cachorro".
A UML utiliza o smbolo de generalizao para mostrar generalizao. Se voc
mostrar uma classificao, use uma dependncia com a palavra-chave instantiate.

-
CLASSIFICAAO
'
MULTIPLA E DINAMICA
~

Classificao refere-se ao relacionamento entre um objeto e o seu tipo. As prin

linguagens de programao presumem que um objeto pertena a uma nica class
existem mais opes de classificao, alm dessa.
Na classificao nica, um objeto pertence a um nico tipo, que pode he
supertipos. Na classificao mltipla, um objeto pode ser descrito por vrios tip
no esto necessariamente conectados por herana.
A classificao mltipla diferente da herana mltipla. A herana mlt
que um tipo pode ter muitos supertipos, mas que um tipo nico deve ser defini
cada objeto. A classificao mltipla permite tipos mltiplos para um objeto, sem
um tipo especfico para esse propsito.
Por exemplo, considere uma pessoa subtipada como homem ou como
mdico ou enfermeira, paciente ou no (veja Figura 5.11). A classificao mlt
mite que um objeto tenha quaisquer destes tipos atribudos a ele, em qualquer c
o possvel, sem a necessidade de os tipos serem definidos para todas as comb

vlidas .
Se voc utiliza classificao mltipla, tem que ter certeza de que deixa cla

combinaes so vlidas. A UML 2 faz isso colocando cada relacionamento de

zao em um conjunto de generalizao. No diagrama de classes, voc rotula a
seta de generalizao com o nome do conjunto de generalizao, o qual, na UM
chamado de discriminador. A classificao simples corresponde a um nico con
generalizao, sem denominao.
Quando no houver especificao, os conjuntos de generalizao so s
qualquer instncia do supertipo pode ser uma instncia de apenas um dos subt
tro desse conjunto. Se voc envolver as generalizaes em uma nica seta,

devero fazer parte do mesmo conjunto de generalizao, como mostrado
5.11. Como alternativa, voc pode ter vrias setas com o mesmo rtulo de tex

Para ilustrar, observe as seguintes combinaes vlidas de subtipos no
(Feminino, Paciente, Enfermeira); (Masculino, Fisioterapeuta); (Feminino, P
 CAPTUI.O 5: DIAGRAMAS DE CLASSES: CONCEITOS AVANADOS 87

Cirurgio
discriminador

.. ,
Doutor I<
..
,.~,-,
.
Clnico
Mulher Geral
papel

sexo
[>I Pessoa < Enfermeira

Homem
7\.
paciente
Fisiotera-
peut a

paciente

FIGURA 5.11 Classificao mltipla.

(Feminino, Mdico, Cirurgio). A combinao (Paciente, Mdico, Enfermeira) invli

da, pois ela contm dois tipos do conjunto de generalizao de papel.
Outra questo se um objeto pode mudar a sua classe. Por exemplo, quando uma
conta bancria est sem fundos, ela muda substancialmente o seu comportamento. Es
pecificamente, vrias operaes, incluindo "retirar" e "fechar", so sobrescritas.
A classificao dinmica permite que os objetos mudem de classe dentro da estru
tura de subtipagem; a classificao esttica no admite isso. Na classificao esttica,
feita uma separao entre tipos e estados; a classificao dinmica combina essas noes.
Deve-se utilizar classificao mltipla e dinmica? Considero-a til para modela
gem conceitua!. Da perspectiva do soittuare, entretanto, a distncia entre ela e as imple
mentaes enorme. Na grande maioria dos diagramas em UML, voc ver apenas a
classificao esttica simples; portanto, esse deve ser seu padro.

-
CLASSE DE ASSOCIAAO

As classes de associao permitem que voc acrescente atributos, operaes e outras

caractersticas a associaes, como mostrado na Figura 5.12. Podemos ver pelo diagrama
que uma pessoa pode participar de muitas reunies. Precisamos manter informaes
sobre o quanto essa pessoa estaria desperta; podemos fazer isso adicionando o atributo
atenciosidade associao.
A Figura 5.13 mostra outra maneira de representar essa informao: tornar Com
parecimento uma classe completa. Observe como as multiplicidades mudaram.
Que vantagens voc obtm com a classe de associao para compensar a notao
extra que precisa lembrar? A classe de associao acrescenta uma restrio a mais, no
sentido de que pode haver apenas uma instncia da classe de associao entre quaisquer
dois objetos participantes. Sinto a necessidade de outro exemplo.
D uma olhada nos dois diagramas da Figura 5.14. Esses diagramas tm pratica
mente a mesma forma. Entretanto, podemos imaginar uma Empresa desempenhando
diferentes papis no mesmo Contrato, mas difcil imaginar uma Pessoa tendo rnlti-

" . -.

 88 UML ESSENCIAL

2 . .*
Pessoa Reunio
I
I
I
*
I
I
I . classe de associao
I

Comparecimento

atenciosidade

FIGURA 5.12 Classe de associao.

Comparecimento
2 . .* 1
Pessoa 1 * atenciosidade Reunio

FIGURA 5.13 Promovendo uma classe de associao para uma classe completa.
.
'
plas competncias na mesma habilidade; na verdade, voc provavelmente conside

isso um erro.
Na UML, apenas o ltimo caso vlido. Voc pede ter apenas uma cornpe
para cada combinao de Pessoa e Habilidade. O diagrama superior na Figura 5.1
permitiria que uma Empresa tivesse mais de um Papel em um nico contrato. Se
precisa permitir isso, ento necessrio tornar Papel uma classe completa, no est
Figura 5.13.
A implementao de classes de associao no terrivelmente bvia. Meu can
implementar uma classe de associao como se ela fosse uma classe completa
fornecer mtodos que obtenham informaes para as classes vinculadas pela cla
associao. Assim, para a Figura 5 .12, veramos os seguintes mtodos em Pessoa:

class Pessoa

List obterComparecimentos ()

List obterReunies()

Desse modo, um cliente de Pessoa pode controlar as pessoas na reunio;

quiserem detalhes, podem obter os Comparecimentos por si prprias. Se voc fize

lembre-se de impor a restrio de que s pode haver um objeto Comparecimento
qualquer par de Pessoa e Reunio. Voc deve colocar uma verificao em qualquer
. . do que crie objetos Comparecimento .

Voc encontra freqentemente esse tipo de construo com informaes h
cas, como na Figura 5.15. No entanto, acho que criar classes extras ou classes de as
es pode tornar o modelo difcil de entender, assim corno inclina a implementao
uma direo especfica, que rnuitas vezes inapropriada.
Se eu tenho esse tipo de informao temporal, uso a palavra-chave temp
na associao (veja a Figura 5 .16). O modelo indica que uma Pessoa pode trab
 CAPTU!,O 5: DIAGRA!VlAS DE CLASSES: CONCEITOS AVANADOS 89

Empresa * Contrato
I
I
I *
I
I
I
I

Papel

descrio

Pessoa *
* Habilidade
I
I
I
I
I
I
I

Competncia

nvel

FIGURA 5.14 Sutilezas da classe de associao (Papel provavelmente no deveria ser uma classe
de associao).

Emprego
Pessoa
1 1 Empresa
perodo : intervalodeDatas
* *
FIGURA 5.15 Usando uma classe para um relacionamento temporal.

emprega d or
temporal
Pessoa * Empresa
0 .. 1

FIGURA 5.16 A palavra-chave temporal para associaes.

apenas para uma nica Empresa por vez. Com o passar do tempo, entretanto, uma
Pessoa pode trabalhar para vrias Empresas. Isso sugere uma interface de acordo

com o seguinte:

class Pessoa
Empresa obterEmpregador();//obtm o empregador atual
Empresa obterEmpregador(Date);//obtm empregador em determinada data
void trocarde mudarEmpregador(Empresa novoEmpregador, Date datadaTroca);
void deixarEmpregador (Date datadaTroca);

'
 90 UML ESSENCIAL

A palavra-chave temporal no faz parte da UML, mas eu a menciono aqui por

dois motivos. Primeiro, trata-se de uma notao que considerei til em vrias ocasies
em minha carreira de modelagem. Segundo, ela mostra como voc pode usar palavras
chave para estender a UML. Voc pode ler muito mais sobre isso no endereo http:/ I
martinfowler.com/ ap2/ timeN arrative. html.

-CLASSE TEMPLATE (PARAMETRIZADA)

Vrias linguagens, mais notadamente C++, tm a noo de classe parametrizada ou
template. (Os templates esto na lista para serem includos em Java e em C# em um
futuro prximo.)
Esse conceito, obviamente, mais til para trabalhar com colees em uma lingua
gem fortemente ripada. Dessa forma, voc pode definir comportamento para conjuntos
em geral, definindo uma classe template Conjunto.

class Conjunto <T> {

void insert (T novoElemento);
void remove (T umElemento);

Tendo feito isso, voc pode usar a definio geral para fazer classes Conjunto para
elementos mais especficos.

Conjunto <Funcionrio> conjuntodeFuncionrios;

Voc declara uma classe template na UML usando a notao mostrada na Figura
5.17. OT no diagrama um lugar reservado para o parmetro de tipo. (Voc pode ter
mais de um.)
Um uso de uma classe parametrizada tal como Conjunto<Funcionrio>, chamado
de derivao. Voc pode mostrar uma derivao de duas maneiras. A primeira espelha a
sintaxe da linguagem C++ (veja a Figura 5.18). Voc descreve a expresso de derivao
entre colchetes, na forma <nome-parmetro:: valor-parmetro>. Se houver apenas um

e- ----,

.-------1 T I .
L- - - _J
Conjunto parmetro do template

classe template
insert(T)

remove(T)

FIGURA 5.17 Classe template .

Conjunto

<T::Funcionrio>

FIGURA 5.18 Elemento de amarrao (verso 1).

 CAPTULO 5: DIAGRAMAS DE CLASSES: CONCEITOS AVANADOS 91

parmetro, o uso convencional freqentemente omite o nome do parmetro. A notao

alternativa (veja a Figura 5.19) refora o elo para o template e permite que voc mude o
nome do elemento de amarrao.
A palavra-chave bind um esteretipo no relacionamento de refinamento. Esse
relacionamento indica que Conj untodeFuncionrios estar de acordo com a interface de
Conjunto. Voc pode considerar ConjuntodeFuncionrios como um subtipo de Conjun
to. Isso se encaixa na outra forma de implementar colees de tipo especfico, que
declarar todos os subtipos apropriados.
No entanto, o uso de uma derivao no o mesmo que subtipagem. Voc no
pode acrescentar propriedades no elemento de amarrao, que completamente especi
ficado pelo seu template; voc est acrescentando somente uma informao de tipo res
trito. Se quiser acrescentar propriedades, voc deve criar um subtipo.

r----,
I
T
L- - __ J
Conjunto

....

classe template insert(T)

remove(T)

/'

bind

<T::Funci onri-

ConjuntodeFun
, . amarrao do
.. , conros
elemento de parmetro
-
amarraao

FIGURA 5.19 Elemento de amarrao (verso 2).

-
ENUMERAOES

As enumeraes (Figura 5.20) so usadas para mostrar um conjunto fixo de valores que
no possuem quaisquer propriedades alm de seu valor simblico. Elas so mostradas
como a classe com a palavra-chave enumeration.

enumeration
Cor

vermelho
branco
azul

FIGURA 5.20 Enumerao.

"
92 UML ESSENCIAL

-
CLASSE ATIVA
Uma classe ativa tem instncias, cada uma das quais executa e controla sua prpria
de execuo de controle. Chamadas de mtodo podem ser executadas em uma lin
execuo do cliente ou em uma linha de execuo do objeto ativo. Um bom exe
disso um processador de comandos que aceita objetos comando do exterior e, e
executa os comandos dentro de sua prpria linha d execuo de controle.
A notao para classes ativas mudou da UML 1 para a UML 2, como mostra
Figura 5 .21. Na UML 2, uma classe ativa tem linhas verticais extras na lateral; na UM
uma classe ativa tinha uma borda grossa e era chamada de objeto ativo.

Processador
Processador de
de Comandos
Comandos

objeto ativo (UML 1) classe ativa (UML 2)

FIGURA 5.21 Classe ativa.

--------------------------------
V IS 181 LID AD E
A visibilidade um assunto que simples em princpio, mas tem sutilezas comp
idia bsica que qualquer classe tem elementos pblicos e elementos privad
elementos pblicos podem ser usados por qualquer outra classe; os elementos p
podem ser usados somente pela classe proprietria. Entretanto, cada linguagem t
prprias regras. Embora muitas linguagens usem termos como public (pblico),
(privado) e protected (protegido), eles tm significados distintos nas diferentes
gens. Essas diferenas so pequenas, mas causam confuso, especialmente para
pessoas que utilizam mais de uma linguagem.
A UML tenta abordar o tema sem entrar em uma terrvel confuso. Basic
dentro da UML, voc pode rotular qualquer atributo ou operao com um indi
visibilidade. Voc pode usar o marcador que quiser, e seu significado depend
linguagem. Entretanto, a UML fornece quatro abreviaes para visibilidade;
co), - (privado), ~ (pacote) e# (protegido). Esses quatro nveis so usados d
metamodelo da UML e so definidos dentro dele, mas suas definies variam su
daquelas das outras linguagens.
Quando voc estiver aplicando visibilidade, utilize as regras da linguagem
est trabalhando. Quando voc estiver examinando um modelo da UML de
outra origem, seja cuidadoso com o significado dos marcadores de visibilidade
ciente de como esses significados podem mudar de uma linguagem para outra
Na maioria das vezes, no desenho marcadores de visibilidade nos diagram
utilizo apenas se preciso destacar as diferenas na visibilidade de cerros recursos
assim, posso me virar com + e -, que pelo menos so fceis de lembrar.
 CAPTULO 5: DIAGRAMAS DE CLASSES: CONCEITOS AVANADOS 93

MENSAGENS

A UML padro no mostra nenhuma informao sobre chamadas de mensagem nos '
diagramas de classe. Entretanto, s vezes, tenho visto diagramas convencionais como o
da Figura 5.22.

calcularPreo
preencher

Pedido
> Item de Pedido
1
*
* obterValorComDesconto *
calcularPreo
itens Esperando obterPreo( quantidade)
obterTempodeSada
. I
no-
normativo .
1 1

Cliente ------------- --- Produto

<
ObterPreoEspecial

FIGURA 5.22 Classes com mensagens.

Eles adicionam setas ao longo das associaes. As setas so rotuladas com as mensa
gens que um objeto envia para outro. Como voc no precisa de uma associao com
uma classe para enviar uma mensagem a ela, talvez tambm precise adicionar uma seta
de dependncia para mostrar as mensagens entre classes que no esto associadas.
Essas informaes de mensagem abrangem mltiplos casos de uso; portanto, no
so numeradas para mostrar seqncias, ao contrrio dos diagramas de comunicao.

 -,rt=,
/

Captulo 6

iagramas de Objetos

Um diagrama de objetos um instantneo dos objetos em um sistema em um~

determinado ponto no tempo. Como ele mostra instncias, em vez de classes, um dia-l ,:j

grama de objetos freqentemente chamado de diagrama de instncias. .a

Voc pode usar um diagrama de objetos para mostrar um exemplo de configurao.t

de objetos. (Veja a Figura 6.1, que mostra um conjunto de classes, e a Figura 6.2, que;,
mostra um conjunto de objetos associados.) Este ltimo uso muito til, quando asJ
conexes possveis entre os objetos so complicadas. :1
Voc pode dizer que os elementos da Figura 6.2 so instncias porque os nornesj..
. )
'
esto sublinhados. Cada nome assume a forma nome de instncia : nome de classe. As;~1
. duas partes do nome so opcionais; portanto, John, : Pessoa e urnaPessoa so nomes]
vlidos. Se voc usar apenas o nome da classe, deve incluir os dois pontos. Voc podel
mostrar valores para atributos e vnculos, como na Figura 6.2. .
Rigorosamente falando, os elementos de um diagrama de objetos so especifica~i',
es de instncias, em vez de serem instncias verdadeiras. O motivo que vlidot
deixar atributos obrigatrios vazios ou mostrar especificaes de instncias de classei{
abstratas. Voc pode considerar uma especificao de instncia como uma instnci\ .,.
parcialmente definida. ~~
Outra maneira de ver tim diagrama de objetos como um diagrama de comunica~{
o (pgina 129) sem mensagens.

w
QUANDO USAR DIAGRAMAS DE OBJETOS

Os diagramas de objetos so teis para mostrar exemplos de objetos interligados. Emi.,.!

muitas situaes, voc pode definir uma estrutura precisamente, com um diagrama de~.
classes, mas a estrutura ainda difcil de entender. Nessas situaes, dois exemplos de~
diagrama de objetos podem fazer a diferena. ,

>,- ::, ,
 CAPTULO 6: DIAGRAMAS DE BJETOS 95

Festa
* filhos
localizao

' '\

O. .1 progenitor

Pessoa Organizao

FIGURA 6.1 Diagrama de classes da estrutura de composio Festa.

engenharia: Organizao
localizao = "Boston"
progenitor

ferramentas: Organizao aglicativos: Organizao

localizao = "Chicago" localizao = "Saba"

progenitor
Don: Pessoa John: Pessoa
localizao= "Champaign" localizao= "Champaign"

FIGURA 6.2 Diagrama de objetos mostrando exemplos de instncias de Festa.

 Captulo 7

iagramas de Pacotes

As classes representam a forma bsica de estruturao de um sistema orientado a

objetos. Embora elas sejam maravilhosamente teis, voc precisa de algo mais para estru
turar sistemas grandes, os quais podem ter centenas de classes.
Um pacote uma construo de agrupamento que permite a voc pegar qualquer
construo na UML e agrupar seus elementos em unidades de nvel mais alto. Seu uso
mais comum o agrupamento de classes e dessa maneira que o estou descrevendo aqui,
mas lembre-se de que voc tambm pode usar pacotes para todos os outros elementos da
UML.
Em um modelo da UML, cada classe membro de um nico pacote. Os pacotes
tambm podem ser membros de outros pacotes, de modo que voc obtm uma estrutura
hierrquica na qual os pacotes de nvel superior so divididos em subpacotes que pos
suem seus prprios subpacotes e assim por diante, at que a hierarquia chegue nas clas
ses. Um pacote pode conter subpacotes e classes.
Em termos de programao, os pacotes correspondem a contrues de agrupamen
to como pacotes (em Java) e espaos de nomes (em C++ e .NET).
Cada pacote representa um espao de nomes, o que significa que toda classe deve
ter um nome exclusivo dentro do pacote a que pertence. Se eu quiser criar uma classe
chamada Date e j houver uma classe Date no pacote System, posso ter minha classe
Date, desde que a coloque em um pacote separado. Para tornar claro qual qual, posso
usar um nome totalmente qualificado; isto , um nome que mostra a estrutura de paco
tes ao qual pertence. Para indicar nomes de pacote na UML, voc usa dois pontos du

plos; portanto, as datas poderiam ser System:: Date e MartinFowler: :Util:: Date.
Nos diagramas, os pacotes so mostrados por uma pasta com guia, como se v na
Figura 7.1. Voc pode mostrar simplesmente o nome do pacote ou mostrar tambm o
contedo. Em qualquer ponto, voc pode usar nomes totalmente qualificados ou apenas

nomes normais. Exibir o contedo com cones de classe permite a voc mostrar todos os
detalhes de uma classe, podendo apresentar at mesmo um diagrama de classes dentro
do pacote. Listar simplesmente os nomes faz sentido quando tudo que voc quer fazer
indicar, quais classes esto em quais pacotes.

E muito comum ver uma classe rotulada com algo como Date (de java. u til), em
vez da forma totalmente qualificada. Esse estilo uma conveno que foi muito utilizada
pela ,~ational Rose; ele no faz parte do padro .
A UML permite que as classes de um pacote sejam pblicas ou privadas. Uma
classe pblica faz parte da interface do pacote e pode ser usada por classes de outros
pacotes; urna classe privada fica oculta. Diferentes ambientes de programao tm regras
distintas sobre visibilidade entre suas construes de empacotamento; voc deve seguir a
 CAPTULO 7: DIAGRAMAS DE PACOTES 97

util util

Date

util Date

Contedo listado Contedo diagramado

na caixa na caixa

java

util
java::util

Date
Date
java:: util:: Date

Nome de pacote Pacotes aninhados Nome de classe

totalmente qualificado totalmente qualificado

FIGURA 7.1 Maneiras de mostrar pacotes em diagramas.

conveno de seu ambiente de programao, mesmo que isso signifique violar as regras +

da UML.
Uma tcnica til, aqui, reduzir a interface do pacote, exportando apenas um
pequeno subconjunto das operaes associadas s classes pblicas do pacote. Voc pode
fazer isso fornecendo visibilidade privada a todas as classes, para que elas possam ser
vistas apenas por outras classes do mesmo pacote, e adicionando classes pblicas extras
para o comportamento pblico. Ento, essas classes extras, chamadas Facades [Gangue
dos Quatro], delegam operaes pblicas s suas companheiras mais tmidas do pacote.
Como voc escolhe que classes vai colocar em quais pacotes? Na verdade, essa
uma questo bastante complicada, que precisa de uma boa habilidade com projetos para
ser respondida. Dois princpios teis so o Princpio do Fechamento Comum e o Princ
pio da Reutilizao Comum [Martin]. O Princpio do Fechamento Comum diz que as
classes de um pacote devem precisar de alterao por motivos semelhantes. O Princpio
da Reutilizao Comum diz que todas as classes de um pacote devem ser reutilizadas
juntas. Muitos dos motivos para o agrupamento de classes em pacotes esto relacionados
s dependncias entre os pacotes, que o que veremos a seguir.

PACOTES E DEPENDENCIAS

Um diagrama de pacotes mostra pacotes e suas dependncias. Eu apresentei a noo de

dependncia na pgina 47. Se voc tem pacotes de apresentao e de domnio, ento tem
uma dependncia do pacote de apresentao para o pacote de domnio, caso qualquer
classe no pacote de apresentao tenha uma dependncia de qualquer classe no pacote de

. ~

 98 UML ESSENCIAL

domnio. Desse modo, as dependncias entre os pacotes resumem as dependncias entre

seus contedos.
A UML tem muitas variedades de dependncias, cada uma com uma semntica e um
esteretipo em particular. Acho mais fcil comear com a dependncia no-estereotipada e
usar as dependncias mais particulares somente se for necessrio, o que dificilmente acontece.
Em um sistema mdio ou grande, representar um diagrama de pacotes pode ser
uma das coisas mais valiosas que voc pode fazer para controlar a estrutura de larga escala
do sistema, De preferncia, esse diagrama deve ser gerado a partir da prpria base de
cdigo, para que voc possa ver o que realmente h no sistema.
Uma boa estrutura de pacotes tem um fluxo claro das dependncias, um conceito
difcil de definir, mas freqentemente mais fcil de reconhecer. A Figura 7.2 mostra um
exemplo de diagrama de pacotes para uma aplicao comercial, o qual bem estruturado
e tem um fluxo claro.
Freqentemente, voc pode identificar um fluxo claro porque todas as dependn
cias seguem uma nica direo. Embora esse seja um bom indicador de um sistema bem
estruturado, os pacotes de mapeamento de dados da Figura 7.2 mostram uma exceo a
essa regra geral. Os pacotes de mapeamento de dados atuam como uma camada de
isolamento entre os pacotes de domnio e de banco de dados, um exemplo do padro
Mapper [Fowler, P de EAAJ.
Muitos autores dizem que no devem existir ciclos nas dependncias (o Princpio
da Dependncia Acclica [Martin]). No trato isso como uma regra absoluta, mas acho
que os ciclos devem ser localizados e, em particular, que voc no deve ter ciclos que
cruzem camadas.

apresentao apresentao
de arrendamento ---------------------~ de bens
I I

I I I I
I estrutura da I
I I
I L------), interface com <------..1 I

,1 o usuario
\Y
domnio de
arrendamento
---------------------~ domnio dos bens

I
I I
I I
I I
I

mapeamento dos
mapeamento dos
dados de - - - - - - - - - - - - - - - - - - - - - -_,...,
dados de bens
arrendamento
I

I I
I I
I I
I I
L---------), banco de dados <---------..!
FIGURA 7.2 Diagrama de pacotes para. uma aplicao comercial.

-
 CAPTULO 7: DIAGRAMAS DE PACOTES 99

Quanto mais dependncias entram em um pacote, mais estvel a interface do pa
cote precisa ser, pois qualquer alterao em sua interface ser propagada para todos os
pacotes que so dependentes dela (o Princpio das Dependncias Estveis [Martin]).

Assim, na Figura 7.2, o pacote do domnio dos bens precisa de uma interface mais estvel
do que o pacote de mapeamento de dados de arrendamento. Freqentemente, voc ver que
os pacotes mais estveis tendem a ter uma proporo mais alta de interfaces e classes abstratas

(o Princpio das Abstraes Estveis [Martin]).

Os relacionamentos de dependncia no so transitivos (pgina 48). Para ver por
que isso importante para dependncias, veja novamente a Figura 7.2. Se uma classe no
pacote do domnio de bens muda, talvez tenhamos que alterar as classes dentro do paco
te do domnio de arrendamento. Mas essa alterao no se propaga necessariamente para

a apresentao de arrendamento. (Ela s se propaga se o domnio de arrendamento muda

sua interface.)
Alguns pacotes so usados em tantos lugares, que seria uma confuso desenhar
todas as linhas de dependncia para eles. Nesse caso, uma conveno usar uma palavra
chave, como global, no pacote.
Os pacotes da UML tambm definem construes para permitir a importao e
mesclagem de classes de um pacote para outro, usando dependncias com palavras-cha
ve para denotar isso. Entretanto, as regras para esse tipo de coisa variam muito com as
linguagens de programao. Em geral, considero a noo de dependncias bem mais til
, .
na pratica .

............... r--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-

ASP ECTOS DOS PACOTES

Se voc pensar a respeito da Figura 7.2, perceber que o diagrama tem dois tipos de
estruturas. Uma delas a estrutura de camadas na aplicao: apresentao, domnio,
mapeamento de dados e banco de dados. A outra uma estrutura de reas de assunto:
arrendamento e bens.
Voc pode tornar isso mais aparente, separando os dois aspectos, como na Figura
7.3. Com esse diagrama, voc pode ver claramente cada aspecto. Entretanto, esses dois
aspectos no so pacotes verdadeiros, pois voc no pode atribuir classes a um nico
pacote. (Voc teria que escolher uma de cada aspecto.) Esse problema espelha o proble
ma dos espaos de nomes hierrquicos nas linguagens de programao. Embora diagra
mas como o da Figura 7.3 no sejam UML padro, freqentemente eles so muito teis
na explicao da estrutura de uma aplicao complexa .

. COMO IMPLEMENTAR PACOTES

Freqentemente, voc ver um caso em que um pacote define uma interface, que pode
ser implementada por vrios outros pacotes, como mostra a Figura 7 .4. Nesse caso, o
relacionamento de realizao indica que o gateway do banco de dados define uma inter
face e que as outras classes de gateway fornecem uma implementao. Na prtica, isso
significaria que o pacote de gateway de banco de dados contm interfaces e classes abstra
tas que so totalmente implementadas pelos outros pacotes.
muito comum que uma interface e sua implementao estejam em pacotes se
parados. Na verdade, um pacote de cliente freqentemente contm uma interface para

- " . ....,.;:

 1 OO UML ESSENCIAL

estrutura da
apresentao - - - ;> interface, com arrendamento
.
o usuario
I I

I I
I I
I I
I

domnio YI
I .

li\ . -
nao-
normativo . .
bens
I
I
I

mapeamento
de dados
I

I
I

\V
banco de dados

FIGURA 7.3 Separando a Figura 7.3 em dois aspectos.

Gateway do
Aplicao I- - - - - - - -
Banco de Dados

I
I

r-----------L----------,
I
I I
I
I I I
I I I

Gateway do Gateway do SQL Gateway do Stub

Oracle Server de Teste

FIGURA 7.4 Um pacote implementado por outros pacotes .

um outro pacote implementar: a mesma noo de interface obrigatria que discuti

pgina 70.

Imagine que queiramos fornecer alguns controles de interface com o usurio
para ligar e desligar coisas. Queremos que isso funcione com muitas coisas diferen
como aquecedores e luzes. Os controles da interface com o usurio precisam exec
mtodos no aquecedor, mas no queremos que os controles tenham uma depend
do aquecedor. Podemos evitar essa dependncia definindo, no pacote de controles,
 CAPTUl,O 7: IAGRAMAS DE PACOTES 101

interface que seja, ento, implementada por qualquer classe que queira trabalhar com
esses controles, como se v na Figura 7.5. Esse um exemplo do padro Separated Inter
face [Fowler, P de EAAJ.

Controle

Boto - - -
-~ 7
interface
Liga Desliga

Liga
Desliga
Caixa de --- -~ /
est Ligado
est Desligado
Seleo
I\'
'
I
I

r - - - - - -'- - - - - - ,
I I

'
Forno: :Aquecedor lluminao::Luz

FIGURA 7.5 Definindo uma interface requerida em um pacote de cliente.

QUANDO USAR DIAGRAMAS DE PACOTES

Considero os diagramas de pacotes extremamente teis em sistemas de grande porte,

para obter uma viso das dependncias entre os principais elementos de um sistema.
Esses diagramas correspondem bem s estruturas usuais de programao. A representa
o de diagramas de pacotes e dependncias o ajuda a manter as dependncias de uma
aplicao sob controle.
Os diagramas de pacotes representam um mecanismo de agrupamento em tempo
de compilao. Para mostrar como os objetos so compostos em tempo de execuo, use
um diagrama de estrutura composta (pgina 132).

ONDE ENCONTRAR -
MAIS INFORMAOES

A melhor discusso que conheo sobre pacotes e como utiliz-los [Martin]. H algum
tempo, Robert Martin tem uma obsesso quase patolgica com dependncias e escreve
muito bem sobre como prestar ateno a elas para que voc possa control-las e minimi
z-las.

 Captulo 8

iagramas de Instalao

Os diagramas de instalao mosrram o layout fsico de urn sistema, revelando q

partes do software so executadas em quais partes do hardware. Os diagramas de di
buio so muito simples; da, a brevidade deste captulo.
A Figura 8.1 um exemplo simples de um diagrama de distribuio. Os
principais do diagrama so ns conectados por caminhos de comunicao. Um n
que pode conter algum software. Os ns aparecem em duas formas. Um dispositiv
hardware; ele pode ser um computador ou uma pea de hardware mais simples con
da a um sistema. Um ambiente de execuo software que contm a si mesmo
contm outro software; exemplos desse so um sistema operacional ou um proc
A
contemer,
Os ns contm artefatos, que so as manifestaes fsicas de software: normalm
te, arquivos. Esses arquivos podem ser executveis (como arquivos.exe, binrios, D
arquivos JAR, programas em linguagem assembly ou scripts) ou arquivos de dados, a
vos de configurao, documentos HTML etc. A listagem de um artefato dentro d
n mostra que ele est instalado nesse n do sistema que est em execuo.
Voc pode mostrar artefatos como caixas de classe ou listando o nome dent
um n. Se voc os mostrar como caixas de classe, poder adicionar um cone de
mento ou a palavra-chave artifact. Voc pode rotular ns ou artefatos com v
para indicar diversas informaes interessantes a respeito do n, tais como forne
sistema operacional, localizao ou qualquer coisa que voc desejar.
Freqentemente, voc ter vrios ns fsicos executando a mesma tarefa
Voc pode mostrar isso com vrias caixas de n ou declarar o nmero como um
afixado. Na Figura 8.1, usei o rtulo "nmero instalado" para indicar trs serv
fsicos de Web, mas no existe nenhum rtulo padro para isso.
Muitas vezes, os artefatos so a implementao de um componente. Para m

isso, voc pode usar um valor indicado na caixa do artefato.
Os caminhos de comunicao entre os ns indicam como as coisas se comun
Voc pode rotular esses caminhos com informaes sobre os protocolos de comun

utilizados .

 CAPTULO 8: !AG!ZAMAS DE DrsTRIBUIO 103

ClienteNavegador Cliente Rico

{SO = Windows}<

navegador
herculesClient.exe valor rotulado

caminho de comunicao

Servidor de Aplicativos

.,-,-... '-

http/Internet http/Rede Local

JoveGL.exe Cl
{fornecedor = romanSoft}
{componente = General Ledger}

artefato
distribudo

Continer EJB
Servidor de Web
{SO = Solaris} herculesBase.ear
{servidor de Web = apache} herculesAR.ear
{nmero distribudo = 3} Java RMI/
herculesAP.ear
Rede Local
herculesWeb.war
JDBC
' . .

n de ambiente
n de dispositivo de execuo
SGBD Oracle

FIGURA 8.1 Exemplo de diagrama de instalao.

QUANDO USAR DIAGRAMAS

-
DE INSTALAAO

No deixe que a brevidade deste captulo o faa pensar que os diagramas de instalao
no devem ser usados. Eles so muito teis para mostrar o que instalado e onde; por
tanto, qualquer instalao mais complicada pode fazer bom uso deles.

 ~---~ . -- - .
~

Captulo 9

asos de Uso

Os casos de uso so uma tcnica para captar os requisitos funcionais de um siste

ma. Eles servem para descrever as interaes tpicas entre os usurios de um sistema e o.
prprio sistema, fornecendo uma narrativa sobre como o sistema utilizado.
Em vez de descrever os casos de uso de incio, acho mais fcil rode-los e comear.
descrevendo cenrios. Um cenrio uma sequncia de passos que descreve uma intera
o entre um usurio e um sistema. Assim, se tivermos uma loja on-line baseada na Web
(loja virtual), podemos ter um cenrio de Compra de um Produto que diria:

O cliente navega no catdlogo de itens e adiciona os itens desejados sua cesta de com
pras. Quando o cliente deseja pagar, descreve o endereo de entrega, fornece as informa
es do carto de crdito e confirma a venda. O sistema verifica a autorizao do carto.
de crdito e confirma a venda imediatamente e com um e-mail subseqente.

Esse cenrio uma alternativa que pode acontecer. No entanto, a autorizao do.
carto de crdito pode falhar, o que seria um outro cenrio. Em um outro caso, voc
poderia ter um cliente regular de quem no precisa captar o endereo de entrega e as
informaes do carto de crdito, o que seria um terceiro cenrio.
Todos esses cenrios so diferentes, embora semelhantes. A essncia de sua simila-.
ridade que, em todos, o usurio tem o mesmo objetivo: comprar um produto. Nem
sempre ele tem sucesso, mas o objetivo permanece. Esse objetivo do usurio a chave
dos casos de uso: um caso de uso um conjunto de cenrios amarrados por um objetivo
comum de usurio.
No jargo dos casos de uso, os usurios so referidos como atores. Um ator um
papel que um usurio desempenha com relao ao sistema. Os atores podem ser o cliente..
representante de servio ao cliente, gerente de vendas e analista de produto. Os atores
realizam os casos de uso. Um nico ator pode realizar muitos casos de uso; inversamente,
um caso de uso pode ter vrios atores executando-o. Normalmente, voc tem muitos
clientes; portanto, muitas pessoas podem ser o ator cliente. Alm disso, uma pessoa pode
atuar como mais de um ator, como um gerente de vendas que executa tarefas de represen
tante de servio ao cliente. Um ator no precisa ser um ser humano. Se o sistema realiza um
servio para outro sistema de computador, esse outro sistema um ator.
Na realidade, ator no o termo correto; papel seria muito melhor. Aparencemen-
te, houve uma traduo errada do sueco; ator o termo que a comunidade dos casos de
uso utiliza.
Os casos de uso so reconhecidos como uma. parce importante da UML. Entrecan-
to, a surpresa que, de muitas maneiras, a definio de casos de uso na UML muito

-
 CAPTULO 9: CASOS DE Uso 105

rala. Nada na UML descreve como voc deve capturar o contedo de um caso de uso. O
que a UML descreve um diagrama de casos de uso, que mostra como utilizar casos
relacionados entre si. Mas praticamente todo o valor dos casos de uso reside no contedo
e o diagrama de valor bastante limitado.

,
CONTEUDO DE UM CASO DE USO

No existe nenhuma maneira padronizada para escrever o contedo de um caso de uso e

diferentes formatos funcionam bem em diferentes casos. A Figura 9 .1 mostra um estilo
comum de uso. Voc comea escolhendo um dos cenrios como sendo o cenrio princi
pal de sucesso (CPS). D incio ao corpo do caso de uso escrevendo o cenrio principal
de sucesso como uma seqncia de passos numerados. Ento, pega os outros cenrios e
os escreve como extenses, descrevendo-os em termos de variaes em relao ao cenrio
principal de sucesso. As extenses podem ser bem-sucedidas - o usurio atinge o objeti
vo, como em 3a - ou falhas, como em Ga.
Cada caso de uso tem um ator principal, que pede ao sistema para que execute um
servio. O ator principal aquele cujo objetivo o caso de uso est tentando satisfazer e,
normalmente (mas nem sempre) o iniciador do caso de uso. Podem existir outros
atores com os quais o sistema se comunica enquanto executa o caso de uso. Eles so
conhecidos como atores secundrios.
Cada passo em um caso de uso um elemento da interao entre um ator e o
sistema. Cada passo deve ser uma declarao simples e mostrar claramente quem est
executando o passo. O passo deve mostrar a inteno do ator e no os mecanismos do que o
ator faz. Conseqentemente, voc no descreve a interface com o usurio no caso de uso. Na
verdade, a escrita do caso de uso normalmente precede o projeto da interface com o usurio.
Uma extenso dentro do caso de uso nomeia uma condio que resulta em diferen
tes interaes daquelas descritas no cenrio principal de sucesso e informa quais so essas

Compra de um Produto
Nvel do Objetivo: Nvel do Mar
Cenrio Principal de Sucesso:
1. O cliente navega pelo catlogo e seleciona itens para comprar
2. O cliente vai para o caixa
3. O cliente preenche o formulrio da remessa (endereo de entrega; opo de entrega ime-
diata ou em trs dias)
4. O sistema apresenta a informao completa do faturamento, incluindo a remessa
5. O cliente preenche a informao de carto de crdito
6. O sistema autoriza a compra
7. O sistema confirma imediatamente a venda
8. O sistema envia uma confirmao para o cliente por e-mail
Extenses:
3a: Cliente regular
.1: O sistema mostra a informao atual da remessa, a informao de preo e a informa
o de cobrana
.2: O cliente pode aceitar ou escrever por cima desses padres, retornando ao CPS, no
passo 6
6a. O sistema falha na autorizao da compra a crdito
.1: O cliente pode inserir novamente a informao do carto de crdito ou cancelar

Fgura 9.1 Exemplo de texto de caso de uso.

 106 UML ESSENCIAL

diferenas. Inicie a extenso dando um nome ao passo em que a condio detectad

fornea uma breve descrio da condio. Aps a condio, coloque passos numerad
no mesmo estilo que o do cenrio principal de sucesso.
Conclua esses passos descrevendo onde voc volta para o cenrio principal de
cesso, caso volte.
A estrutura do caso de uso uma excelente maneira de criar alternativas ao cen
principal de sucesso. Para cada passo, pergunte: como isso poderia ser feito de
forma diferente? E em particular, pergunte: o que poderia dar errado? Normalmen
melhor pensar em todas as condies de extenso primeiro, antes de se aprofunda
soluo das conseqncias. Dessa maneira, voc provavelmente considerar mais co
es, o que se traduz em menos erros a serem capturados posteriormente.
Um passo complicado em um caso de uso pode ser um outro caso de uso.
termos de UML, dizemos que o primeiro caso de uso inclui o segundo. No ex
nenhuma maneira padronizada para mostrar no texto um caso de uso includo,
acho que o sublinhado, que sugere um elo de hipertexto, funciona muito bem e,
muitas ferramentas, ser realmente isso. Assim, na Figura 9.1, o primeiro passo incl
caso de uso "navega pelo catlogo e seleciona itens para comprar".
Os casos de uso includos podem ser teis em um passo complexo que conges
naria o cenrio principal ou em passos que so repetidos em vrios casos de uso.
entanto, no tente subdivir os casos de uso em sub-casos de uso e sub-sub-casos de
utilizando decomposio funcional. Tal decomposio uma boa maneira de pe

muito tempo.
Assim como acontece com os passos nos cenrios, voc pode adicionar algu
outras informaes comuns a um caso de uso.
Uma pr-condio descreve o que o sistema deve garantir como verdade
antes de permitir que o caso de uso comece. Isso til para dizer aos progra
dores quais condies eles no precisam verificar no cdigo.
Uma garantia descreve o que o sistema ir assegurar no final do caso de uso
garantias de sucesso se mantm aps um cenrio bem-sucedido; as garan
mnimas se mantm aps qualquer cenrio.
Um gatilho especifica o evento que inicia o caso de uso.
,
Quando voc estiver considerando a adio de elementos, seja ctico. E me
fazer muito pouco do que fazer demais. Alm disso, faa o mximo para manter o
de uso breve e fcil de ler. Descobri que os casos de uso longos e detalhados no so li
o que anula seu objetivo.
O volume de detalhes necessrio em um caso de uso depende do risco nesse cas
uso. Freqentemente, voc precisa de detalhes apenas no incio de alguns poucos c
- de uso importantes; os outros podem ser considerados imediatamente antes de
implement-los. Voc no precisa escrever todos os detalhes; a comunicao verb
freqentemente muito eficaz, particularmente dentro de um ciclo iterativo em qu
necessidades so rapidamente atendidas por meio da execuo do cdigo.

DIAGRAMAS DE CASOS DE USO

Conforme eu disse anteriormente, a UML nada diz sobre o contedo de um caso de

mas fornece um formato de diagrama para mostr-lo, como se v na Figura 9.2. Emb
 CAPTULO 9: CASOS DE Uso 107

Estabelecer Atualiza
Limites Contas

Analisar incluso Sistema de

include
Riscos
~~::,:....--,, Contabilidade
Gerente ' ,, ....... :,. .
Comercial ... ~
Fechar -----;> Avaliar
Preo include Negcio

Registrar
Negcio

ator
Gerente

caso de uso
Vendedor
limite do
sistema
FIGURA 9.2 Diagrama de casos de uso.

o diagrama s vezes seja til, ele no obrigatrio. Em seu trabalho com casos de uso,
no se esmere muito no diagrama. Em vez disso, concentre-se no contedo textual dos
casos de uso.
A melhor maneira de pensar um diagrama de caso de uso como um sumrio
grfico do conjunto de casos de uso. Ele tambm semelhante ao diagrama de contexto +
usado nos mtodos estruturados, pois mostra o limite do sistema e as interaes com o
mundo exterior. O diagrama de casos de uso mostra os atores, os casos de uso e os
relacionamentos entre eles:

Quais atores realizam quais casos de uso

Quais casos de uso incluem outros casos de uso

A UML inclui outros relacionamentos entre os casos de uso, alm da incluso

simples, como extend. Sugiro que voc os ignore. Tenho visto muitas situaes em que
as equipes podem ficar terrivelmente atrasadas ao usar diferentes relacionamentos de
caso de uso e muita energia desperdiada. Em vez disso, concentre-se na descrio
textual de um caso de uso; a que reside o valor real da tcnica.

--------------------------------------

NIVEIS DE CASOS DE USO

Um problema comum que pode acontecer com casos de uso que, concentrando-se na
interao entre um usurio e o sistema, voc pode negligenciar situaes nas quais uma
mudana no processo do negcio pode ser a melhor maneira de lidar com o problema.
Freqentemente, as pessoas falam sobre casos de uso de sistema e casos de uso de neg
cio. Os termos no so precisos, mas o uso geral que um caso de uso de sistema uma
interao com o sotturare, enquanto um caso de uso de neg6cio examina como a aplica
o responde ao cliente ou a um evento.

 108 UML ESSENCIAL

[Cockburn, use cases] sugere um esquema de nveis de casos de uso. Os casos

de uso bsicos esto "no nvel do mar". Normalmente, os casos de uso no nvel elo
mar representam uma interao distinta entre um ator principal e o sistema. Tais
casos de uso transmitiro algo de valor para o ator principal e, normalmente, este
levar de alguns minutos a meia hora para terminar. Os casos de uso existentes ape-
nas porque foram includos pelos casos de uso de nvel do mar esto em nvel de
peixe. Os casos de uso de nvel mais alto (em nvel de pssaro) mostram como os
casos de uso de nvel do mar se encaixam nas interaes do negcio mais amplas. Os
casos de uso em nvel de pssaro normalmente so casos de uso de negcio, enquan
to os casos de nveis do mar e de peixe so casos de uso de sistema. Voc dever ter a
maioria de seus casos de uso em nvel do mar. Eu prefiro indicar o nvel no incio do.
caso de uso, como na Figura 9 .1.

CASOS DE USO E FUNCIONALIDADES (OU HISTORIAS)

Muitas estratgias utilizam as funcionalidades de um sistema - a Extreme Programming

os chama de histrias de usurio - para ajudar a descrever requisitos. Uma questo co-
mum como funcionalidades e casos de uso se correlacionam.
As funcionalidades constituem uma boa maneira de repartir um sistema para pla-
nejar um projeto iterativo, pelo qual cada iterao implementa vrias funcionalidades.'
Os casos de uso fornecem uma narrativa de como os atores utilizam o sistema. Ento,'
embora as duas tcnicas descrevam requisitos, seus propsitos so diferentes.
Embora voc possa passar diretamente descrio das funcionalidades, muitas pes-.
soas acham interessante desenvolver primeiro os casos de uso e depois gerar uma lista de:
funcionalidades. Um recurso pode ser um caso de uso inteiro, um cenrio em um caso
de uso, um passo em um caso de uso ou algum comportamento variante, como a adio.
de um outro mtodo de depreciao para suas avaliaes de bens, que no aparea em
uma narrativa de caso de uso. Normalmente, os recursos acabam sendo mais refinados
do que os casos de uso .

..............~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-
QUAND O UTILIZAR CASOS DE USO

Os casos de uso so uma ferramenta valiosa para ajudar no entendimento dos requisitos
funcionais de um sistema. Uma primeira passagem nos casos de uso deve ser feita no

incio. Verses mais detalhadas dos casos de uso devem ser elaboradas apenas antes do
desenvolvimento desse caso de uso.
importante lembrar que casos de uso representam urna viso externa do sistema.
Como tal, no espere quaisquer correlaes entre eles e as classes dentro do sistema .
Quanto mais eu observo os casos de uso, menos valioso parece ser o diagrama de
casos de uso. Corn os casos de uso, voc concentra sua energia no texto e no no diagra-

ma. A despeito do fato de que a UML nada tem a dizer sobre o texto do caso de uso,
esse texto que contm todo o valor da tcnica.
Um grande perigo dos casos de uso que as pessoas os tornam complicados demais

e no conseguem prosseguir. Normalmente, voc ter menos problemas fazendo pouco.
do que fazendo demais. Umas duas pginas por caso de uso est bom, para a maioria das
situaes. Se voc tiver muito pouco, pelo menos ter um documento curto e legvel,
 CAPTULO 9: CASOS DE Uso 109

que ser um po11to de partida para perguntas. Se voc tiver demais, dificilmente algum

o ler e o entender.

ONDE ENCONTRAR -
MAIS INFORMAOES

Os casos de uso foram popularizados originalmente por Ivar Jacobson [Jacobson, OOSE].
Embora os casos de uso j existam h algum tempo, havia pouca padronizao para
seu uso. A UML nada diz sobre o importante contedo de um caso de uso e tem padro

nizado apenas os diagramas, muito menos importantes. Como resultado, voc pode
encontrar uma variedade de opinies divergentes a respeito dos casos de uso.

Nos ltimos anos, entretanto, [Cockburn, use cases] tornou-se o livro padro sobre
o assunto. Neste captulo, segui a terminologia e as recomendaes desse livro, pelo
excelente motivo de que, quando discordamos no passado, no final acabei aceitando a
opinio de Alistair Cockburn. Ele tambm mantm uma pgina na Web, no endere
o http://usecases.org. [Constantine e Lockwood] fornecem um convincente pro
cesso para derivar interfaces com o usurio a partir de casos de uso; veja tambm o
endereo http://foruse.com .

 -.,
. -
..,,..
.. ,..,'
.

Captulo 1O

iagramas de
Mquina de Estados

Os diagramas de mquina de estados so uma tcnica conhecida para descrever :

comportamento de um sistema. Existem vrias formas de diagramas de estados desde o
anos 60 e as mais antigas tcnicas orientadas a objetos os adotaram para mostrar com
portamento. Nas estratgias orientadas a objetos, voc desenha um diagrama de mqui
na de estados para uma nica classe, para mostrar o comportamento do ciclo de vida d(
um nico objeto.
Quando as pessoas escrevem sobre mquina de estados, inevitavelmente os exem.
plos so controles de navegao ou mquina de vendas. Como estou um pouco enjoadc
desses exemplos, decidi usar um controlador para um painel secreto em um castelo gti.
co. Nesse castelo, quero manter meus objetos de valor em um cofre que seja difcil d(
encontrar. Assim, para revelar o cadeado do cofre, tenho que remover uma vela estratgi
ca de seu castial, mas isso mostrar o cadeado somente enquanto a porta estiver fecha
da. Uma vez que eu consiga ver o cadeado, posso inserir minha chave para abrir o cofre
Como uma medida de segurana extra, garanto que s posso abrir o cofre se primeirc
substituir a vela. Se um ladro se esquecer dessa precauo, eu soltarei um monstre
asqueroso para devor-lo.
A Figura 10.1 mostra um diagrama de mquina de estados da classe do controlador
que dirige meu sistema de segurana incomum. O diagrama de estados comea com e
estado do objeto controlador, quando ele criado: na Figura 10.1, o estado Esperar. O
diagrama indica isso com o pseudo-estado inicial, que no um estado, mas tem urns
seta que aponta para o estado inicial.
O diagrama mostra que o controlador pode estar em trs estados: Esperar, Trancar
e Abrir. Ele tambm fornece as regras por meio das quais o controlador muda de um estado
para outro. Essas regras esto na forma de transies: as linhas que conectam os estados.
A transio indica um movimento de um estado para outro. Cada transio tem
um rtulo que possui trs partes: assinatura-do-gatilho [sentinela] /atividade. To
das as partes so opcionais. A assinatura-do-gatilho normalmente um nico evento
que dispara uma mudana de estado em potencial. A sentinela, se estiver presente,
uma condio booleana que deve ser verdadeira para que a transio ocorra. A atividade
algum comportamento executado durante a transio. Pode ser qualquer expresso
comportamental. A forma completa de uma assinatura-do-gatilho pode incluir mlti
plos eventos e parmetros. Assim, na Figura 10.1, voc l a transio externa do estado
Esperar como: "No estado Esperar, se a vela for removida na condio em que a porta
esteja aberta, voc revelar o cadeado e mudar para o estado Trancar".
Todas as trs partes de uma transio so opcionais. Uma atividade ausente indica
que voc no faz nada durante a transio. Uma sentinela ausente indica que voc sem-
 CAPfTULO 10: DIAGRAMAS DE MQUINA DE ESTADOS 113

Tanto realizar-atividades como as atividades normais representam a execuo de

algum comportamento. A diferena fundamental entre as duas que as atividades nor

mais ocorrem "instantaneamente" e no podem ser interrompidas por eventos regulares,

enqua11to as do tipo realizar-atividades podem demorar um tempo finito e podem ser
interrompidas, como na Figura 10.3. O termo instantaneamente significar diferentes

coisas para sistemas distintos; para sistemas de hardware em tempo real, poderia signifi
car algumas instrues de mquina, mas para software executando localmenre poderia
ser vrios segundos.
A UML 1 usava o termo ao para atividades normais e usava atividades somente

para a modalidade realizar-atividades.

SUPERESTADOS

Freqentemente, voc ver que vrios estados compartilham transies e atividades in

ternas comuns. Nesses casos, voc pode transform-los em subestados e mover o com
portamento compartilhado para um superestado, como na Figura 10.4. Sem o superes
tado, voc teria que desenhar uma transio de cancelamento para todos os trs estados
dentro do estado Inserir Detalhes da Conexo.

ESTADOS CONCORRENTES

Os estados podem ser divididos em vrios diagramas de estados ortogonais que execu
tam concorrentemente. A Figura 10.5 mostra um despertador absurdamente simples,
que pode tocar CDs ou ligar o rdio e mostrar a hora atual ou a hora de alarme.
As escolhas CD/ rdio e hora atual/ de alarme so ortogonais. Se voc quisesse
representar isso com um diagrama de estados no-ortogonal, precisaria de um dia
grama confuso, que ficaria fora de controle se fossem necessrios mais estados. Sepa
rar as duas reas de comportamento em diagramas de estados distintos torna isso
muito mais claro.

Mostrar
Conexes ~

nova salvar

cancelar
'
Inserir Detalhes da Conexo

prximo ; prximo
;
. Inserir
Escolher "?"
Nmero Compartilhado Inserir Nome
de Telefone ou Sozinho
voltar voltar

FIGURA 10.4 Superestado com subestados aninhados.

... i, ......

 -- "'

114 UML ESSENCIAL

Ligado

hora
Exibir Hora Exibir Hora de
Atual Alarme alarme

limite concorrente

Ligar o Rdio Tocar CD

H
Rdio CD

Pseudo-estado de ligado desligado

histrico

Desligado

FIGURA 10.5 Estados concorrentes ortogonais.

A Figura 10.5 tambm inclui um pseudo-estado de histrico. Isso indica que,

quando o despertador ligado, a escolha de rdio/CD volta para o estado em que o
despertador estava quando foi desligado. A seta do pseudo-estado de histrico indica em
qual estado estar na primeira vez, quando ainda no houver histrico.

COMO IMPLEMENTAR DIAGRAMAS DE ESTADOS

Um diagrama de estados pode ser implementado de trs maneiras principais: comando

switch aninhado, o padro State e tabelas de estado. A estratgia mais direta para lidar
com um diagrama de estados por meio de uma instruo switch aninhada, como se v


na Figura 10.6. Embora seja direta, ela cansativa, mesmo para este caso simples. Essa
estratgia tambm sai muito facilmente de controle, de modo que no gosto de us-la,
mesmo para casos simples.

O padro State [Gangue dos Quatro] cria uma hierarquia de classes de estado para .
manipular o comportamento dos estados. Cada estado no diagrama tem uma subclasse
de estado. O controlador tem mtodos para cada evento, os quais simplesmente encami- '

nham para a classe do estado. O diagrama de estados da Figura 10.1 produziria uma .
implementao indicada pelas classes da Figura 10.7.

O topo da hierarquia uma classe abstrata que implementa todos os mtodos de
tratamento de eventos para no fazer nada. Para cada estado concreto, voc simplesmen
te reescreve os mtodos de eventos especficos para os quais o estado possui transies.
A estratgia da tabela de estados captura as informaes do diagrama de estados como
dados. Assim, a Figura 10.1 poderia acabar sendo representada como a Tabela 10.1.
 CAPTULO 10: DIAGRAMAS DE MQUINA DE ESTADOS 115

public void TratarEvento (EventodePainel umEvento) {

switch (EstadoCorrente) {
case EstadodoPainel.Abrir:
switch (umEvento) {
case EventodePainel.CofreFechado:
EstadoCorrente = EstadodoPainel.Esperar
break;
)

break;
case EstadodoPainel.Esperar:
switch (umEvento) {

case EventodePainel.VelaRemovida:
if ( aPortaEs tAberta I (
RevelaCadeado();

EstadoCorrente = EstadodoPainel.Trancar;
)
break;
}
break;
case EstadodoPainel.Trancar:
switch (umEvento) (
case EventodePainel.ChaveGirada:
if (aVelaEstPresente) {
AbrirCofre();
EstadoCorrente = EstadodoPainel.Abrir;
) else {
SoltarCoelhoAssassino();
EstadoCorrente = EstadodoPainel.Final;
)
break;
)
break;
)
)
)

FIGURA 10.6 Uma instruo switch aninhada da linguagem C# para manipular a transio de esta
dos da Figura 10.1.

Construmos, ento, um interpretador que usa a tabela de estados em tempo de execu

o ou um gerador de cdigo que gera classes com base na tabela de estados.
Obviamente, a tabela de estados d mais trabalho para fazer, mas ento voc pode
us-la sempre que tiver um problema de estados para resolver. Uma tabela de estados de
tempo de execuo tambm pode ser modificada sem recompilao, o que muito til
em alguns contextos. O padro State mais fcil construir, quando voc precisa dele e,
embora ele necessite de uma nova classe para cada estado, trata-se de um pequeno volu
me de cdigo a ser escrito em cada caso.
Essas implementaes so mnimas, mas devem dar a voc uma idia de como
proceder na implementao de diagramas de estados. Em cada caso, a implementao de
modelos de estado leva a um cdigo bastante padronizado; portanto, normalmente
melhor usar alguma forma de gerao de cdigo para faz-lo.

...............~-----------------------------------~
QUANDO UTILIZAR DIAGRAMAS DE ESTADOS

Os diagramas de estados so bons para descrever o comportamento de um objeto por

intermdio de vrios casos de uso. No entanto, esses diagramas no so muito bons para

 .,...,..,..-
. .

116 UML EssENCIAI

descrever um comportamento que envolva vrios objetos em colaborao. Para tal, til
combinar diagramas de estados com outras tcnicas. Por exemplo, os diagramas de inte
rao (veja o Captulo 4) so bons para descrever o comportamento de vrios objetos em
um nico caso de uso e os diagramas de atividades (veja Captulo 11) so bons para
mostrar a seqncia geral de atividades para vrios objetos e casos de uso.
Nem todo mundo considera que os diagramas de estados sejam naturais. Fique
atento ao modo como as pessoas trabalham com eles. Pode ser que sua equipe no con
sidere os diagramas de estados teis para seu modo de trabalhar. Isso no um grande
problema; como sempre, voc deve lembrar de usar uma combinao das tcnicas que
funcionem para seu caso.
Se voc utilizar diagramas de estados, no tente desenh-los para cada classe
presente no sistema. Embora essa estratgia seja freqentemente utilizada por per
feccionistas de muita formalidade, ela quase sempre um desperdcio de trabalho.
Use diagramas de estados somente para aquelas classes que exibem comportamento
interessante, para as quais a construo do diagrama de estados ajude a compreender
o que est acontecendo. Muitas pessoas acreditam que a interface com o usurio e os
objetos de controle tm o tipo de comportamento que til representar com um
diagrama de estados.

. f TABELA 10.1 Uma tabela de estados para a Figura 10.1

Estado de Origem Estado de Destino Evento Sentinela Procedimento

Esperar Trancar Vela removida Porta aberta Revelar cadeado

Trancar Abrir Chave girada Vela presente Abrir cofre

Trancar Final Chave girada Vela removida Soltar coelho assassino

Abrir Esperar Cofre fechado

Controlador do Painel Secreto

Estado do Painel Secreto
estado 1

mudarEstadoP ara(EstadodoPainelSecreto) tratarVelaRemovida,

tratarVelaRemovida, tratarChaveGirada ,

tratarChaveGirada , tratarCofreFechado '

tratarCofreFechado ' '
' no faz nada
''

estado. tratarVela Removida

Estado Esperar Estado Trancar Estado Abrir

if (porta aberta) {
relevarCadeado()
' tratarVelaRemovida
,,.
tratarChaveGirada tratarCofreFechado

mudarEstadoPara(Estadorancar) , __......_ _
}

FIGURA 1 O. 7 Uma implementao de padro de estado para a Figura 10.1.

Fl-- --------------------------------
 CAPTULO 10: IAGRAMAS DE MQUINA DE ESTADOS 117

ONDE ENCONTRAR
-
MAIS INFORMAOES

Tanto o User Guide [Booch, UML user] como o Reference Manual [Rumbaugh, UML
Reference] tm mais informaes sobre diagramas de estados. Os projetistas de tempo
real tendem a usar muito os modelos de estado; portanto, no de surpreender que
[Douglass] tenha muito a dizer sobre diagramas de estados, incluindo informaes sobre
como implement-los. [Martin] contm um captulo muito bom sobre as vrias manei
ras de implementar diagramas de estados.

 Captulo 11

iagramas de Atividades

Os diagramas de atividades so uma tcnica para descrever lgica de procedimen

to, processo de negcio e fluxo de trabalho. De vrias formas, eles desempenham um
papel semelhante aos fluxogramas, mas a principal diferena entre eles e a notao de
fluxograma que os diagramas suportam comportamento paralelo.
Os diagramas de atividades tm recebido as maiores modificaes nas diversas ver
ses da UML; portanto, no surpreende que renham sido significativamente estendidos
e novamente alterados para a UML 2. Na UML 1, os diagramas de atividades eram
.
J vistos como casos especiais dos diagramas de estados. Isso causou muitos problemas para
os modeladores de fluxos de trabalho, para os quais os diagramas de atividades eram
muito convenientes. Na UML 2, esse vnculo foi eliminado.
A Figura 11.1 mostra um exemplo simples de diagrama de atividades. Comeamos
na ao do n inicial e depois executamos a ao Receber Pedido. Unia vez feito isso,
encontramos uma separao. Uma separao tem um fluxo de entrada e vrios fluxos
concorrentes de sada.
A Figura 11.1 diz que Preencher Pedido, Enviar Fatura e as aes subseqentes
ocorrem em paralelo. Basicamente, isso significa que a seqncia entre elas irrelevante.
Eu poderia preencher o pedido, enviar a fatura, entregar e depois receber o pagamento;
ou ento, poderia enviar a fatura, receber o pagamento, preencher o pedido e depois
entregar: voc entende a situao.
Essas atividades tambm podem ser executadas intercaladamenre. Por exemplo,
pego o primeiro item de linha do depsito, escrevo a fatura, pego o segundo item de
linha, coloco a fatura em um envelope e assim por diante. Ou ento, poderia fazer algu
ma dessas coisas simultaneamente: escrever a fatura com uma das mos, enquanto pego
o prximo item com a outra. Qualquer uma dessas seqncias est correta, de acordo
com o diagrama.
O diagrama de atividades permite que quem est seguindo o processo escolha a
ordem na qual fazer as coisas. Em outras palavras, ele simplesmente determina as
regras essenciais de seqncia que se deve seguir. Isso importante para modelagem
de negcios, pois os processos freqentemente ocorrem em paralelo. Isso tambm
til para algoritmos concorrentes, nos quais linhas de execuo independentes po
dem fazer coisas em paralelo.
Quando voc tem comportamento paralelo, precisa sincronizar. No fechamos um
pedido at que ele seja entregue e pago. Mostramos isso com a juno, antes da ao
Fechar Pedido. Com uma juno, o fluxo de sada executado somente quando todos os
fluxos de entrada chegarem juno. Assim, voc somente pode fechar o pedido quando
tiver recebido o pagamento e entregue o pedido.
 CAPTULO 11: DIAGRAMAS DE ATIVIDADES 119

n inicial
Receber
Pedido

separaao - . -
aao

Preerncher
.Peeido
Enviar Fatura

deciso

[ordem de prioridade] fluxo/aresta

[else]

Entrega no Entrega
Dia seguinte Normal Receber
Pagamento

intercalao
.. .,, .:. ' .
. ...
juno

Fechar
Pedido

atividade final

FIGURA 11.1 Um diagrama de atividades simples.

A UML 1 tinha regras particulares para harmonizar separaes e junes, pois os

diagramas de atividades eram casos especiais dos diagramas de estados. Na UML 2, tal
harmonizao no mais necessria.
Voc notar que os ns em um diagrama de atividades so chamados de aes e no
de atividades. Rigorosamente falando, uma atividade se refere a uma seqncia de aes;
portanto, o diagrama mostra uma atividade constituda de aes. .
O comportamento condicional delineado por decises e intercalaes. Uma de
ciso, denominada desvio na UML 1, tem um nico fluxo de entrada e vrios fluxos de
sada vigiados. Cada fluxo de sada tem uma sentinela: uma condio booleana colocada
entre colchetes. Sempre que voc chega em uma deciso, pode seguir apenas um dos
fluxos de sada, de modo que as sentinelas devem ser mutuamente exclusivas. A utiliza-

 120 UML ESSENCIAL

o de [else] como sentinela indica que o fluxo [else] deve ser usado, caso todas as
outras sentinelas da deciso sejam falsas.
Na Figura 11.1, depois que um pedido preenchido, h uma deciso. Se voc tiver
um pedido urgente, far uma Entrega no Dia Seguinte; caso contrrio, far uma Entrega
Normal.
Uma intercalao tem vrios fluxos de entrada e uma nica sada. Uma inter
calao marca o final de um comportamento condicional iniciado por uma dcci-
-
sao.
Em meus diagramas, cada ao tem um nico fluxo de entrada e um nico fluxo de
sada. Na UML l, mltiplos fluxos de entrada tinham uma intercalao implcita. Isto ,
sua ao seria executada se qualquer fluxo fosse disparado. Na UML 2, isso mudou, de
modo que, em vez disso, h uma juno implcita; assim, a ao executada somente se
todos os fluxos dispararem. Como resultado dessa mudana, recomendo que voc use
apenas um fluxo de entrada e um fluxo de sada para uma ao e mostre todas as junes
e intercalaes explicitamente; isso evitar confuso.

COMO DECOMPOR
-
UMA AAO

As aes podem ser decompostas em sub-atividades. Posso pegar a lgica de entrega da

.
J
Figt1ra 11.1 e defini-la como sua prpria atividade (Figura 11.2). Ento, posso cham-la
como uma ao (Figura 11.3, na pgina 121).
As aes podem ser implementadas como sub-atividades ou como mtodos nas
classes. Voc pode mostrar uma sub-atividade utilizando o smbolo de ancinho. Uma
chamada de mtodo pode ser mostrada com a sintaxe nome-da-classe:: nome-do-mtodo.
Voc tambm pode escrever um fragmento de cdigo no smbolo de ao, se o compor
tamento executado no for uma nica chamada de mtodo.

-
PARTIOES

Os diagramas de atividades dizem o que acontece, mas no dizem quem faz o que. Em
programao, isso significa que o diagrama no comunica qual classe responsvel por

cada ao. Na modelagem do processo de negcio, isso no comunica qual parte de uma
organizao executa qual ao. Isso no necessariamente um problema; freqentemen

te, faz sentido se concentrar no que feito, em vez de em quem realiza quais partes do
comportamento.
Se voc quiser mostrar quem faz o que, pode dividir um diagrama de atividades em

parties, que mostram quais aes uma classe ou unidade da organizao executa. A
Figura 11.4 (na pgina 122) tem um exemplo simples disso, mostrando como as
aes envolvidas no processamento do pedido podem ser separadas entre vrios de
' partamentos .
O particionamento da Figura 11.4 unidimensional simples. Esse estilo freqen

temen te referido como raias de piscina, por motivos bvios, e era a nica forma usada na
UML l .x. Na UML 2, voc pode usar uma grade bidimensional; portanto, a metfora
da raia de piscina no vale mais. Voc tambm pode pegar cada dimenso e dividir as
linhas e colunas hierarquicamente.
 CAPTULO 11: DIAGRAMAS DE ATIVIDADES 121

nome da atividade

/
' .

Entregar Pedido / ...

.;. Entrega Normal

,,
[else]
'

Pedido - Pedido

[Pedido Urgente]
~
/
'
Entrega no Dia
Seguinte A

p armetro parametr o
d e entrada ' ~
de sada

,,
'"
FIGURA 11.2 Um diagrama de atividades auxiliar.

Receber
Pedido

chamada de
mtodo

Preencher Enviar Fatura

Pedido (Pedido: :enviarFatu ra)
o ancinho indica
diagrama de sub
atividade

Entregar Receber
rh Pedido Pagamento

Fechar
Pedido

FIGURA 11.3 A atividade da Figura 11.1, modifi

D cada para executar a atividade da Figura 11.2.

 122 UML ESSENCIAL

Execuo Servio de Atendi Departamento

mento ao Cliente Financeiro

Receber
Pedido

Preencher Enviar
Pedido Fatura

Entregar Receber
Pedido Pagamento

' '
Fechar
Pedido

FIGURA 11.4 Parties em um diagrama de atividades.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SINAIS

No exemplo simples da Figura 11.1, os diagramas de atividades tm um ponto de parti

da claramente definido, que corresponde a uma chamada de um programa ou de uma
rotina. As aes tambm podem responder a sinais.

Um sinal de tempo ocorre devido passagem do tempo. Tais sinais poderiam
indicar o final de um ms em um perodo financeiro ou cada microssegundo em um
controlador de tempo real.
A Figura 11.5 mostra uma atividade que espera receber dois sinais. Um sinal indica

que a atividade recebe um evento de um processo externo. Isso indica que a atividade
capta esses sinais constantemente, e o diagrama define como a atividade reage.
No caso da Figura 11. 5, duas horas antes de meu vo sair, preciso comear a fazer
minhas malas. Se eu for rpido ao faz-las, ainda no posso sair enquanto o txi no
chegar. Se o txi chegar antes de minhas malas estarem prontas, ele precisar esperar que
eu termine, antes de sairmos.
 CAPTULO 11: DIAGRAMAS DE ATIVIDADES 123

sinal de tempo

Empacotar
Malas

Duas horas Sair para o

antes do vo Aeroporto

Chegada
do Txi

,. ,. sinal de reconhecimento

FIGURA 11.5 Sinais em um diagrama de atividades.

Assim como podemos aceitar sinais, tambm podemos envi-los. Isso til quan
do precisamos enviar uma mensagem e depois esperar pela resposta, antes de podermos
continuar. A Figura 11.6 mostra um bom exemplo disso, com um jargo comum da
temporizao. Note que os dois fluxos esto em uma disputa: o primeiro a chegar ao
estado final vencer e terminar o outro fluxo.
Embora os reconhecimentos normalmente sejam apenas esperar por um evento
externo, tambm podemos mostrar um fluxo em sua direo. Isso indica que no come
amos a captar at que o fluxo dispare o reconhecimento.

TOKENS

Se voc for suficientemente audaz para se aventurar nas profundezas demonacas da

especificao da UML, ver que a seo sobre atividades fala muito sobre tokens e sua
produo e consumo. O n inicial cria um token, o qual passado para a prxima ao,
que executada e depois passa o token para a seguinte. Em uma separao, um token
entra e a separao produz um token em cada um de seus fluxos de sada. Inversamente,

Reservar
sinal de
Itinerrio
reconhecimento

.... .,,

Itinerrio Contratar
Enviar Itinerrio Confirmado Itinerrio

D
Cancelar
Itinerrio
sinal de envio
i
I
Esperar 48 horas
'
FIGURA 11.6 Enviando e recebendo sinais.

'

. .,

124 UML ESSENCIAL

em uma juno, quando cada token de entrada chega, nada acontece at que todos os
tokens apaream na juno; ento, um token produzido no fluxo de sada.
Voc pode visualizar os tokens com moedas ou contadores se movendo pelo diagra
ma. Quando voc v exemplos mais complicados de diagramas de atividades, os tokens
freqentemente tornam mais fcil visualizar as coisas.

FLUXOS E ARESTAS

A UML 2 utiliza os termos fluxo e aresta como sinnimos para descrever as conexes entre
duas aes. O tipo mais simples de aresta a seta simples entre duas aes. Se voc
quiser, pode dar um nome a uma aresta, mas na maioria das vezes uma seta simples bastar.
Se voc estiver com dificuldade para traar o caminho das linhas, pode usar conec
tores, que simplesmente evitam o desenho de uma linha pela distncia inteira. Quando
voc usa conectores, deve faz-lo em pares: um com o fluxo de entrada, outro com um
fluxo de sada e ambos com o mesmo rtulo. Se possvel, eu tento evirar o uso de conec
tores, pois eles confundem a visualizao do fluxo de controle.
As arestas mais simples passam um token que no tem outro significado a no ser
controlar o fluxo. Entretanto, voc tambm pode passar objetos atravs das arestas; os
objetos desempenham, ento, o papel de tokens, assim como transportam dados. Se voc
estiver passando um objeto atravs de uma aresta, pode mostrar isso colocando uma
caixa de classe na aresta ou usar pinos nas aes, embora os pinos impliquem mais algu
mas sutilezas, que descreverei em breve.
Todos os estilos mostrados na Figura 11. 7 so equivalentes; voc deve usar o que trans
mitir melhor o que est tentando comunicar. Na maioria das vezes, a seta simples suficiente.

-r-----------------------------------
-
PINOS E TRANSFORMAOES

As aes podem ter parmetros, exatamente como acontece com os mtodos. Voc no
precisa mostrar informaes sobre parmetros no diagrama de atividades, mas, se quiser,

Receber Fazer
Fatura - Pagamento

conector

Receber Fazer
Fatura
A A .;;.
Pagamento
.-. n de objeto

Receber
Fatura
Pedido -- Fazer
Pagamento

. Pedido
Receber ]. Fazer
~
Fatura Pedido Pagamento

FIGURA 11.7 Quatro maneiras de mostrar uma aresta.

 CAPTULO 11: IAGRAMAS DE ATIVIDADES 125

pode mostr-los com pinos. Se voc estiver decompondo uma ao, os pinos correspon
dem s caixas de parmetro no diagrama decomposto.
Quando voc est desenhando rigorosamente um diagrama de atividades, precisa

certificar-se de que os parmetros de sada de uma ao de sada correspondam aos par

metros de entrada de outra. Se eles no corresponderem, voc pode indicar uma trans
formao (Figura 11.8) para ir de um para outro. A transformao deve ser uma expres
so isenta de efeitos colaterais: basicamente, uma consulta sobre o pino de sada que
fornece um objeto do tipo correto para o pino de entrada.
Voc no precisa mostrar pinos em um diagrama de atividades. Eles so mais indi

cados quando voc quer ver os dados necessrios e produzidos pelas vrias aes. Na

modelagem de processo de negcio, voc pode usar pinos para mostrar os recursos pro

duzidos e consumidos por aes.

Se voc usa pinos, seguro mostrar vrios fluxos entrando na mesma ao. A nota
o de pino refora a juno implcita, e a UML 1 no tinha pinos; portanto, no h
confuso com as suposies anteriores.

Cancelar
Consulta

Co ns uIta , :
.. .. .
..
. A
pino para parametro

transformation
consulta.avisodeCancelamento - - -- --- -- transformation
consulta.paciente
"

Mensage m Pa ciente

Notificar Paciente
expresso de
transformao

FIGURA 11.8 Transformao em um fluxo.

-REGIOES
- DE EXPANSAO
-
Com os diagramas de atividades, voc freqentemente se depara com situaes em que a
sada de uma ao dispara mltiplas execues de outra. Existem vrias maneiras de
mostrar isso, mas a melhor usar uma regio de expanso. Uma regio de expanso
marca uma rea do diagrama de atividades onde as aes ocorrem uma vez para cada
item de uma coleo.
Na Figura 11.9, a ao Escolher Tpicos gera uma lista de tpicos como sada.
Cada elemento dessa lista se torna, ento, um token de entrada para a ao Escrever
Artigo. Analogamente, cada ao Examinar Artigo gera um nico artigo, que adiciona
do lista de sada da regio de expanso. Quar1d) todos os tokens da regio de expanso
acabam na coleo de sada, a regio gera um nico token para a lista, que passado para
Publicar Boletim.

 . .,

126 UML ESSENCIAL

Escolher
Tpicos
regio de
.. ,
expanso
palavra-chave
lista de tpicos

/
_.,.-- --CJ!D- - -
.;,,

- -,
I concurrent I
I Escrever Examinar Publicar
Artigo Artigo Boletim
I
I , , .
, /
pino da caixa de lista
FIGURA 11.9 Regio de expanso.

Neste caso, voc tem o mesmo nmero de itens na coleo de sada e na coleo de
entrada. Entretanto, voc poderia ter menos, caso em que a regio de expanso atuaria
como um filtro.
Na Figura 11.9, todos os artigos so escritos e examinados em paralelo, o que
marcado pela palavra-chave concurrent. Voc tambm pode ter uma regio de expan-
so iterativa. As regies iterativas devem processar completamente cada elemento de
entrada, um por vez.
Se voc tem apenas uma ao que precisa de chamada mltipla, use a abreviao da
Figura 11.1 O. A abreviao assume expanso concorrente, pois essa a mais comum.
Essa notao corresponde ao conceito de concorrncia dinmica da UML 1.

Escolher
Tpicos Preparar Artigo Publicar Boletim

FIGURA 11.1 O Abreviao para uma nica ao em uma regio de expanso.

~,-----------------------------------~
FINAL DE FLUXO

Quando voc tem mltiplos tokens, como em uma regio de expanso, freqentemente voc
tem fluxos que param mesmo quando a atividade como um todo no termina. Um final de
fluxo indica o trmino de um fluxo em particular, sem terminar a atividade inteira.
A Figura 11.11 mostra isso por meio de uma modificao do exemplo da Figu
ra 11.9, para permitir que artigos sejam rejeitados. Se um artigo rejeitado, o token
destrudo pelo final de fluxo. Ao contrrio de um final de atividade, o restante da
atividade pode continuar. Essa estratgia permite que as regies de expanso atuem
como filtros, por meio dos quais a coleo de sada fica menor do que a coleo de
entrada.
 CAPl'ULO 11: [AGRAMAS DE ATIVIDADES 127

Escolher
Tpicos

lista de tpicos
concurrent

Escrever Artigo Avaliar Artigo

Publicar Boletim
[rejeio]
final de fluxo
. - - -----
-.-, ' -
.. ...

FIGURA 11.11 Finais de fluxo em uma atividade.

-
ESPECIFICAOES
-
DE JUNAO

Por padro, uma juno permite que a execuo passe por seu fluxo de sada quando
todos os seus fluxos de entrada tiverem chegado nela. (Ou, em uma linguagem mais
formal, ela emite um token em seu fluxo de sada, quando um token tiver chegado em
cada fluxo de entrada.) Em alguns casos, particularmente quando voc tem um fluxo
com mltiplos tokens, interessante ter uma regra mais complicada.
Uma especificao de juno uma expresso booleana ligada a uma juno. Sem
pre que um token chega juno, a especificao da juno avaliada e, se for verdadeira,
um token de sada emitido. Assim, na Figura 11.12, quando seleciono uma bebida ou
insiro uma moeda, a mquina avalia a especificao de juno. A mquina satisfaz meu
desejo somente se eu tiver colocado dinheiro suficiente. Se, como neste caso, voc quiser

Selecionar
Bebida A
Entregar
Bebida
Inserir B
Moeda
{especJuno = A e B e valor das moedas
inseridas >= preo da bebida selecionada}

especificao de juno FIGURA 11.12 Especificao de juno.

'
128 UML ESSENCIAL

indicar que recebeu um token en1 cada fluxo de entrada, rotule os fluxos e os inclu
especificao de juno.

--------------------------------
,
E HA MAIS
Devo salientar que este captulo apenas toca a superfcie dos diagramas de atividades.
como para grande parte da UML, voc poderia escrever um livro inteiro apenas sobr
tcnica. Na verdade, acho que os diagramas de atividades se constituiriam em um as
muito conveniente para um livro que entrasse realmente a fundo na notao e como
A questo fundamental se seu uso seria difundido. Os diagramas de ativi
no so a tcnica da UML mais amplamente utilizada no momento, e seus progen
de modelagem de fluxo tambm no eram muito usados. As tcnicas de diagram
ainda no se tornaram muito populares para descrever comportamento dessa ma
Por outro lado, existem sinais em vrias comunidades de uma demanda reprimid
uma tcnica padro ajudaria a satisfazer.

---------------------------------
QUAND O UTILIZAR DIAGRAMAS DE ATIVIDADES

A maior qualidade dos diagramas de atividades est no fato de que eles supo
estimulam o comportamento paralelo. Isso os torna uma excelente ferramenta pa
. delagen1 de fluxos de trabalho e de processos. Na verdade, grande parte do ava
UML 2 devido s pessoas envolvidas com fluxo de trabalho.
Voc tambm pode usar um diagrama de atividades como um fluxograma
tvel com a UML. Embora isso permita fazer fluxogramas nos moldes da UML,
trata de algo muito interessante. Em princpio, voc pode usufruir das vantage
separaes e junes para descrever algoritmos paralelos para programas concor
Embora eu no participe de grupos que trabalhem com programao concorren
tenho visto muitas evidncias de pessoas os utilizando nisso. Acho que o motivo
grande parte da complexidade da programao concorrente evitar a disputa de
e os diagramas de atividades no ajudam muito nesse sentido.
A principal vantagem de fazer isso pode ser para pessoas que usam a UML
linguagem de programao. Nesse caso, os diagramas de atividades representa
tcnica importante para representar lgica comportamental.
Freqentemente, tenho visto diagramas de atividades utilizados para descr
caso de uso. O perigo dessa estratgia que, muitas vezes, os especialistas no
no os acompanham facilmente. Se assim for, melhor usar a forma textual no

--.-------------------------------
ONDE ENCONTRAR MAIS INFORMAES

Embora os diagramas de atividades sempre tenham sido bastante complicados

ainda mais na UML 2, nunca houve um bom livro que os descrevesse com pro
de. Espero que essa lacuna seja preenchida algum dia.
Vrias tcnicas orientadas a fluxos tm estilo semelhante aos diagramas d
des. Uma das melhores - mas dificilmente conhecida - so as Redes Petri, para
o endereo http://www.daimi.au.dk!PetriNets/ uma boa pgina na Web.
 12

Captulo

iagramas de Comunicao

Os diagramas de comunicao, um tipo de diagrama de interao, enfatiza os

vnculos de dados entre os vrios participantes na interao. Em vez de desenhar
cada participante como uma linha de vida e mostrar a seqncia de mensagens por
meio da direo vertical, como fazem os diagramas de seqncia, o diagrama de
comunicao permite livre posicionamento dos participantes, permite desenhar vn
culos para mostrar como eles se conectam e usa numerao para mostrar a seqncia
de mensagens.
Na UML l .x, esses diagramas eram chamados de diagramas de colaborao. Esse
nome pegou bem e suspeito que as pessoas demoraro algum tempo para se acostumar
com o novo nome. (Eles so diferentes das Colaboraes [pgina 143]; da a mudana de
nome.)
A Figura 12.1 mostra um diagrama de comunicao para a mesma interao de
controle centralizado da Figura 4.2. Com um diagrama de comunicao, podemos mos
trar como os participantes esto vinculados.
'
Assim como mostrar vnculos que so instncias de associaes, podemos mostrar
tambm vnculos transitrios, que surgem somente no contexto da interao. Neste caso,


'
o vnculo Local de Pedido para Produto uma varivel local; outros vnculos transit
'
rios so par amet er e Loca l. Essas palavras-chave eram usadas na UML 1, mas esto
ausentes na UML 2. Como elas so teis, espero que permaneam em uso convencional.
O estilo de numerao da Figura 12.1 simples e comumente usado, mas na ver
dade no vlido na UML. Para estar de acordo com a UML, voc precisa usar um
esquema de numerao decimal aninhada, como na Figura 12.2.
O motivo para os nmeros decimais aninhados resolver a ambiguidade com as
autochamadas. Na Figura 4.2, voc pode ver claramente que obterinformaodeDescon
to chamado dentro do mtodo calcularDesconto. Com a numerao simples da Figu
ra 12.1, entretanto, voc no pode identificar se obterinformaodeDesconto chamado
'
'
dentro de calcularDesconto ou dentro do mtodo global calcular Preo. O esquema de
'
numerao aninhada resolve esse problema.
Apesar de sua ilegalidade, muitas pessoas preferem um esquema de numerao
simples. Os nmeros aninhados podem ficar muito confusos, particularmente quando
as chamadas ficam aninhadas demais, levando a nmeros de sequncia como 1.1.1.2.1.1.
Nesses casos, a cura da ambiguidade pode ser pior do que a doena.
Assim como nmeros, voc tambm pode ver letras nas mensagens; essas letras
indicam diferentes linhas de execuo de controle. Assim, as mensagens A5 e B2
estariam em diferentes linhas de execuo; as mensagens 1 al e 1 b 1 seriam diferentes
linhas de execuo aninhadas dentro da mensagem 1. Voc tambm v letras de linha

130 UML ESSENCIAL

I
no-
autovnculo .. , .. normativo
.
.,, " . ,,".. ,-....
.

1: calcularPreo
7: obterlnformao
deDesconto
5: calcularPreoBase()
um Pedido
> um Cliente
6: calcularDescontos()

tipo de vnculo
2: obterQuantidade() transitrio
3: obterProduto()
local

uma Linha do um Produto

Pedido

FIGURA 12.1 Diagrama de comunicao para controle centralizado.

1: calcularPreo
1.5.1: obterlnformao
deDesconto
1.4: calcularPreoBase()
1.5: calcularDescontos() um Pedido
> um Cliente

1.1: obterQuantidade()
1.2: obterProduto()

uma Linha do
um Produto
Pedido

FIGURA 12.2 Diagrama de comunicao com numerao decimal aninhada.

de execuo em diagramas de seqncia, embora isso no transmita visualmente a con-

A
correncia.
Os diagramas de comunicao no tm qualquer notao precisa para lgica de contro-
le. Eles permitem que voc use marcadores de iterao e sentinelas (pgina 72), mas no
permitem especificar totalmente a lgica de controle. No h nenhuma notao especial para
criar ou destruir objetos, mas as palavras-chave create e del et.e so convenes comuns.

QUANDO USAR DIAGRAMAS

-
DE COMUNICAAO

A principal questo com os diagramas de comunicao quando us-los em lugar dos

diagramas de seqncia, mais comuns. Grande parte da deciso questo de preferncia
 CAPTULO 12: DIAGRAMAS DE COMUNICAO 131

pessoal: algumas pessoas gostam mais de um do que de outro. Freqentemente, isso

direciona a escolha mais do que tudo. Em geral, a maioria das pessoas parece preferir os
diagramas de seqncia e, pelo menos uma vez, estou com a maioria.
Uma abordagem mais racional diz que os diagramas de seqncia so melhores
quando voc quer salientar a seqncia de chamadas e que os diagramas de comunicao
so melhores quando quer salientar os vnculos. Muitas pessoas acham que os diagramas
de comunicao so mais fceis de alterar em um quadro branco, de modo que eles so
uma boa estratgia para explorar alternativas, embora nesses casos, eu freqentemente
prefira os cartes CRC.

-_. '-'
 .. '

Captulo 13

struturas Compostas

Um dos recursos novos mais significativos da UML 2 a capacidade de decompor

hierarquicamente uma classe em uma estrutura interna. Isso permite que voc pegue um
objeto complexo e divida-o em partes.
A Figura 13. l mostra uma classe Visualizador de TV com suas interfaces forneci
das e exigidas (pgina 69). Mostrei isso de duas maneiras: usando a notao de bola-e
soquete e listando-as internamente.
A Figura 13.2 mostra como essa classe decomposta internamente em duas partes
e quais partes suportam e exigem as diferentes interfaces. Cada parte tem um nome da
forma nome: classe, com os dois elementos individualmente opcionais. As partes no
so especificaes de instncia, de modo que aparecem em negrito e no sublinhadas.
Voc pode mostrar quantas instncias de uma parte esto presentes. A Figura 13.2
informa que cada Visualizador de TV contm uma parte geradora e uma parte de con
troles.
Para mostrar uma parte implementando uma interface, voc desenha um conector
de delegao a partir dessa interface. Similarmente, para mostrar que a parte necessita de
uma interface, voc mostra um corretor de delegao para a interface. Voc tambm
pode mostrar conectores entre as partes com uma linha simples, conforme fiz aqui, ou
com notao de bola-e-soquete (pgina 82).
Voc pode adicionar portas (Figura 13.3) estrutura externa. As portas permitem
que voc agrupe as interfaces exigidas e fornecidas em interaes lgicas que um compo
nente possui com o mundo externo .

QUANDO USAR ESTRUTURAS COMPOSTAS

As estruturas compostas so novas na UML 2, embora alguns mtodos mais antigos

tivessem algumas idias semelhantes. Uma boa maneira de pensar a respeito da diferena
entre pacotes e estruturas compostas que os pacotes so um agrupamento em tempo de
compilao, enquanto que as estruturas compostas mostram agrupamentos em tempo

de execuo. Desse modo, elas servem naturalmente para mostrar componentes e como
eles so divididos em partes; assim, grande parte dessa notao usada em diagramas de
componentes .
Con10 as estruturas compostas so novas na UML, muito cedo para dizer o quan
to elas se mostraro eficazes na prtica; muitos membros do comit da UML acham que
esses diagramas se tornaro uma adio muito valiosa.
 CAPfTULO 13: ESTRUTURAS COMPOSTAS 133

IU do controle da TV API do controle da TV

Visualizador de TV

interfaces fornecidas
Visualizador de TV IU do controle da TV
API do controle da TV
sintonia
interfaces exigidas
sintonia
fluxo de imagens tela
tela fluxo de imagens

FIGURA 13.1 Duas maneiras de mostrar um visualizador de TV e suas interfaces.

IU do controle da TV

multiplicidade

Visualizador de
TV

1
parte controles:
ApresentadordeTV

conector de delegao
conector

tela

:Gerador [1]

API do controle da TV

sintonia fluxo de imagens

FIGURA 13.2 Visao interna de um componente (exemplo sugerido por Jim Rumbaugh).

,;
.
.
IU do controle da TV -
- ' ~ tela

'
.
sistema de janelas
sintonia
sintonizador r:
...
Visualizador de TV ,.
...
fluxo de imagens

.....,._. API
porta FIGURA 13.3 Um componente
' 'API do controle da TV com vrias portas.

Captulo 14

iagramas de Componentes

Uma polmica que sempre vai longe na comunidade orientada a objetos a dife
rena existente entre um componente e uma classe regular qualquer. Esse no um
debate que quero estabelecer aqui, mas posso mostrar a notao que a UML utiliza para
distingu- I os.
A UML 1 tinha um smbolo caracterstico para um componente (Figura 14.1). A
UML 2 retirou esse cone, mas permite que voc anote uma caixa de classe com um
cone de aparncia semelhante. Como alternativa, voc pode usar a palavra-chave com
ponerit .
Alm do cone, os componentes no introduzem nenhuma notao que ainda no
tenhamos visto. Os componentes so conectados por meio de interfaces implementadas
e exigidas, freqentemente usando a notao de bola-e-soquete (pgina 71), exatamente
como para diagramas de classes. Voc tambm pode decompor os componentes usando
diagramas de estrutura composta.
A Figura 14.2 mostra um exemplo de diagrama de componentes. Nesse exemplo,
uma caixa registradora pode se conectar com um componente servidor de vendas, usan
do uma interface de mensagens de vendas. Como a rede no confivel, um componen
te fla de mensagens introduzido para que a caixa possa se comunicar com o servidor,
quando a rede estiver ativa, e se comunicar com uma fla, quando a rede estiver desativa
da; a fla se comunicar ento com o servidor, quando a rede se tornar disponvel. Como
resultado, a fla de mensagens fornece a interface de me11sagens de vendas para se comu
nicar com a caixa e exige essa interface para se comunicar com o servidor. O servidor

dividido em dois componentes principais. O processador de transaes implementa a

interface de mensagens de vendas e o driver de contabilidade se comunica com o sistema
de contabilidade.
Conforme eu j disse, a questo do que um componente um assunto de discus-
ses interminveis. Uma das declaraes mais teis que encontrei a seguinte:

Componentes no so uma tecnologia. O pessoal tcnico parece achar isso dificil de

entender. Os componentes dizem como os clientes querem se relacionar com o software.

Eles querem comprar seu software uma pea de cada vez e atualiz-lo, exatamente
como fazem com seus equipamentos estereotnicos. Eles querem que as novas peasfun
cionem transparentemente com aspeas mais antigas e querem atualizar em seu prprio

ritmo, e no de acordo com a programao do fabricante. Eles qzterem misturar e com
binar peas de vrios fabricantes. Essa uma exigncia bastante razovel. apenas
dificil de satisfazer.

Ralph Johnson, http://www.c2.com/cgi/wiki?DoComponentsExist

.
CAPTULO 14: DIAGRAMAS DE Cl\1PONENTES 135
{

O ponto importante que os componentes representam peas que podem ser ad
quiridas e atualizadas independentemente. Como resultado, dividir um sistema em com
'
po11entes tanto uma deciso de marketing quanto uma deciso tcnica, para a qual

[Hohmann] um guia excelente. Tambm um lembrete para tomar cuidado com com
ponentes demasiadamente refinados, pois tendo-se componentes demais torna-se difcil
gerenciar, especialmente quando o controle de verso mostra sua cabea horrenda; por
isso, o termo "inferno da D LL".
Nas verses anteriores da UML, os componentes eram usados para representar
estruturas fsicas, como as DLLs. Isso no mais verdade; para essa tarefa, agora voc usa
artefatos (pgina 97).

QUANDO USAR DIAGRAMAS DE COMPONENTES

Use diagramas de componentes quando voc estiver dividindo seu sistema em compo

nentes e quiser mostrar seus relacionamentos por intermdio de interfaces ou a decom
\.
posio de componentes em uma estrutura de nvel mais baixo .

i I

Elemento de ~

Elemento
janela
I
de janela

I Notao da UML 2
Notao da UML 1
FIGURA 14.1 Notao para componentes.

~
Caixa

Servidor de Vendas ~

,
mensagem
de vendas ~ ~

"

- -- - - Processador de Driver de
Transaes Contabilidade

I
~
I
Fila de
Mensagens
-T
~

Sistema de
Contabilidade

FIGURA 14.2 Um exemplo de diagrama de componentes .

 Captulo 15

alabo raes

Ao contrrio dos outros captulos deste livro, este no corresponde a um diagrama

oficial da UML 2. O padro discute colaboraes como parte de estruturas compostas,
mas o diagrama bastante diferente e foi usado na UML 1 sem qualquer vnculo com as
estruturas compostas. Assim, achei melhor discutir as colaboraes em seu prprio cap
tulo.
Vamos considerar a noo de leilo. Em qualquer leilo, devemos ter um vendedor,
alguns compradores, lotes de mercadorias e algumas ofertas para a venda. Podemos des
crever esses elem en tos em termos de um diagrama de classes (Figura 15 .1) e, talvez,
alguns diagramas de interao (Figura 15.2).
A Figura 15.1 no um diagrama de classes normal. Para comear, o diagrama est
circundado pela elipse tracejada, que representa a colaborao leilo. Segundo, as assim
chamadas classes na colaborao no so classes propriamente ditas, mas papis que
sero desempenhados quando a colaborao for aplicada - da o fato de seus nomes no
iniciarem por letras maisculas. No incomum ver interfaces reais ou classes que cor
respondam aos papis da colaborao, mas voc no precisa t-las.

> -- ---- -- ..............

...- Leilo ......

/
_ / ' '
''
/

I
/ '\
I \
I \

I I
\ co I
\ I

\ I
' I
'' /
/

' -......
......... /
/ /

--- -- ---
FIGURA 15.1 Uma colaborao com seu diagrama de classes de papis.
 l CAPTULO 15: COLABORAES 137
\

I
I /vendedor c1 /comprador c2/comprador
J_:-
1

I
! I

anunciar lote
I
I
I
I
I I I
I
I I
l. I I
I I
I fazer oferta I I
r
I I
I I
j__ I I
I
fazer oferta
'' I
) ' I
aceitar oferta I

I
I
.i ' I I
;
I rejeitar oferta I
( I I
i I I
iI I I I
I I I

FIGURA 15.2 Um diagrama de seqncia para a colaborao leilo.

,
1- No diagrama de interao, os participantes so rotulados de modo ligeiramente
diferente do caso normal. Em uma colaborao, o esquema de atribuio de nomes
nome-do-participante I nome-do-papel: nome-da-classe. Como sempre, todos esses
elementos so opcionais.

Quando voc usa uma colaborao, pode mostrar isso colocando uma ocorrncia
''
de colaborao em um diagrama de classes, como na Figura 15.3, um diagrama de aigu-

I

I
' * Lance
Oferta

'.
'
\
* \
\ ligao de papis

\
eomprador 1 1 \
I
vendedor \
Sujeito Casa
* * \
- \
' comprador, vendedor - - _ _ lote , ....._ \

........._...L_
-
---
-- - \
<,
/
Leilo
.......
\

ocorrncia de
' - /
J
colaborao

FIGURA 15.3 Uma ocorrncia de colaborao.

, ......

(
 ., .~ .

138 UML ESSENCIAL

mas das classes da aplicao. Os vnculos da colaborao para essas classes indicam como
as classes desempenham os vrios papis definidos na colaborao.
A UML sugere que voc pode usar a notao de ocorrncia de colaborao para
mostrar o uso de padres, mas dificilmente os autores de padres tm feito isso.
Erich Gamma desenvolveu uma excelente notao alternativa (Figura 15 .4). Os ele
mentos do diagrama so rotulados com o nome do padro ou com uma combinao
de padro:papel.

Composite: Componente Test testes

run(TestResult) *

r---------J.- -------- -1
I I
I I
I I

Testease TestSuite

name
run(TestResult)
. . } run(TestResult)
ru Test()
setUp()
tearDown()
-
nao-
. normativo

Composite: Folha

FIGURA 15.4 Uma maneira no-padronizada de mostrar o uso de padres em JUnit Gunit.org).

-
QUANDOUSARCOLABORAOES

As colaboraes j existem desde a UMl_ 1, mas admito que dificilmente as tenho utili
zado, mesrno quando escrevo sobre padres. As colaboraes fornecem uma maneira de
agrupar trechos de comportamento de interao, quando os papis so desempenhados

por classes diferentes. Na prtica, entretanto, no considero que eles sejam um tipo de
diagrama atraente .


I
I'
I

1 I
I
Captulo 16

,-.
iagramas de Viso
i
(


Geral da Interao
1
!
l
!
I

Os diagramas de viso geral da interao so uma mistura de diagramas de ativida

des e diagramas de seqncia. Voc pode considerar os diagramas de viso geral da inte
i
rao como diagramas de atividades nos quais as atividades so substitudas por peque
I
.nos diagramas de seqncia ou como um diagrama de sequncia fragmentado, com a
II notao de diagrama de atividades usada para mostrar o fluxo de controle. De qualquer
l
II modo, eles fazem uma mistura bastante estranha.
I

'
A Figura 16.1 mostra um exemplo de diagrama simples; a notao conhecida, a
'

partir do que voc j viu nos captulos sobre diagramas de atividades e sobre diagramas
''
de seqncia. Nesse diagrama, queremos produzir e formatar um relatrio de resumo de
' pedidos. Se o cliente externo, obtemos as informaes em XML; se interno, as obte
mos de um banco de dados. Pequenos diagramas de seqncia mostram as duas alterna
tivas. Quando obtemos os dados, formatamos o relatrio; neste caso, no mostramos o
< diagrama de seqncia, mas simplesmente fazemos referncia a ele com um quadro de
'
interao de referncia.

QUANDO USAR DIAGRAMAS

-
DE VISAO GERAL
-
DA INTERAAO

l Esses diagramas so novos na UML 2 e cedo demais para se ter uma idia de como eles
'' funcionaro na prtica. No gosto muito deles, pois acho que eles misturam dois estilos
que no se encaixam muito bem. Desenhe um diagrama de atividades ou use um diagra
ma de seqncia, dependendo do que melhor atender seu propsito.

' '

'
I

(
I

'

140 UML ESSENCIAL

[dados externos] [dados internos]

ds ds

:Analisador :Banco de
:Cliente :Cliente
deXml dados

carregar selecionar clielntes e pedidos

I I
I I I
I analisar
novo :Resumo
do Pedido
I i.... I

I I
I obterNome I
I I
I obterPedidos I
I
I
I
I
novo :Resumo
do Pedido
I I

ref
Formatar Relatrio de Resumo
do Pedido

D
FIGURA 16.1 Diagrama de resumo de interao.
 Captulo 17
,
I
'

iagramas de Temporizao
I
\

Aps sair da escola secundria, comecei. a fazer engenharia eletrnica, antes de

mudar para a computao. Assim, sinto certa familiaridade angustiosa quando vejo a
UML definir diagramas de temporizao como um de seus diagramas padro. Os dia
I gramas de temporizao existem na engenharia eletrnica h muito tempo e parecem
nunca ter precisado da ajuda da UML para definir seu significado. Mas como eles esto
na UML, merecem uma breve meno.
Os diagramas de temporizao so outra forma de diagrama de interao, nos quais
'
j o foco est nas restries de temporizao: ou para um nico objeto ou, de forma mais
til, para vrios. Vamos considerar um cenrio simples, baseado na bomba e na chapa
eltrica de uma cafeteira. Vamos imaginar uma regra que diga que pelo menos 1 O segun
+
dos devem passar entre o acionamento da bomba e o aquecimento da chapa. Quando o
reservatrio de gua se esvazia, a bomba desliga, e a chapa no pode permanecer ligada
i por mais de 15 minutos depois disso.
As figuras 17.1 e 17.2 so maneiras alternativas de mostrar essas restries de tem
" porizao. Os dois diagramas mostram a mesma informao bsica. A principal diferen
a que a Figura 17.1 mostra as mudanas de estado, movendo-se de uma linha horizon

tal para outra, enquanto a Figura 17.2 mantm a mesma posio horizontal, mas mostra
as mudanas de estado com uma cruz. O estilo da Figura 17 .1 funciona melhor quando
existem apenas alguns estados, como neste caso, e a Figura 17.2 melhor quando exis
tem muitos estados para se lidar.

(
estado
evento

a, I I semgua
~ Ligada
E
o
I
Desligada --1
I
a, mudana
-...
CJ I
(
--
Q)
w
Ligada
Desligada --1---1
de estado

[
a, ~ ~ < {<15s} >
s: {>10s}
(.)

I objeto
I restrio de temporizao

FIGURA 17.1 Diagrama de temporizao mostrando os estados como linhas.

......
', ,

142 UML ESSENCIAL

mudana de
estado estado

..
evento

I . 1 semgua
.l!l -~----- ~~~~~~~~~~~-
E Desligada Desligada
o
III

m
o
-,...a,
--
w
Desligada Ligada Desligada

{>10s}
I< {<15s}
....
~

...

objeto restrio de temporizao

FIGURA 17.2 Diagrama de temporizao mostrando os estados como reas.

As linhas tracejadas que usei nas restries {> 1 Os} so opcionais. Utilize-as se voc
achar que elas ajudam a esclarecer exatamente quais eventos a temporizao restringe.

QUANDO USAR DIAGRAMAS

-
DE TEMPORIZAAO

Os diagramas de temporizao so teis para mostrar restries de temporizao entr

mudanas de estado em diferentes objetos. Os diagramas so particularmente conheci
dos dos engenheiros de hardware.

------------------


pndice.

(.

odificaes nas
Verses da UML

Quando a primeira edio deste livro foi para as livrarias, a UML estava na verso
1.0. Grande parte dela parecia ter se estabilizado e estava no processo de reconhecimento
pelo OMG. Desde ento, vrias revises tm sido feitas. Neste apndice, descrevo as
( modificaes significativas que ocorreram desde a verso 1.0 e como essas mudanas
afetam o material deste livro.
Este apndice resume as modificaes para que voc possa se manter atualizado, caso
tenha uma edio mais antiga. Fiz alteraes no livro para acompanhar a UML; portan
to, se voc tem uma edio mais antiga, ela descreve a situao na data da publicao:

-
REVISOES NA UML I

(
O lanamento pblico mais antigo do que veio a ser a UML foi a verso 0.8 do Mtodo
Unificado lanado na OOPSLA, em outubro de 1995. Esse foi um trabalho de Booch e
Rumbaugh, pois Jacobson ainda no era membro da Rational naquela poca. Em 1996,
a Rational lanou as verses 0.9 e 0.91, que incluam o trabalho de Jacobson. Depois
I dessa ltima verso, eles mudaram o nome para UML.
A Rational e um grupo de parceiros submeteram a verso 1.0 da UML para a
Analysis and Design Task Force do OMG, em janeiro de 1997. Subseqentemente, a
parceria da Rational e os outros remetentes combinaram seu trabalho e submeteram
uma proposta nica para o padro OMG, em setembro de 1997, da verso 1.1 da UML.
(
Esta foi adotada pelo OMG no final de 1997. Entretanto, devido a uma confuso, o
OMG chamou esse padro de verso 1.0. Ento, a UML era tanto a verso 1.0 do OMG
como a verso 1.1 da Rational, para no ser confudida com a verso 1.0 da Rational. Na
prtica, todos chamam esse padro de verso 1.1.
( Da em diante, houve vrios outros desenvolvimentos na UML. A UML 1.2 apare
ceu em 1998, a 1.3, em 1999, a 1.4, em 2001 e a 1.5, em 2002. A maior parte das
alteraes entre as verses l .x foi muito profunda na UML, exceto quanto UML 1.3, o
que causou algumas mudanas bastante visveis, especialmente nos casos de uso e nos
diagramas de atividades.
( '
A medida que a srie UML 1 continuou, os desenvolvedores da UML se concen-
traram em uma reviso importante na UML, com a verso 2. Os primeiros RFPs (Re
quest for Proposals) foram publicados em 2000, mas a UML 2 no comeou a se estabi
lizar propriamente at 2003.
Desenvolvimentos futuros na UML certamente ocorrero. Normalmente, o UML
Forum (http://uml-forum.com) um bom lugar para procurar mais informaes. Eu

144 UML Essr,NcrAL

' .
tambm mantenho algumas informaes sobre a UML em minha pagina (http://
marrinfowler.com).

MUDANAS NO UML ESSENCIAL

'
A medida que essas revises acontecem, venho tentando acompanh-las, revisando o
livro UML Essencial com impresses subsequentes". Tambm tive a oportunidade de
corrigir erros e fazer esclarecimentos.
O perodo mais dinmico de acompanhamento foi durante a primeira edio do
UML Essencial, quando tnhamos que fazer atualizaes freqentes entre as impresses
para acompanhar o padro UML emergente. UML I .O foi usada corno base da primeira
quinta impresso. As mudanas na UML entre essas impresses foram mnimas. A
sexta impresso levou em considerao a UML 1.1.
Da stima dcima impresso, a UML 1.2 foi usada como base; a dcima-primeira
impresso foi a primeira a usar a UML 1.3. As edies baseadas em verses da UML
posteriores a 1.0 tm o nmero de verso da UML na capa.
A primeira at a sexta impresso da segunda edio foram baseadas na verso 1.3. A
stima impresso foi a primeira a levar em conta as pequenas alteraes da verso 1.4.
A terceira edio foi lanada para atualizar o livro com a UML 2 (veja a Tabela
A.l). No restante deste apndice, fao um resumo das principais mudanas na UML,
das verses 1.0 para 1.1, da 1.2 para 1.3 e da l .x para a 2.0. No discuto todas as
alteraes que ocorreram, mas somente aquelas que mudam algo que eu disse no UML
Essencial ou que representam recursos importantes que eu teria discutido no livro.
Continuo a seguir o esprito do UML Essencial: discutindo os elementos principais
da UML, conforme eles afetam a aplicao de UML em projetos do mundo real. Como
sempre, as escolhas e os conselhos so meus. Se houver algum conflito entre o que eu
digo e os documentos oficiais da UML, os documentos que devem ser seguidos. (Mas
me informem, para que eu possa fazer correes).

TABELA A.1 UML Essencial e verses correspondentes da UML

UML Essencial Verses da UML
1 edio UML 1.0-1.3
2 edio UML 1.3-1.4
3 edio UML 2.0 em diante

Tambm aproveitei a oportunidade para indicar erros e omisses importantes das

edies anteriores. Agradeo aos leitores que me mostraram esses erros .

MUDANAS DA UML 1.0 PARA 1.1

Tipo e Classe de Implementao

Na primeira edio do UML Essencial, abordei perspectivas e como elas alteravam a

maneira como as pessoas desenham e interpretam modelos - particularmente diagramas

* N. dc R.: As reirnpresses a que se refere o autor dizem respeito obra original, publicada nos EUA.
 . APNDICE 145

de classes. Agora, a UML leva isso em considerao, dizendo que todas as classes em um
diagrama de classes podem ser especializadas tanto como tipos quanto como classes de
implementao.
Uma classe de implementao corresponde a uma classe no ambiente de software
no qual voc est programando. Um tipo ainda mais nebuloso; ele representa uma

abstrao no to amarrada implementao. Esse poderia ser um tipo CORBA, uma
perspectiva de especificao de uma classe ou uma perspectiva conceituai. Se necessrio,
voc pode acrescentar esteretipos para diferenciar ainda mais.
Voc pode determinar que, para um diagrama em particular, todas as classes sigam
um esteretipo especfico. Isso o que voc faria ao desenhar um diagrama a partir de
uma perspectiva determinada. A perspectiva de implementao usaria classes de imple
I
mentao, enquanto as perspectivas conceituais e de especificao usariam tipos.
Voc usa o relacionamento de realizao para indicar que uma classe de implemen
tao implementa um ou mais tipos.
Existe uma distino entre tipo e interface. Uma interface tem como objetivo cor
responder diretamente a uma interface de estilo COM ou Java. Portanto, as interfaces s
tm operaes e no atributos.
Voc pode usar somente classificao esttica e simples com classes de implementa
o, mas pode usar classificao dinmica e mltipla com tipos. (Acredito que isso ocor
re porque as linguagens orientadas a objetos mais importantes seguem a classificao
esttica e simples. Se um dia voc usar uma linguagem que suporte classificao dinmi
ca ou mltipla, essa restrio no dever ser aplicada.)

Restries Discriminadoras Completas e Incompletas

(

Nas edies anteriores do UML Essencial, afirmei que uma restrio {complete} em urna
generalizao indicava que todas as instncias do supertipo tambm devem ser uma
instncia de um subtipo dentro dessa partio. Em vez disso, a UML 1.1 define que
(
{complete} indica que todos os subtipos dentro de uma partio foram especificados, o
que no exatamente a mesma coisa. Encontrei alguma inconsistncia na interpretao
dessa restrio; portanto, voc deve ser cauteloso quanto a isso. Se voc quiser indicar que
todas as instncias de um supertipo devem ser uma instncia de um dos subtipos, sugiro o uso
de uma outra restrio para evitar confuso. Atualmente, estou usando {mandatory}.
l

Composio

Na UML 1.0, o uso da composio implicava que o vnculo fosse imutvel (ou frozen),
pelo menos para componentes de valor nico. Essa restrio no faz mais parte da defi-
.
n1ao.-

Imutabilidade e Congelamento

A UML estabelece a restrio {frozen} para definir a imutabilidade em papis de associa

o. Conforme ela est atualmente definida, isso no parece se aplicar a atributos ou a
(
classes. No meu trabalho, uso agora o termo frozen, em vez de imutabilidade, e aplico a
restrio a papis de associaes, classes e atributos.
 . 146 UML ESSENCIAL
:,,'

,i~_:/."'
Retornos em Diagramas de Seqncia \
'.11,,
~:::::..
... ',

}'.t.:.:

Na UML 1.0, um retorno em diagramas de seqncia era diferenciado pelo uso de uma
ponta de seta, em vez de uma seta cheia (veja as edies anteriores). Isso era um pouco
complicado, pois a distino era muito sutil e fcil de passar despercebida. A UML 1.1
usa uma seta tracejada para um retorno, o que me agrada, pois isso torna os retornos
muito mais bvios. (Quando usei retornos tracejados no livro Analysis Patterns [Fowler,
AP], isso tambm me faz parecer influente). Voc pode dar nome ao que retornado
para uso posterior, usando a forma estoqueSuf .i c.ient e i= verificar () .

Uso do Termo ''Papel''

Na UML 1.0, o termo papel indicava, principalmente, uma direo em uma associao
I
(veja as edies anteriores). A UML 1.1 se refere a esse uso como papel de associao.
,.
Existe tambm um papel de colaborao, que o papel que uma instncia de uma classe
desempenha em uma colaborao. A UML 1.1 d muito mais nfase s colaboraes e
I

i
parece que esse uso de papel" pode se tornar o principal.
.II

v. .J l.
... MUDANAS DA UML 1.2 (E 1.1) PARA 1.3 (E 1.5)
..
1.:
I
.
1.
Casos de Uso
Li
.\. '
l'

J
I
I
As mudanas nos casos de uso envolvem novos relacionamentos entre eles. A UML 1.1
i;
r tem dois relacionamentos de caso de uso: uses e extends, sendo os dois esteretipos
I:
de generalizao. A UML 1.3 oferece trs relacionamentos.
I
II
I '

i:

A construo include um esteretipo de dependncia. Isso indica que o
caminho de um caso de uso est includo em um outro. Normalmente, isso
'
'
ocorre quando poucos casos de uso compartilham passos em comum. O caso de
uso includo pode fatorar o comportamento comum. Um exemplo de um Caixa
Automtico poderia ser que tanto Retirar Dinheiro quanto Fazer Transferncia
.. usem Validar Cliente. Isso substitui o uso comum de uses .
,

A generalizao de casos de uso indica que um caso de uso uma variao de

.


um outro. Portanto, poderamos ter um caso para Retirar Dinheiro (o caso de
uso de base) e um caso de uso separado para lidar com o caso de quando a
retirada recusada devido falta de fundos. A recusa poderia ser tratada como
um caso de uso que especializa o caso de uso de retirada. (Voc tambm poderia
tratar disso simplesmente como um outro cenrio dentro do caso de uso Retirar
Dinheiro.) Uma especializao de caso de uso como essa pode mudar qualquer
aspecto do caso de uso de base .
A construo extend um esteretipo de dependncia. Isso fornece uma for
ma mais controlada de extenso do que o relacionamento de generalizao. Aqui,

o caso de uso de base declara vrios pontos de extenso. O caso de uso estendido
pode alterar o comportamento somente nesses pontos de extenso. Ento, se
voc est comprando um produto on-line, pode ter um caso de uso para
comprar um produto com pontos de extenso, para capturar a informao
 ------------------------

APNDICE 147

de eJJedco e a jn.formao de__pqgament:o. Esse caso de uso__poderiaJ enr5o,

ser estencfcf para um ciente regu1.r, para o qua(essas mforrnacs seriam
obtidas de forma diferente ..

Existe certa confuso sobre a relao entre os relacionamentos antigos e os novos.

A maioria das pessoas usava uses da maneira como includes usado na verso I .3;

portanto, para a maioria das pessoas, podemos dizer que includes substitui uses. E
a maioria das pessoas usava extends da verso I. I tanto na maneira controlada da
palavra-chave extends da verso 1.3 quanto como uma sobreposio geral no estilo da
generalizao da verso 1.3. Assim, voc pode pensar que extends da verso I. I foi
dividida em extend e na generalizao da verso 1.3.
.
I Agora, embora essa explicao cubra a maioria dos usos da UML que j vi, no a
maneira estritamente correta de usar esses antigos relacionamentos. Entretanto, a maio
ria das pessoas no seguiu o uso estrito e no quero entrar nesse assunto aqui.

I Diagramas de Atividades

Quando a UML chegou verso 1.2, havia algumas questes em aberto sobre a semn
tica dos diagramas de atividades. Assim, o trabalho da 1.3 envolveu muito ajuste nessa
' .
semantica.
Para comportan1ento condicional, agora voc pode usar a atividade de deciso, em
forma de losango, para uma intercalao de comportamentos, bem como para uma ra
mificao. Embora nem intercalaes nem ramificaes sejam necessrias para descrever
comportamento condicional, mostr-las um estilo cada vez mais comum, para que
I voc possa colocar o comportamento condicional entre colchetes.
t-

A barra de sincronizao agora referida como separao (ao dividir o controle) ou

como juno (ao sincronizar o controle). Entretanto, voc no pode mais acrescentar
,:
condies arbitrrias