FOREWORD TO THE THIRD EDITION ...................................................................................................................................

4FOREWORD
TO THE FIRST
EDITION....................................................................................................................................5PREFACE...................................................
........................................................................................................................5
Why Bother with the UML?........................................................................................................................................6Structure of
the Book..................................................................................................................................................7Changes for the Third
Edition....................................................................................................................................7Acknowledgments .............................
.........................................................................................................................7
DIAGRAMS .......................................................................................................................................................................10CHAPTER 1.
INTRODUCTION ............................................................................................................................................14
What s the UML?.....................................................................................................................................................14Where to
!ind "ut More ..........................................................................................................................................14Ways of Using the
UML ...........................................................................................................................................15#ow We $ot to the
UML..........................................................................................................................................18%otations and Meta&
Models.....................................................................................................................................20UML
'iagrams..........................................................................................................................................................21What s Legal
UML?.................................................................................................................................................23The Meaning of
UML................................................................................................................................................24UML s %ot
Enough..................................................................................................................................................24Where to Start with the
UML....................................................................................................................................25
CHAPTER 2. DEVELOPMENT PROCESS ............................................................................................................................26terati(e
and Waterfall )rocesses............................................................................................................................26)redicti(e and
Ada*ti(e )lanning............................................................................................................................28Agile
)rocesses........................................................................................................................................................29+ational Unified
)rocess..........................................................................................................................................30!itting a )rocess to a
)ro,ect...................................................................................................................................30!itting the UML into a )rocess
................................................................................................................................32Choosing a 'e(elo*ment
)rocess..........................................................................................................................35Where to !ind "ut More
..........................................................................................................................................35
CHAPTER 3. CLASS DIAGRAMS: THE ESSENTIALS
...........................................................................................................35)ro*erties..................................................................................
................................................................................36When to Use Class 'iagrams
.................................................................................................................................38Where to !ind "ut More
..........................................................................................................................................38Multi*licity...................................................
...............................................................................................................38)rogramming nter*retation of
)ro*erties..............................................................................................................39Bidirectional
Associations........................................................................................................................................41"*erations..............................
...................................................................................................................................42$enerali-ation...................................................
........................................................................................................43%otes and Comments
..............................................................................................................................................44'e*endency...........................................
...................................................................................................................44Constraint
+ules.......................................................................................................................................................46
CHAPTER 4. SEQUENCE DIAGRAMS.................................................................................................................................47Creating
and 'eleting )artici*ants..........................................................................................................................50Loo*s. Conditionals.
and the Like...........................................................................................................................51Synchronous and Asynchronous
Calls...................................................................................................................54When to Use Se/uence
'iagrams..........................................................................................................................54
CHAPTER 5. CLASS DIAGRAMS: ADVANCED CONCEPTS ..................................................................................................560eywords
..................................................................................................................................................................56Classification and
$enerali-ation............................................................................................................................57Multi*le and 'ynamic
Classification........................................................................................................................57Association
Class.....................................................................................................................................................58Tem*late 1)arameteri-ed2
Class.............................................................................................................................61Enumerations................................................
............................................................................................................62Acti(e Class
..............................................................................................................................................................633isi4ility ..................................
...................................................................................................................................63Messages..........................................................
........................................................................................................64+es*onsi4ilities............................................................................
.............................................................................64Static "*erations and
Attri4utes..............................................................................................................................65Aggregation and
Com*osition.................................................................................................................................65'eri(ed
)ro*erties....................................................................................................................................................66nterfaces and A4stract
Classes..............................................................................................................................67+ead&"nly and
!ro-en.............................................................................................................................................70+eference "4,ects and 3alue
"4,ects....................................................................................................................705ualified
Associations..............................................................................................................................................71
CHAPTER 6. OBJECT DIAGRAMS......................................................................................................................................72
When to Use "4,ect 'iagrams................................................................................................................................72
CHAPTER . PAC!AGE DIAGRAMS ...................................................................................................................................73)ackages
and 'e*endencies..................................................................................................................................74)ackage
As*ects......................................................................................................................................................76m*lementing
)ackages...........................................................................................................................................76When to Use )ackage
'iagrams............................................................................................................................77Where to !ind "ut More
..........................................................................................................................................78
CHAPTER ". DEPLO#MENT DIAGRAMS .............................................................................................................................78
When to Use 'e*loyment 'iagrams.......................................................................................................................79
CHAPTER $. USE CASES .................................................................................................................................................79Content of a
Use Case.............................................................................................................................................80Use Case
'iagrams.................................................................................................................................................81Le(els of Use Cases
................................................................................................................................................82Use Cases and !eatures 1or
Stories2 .....................................................................................................................82When to Use Use
Cases..........................................................................................................................................83Where to !ind "ut More
..........................................................................................................................................83
CHAPTER 1%. STATE MACHINE DIAGRAMS ......................................................................................................................83nternal
Acti(ities ......................................................................................................................................................85Acti(ity States
...........................................................................................................................................................85Su*erstates...............................
................................................................................................................................86Concurrent
States.....................................................................................................................................................86m*lementing State
'iagrams.................................................................................................................................87When to Use State
'iagrams..................................................................................................................................89Where to !ind "ut More
..........................................................................................................................................89
CHAPTER 11. ACTIVIT# DIAGRAMS ..................................................................................................................................89'ecom*osing
an Action...........................................................................................................................................91And There6s
More.....................................................................................................................................................93When to Use Acti(ity
'iagrams...............................................................................................................................93Where to !ind "ut More
..........................................................................................................................................93)artitions ....................................................
...............................................................................................................93Signals....................................................................................
...................................................................................94Tokens................................................................................................................
.......................................................95!lows and
Edges......................................................................................................................................................96)ins and
Transformations........................................................................................................................................96E7*ansion +egions
..................................................................................................................................................97!low
!inal..................................................................................................................................................................988oin
S*ecifications....................................................................................................................................................99
CHAPTER 12. COMMUNICATION DIAGRAMS ................................................................................................................... 100
When to Use Communication 'iagrams............................................................................................................... 101
CHAPTER 13. COMPOSITE STRUCTURES ....................................................................................................................... 101
When to Use Com*osite Structures...................................................................................................................... 103
CHAPTER 14. COMPONENT DIAGRAMS .......................................................................................................................... 103
When to Use Com*onent 'iagrams..................................................................................................................... 105
CHAPTER 15. COLLABORATIONS ................................................................................................................................... 105
When to Use Colla4orations.................................................................................................................................. 107
CHAPTER 16. INTERACTION OVERVIEW DIAGRAMS........................................................................................................ 107
When to Use nteraction "(er(iew 'iagrams...................................................................................................... 108
CHAPTER 1. TIMING DIAGRAMS ................................................................................................................................... 109
When to Use Timing 'iagrams.............................................................................................................................. 110
APPENDI& CHANGES BETWEEN UML VERSIONS............................................................................................................ 110+e(isions to
the UML............................................................................................................................................. 110Changes in UML
'istilled....................................................................................................................................... 111Changes from UML 9:; to 9:9
............................................................................................................................... 112Changes from UML 9:< 1and 9:92 to 9:=
1and 9:>2............................................................................................... 113Changes from UML 9:= to 9:?
............................................................................................................................... 114Changes from UML 9:?: to 9:>
.............................................................................................................................. 114!rom UML 9:7 to UML
<:;...................................................................................................................................... 114
BIBLIOGRAPH#............................................................................................................................................................... 116
Foreword to the Third Edition
Since ancient times, the most talented architects and the most gifted designers have known the law of
parsimony. Whether it is stated as a paradox ("less is more"), or a koan ("Zen mind is beginners mind"),
its wisdom is timeless! "ed#ce everything to its essence so that form harmoni$es with f#nction. %rom the
pyramids to the Sydney &pera 'o#se, from von (e#mann architect#res to )(*+ and Smalltalk, the best
architects and designers have strived to follow this #niversal and eternal principle.
"ecogni$ing the val#e of shaving with &ccams "a$or, when * architect and read * seek pro,ects and books
that adhere to the law of parsimony. -onse.#ently, * appla#d the book yo# are reading now.
/o# may find my last remark s#rprising at first. * am fre.#ently associated with the vol#mino#s and dense
specifications that define the )nified 0odeling 1ang#age ()01). 2hese specifications allow tool vendors to
implement the )01 and methodologists to apply it. %or seven years, * have chaired large international
standardi$ation teams to specify )01 3.3 and )01 4.5, as well as several minor revisions in between.
6#ring this time, the )01 has mat#red in expressiveness and precision, b#t it has also added grat#ito#s
complexity as a res#lt of the standardi$ation process. "egrettably, standardi$ation processes are better
known for design7by7committee compromises than parsimonio#s elegance.
What can a )01 expert familiar with the arcane min#tiae of the specification learn from 0artins distillation
of )01 4.58 9#ite a bit, as can yo#. 2o start with, 0artin adroitly red#ces a large and complex lang#age
into a pragmatic s#bset that he has proven effective in his practice. 'e has resisted the easy ro#te of
tacking on additional pages to the last edition of his book. :s the lang#age has grown, 0artin has kept tr#e
to his goal of seeking the "fraction of )01 that is most #sef#l" and telling yo# ,#st that. 2he fraction he
refers to is the mythical 45 percent of )01 that helps yo# do ;5 percent of yo#r work. -apt#ring and
taming this el#sive beast is no mean accomplishment<
*t is even more impressive that 0artin achieves this goal while writing in a wonderf#lly engaging
conversational style. =y sharing his opinions and anecdotes with #s, he makes this book f#n to read and
reminds #s that architecting and designing systems sho#ld be both creative and prod#ctive. *f we p#rs#e
the parsimony koan to its f#ll intent, we sho#ld find )01 modeling pro,ects to be as en,oyable as we fo#nd
finger7painting and drawing classes in grammar school. )01 sho#ld be a lightning rod for o#r creativity as
well as a laser for precisely specifying system bl#eprints so that third parties can bid and b#ild those
systems. 2he latter is the acid test for any bona fide bl#eprint lang#age.
So, while this may be a small book, it is not a trivial one. /o# can learn as m#ch from 0artins
approach to modeling as yo# can learn from his explanations of )01 4.5.
* have en,oyed working with 0artin to improve the selection and correctness of the )01 4.5 lang#age
feat#res explained in this revision. We need to keep in mind that all living lang#ages, both nat#ral and
synthetic, m#st evolve or perish. 0artins choices of new feat#res, along with yo#r preferences and those
of other practitioners, are a cr#cial part of the )01 revision process. 2hey keep the lang#age vital and
help it evolve via nat#ral selection in the marketplace.
0#ch challenging work remains before model7driven development becomes mainstream, b#t * am
enco#raged by books like this that explain )01 modeling basics clearly and apply them pragmatically. *
hope yo# will learn from it as * have and will #se yo#r new insights to improve yo#r own software
modeling practices.
-ris >obryn -hair, )4 ?artners )01 4.5 S#bmission 2eam -hief 2echnologist, 2elelogic
Foreword to the First Edition
When we began to craft the )nified 0odeling 1ang#age, we hoped that we co#ld prod#ce a standard
means of expressing design that wo#ld not only reflect the best practices of ind#stry, b#t wo#ld also help
demystify the process of software system modeling. We believed that the availability of a standard
modeling lang#age wo#ld enco#rage more developers to model their software systems before b#ilding
them. 2he rapid and widespread adoption of the )01 demonstrates that the benefits of modeling are
indeed well known to the developer comm#nity.
2he creation of the )01 was itself an iterative and incremental process very similar to the modeling of a
large software system. 2he end res#lt is a standard b#ilt on, and reflective of, the many ideas and
contrib#tions made by n#mero#s individ#als and companies from the ob,ect comm#nity. We began the )01
effort, b#t many others helped bring it to a s#ccessf#l concl#sion@ we are gratef#l for their contrib#tion.
-reating and agreeing on a standard modeling lang#age is a significant challenge by itself. Ad#cating the
development comm#nity, and presenting the )01 in a manner that is both accessible and in the context of
the software development process, is also a significant challenge. *n this deceptively short book, #pdated
to reflect the most recent changes to the )01, 0artin %owler has more than met this challenge.
*n a clear and friendly style, 0artin not only introd#ces the key aspects of )01, b#t also clearly
demonstrates the role )01 plays in the development process. :long the way, we are treated to ab#ndant
n#ggets of modeling insight and wisdom drawn from 0artins 347pl#s years of design and modeling
experience.
2he res#lt is a book that has introd#ced many tho#sands of developers to )01, whetting their
appetite to f#rther explore the many benefits of modeling with this now standard modeling
lang#age.
We recommend the book to any modeler or developer interested in getting a first look at )01 and in
gaining a perspective on the key role it plays in the development process.
Brady =ooch *var
Cacobson Cames
"#mba#gh
Preface
*ve been l#cky in a lot of ways in my life@ one of my great strokes of fort#ne was being in the right place
with the right knowledge to write the first edition of this book in 3DDE. =ack then, the chaotic world of
ob,ect7oriented (&&) modeling was ,#st beginning to #nify #nder the )nified 0odeling 1ang#age ()01).
Since then, the )01 has become the standard for the graphical modeling of software, not ,#st for ob,ects.
0y fort#ne is that this book has been the most pop#lar book on the )01, selling more than a .#arter of a
million copies.
Well, thats very nice for me, b#t sho#ld yo# b#y this book8
* like to stress that this is a brief book. *ts not intended to give yo# the details on every facet of the )01,
which has grown and grown over the years. 0y intention is to find that fraction of the )01 that is most
#sef#l and tell yo# ,#st that. :ltho#gh a bigger book gives yo# more detail, it also takes longer to read.
:nd yo#r time is the biggest investment yo#ll make in a book. =y keeping this book small, *ve spent the
time selecting the best bits to save yo# from having to do that selection yo#rself. (Sadly, being smaller
doesnt mean proportionately cheaper@ there is a certain fixed cost to prod#cing a .#ality technical book.)
&ne reason to have this book is to begin to learn abo#t the )01. =eca#se this is a short book, it will
.#ickly get yo# #p to speed on the essentials of the )01. With that #nder yo#r belt, yo# can go into more
detail on the )01 with the bigger books, s#ch as the User Guide F=ooch, )01 #serG or the Reference
Manual F"#mba#gh, )01 "eferenceG.
2his book can also act as a handy reference to the most common parts of the )01. :ltho#gh the book
doesnt cover everything, its a lot lighter to carry aro#nd than most other )01 books.
*ts also an opinionated book. *ve been working with ob,ects for a long time now, and * have definite ideas
abo#t what works and what doesnt. :ny book reflects the opinions of the a#thor, and * dont try to hide
mine. So if yo#re looking for something that has a flavor of ob,ectivity, yo# might want to try something
else.
:ltho#gh many people have told me that this book is a good introd#ction to ob,ects, * didnt write it with
that in mind. *f yo# are after an introd#ction to && design, * s#ggest -raig 1armans book F1armanG.
0any people who are interested in the )01 are #sing tools. 2his book concentrates on the standard and on
conventional #sage of the )01 and doesnt get into the details of what vario#s tools s#pport. :ltho#gh the
)01 did resolve the tower of =abel of pre7)01 notations, many annoying differences remain between what
tools show and allow when drawing )01 diagrams.
* dont say m#ch in this book abo#t 0odel 6riven :rchitect#re (06:). :ltho#gh many people consider
the two to be the same thing, many developers #se the )01 witho#t being interested in 06:. *f yo#
want to learn more abo#t 06:, * wo#ld start with this book to get an overview of the )01 first and then
move on to a book thats more specific abo#t 06:.
:ltho#gh the main point of this book is the )01, *ve also added bits of other material abo#t techni.#es,
s#ch as -"- cards, that are val#able for && design. 2he )01 is ,#st a part of what yo# need to s#cceed
with ob,ects, and * think that its important to introd#ce yo# to some other techni.#es.
*n a brief book like this, its impossible to go into detail abo#t how the )01 relates to so#rce code,
partic#larly as there is no standard way of making that correspondence. 'owever, * do point o#t common
coding techni.#es for implementing pieces of the )01. 0y code examples are in Cava and -H, as *ve
fo#nd that these lang#ages are #s#ally the most widely #nderstood. 6ont ass#me that * prefer those
lang#ages@ *ve done too m#ch Smalltalk for that<
Why Bother with the UML?
Braphical design notations have been with #s for a while. %or me, their primary val#e is in comm#nication
and #nderstanding. : good diagram can often help comm#nicate ideas abo#t a design, partic#larly when
yo# want to avoid a lot of details. 6iagrams can also help yo# #nderstand either a software system or a
b#siness process. :s part of a team trying to fig#re o#t something, diagrams both help #nderstanding and
comm#nicate that #nderstanding thro#gho#t a team. :ltho#gh they arent, at least yet, a replacement for
text#al programming lang#ages, they are a helpf#l assistant.
0any people believe that in the f#t#re, graphical techni.#es will play a dominant role in software
development. *m more skeptical of that, b#t its certainly #sef#l to have an appreciation of what these
notations can and cant do.
&f these graphical notations, the )01s importance comes from its wide #se and standardi$ation within
the && development comm#nity. 2he )01 has become not only the dominant graphical notation within
the && world b#t also a pop#lar techni.#e in non7&& circles.
Structure of the Book
-hapter 3 gives an introd#ction to the )01! what it is, the different meanings it has to different
people, and where it came from.
-hapter 4 talks abo#t software process. :ltho#gh this is strictly independent of the )01, * think that its
essential to #nderstand process in order to see the context of something like the )01. *n partic#lar, its
important to #nderstand the role of iterative development, which has been the #nderlying approach to
process for most of the && comm#nity.
*ve organi$ed the rest of the book aro#nd the diagram types within the )01. -hapters I and J disc#ss
the two most #sef#l parts of the )01! class diagrams (core) and se.#ence diagrams. Aven tho#gh this
book is slim, * believe that yo# can get the most val#e o#t of the )01 by #sing the techni.#es that * talk
abo#t in these chapters. 2he )01 is a large and growing beast, b#t yo# dont need all of it.
-hapter K goes into detail on the less essential b#t still #sef#l parts of class diagrams. -hapters L thro#gh
; describe three #sef#l diagrams that shed f#rther light on the structure of a system! ob,ect diagrams,
package diagrams, and deployment diagrams.
-hapters D thro#gh 33 show three f#rther #sef#l behavioral techni.#es! #se cases, state diagrams
(altho#gh officially known as state machine diagrams, they are generally called state diagrams), and
activity diagrams. -hapters 34 thro#gh 3E are very brief and cover diagrams that are generally less
important, so for these, *ve only provided a .#ick example and explanation.
2he inside covers s#mmari$e the most #sef#l parts of the notation. *ve often heard people say that these
covers are the most val#able part of the book. /o#ll probably find it handy to refer to them as yo#re
reading some of the other parts of the book.
Changes for the Third Edition
*f yo# have earlier editions of this book, yo#re probably wondering what is different and, more
important, whether yo# sho#ld b#y the new edition.
2he primary trigger for the third edition was the appearance of )01 4. )01 4 has added a lot of new st#ff,
incl#ding several new diagram types. Aven familiar diagrams have a lot of new notation, s#ch as interaction
frames in se.#ence diagrams. *f yo# want to be aware of whats happened b#t dont want to wade thro#gh
the specification (* certainly dont recommend that<), this book sho#ld give yo# a good overview.
*ve also taken this opport#nity to completely rewrite most of the book, bringing the text and examples #p
to date. *ve incorporated m#ch that *ve learned in teaching and #sing the )01 over the past five years.
So altho#gh the spirit of this #ltrathin )01 book is intact, most of the words are new.
&ver the years, *ve worked hard to keep this book as c#rrent as is possible. :s the )01 has gone thro#gh
its changes, *ve done my best to keep pace. 2his book is based on the )01 4 drafts that were accepted
by the relevant committee in C#ne 455I. *ts #nlikely that f#rther changes will occ#r between that vote
and more formal votes, so * feel that )01 4 is now stable eno#gh for my revision to go into print. *ll post
information any f#rther #pdates on my Web site (http://martinfowler.com).
Acknowedg!ents
&ver many years, many people have been part of the s#ccess of this book. 0y first thanks go -arter
Shanklin and >endall Scott. -arter was the editor at :ddison7Wesley who s#ggested this book to me.
>endall Scott helped me p#t together the first two editions, working over the text and graphics. =etween
them, they p#lled off the impossible in getting the first edition o#t in an impossibly short time, while
keeping #p the high .#ality that people expect from :ddison7Wesley. 2hey also kept p#shing o#t changes
d#ring the early days of the )01 when nothing seemed stable.
Cim &dell has been my mentor and g#ide for m#ch of the early part of my career. 'es also been deeply
involved with the technical and personal iss#es of making opinionated methodologists settle their
differences and agree to a common standard. 'is contrib#tion to this book is both profo#nd and diffic#lt
to meas#re, and * bet its the same for the )01 too.
2he )01 is a creat#re of standards, b#t *m allergic to standards bodies. So to know whats going on, *
need a network of spies who can keep me #p to date on all the machinations of the committees. Witho#t
these spies, incl#ding -onrad =ock, Steve -ook, -ris >obryn, Cim &dell, B##s "amackers, and Cim
"#mba#gh, * wo#ld be s#nk. 2heyve all given me #sef#l tips and answered st#pid .#estions.
Brady =ooch, *var Cacobson, and Cim "#mba#gh are known as the 2hree :migos. 6espite the playf#l ,ibes
*ve given them over the years, they have given me m#ch s#pport and enco#ragement with this book.
(ever forget that my ,abs #s#ally spro#t from fond appreciation.
"eviewers are the key to a books .#ality, and * learned from -arter that yo# can never have too many
reviewers. 2he reviewers of the previo#s editions of this book were Simmi >ochhar =hargava, Brady
=ooch, Aric Avans, 2om 'adfield, *var Cacobson, "onald A. Ceffries, Cosh#a >erievsky, 'elen >lein, Cim
&dell, Cim "#mba#gh, and Mivek Salgar.
2he third edition also had a fine gro#p of reviewers!
-onrad =ock -raig 1arman
:ndy -armichael Steve 0ellor
:listair -ockb#rn Cim &dell
Steve -ook :lan &-allaghan
1#ke 'ohmann B##s "amackers
?avel 'r#by Cim "#mba#gh
Con >ern 2im Selt$er
-ris >obryn
:ll these reviewers spent time reading the man#script, and every one of them fo#nd at least one
embarrassing howler. 0y sincere thanks to all of them. :ny howlers that remain are entirely my
responsibility. * will post an errata sheet to the books section of martinfowler.com when * find them.
2he core team that designed and wrote the )01 specification are 6on =aisley, 0organ =,Nrkander, -onrad
=ock, Steve -ook, ?hilippe 6esfray, (athan 6ykman, :nders Ak, 6avid %rankel, Aran Bery, Oystein
'a#gen, Sridhar *yengar, -ris >obryn, =irger 0Pller7?edersen, Cames &dell, B#nnar Qvergaard, >arin
?almkvist, B##s "amackers, Cim "#mba#gh, =ran Selic, 2homas Weigert, and 1arry Williams. Witho#t
them, * wo#ld have nothing to write abo#t.
?avel 'r#by developed some excellent Misio templates that * #se a lot for )01 diagrams@ yo# can get
them at http://phruby.com.
0any people have contacted me on the (et and in person with s#ggestions and .#estions and to point
o#t errors. * havent been able to keep track of yo# all, b#t my thanks are no less sincere.
2he people at my favorite technical bookstore, Soft?ro in =#rlington, 0assach#setts, let me spend many
ho#rs there looking at their stock to find how people #se the )01 in practice and fed me good coffee while
* was there.
%or the third edition, the ac.#isition editor was 0ike 'endrickson. >im :rney 0#lcahy managed the
pro,ect, as well as did the layo#t and clean7#p of the diagrams. Cohn %#ller, at :ddison7Wesley, was the
prod#ction editor, while Avelyn ?yle and "ebecca "ider helped with the copyediting and proofreading of the
book. * thank them all.
-indy has stayed with me while * persist in writing books. She then plants the proceeds in the
garden.
0y parents started me off with a good ed#cation, from which all else springs.
0artin %owler 0elrose, 0assach#setts
http://martinfowler.com
"iagra!s
Cha#ter $% &ntroduction
What *s the )018
Ways of )sing the )01
'ow We Bot to the )01
(otations and 0eta70odels
)01 6iagrams
What *s 1egal )018
2he 0eaning of )01
)01 *s (ot Ano#gh
Where to Start with the )01
Where to %ind &#t 0ore
What &s the UML?
2he )nified 0odeling 1ang#age ()01) is a family of graphical notations, backed by single metamodel, that
help in describing and designing software systems, partic#larly software systems b#ilt #sing the ob,ect7
oriented (&&) style. 2hats a somewhat simplified definition. *n fact, the )01 is a few different things to
different people. 2his comes both from its own history and from the different views that people have abo#t
what makes an effective software engineering process. :s a res#lt, my task in m#ch of this chapter is to
set the scene for this book by explaining the different ways in which people see and #se the )01.
Braphical modeling lang#ages have been aro#nd in the software ind#stry for a long time. 2he f#ndamental
driver behind them all is that programming lang#ages are not at a high eno#gh level of abstraction to
facilitate disc#ssions abo#t design.
6espite the fact that graphical modeling lang#ages have been aro#nd for a long time, there is an
enormo#s amo#nt of disp#te in the software ind#stry abo#t their role. 2hese disp#tes play directly into
how people perceive the role of the )01 itself.
2he )01 is a relatively open standard, controlled by the &b,ect 0anagement Bro#p (&0B), an open
consorti#m of companies. 2he &0B was formed to b#ild standards that s#pported interoperability,
specifically the interoperability of ob,ect7oriented systems. 2he &0B is perhaps best known for the -&"=:
(-ommon &b,ect "e.#est =roker :rchitect#re) standards.
2he )01 was born o#t of the #nification of the many ob,ect7oriented graphical modeling lang#ages that
thrived in the late 3D;5s and early 3DD5s. Since its appearance in 3DDE, it has relegated that partic#lar
tower of =abel to history. 2hats a service *, and many other developers, am deeply thankf#l for.
Where to Find 'ut More
2his book is not a complete and definitive reference to the )01, let alone && analysis and design. : lot of
words are o#t there and a lot of worthwhile things to read. :s * disc#ss the individ#al topics, * also
mention other books yo# sho#ld go to for more in7depth information there. 'ere are some general books
on the )01 and ob,ect7oriented design.
:s with all book recommendations, yo# may need to check which version of the )01 they are written for.
:s of C#ne 455I, no p#blished book #ses )01 4.5, which is hardly s#rprising, as the ink is barely dry on
the standard. 2he books * s#ggest are good books, b#t * cant tell whether or when they will be #pdated
to the )01 4 standard.
*f yo# are new to ob,ects, * recommend my c#rrent favorite introd#ctory book! F1armanG. 2he
a#thors strong responsibility7driven approach to design is worth following.
%or the concl#sive word on the )01, yo# sho#ld look to the official standards doc#ments@ b#t remember,
they are written for consenting methodologists in the privacy of their own c#bicles. %or a m#ch more
digestible version of the standard, take a look at F"#mba#gh, )01 "eferenceG.
%or more detailed advice on ob,ect7oriented design, yo#ll learn many good things from F0artinG.
* also s#ggest that yo# read books on patterns for material that will take yo# beyond the basics. (ow
that the methods war is over, patterns (page 4E) are where most of the interesting material abo#t
analysis and design appears.
Ways of Using the UML
:t the heart of the role of the )01 in software development are the different ways in which people want
to #se it, differences that carry over from other graphical modeling lang#ages. 2hese differences lead to
long and diffic#lt arg#ments abo#t how the )01 sho#ld be #sed.
2o #ntangle this, Steve 0ellor and * independently came #p with a characteri$ation of the three modes in
which people #se the )01! sketch, bl#eprint, and programming lang#age. =y far the most common of the
three, at least to my biased eye, is UML as sketch. *n this #sage, developers #se the )01 to help
comm#nicate some aspects of a system. :s with bl#eprints, yo# can #se sketches in a forward7engineering
or reverse7engineering direction. Forward engineering draws a )01 diagram before yo# write code,
while reverse engineering b#ilds a )01 diagram from existing code in order to help #nderstand it.
2he essence of sketching is selectivity. With forward sketching, yo# ro#gh o#t some iss#es in code yo# are
abo#t to write, #s#ally disc#ssing them with a gro#p of people on yo#r team. /o#r aim is to #se the
sketches to help comm#nicate ideas and alternatives abo#t what yo#re abo#t to do. /o# dont talk abo#t
all the code yo# are going to work on, only important iss#es that yo# want to r#n past yo#r colleag#es
first or sections of the design that yo# want to vis#ali$e before yo# begin programming. Sessions like this
can be very short! a 357min#te session to disc#ss a few ho#rs of programming or a day to disc#ss a 47
week iteration.
With reverse engineering, yo# #se sketches to explain how some part of a system works. /o# dont show
every class, simply those that are interesting and worth talking abo#t before yo# dig into the code.
=eca#se sketching is pretty informal and dynamic, yo# need to do it .#ickly and collaboratively, so a
common medi#m is a whiteboard. Sketches are also #sef#l in doc#ments, in which case the foc#s is
comm#nication rather than completeness. 2he tools #sed for sketching are lightweight drawing tools, and
often people arent too partic#lar abo#t keeping to every strict r#le of the )01. 0ost )01 diagrams shown
in books, s#ch as my other books, are sketches. 2heir emphasis is on selective comm#nication rather than
complete specification.
*n contrast, UML as blueprint is abo#t completeness. *n forward engineering, the idea is that bl#eprints
are developed by a designer whose ,ob is to b#ild a detailed design for a programmer to code #p. 2hat
design sho#ld be s#fficiently complete in that all design decisions are laid o#t, and the programmer sho#ld
be able to follow it as a pretty straightforward activity that re.#ires little tho#ght. 2he designer may be the
same person as the programmer, b#t #s#ally the designer is a more senior developer who designs for a
team of programmers. 2he inspiration for this approach is other forms of engineering in which professional
engineers create engineering drawings that are handed over to constr#ction companies to b#ild.
=l#eprinting may be #sed for all details, or a designer may draw bl#eprints to a partic#lar area. :
common approach is for a designer to develop bl#eprint7level models as far as interfaces of s#bsystems
b#t then let developers work o#t the details of implementing those details.
*n reverse engineering, bl#eprints aim to convey detailed information abo#t the code either in paper
doc#ments or as an interactive graphical browser. 2he bl#eprints can show every detail abo#t a class in a
graphical form thats easier for developers to #nderstand.
=l#eprints re.#ire m#ch more sophisticated tools than sketches do in order to handle the details
re.#ired for the task. Speciali$ed -:SA (comp#ter7aided software engineering) tools fall into this
category, altho#gh the term -:SA has become a dirty word, and vendors try to avoid it now. %orward7
engineering tools s#pport diagram drawing and back it #p with a repository to hold the information.
"everse7engineering tools read so#rce code and interpret from it into the repository and generate
diagrams. 2ools that can do both forward and reverse engineering like this are referred to as round-
trip tools.
Some tools #se the so#rce code itself as the repository and #se diagrams as a graphic viewport on the
code. 2hese tools tie m#ch more closely into programming and often integrate directly with programming
editors. * like to think of these as tripless tools.
2he line between bl#eprints and sketches is somewhat bl#rry, b#t the distinction, * think, rests on the fact
that sketches are deliberately incomplete, highlighting important information, while bl#eprints intend to be
comprehensive, often with the aim of red#cing programming to a simple and fairly mechanical activity. *n a
so#nd bite, *d say that sketches are explorative, while bl#eprints are definitive.
:s yo# do more and more in the )01 and the programming gets increasingly mechanical, it becomes
obvio#s that the programming sho#ld be a#tomated. *ndeed, many -:SA tools do some form of code
generation, which a#tomates b#ilding a significant part of a system. Avent#ally, however, yo# reach the
point at which all the system can be specified in the )01, and yo# reach UML as programming
language. *n this environment, developers draw )01 diagrams that are compiled directly to exec#table
code, and the )01 becomes the so#rce code. &bvio#sly, this #sage of )01 demands partic#larly
sophisticated tooling. (:lso, the notions of forward and reverse engineering dont make any sense for this
mode, as the )01 and so#rce code are the same thing.)
Mode "ri(en Ar)uitecture and E*ecuta+e UML
When people talk abo#t the )01, they also often talk abo#t Model riven !rchitecture (M!) F>leppe
et al.G. Assentially, 06: is a standard approach to #sing the )01 as a programming lang#age@ the
standard is controlled by the &0B, as is the )01. =y prod#cing a modeling environment that conforms to
the 06:, vendors can create models that can also work with other 06:7compliant environments.
06: is often talked abo#t in the same breath as the )01 beca#se 06: #ses the )01 as its basic
modeling lang#age. =#t, of co#rse, yo# dont have to be #sing 06: to #se the )01.
06: divides development work into two main areas. 0odelers represent a partic#lar application by creating
a "latform #ndependent Model ("#M). 2he ?*0 is a )01 model that is independent of any partic#lar
technology. 2ools can then t#rn a ?*0 into a "latform $pecific Model ("$M). 2he ?S0 is a model of a
system targeted to a specific exec#tion environment. %#rther tools then take the ?S0 and generate code
for that platform. 2he ?S0 co#ld be )01 b#t doesnt have to be.
So if yo# want to b#ild a wareho#sing system #sing 06:, yo# wo#ld start by creating a single ?*0 of yo#r
wareho#sing system. *f yo# then wanted this wareho#sing system to r#n on C4AA and .(A2, yo# wo#ld #se
some vendor tools to create two ?S0s! one for each platform. 2hen f#rther tools wo#ld generate code for
the two platforms.
*f the process of going from ?*0 to ?S0 to final code is completely a#tomated, we have the )01 as
programming lang#age. *f any of the steps is man#al, we have bl#eprints.
Steve 0ellor has long been active in this kind of work and has recently #sed the term %&ecutable UML
F0ellor and =alcerG. Axec#table )01 is similar to 06: b#t #ses slightly different terms. Similarly, yo# begin
with a platform7independent model that is e.#ivalent to 06:s ?*0. 'owever, the next step is to #se a
0odel -ompiler to t#rn that )01 model into a deployable system in a single step@ hence, theres no need
for the ?S0. :s the term compiler s#ggests, this step is completely a#tomatic.
2he model compilers are based on re#sable archetypes. :n archetype describes how to take an
exec#table )01 model and t#rn it into a partic#lar programming platform. So for the wareho#sing
example, yo# wo#ld b#y a model compiler and two archetypes (C4AA and .(A2). "#n each archetype on
yo#r exec#table )01 model, and yo# have yo#r two versions of the wareho#sing system.
Axec#table )01 does not #se the f#ll )01 standard@ many constr#cts of )01 are considered to be
#nnecessary and are therefore not #sed. :s a res#lt, Axec#table )01 is simpler than f#ll )01.
:ll this so#nds good, b#t how realistic is it8 *n my view, there are two iss#es here. %irst is the .#estion of
the tools! whether they are mat#re eno#gh to do the ,ob. 2his is something that changes over time@
certainly, as * write this, they arent widely #sed, and * havent seen m#ch of them in action.
: more f#ndamental iss#e is the whole notion of the )01 as a programming lang#age. *n my view, its
worth #sing the )01 as a programming lang#age only if it res#lts in something thats significantly more
prod#ctive than #sing another programming lang#age. *m not convinced that it is, based on vario#s
graphical development environments *ve worked with in the past. Aven if it is more prod#ctive, it still
needs to get a critical mass of #sers for it to make the mainstream. 2hats a big h#rdle in itself. 1ike many
old Smalltalkers, * consider Smalltalk to be m#ch more prod#ctive than c#rrent mainstream lang#ages. =#t
as Smalltalk is now only a niche lang#age, * dont see many pro,ects #sing it. 2o avoid Smalltalks fate, the
)01 has to be l#ckier, even if it is s#perior.
&ne of the interesting .#estions aro#nd the )01 as programming lang#age is how to model behavioral
logic. )01 4 offers three ways of behavioral modeling! interaction diagrams, state diagrams, and activity
diagrams. :ll have their proponents for programming in. *f the )01 does gain pop#larity as a programming
lang#age, it will be interesting to see which of these techni.#es become s#ccessf#l.
:nother way in which people look at the )01 is the range between #sing it for concept#al and for
software modeling. 0ost people are familiar with the )01 #sed for software modeling. *n this software
perspective, the elements of the )01 map pretty directly to elements in a software system. :s we
shall see, the mapping is by no means prescriptive, b#t when we #se the )01, we are talking abo#t
software elements.
With the conceptual perspective, the )01 represents a description of the concepts of a domain of
st#dy. 'ere, we arent talking abo#t software elements so m#ch as we are b#ilding a vocab#lary to talk
abo#t a partic#lar domain.
2here are no hard7and7fast r#les abo#t perspective@ as it t#rns o#t, theres really .#ite a large range of
#sage. Some tools a#tomatically t#rn so#rce code into the )01 diagrams, treating the )01 as an
alternative view of the so#rce. 2hats very m#ch a software perspective. *f yo# #se )01 diagrams to try
and #nderstand the vario#s meanings of the terms asset pool with a b#nch of acco#ntants, yo# are in a
m#ch more concept#al frame of mind.
*n previo#s editions of this book, * split the software perspective into specification (interface) and
implementation. *n practice, * fo#nd that it was too hard to draw a precise line between the two, so * feel
that the distinction is no longer worth making a f#ss abo#t. 'owever, *m always inclined to emphasi$e
interface rather than implementation in my diagrams.
2hese different ways of #sing the )01 lead to a host of arg#ments abo#t what )01 diagrams mean and
what their relationship is to the rest of the world. *n partic#lar, it affects the relationship between the
)01 and so#rce code. Some people hold the view that the )01 sho#ld be #sed to create a design that is
independent of the programming lang#age thats #sed for implementation. &thers believe that lang#age7
independent design is an oxymoron, with a strong emphasis on the moron.
:nother difference in viewpoints is what the essence of the )01 is. *n my view, most #sers of the )01,
partic#larly sketchers, see the essence of the )01 to be the diagrams. 'owever, the creators of the )01
see the diagrams as secondary@ the essence of the )01 is the meta7model. 6iagrams are simply a
presentation of the meta7model. 2his view also makes sense to bl#eprinters and )01 programming
lang#age #sers.
So whenever yo# read anything involving the )01, its important to #nderstand the point of view of the
a#thor. &nly then can yo# make sense of the often fierce arg#ments that the )01 enco#rages.
'aving said all that, * need to make my biases clear. :lmost all the time, my #se of the )01 is as
sketches. * find the )01 sketches #sef#l with forward and reverse engineering and in both concept#al
and software perspectives.
*m not a fan of detailed forward7engineered bl#eprints@ * believe that its too diffic#lt to do well and slows
down a development effort. =l#eprinting to a level of s#bsystem interfaces is reasonable, b#t even then
yo# sho#ld expect to change those interfaces as developers implement the interactions across the
interface. 2he val#e of reverse7engineered bl#eprints is dependent on how the tool works. *f its #sed as a
dynamic browser, it can be very helpf#l@ if it generates a large doc#ment, all it does is kill trees.
* see the )01 as programming lang#age as a nice idea b#t do#bt that it will ever see significant #sage.
*m not convinced that graphical forms are more prod#ctive than text#al forms for most programming
tasks and that even if they are, its very diffic#lt for a lang#age to be widely accepted.
:s a res#lt of my biases, this book foc#ses m#ch more on #sing the )01 for sketching. %ort#nately, this
makes sense for a brief g#ide. * cant do ,#stice to the )01 in its other modes in a book this si$e, b#t a
book this si$e makes a good introd#ction to other books that can. So if yo#re interested in the )01 in its
other modes, *d s#ggest that yo# treat this book as an introd#ction and move on to other books as yo#
need them. *f yo#re interested only in sketches, this book may well be all yo# need.
,ow We -ot to the UML
*ll admit, *m a history b#ff. 0y favorite idea of light reading is a good history book. =#t * also know that
its not everybodys idea of f#n. * talk abo#t history here beca#se * think that in many ways, its hard to
#nderstand where the )01 is witho#t #nderstanding the history of how it got here.
*n the 3D;5s, ob,ects began to move away from the research labs and took their first steps toward the
"real" world. Smalltalk stabili$ed into a platform that people co#ld #se, and -RR was born. :t that time,
vario#s people started thinking abo#t ob,ect7oriented graphical design lang#ages.
2he key books abo#t ob,ect7oriented graphical modeling lang#ages appeared between 3D;; and 3DD4.
1eading fig#res incl#ded Brady =ooch F=ooch, &&:6G@ ?eter -oad F-oad, &&:G, F-oad, &&6G@ *var
Cacobson (&b,ectory) FCacobson, &&SAG@ Cim &dell F&dellG@ Cim "#mba#gh (&02) F"#mba#gh, insightsG,
F"#mba#gh, &02G@ Sally Shlaer and Steve 0ellor FShlaer and 0ellor, dataG, FShlaer and 0ellor, statesG@
and "ebecca Wirfs7=rock ("esponsibility 6riven 6esign) FWirfs7=rockG.
Aach of those a#thors was now informally leading a gro#p of practitioners who liked those ideas. :ll these
methods were very similar, yet they contained a n#mber of often annoying minor differences among
them. 2he same basic concepts wo#ld appear in very different notations, which ca#sed conf#sion to my
clients.
6#ring that heady time, standardi$ation was as talked abo#t as it was ignored. : team from the &0B
tried to look at standardi$ation b#t got only an open letter of protest from all the key methodologists.
(2his reminds me of an old ,oke. 9#estion! What is the difference between a methodologist and a
terrorist8 :nswer! /o# can negotiate with a terrorist.)
2he cataclysmic event that first initiated the )01 was when Cim "#mba#gh left BA to ,oin Brady =ooch at
"ational (now a part of *=0). 2he =oochS"#mba#gh alliance was seen from the beginning as one that
co#ld get a critical mass of market share. Brady and Cim proclaimed that "the methods war is over we
won," basically declaring that they were going to achieve standardi$ation "the 0icrosoft way." : n#mber
of other methodologists s#ggested forming an :nti7=ooch -oalition.
=y &&?S1: DK, Brady and Cim had prepared their first p#blic description of their merged method! version
5.; of the Unified Method doc#mentation. Aven more significant, they anno#nced that "ational Software
had bo#ght &b,ectory and that therefore, *var Cacobson wo#ld be ,oining the )nified team. "ational held a
well7attended party to celebrate the release of the 5.; draft. (2he highlight of the party was the first p#blic
display of Cim "#mba#ghs singing@ we all hope its also the last.)
2he next year saw a more open process emerge. 2he &0B, which had mostly stood on the sidelines, now
took an active role. "ational had to incorporate *vars ideas and also spent time with other partners. 0ore
important, the &0B decided to take a ma,or role.
:t this point, its important to reali$e why the &0B got involved. 0ethodologists, like book a#thors, like to
think that they are important. =#t * dont think that the screams of book a#thors wo#ld even be heard by
the &0B. What got the &0B involved were the screams of tools vendors, all of which were frightened that
a standard controlled by "ational wo#ld give "ational tools an #nfair competitive advantage. :s a res#lt,
the vendors energi$ed the &0B to do something abo#t it, #nder the banner of -:SA tool interoperability.
2his banner was important, as the &0B was all abo#t interoperability. 2he idea was to create a )01 that
wo#ld allow -:SA tools to freely exchange models.
0ary 1oomis and Cim &dell chaired the initial task force. &dell made it clear that he was prepared to give
#p his method to a standard, b#t he did not want a "ational7imposed standard. *n Can#ary 3DDE, vario#s
organi$ations s#bmitted proposals for a methods standard to facilitate the interchange of models. "ational
collaborated with a n#mber of other organi$ations and released version 3.5 of the )01 doc#mentation as
their proposal, the first animal to answer to the name )nified 0odeling 1ang#age.
2hen followed a short period of arm twisting while the vario#s proposals were merged. 2he &0B adopted
the res#lting 3.3 as an official &0B standard. Some revisions were made later on. "evision
3.4 was entirely cosmetic. "evision 3.I was more significant. "evision 3.J added a n#mber of
detailed concepts aro#nd components and profiles. "evision 3.K added action semantics.
When people talk abo#t the )01, they credit mainly Brady =ooch, *var Cacobson, and Cim "#mba#gh as its
creators. 2hey are generally referred to as the 2hree :migos, altho#gh wags like to drop the first syllable
of the second word. :ltho#gh they are most credited with the )01, * think it somewhat #nfair to give them
the dominant credit. 2he )01 notation was first formed in the =oochS"#mba#gh )nified 0ethod. Since
then, m#ch of the work has been led by &0B committees. 6#ring these later stages, Cim "#mba#gh is the
only one of the three to have made a heavy commitment. 0y view is that its these members of the )01
committee process that deserve the principal credit for the )01.
.otations and Meta/Modes
2he )01, in its c#rrent state, defines a notation and a meta7model. 2he notation is the graphical st#ff
yo# see in models@ it is the graphical syntax of the modeling lang#age. %or instance, class diagram
notation defines how items and concepts, s#ch as class, association, and m#ltiplicity, are represented.
&f co#rse, this leads to the .#estion of what exactly is meant by an association or m#ltiplicity or even a
class. -ommon #sage s#ggests some informal definitions, b#t many people want more rigor than that.
2he idea of rigoro#s specification and design lang#ages is most prevalent in the field of formal methods.
*n s#ch techni.#es, designs and specifications are represented #sing some derivative of predicate
calc#l#s. S#ch definitions are mathematically rigoro#s and allow no ambig#ity. 'owever, the val#e of
these definitions is by no means #niversal. Aven if yo# can prove that a program satisfies a
mathematical specification, there is no way to prove that the mathematical specification meets the real
re.#irements of the system.
0ost graphical modeling lang#ages have very little rigor@ their notation appeals to int#ition rather than
to formal definition. &n the whole, this does not seem to have done m#ch harm. 2hese methods may be
informal, b#t many people still find them #sef#lTand it is #sef#lness that co#nts.
'owever, methodologists are looking for ways to improve the rigor of methods witho#t sacrificing their
#sef#lness. &ne way to do this is to define a meta-model: a diagram, #s#ally a class diagram, that
defines the concepts of the lang#age.
%ig#re 3.3, a small piece of the )01 meta7model, shows the relationship among feat#res. (2he
extract is there to give yo# a flavor of what meta7models are like. *m not even going to try to
explain it.)
Figure '.'. ! small piece of the UML meta-model
'ow m#ch does the meta7model affect a #ser of the modeling notation8 2he answer depends mostly on the
mode of #sage. : sketcher #s#ally doesnt care too m#ch@ a bl#eprinter sho#ld care rather more. *ts vitally
important to those who #se the )01 as a programming lang#age, as it defines the abstract syntax of that
lang#age.
0any of the people who are involved in the ongoing development of the )01 are interested primarily in the
meta7model, partic#larly as this is important to the #sage of the )01 and a programming lang#age.
(otational iss#es often r#n second place, which is important to bear in mind if yo# ever try to get familiar
with the standards doc#ments themselves.
:s yo# get deeper into the more detailed #sage of the )01, yo# reali$e that yo# need m#ch more than
the graphical notation. 2his is why )01 tools are so complex.
* am not rigoro#s in this book. * prefer the traditional methods path and appeal mainly to yo#r
int#ition. 2hats nat#ral for a small book like this written by an a#thor whos inclined mostly to a
sketch #sage. *f yo# want more rigor, yo# sho#ld t#rn to more detailed tomes.
UML "iagra!s
)01 4 describes 3I official diagram types listed in 2able 3.3 and classified as indicated on %ig#re
3.4. :ltho#gh these diagram types are the way many people approach the )01 and how *ve organi$ed
this book, the )01s a#thors do not see diagrams as the central part of the )01. :s a res#lt, the
diagram types are not partic#larly rigid. &ften, yo# can legally #se elements from one diagram type on
another diagram. 2he )01 standard indicates that certain elements are typically drawn on certain
diagram types, b#t this is not a prescription.
Figure '.(. )lassification of UML diagram types
*able '.'. +fficial iagram *ypes of the UML
,ook
iagram )hapters "urpose Lineage
:ctivity 33 ?roced#ral and parallel behavior *n )01 3
-lass I, K -lass, feat#res, and relationships *n )01 3
-omm#nication 34 *nteraction between ob,ects@ emphasis )01 3 collaboration
on links diagram
-omponent 3J Str#ct#re and connections of *n )01 3
components
-omposite 3I "#ntime decomposition of a class (ew to )01 4
str#ct#re
6eployment ; 6eployment of artifacts to nodes *n )01 3
*able '.'. +fficial iagram *ypes of the UML
,ook
iagram )hapters "urpose Lineage
*nteraction 3L 0ix of se.#ence and activity diagram (ew to )01 4
overview
&b,ect L Axample config#rations of instances )nofficially in )01 3
?ackage E -ompile7time hierarchic str#ct#re )nofficially in )01 3
Se.#ence J *nteraction between ob,ects@ emphasis *n )01 3
on se.#ence
State machine 35 'ow events change an ob,ect over its *n )01 3
life
2iming 3E *nteraction between ob,ects@ emphasis (ew to )01 4
on timing
)se case D 'ow #sers interact with a system *n )01 3
What &s Lega UML?
:t first bl#sh, this sho#ld be a simple .#estion to answer! 1egal )01 is what is defined as well formed in
the specification. *n practice, however, the answer is a bit more complicated.
:n important part of this .#estion is whether the )01 has descriptive or prescriptive r#les. : lang#age with
prescriptive rules is controlled by an official body that states what is or isnt legal in the lang#age and
what meaning yo# give to #tterances in that lang#age. : lang#age with descriptive rules is one in which
yo# #nderstand its r#les by looking at how people #se the lang#age in practice. ?rogramming lang#ages
tend to have prescriptive r#les set by a standards committee or dominant vendor, while nat#ral lang#ages,
s#ch as Anglish, tend to have descriptive r#les whose meaning is set by convention.
)01 is .#ite a precise lang#age, so yo# might expect it to have prescriptive r#les. =#t )01 is often
considered to be the software e.#ivalent of the bl#eprints in other engineering disciplines, and these
bl#eprints are not prescriptive notations. (o committee says what the legal symbols are on a str#ct#ral
engineering drawing@ the notation has been accepted by convention, similarly to a nat#ral lang#age.
Simply having a standards body doesnt do the trick either, beca#se people in the field may not follow
everything the standards body says@ ,#st ask the %rench abo#t the :cadUmie %ranVaise. *n addition, the
)01 is so complex that the standard is often open to m#ltiple interpretations. Aven the )01 leaders who
reviewed this book wo#ld disagree on interpretation of the )01 standard.
2his iss#e is important both for me writing this book and for yo# #sing the )01. *f yo# want to #nderstand
a )01 diagram, its important to reali$e that #nderstanding the )01 standard is not the whole pict#re.
?eople do adopt conventions, both in the ind#stry widely and within a partic#lar pro,ect. :s a res#lt,
altho#gh the )01 standard can be the primary so#rce of information on the )01, it cant be the only one.
0y attit#de is that, for most people, the )01 has descriptive r#les. 2he )01 standard is the biggest single
infl#ence on what )01 means, b#t it isnt the only one. * think that this will become partic#larly tr#e with
)01 4, which introd#ces some notational conventions that conflict with either )01 3s definition or the
conventional #sage of )01, as well as adds yet more complexity to the )01. *n this book, therefore, *m
trying to s#mmari$e the )01 as * find it! both the standards and the conventional #sage. When * have to
make a distinction in this book, *ll #se the term conventional use to indicate something that isnt in the
standard b#t that * think is widely #sed. %or something that conforms to the standard, *ll #se the terms
standard or normative. ((ormative is the term standards people #se to mean a statement that yo# m#st
conform to be valid in the standard. So non7normative )01 is a fancy way of saying that something is
strictly illegal according to the )01 standard.)
When yo# are looking at a )01 diagram, yo# sho#ld bear in mind that a general principle in the )01 is that
any information may be suppressed for a partic#lar diagram. 2his s#ppression can occ#r either generally
Thide all attrib#tesTor specificallyTdont show these three classes. *n a diagram, therefore, yo# can
never infer anything by its absence. *f a m#ltiplicity is missing, yo# cannot infer what val#e it might be.
Aven if the )01 meta7model has a defa#lt, s#ch as F3G for attrib#tes, if yo# dont see the information on
the diagram, it may be beca#se its the defa#lt or beca#se its s#ppressed.
'aving said that, there are some general conventions, s#ch as m#ltival#ed properties being sets. *n the
text, *ll point o#t these defa#lt conventions.
*ts important to not p#t too m#ch emphasis on having legal )01 if yo#re a sketcher or bl#eprinter. *ts
more important to have a good design for yo#r system, and * wo#ld rather have a good design in illegal
)01 than a legal b#t poor design. &bvio#sly, good and legal is best, b#t yo#re better off p#tting yo#r
energy into having a good design than worrying abo#t the arcana of )01. (&f co#rse, yo# have to be legal
in )01 as programming lang#age, or yo#r program wont r#n properly<)
The Meaning of UML
&ne of the awkward iss#es abo#t the )01 is that, altho#gh the specification describes in great detail what
well7formed )01 is, it doesnt have m#ch to say abo#t what the )01 means o#tside of the rarefied world of
the )01 meta7model. (o formal definition exists of how the )01 maps to any partic#lar programming
lang#age. /o# cannot look at a )01 diagram and say exactly what the e.#ivalent code wo#ld look like.
'owever, yo# can get a rough idea of what the code wo#ld look like. *n practice, thats eno#gh to be
#sef#l. 6evelopment teams often form their local conventions for these, and yo#ll need to be familiar with
the ones in #se.
UML &s .ot Enough
:ltho#gh the )01 provides .#ite a considerable body of vario#s diagrams that help to define an
application, its by no means a complete list of all the #sef#l diagrams that yo# might want to #se. *n
many places, different diagrams can be #sef#l, and yo# sho#ldnt hesitate to #se a non7)01 diagram if
no )01 diagram s#its yo#r p#rpose.
%ig#re 3.I, a screen flow diagram, shows the vario#s screens on a #ser interface and how yo# move
between them. *ve seen and #sed these screen flow diagrams for many years. *ve never seen more than
a very ro#gh definition of what they mean@ there isnt anything like it in the )01, yet *ve fo#nd it a very
#sef#l diagram.
Figure '.-. !n informal screen flow diagram for part of the wiki
.http://c(.com/cgi/wiki/
2able 3.4 shows another favorite! the decision table. 6ecision tables are a good way to show complicated
logical conditions. /o# can do this with an activity diagram, b#t once yo# get beyond simple cases, the
table is both more compact and more clear. :gain, many forms of decision tables are o#t there. 2able 3.4
divides the table into two sections! conditions above the do#ble line and conse.#ences below it. Aach
col#mn shows how a partic#lar combination of conditions leads to a partic#lar set of conse.#ences.
*able '.(. ! ecision *able
?remi#m c#stomer + + / / ( (
?riority order / ( / ( / (
*nternational order / / ( ( ( (
%ee W3K5 W355 WE5 WK5 W;5 WL5
:lert rep X X X
#'()** +(, -,.' /0+-'(1 2-,31 '4 .5616 .5-,71 -, /0+-'(1 8''21. D',). 561-.0.6 .' .+9 '(. .6:5,-;(61 .50.
166< 0==+'=+-0.6 4'+ 9'(+ =+'>6:.. I4 .569 ?'+2 ?6**@ (16 .56<. I4 ,'.@ 3-1:0+3 .56<. AT5-1 -1@ '4 :'(+16@
.56 10<6 03/-:6 01 4'+ UML 3-07+0<1.B
Where to Start with the UML
(obody, not even the creators of the )01, #nderstand or #se all of it. 0ost people #se a small s#bset of
the )01 and work with that. /o# have to find the s#bset of the )01 that works for yo# and yo#r
colleag#es.
*f yo# are starting o#t, * s#ggest that yo# concentrate first on the basic forms of class diagrams and
se.#ence diagrams. 2hese are the most common and, in my view, the most #sef#l diagram types.
&nce yo#ve got the hang of those, yo# can start #sing some of the more advanced class diagram
notation and take a look at the other diagrams types. Axperiment with the diagrams and see how
helpf#l they are to yo#. 6ont be afraid to drop any that dont seem be #sef#l to yo#r work.
Cha#ter 0% "e(eo#!ent Process
:s *ve already mentioned, the )01 grew o#t of a b#nch of && analysis and design methods. 2o some
extent, all of them mixed a graphical modeling lang#age with a process that described how to go abo#t
developing software.
*nterestingly, as the )01 was formed, the vario#s players discovered that altho#gh they co#ld agree on a
modeling lang#age, they most certainly co#ld not agree on a process. :s a res#lt, they agreed to leave any
agreement on process #ntil later and to confine the )01 to being a modeling lang#age.
2he title of this book is UML Distilled, so * co#ld have safely ignored process. 'owever, * dont believe
that modeling techni.#es make any sense witho#t knowing how they fit into a process. 2he way yo# #se
the )01 depends a lot on the style of process yo# #se.
:s a res#lt, * think that its important to talk abo#t process first so that yo# can see the context for #sing
the )01. *m not going to go into great detail on any partic#lar process@ * simply want to give yo# eno#gh
information to see this context and pointers to where yo# can find o#t more.
When yo# hear people disc#ss the )01, yo# often hear them talk abo#t the "ational )nified ?rocess (")?).
")? is one processTor, more strictly, a process frameworkTthat yo# can #se with the )01. =#t other than
the common involvement of vario#s people from "ational and the name "#nified," it doesnt have any
special relationship to the )01. 2he )01 can be #sed with any process. ")? is a pop#lar approach and is
disc#ssed on page 4K.
&terati(e and Waterfa Processes
&ne of the biggest debates abo#t process is that between waterfall and iterative styles. 2he terms often
get mis#sed, partic#larly as iterative is seen as fashionable, while the waterfall process seems to wear
plaid tro#sers. :s a res#lt, many pro,ects claim to do iterative development b#t are really doing waterfall.
2he essential difference between the two is how yo# break #p a pro,ect into smaller ch#nks. *f yo# have
a pro,ect that yo# think will take a year, few people are comfortable telling the team to go away for a
year and to come back when done. Some breakdown is needed so that people can approach the problem
and track progress.
2he waterfall style breaks down a pro,ect based on activity. 2o b#ild software, yo# have to do certain
activities! re.#irements analysis, design, coding, and testing. &#r 37year pro,ect might th#s have a 47
month analysis phase, followed by a J7month design phase, followed by a I7month coding phase, followed
by a I7month testing phase.
2he iterative style breaks down a pro,ect by s#bsets of f#nctionality. /o# might take a year and break it
into I7month iterations. *n the first iteration, yo#d take a .#arter of the re.#irements and do the
complete software life cycle for that .#arter! analysis, design, code, and test. :t the end of the first
iteration, yo#d have a system that does a .#arter of the needed f#nctionality. 2hen yo#d do a second
iteration so that at the end of L months, yo#d have a system that does half the f#nctionality.
&f co#rse, the above is a simplified description, b#t it is the essence of the difference. *n practice, of
co#rse, some imp#rities leak into the process.
With waterfall development, there is #s#ally some form of formal handoff between each phase, b#t there
are often backflows. 6#ring coding, something may come #p that ca#ses yo# to revisit the analysis and
design. /o# certainly sho#ld not ass#me that all design is finished when coding begins. *ts inevitable that
analysis and design decisions will have to be revisited in later phases. 'owever, these backflows are
exceptions and sho#ld be minimi$ed as m#ch as possible.
With iteration, yo# #s#ally see some form of exploration activity before the tr#e iterations begin. :t the
very least, this will get a high7level view of the re.#irements! at least eno#gh to break the re.#irements
down into the iterations that will follow. Some high7level design decisions may occ#r d#ring exploration
too. :t the other end, altho#gh each iteration sho#ld prod#ce prod#ction7ready integrated software, it
often doesnt .#ite get to that point and needs a stabili$ation period to iron o#t the last b#gs. :lso, some
activities, s#ch as #ser training, are left to the end.
/o# may well not p#t the system into prod#ction at the end of each iteration, b#t the system sho#ld be of
prod#ction .#ality. &ften, however, yo# can p#t the system into prod#ction at reg#lar intervals@ this is
good beca#se yo# get val#e from the system earlier and yo# get better7.#ality feedback. *n this sit#ation,
yo# often hear of a pro,ect having m#ltiple releases, each of which is broken down into several
iterations.
*terative development has come #nder many names! incremental, spiral, evol#tionary, and ,ac#$$i spring
to mind. Mario#s people make distinctions among them, b#t the distinctions are neither widely agreed on
nor that important compared to the iterativeSwaterfall dichotomy.
/o# can have hybrid approaches. F0c-onnellG describes the staged delivery life cycle whereby analysis
and high7level design are done first, in a waterfall style, and then the coding and testing are divided #p
into iterations. S#ch a pro,ect might have J months of analysis and design followed by fo#r 47month
iterative b#ilds of the system.
0ost writers on software process in the past few years, especially in the ob,ect7oriented comm#nity,
dislike the waterfall approach. &f the many reasons for this, the most f#ndamental is that its very diffic#lt
to tell whether the pro,ect is tr#ly on track with a waterfall process. *ts too easy to declare victory with
early phases and hide a sched#le slip. )s#ally, the only way yo# can really tell whether yo# are on track is
to prod#ce tested, integrated software. =y doing this repeatedly, an iterative style gives yo# better
warning if something is going awry.
%or that reason alone, * strongly recommend that pro,ects do not #se a p#re waterfall approach. /o#
sho#ld at least #se staged delivery, if not a more p#re iterative techni.#e.
2he && comm#nity has long been in favor of iterative development, and its safe to say that pretty m#ch
everyone involved in b#ilding the )01 is in favor of at least some form of iterative development. 0y
sense of ind#strial practice is that waterfall development is still the more common approach, however.
&ne reason for this is what * refer to as pse#doiterative development! ?eople claim to be doing iterative
development b#t are in fact doing waterfall. -ommon symptoms of this are!
"We are doing one analysis iteration followed by two design iterations. . . ."
"2his iterations code is very b#ggy, b#t well clean it #p at the end."
*t is partic#larly important that each iteration prod#ces tested, integrated code that is as close to
prod#ction .#ality as possible. 2esting and integration are the hardest activities to estimate, so its
important not to have an open7ended activity like that at the end of the pro,ect. 2he test sho#ld be that
any iteration thats not sched#led to be released co#ld be released witho#t s#bstantial extra development
work.
: common techni.#e with iterations is to #se time bo&ing. 2his forces an iteration to be a fixed length of
time. *f it appears that yo# cant b#ild all yo# intended to b#ild d#ring an iteration, yo# m#st decide to slip
some f#nctionality from the iteration@ yo# m#st not slip the date of the iteration.
0ost pro,ects that #se iterative development #se the same iteration length thro#gho#t the pro,ect@ that
way, yo# get a reg#lar rhythm of b#ilds.
* like time boxing beca#se people #s#ally have diffic#lty slipping f#nctionality. =y practicing slipping
f#nction reg#larly, they are in a better position to make an intelligent choice at a big release between
slipping a date and slipping f#nction. Slipping f#nction d#ring iterations is also effective at helping people
learn what the real re.#irements priorities are.
&ne of the most common concerns abo#t iterative development is the iss#e of rework. *terative
development explicitly ass#mes that yo# will be reworking and deleting existing code d#ring the later
iterations of a pro,ect. *n many domains, s#ch as man#fact#ring, rework is seen as a waste. =#t
software isnt like man#fact#ring@ as a res#lt, it often is more efficient to rework existing code than to
patch aro#nd code that was poorly designed. : n#mber of technical practices can greatly help make
rework be more efficient.
!utomated regression tests help by allowing yo# to .#ickly detect any defects that may have
been introd#ced when yo# are changing things. 2he x)nit family of testing frameworks is a
partic#larly val#able tool for b#ilding a#tomated #nit tests. Starting with the original C)nit
http://0unit.org, there are now ports to almost every lang#age imaginable (see
http://www.&programming.com/software.htm). : good r#le of th#mb is that the si$e of yo#r
#nit test code sho#ld be abo#t the same si$e as yo#r prod#ction code.
1efactoring is a disciplined techni.#e for changing existing software F%owler, refactoringG.
"efactoring works by #sing a series of small behavior7preserving transformations to the code base.
0any of these transformations can be a#tomated (see http://www.refactoring.com).
)ontinuous integration keeps a team in sync to avoid painf#l integration cycles F%owler and
%oemmelG. :t the heart of this lies a f#lly a#tomated b#ild process that can be kicked off
a#tomatically whenever any member of the team checks code into the code base. 6evelopers are
expected to check in daily, so a#tomated b#ilds are done many times a day. 2he b#ild process
incl#des r#nning a large block of a#tomated regression tests so that any inconsistencies are ca#ght
.#ickly so they can be fixed easily.
:ll these technical practices have been pop#lari$ed recently by Axtreme ?rogramming F=eckG,
altho#gh they were #sed before and can, and sho#ld, be #sed whether or not yo# #se +? or any other
agile process.
Predicti(e and Ada#ti(e Panning
&ne reason that the waterfall end#res is the desire for predictability in software development. (othing is
more fr#strating than not having a clear idea how m#ch it will cost to b#ild some software and how long it
will take to b#ild it.
: predictive approach looks to do work early in the pro,ect in order to yield a greater #nderstanding of
what has to be done later. 2his way, yo# can reach a point where the latter part of the pro,ect can be
estimated with a reasonable degree of acc#racy. With predictive planning, a pro,ect has two stages. 2he
first stage comes #p with plans and is diffic#lt to predict, b#t the second stage is m#ch more predictable
beca#se the plans are in place.
2his isnt necessarily a black7and7white affair. :s the pro,ect goes on, yo# grad#ally get more
predictability. :nd even once yo# have a predictive plan, things will go wrong. /o# simply expect that
the deviations become less significant once a solid plan is in place.
'owever, there is a considerable debate abo#t whether many software pro,ects can ever be predictable.
:t the heart of this .#estion is re.#irements analysis. &ne of the #ni.#e so#rces of complexity in
software pro,ects is the diffic#lty in #nderstanding the re.#irements for a software system. 2he ma,ority
of software pro,ects experience significant re2uirements churn! changes in re.#irements in the later
stages of the pro,ect. 2hese changes shatter the fo#ndations of a predictive plan. /o# can combat these
changes by free$ing the re.#irements early on and not permitting changes, b#t this r#ns the risk of
delivering a system that no longer meets the needs of its #sers.
2his problem leads to two very different reactions. &ne ro#te is to p#t more effort into the re.#irements
process itself. 2his way, yo# may get a more acc#rate set of re.#irements, which will red#ce the ch#rn.
:nother school contends that re.#irements ch#rn is #navoidable, that its too diffic#lt for many pro,ects to
stabili$e re.#irements s#fficiently to #se a predictive plan. 2his may be either owing to the sheer diffic#lty
of envisioning what software can do or beca#se market conditions force #npredictable changes. 2his
school of tho#ght advocates adaptive planning, whereby predictivity is seen as an ill#sion. *nstead of
fooling o#rselves with ill#sory predictability, we sho#ld face the reality of constant change and #se a
planning approach that treats change as a constant in a software pro,ect. 2his change is controlled so that
the pro,ect delivers the best software it can@ b#t altho#gh the pro,ect is controllable, it is not predictable.
2he difference between a predictive pro,ect and an adaptive pro,ect s#rfaces in many ways that people talk
abo#t how the pro,ect goes. When people talk abo#t a pro,ect thats doing well beca#se its going
according to plan, thats a predictive form of thinking. /o# cant say "according to plan" in an adaptive
environment, beca#se the plan is always changing. 2his doesnt mean that adaptive pro,ects dont plan@
they #s#ally plan a lot, b#t the plan is treated as a baseline to assess the conse.#ences of change rather
than as a prediction of the f#t#re.
With a predictive plan, yo# can develop a fixed7priceSfixed7scope contract. S#ch a contract says exactly
what sho#ld be b#ilt, how m#ch it will cost, and when it will be delivered. S#ch fixing isnt possible with an
adaptive plan. /o# can fix a b#dget and a time for delivery, b#t yo# cant fix what f#nctionality will be
delivered. :n adaptive contract ass#mes that the #sers will collaborate with the development team to
reg#larly reassess what f#nctionality needs to be b#ilt and will cancel the pro,ect if progress ends #p being
too slow. :s s#ch, an adaptive planning process can be fixed priceSvariable scope.
(at#rally, the adaptive approach is less desirable, as anyone wo#ld prefer greater predictability in a
software pro,ect. 'owever, predictability depends on a precise, acc#rate, and stable set of re.#irements. *f
yo# cannot stabili$e yo#r re.#irements, the predictive plan is based on sand and the chances are high that
the pro,ect goes off co#rse. 2his leads to two important pieces of advice.
1 6ont make a predictive plan #ntil yo# have precise and acc#rate re.#irements and are confident
that they wont significantly change.
2 *f yo# cant get precise, acc#rate, and stable re.#irements, #se an adaptive planning style.
?redictivity and adaptivity feed into the choice of life cycle. :n adaptive plan absol#tely re.#ires an
iterative process. ?redictive planning can be done either way, altho#gh its easier to see how it works with
waterfall or a staged delivery approach.
Agie Processes
*n the past few years, theres been a lot of interest in agile software processes. Agile is an #mbrella term
that covers many processes that share a common set of val#es and principles as defined by the 0anifesto
of :gile Software 6evelopment (http://agileManifesto.org). Axamples of these processes are Axtreme
?rogramming (+?), Scr#m, %eat#re 6riven 6evelopment (%66), -rystal, and 6S60 (6ynamic Systems
6evelopment 0ethod).
*n terms of o#r disc#ssion, agile processes are strongly adaptive in their nat#re. 2hey are also very m#ch
people7oriented processes. :gile approaches ass#me that the most important factor in a pro,ects s#ccess
is the .#ality of the people on the pro,ect and how well they work together in h#man terms. Which
process they #se and which tools they #se are strictly second7order effects.
:gile methods tend to #se short, time7boxed iterations, most often of a month or less. =eca#se they dont
attach m#ch weight to doc#ments, agile approaches disdain #sing the )01 in bl#eprint mode. 0ost #se
the )01 in sketch mode, with a few advocating #sing it as a programming lang#age.
:gile processes tend to be low in ceremony. : high7ceremony, or heavyweight, process has a lot of
doc#ments and control points d#ring the pro,ect. :gile processes consider that ceremony makes it harder
to make changes and works against the grain of talented people. :s a res#lt, agile processes are often
characteri$ed as lightweight. *ts important to reali$e that the lack of ceremony is a conse.#ence of
adaptivity and people orientation rather than a f#ndamental property.
1ationa Unified Process
:ltho#gh the "ational )nified ?rocess (")?) is independent of the )01, the two are often talked abo#t
together. So * think its worth saying a few things abo#t it here.
:ltho#gh ")? is called a process, it act#ally is a process framework, providing a vocab#lary and loose
str#ct#re to talk abo#t processes. When yo# #se ")?, the first thing yo# need to do is choose a
development case! the process yo# are going to #se in the pro,ect. 6evelopment cases can vary widely,
so dont ass#me that yo#r development case will look that m#ch like any other development case.
-hoosing a development case needs someone early on who is very familiar with ")?! someone who can
tailor ")? for a partic#lar pro,ects needs. :lternatively, there is a growing body of packaged development
cases to start from.
Whatever the development case, ")? is essentially an iterative process. : waterfall style isnt
compatible with the philosophy of ")?, altho#gh sadly its not #ncommon to r#n into pro,ects that #se a
waterfall7style process and dress it #p in ")?s clothes.
:ll ")? pro,ects sho#ld follow fo#r phases.
1 #nception makes an initial eval#ation of a pro,ect. 2ypically in inception, yo# decide whether to
commit eno#gh f#nds to do an elaboration phase.
2 %laboration identifies the primary #se cases of the pro,ect and b#ilds software in iterations in order
to shake o#t the architect#re of the system. :t the end of elaboration, yo# sho#ld have a good
sense of the re.#irements and a skeletal working system that acts as the seed of development. *n
partic#lar, yo# sho#ld have fo#nd and resolved the ma,or risks to the pro,ect.
3 )onstruction contin#es the b#ilding process, developing eno#gh f#nctionality to release.
4 *ransition incl#des vario#s late7stage activities that yo# dont do iteratively. 2hese may incl#de
deployment into the data center, #ser training, and the like.
2heres a fair amo#nt of f#$$iness between the phases, especially between elaboration and constr#ction.
%or some, the shift to constr#ction is the point at which yo# can move into a predictive planning mode. %or
others, it merely indicates the point at which yo# have a broad vision of re.#irements and an architect#re
that yo# think is going to last the rest of the pro,ect.
Sometimes, ")? is referred to as the )nified ?rocess ()?). 2his is #s#ally done by organi$ations that wish
to #se the terminology and overall style of ")? witho#t #sing the licensed prod#cts of "ational Software.
/o# can think of ")? as "ationals prod#ct offering based on the )?, or yo# can think of ")? and )? as the
same thing. Aither way, yo#ll find people who agree with yo#.
Fitting a Process to a Pro2ect
Software pro,ects differ greatly from one another. 2he way yo# go abo#t software development depends
on many factors! the kind of system yo#re b#ilding, the technology yo#re #sing, the si$e and
distrib#tion of the team, the nat#re of the risks, the conse.#ences of fail#re, the working styles of the
team, and the c#lt#re of the organi$ation. :s a res#lt, yo# sho#ld never expect there to be a one7si$e7
fits7all process that will work for all pro,ects.
-onse.#ently, yo# always have to adapt a process to fit yo#r partic#lar environment. &ne of the first
things yo# need to do is look at yo#r pro,ect and consider which processes seem close to a fit. 2his
sho#ld give yo# a short list of processes to consider.
/o# sho#ld then consider what adaptations yo# need to make to fit them to yo#r pro,ect. /o# have to be
somewhat caref#l with this. 0any processes are diffic#lt to f#lly appreciate #ntil yo#ve worked with them.
*n these cases, its often worth #sing the process o#t of the box for a co#ple of iterations #ntil yo# learn
how it works. 2hen yo# can start modifying the process. *f from the beginning yo# are more familiar with
how a process works, yo# can modify it from the beginning. "emember that its #s#ally easier to start with
too little and add things than it is to start with too m#ch and take things away.
Patterns
2he )01 tells yo# how to express an ob,ect7oriented design. ?atterns look, instead, at the res#lts of the
process! example designs.
0any people have commented that pro,ects have problems beca#se the people involved were not aware of
designs that are well known to those with more experience. ?atterns describe common ways of doing
things and are collected by people who spot repeating themes in designs. 2hese people take each theme
and describe it so that other people can read the pattern and see how to apply it.
1ets look at an example. Say that yo# have some ob,ects r#nning in a process on yo#r desktop and that
they need to comm#nicate with other ob,ects r#nning in another process. ?erhaps this process is also on
yo#r desktop@ perhaps it resides elsewhere. /o# dont want the ob,ects in yo#r system to have to worry
abo#t finding other ob,ects on the network or exec#ting remote proced#re calls.
What yo# can do is create a proxy ob,ect within yo#r local process for the remote ob,ect. 2he proxy has
the same interface as the remote ob,ect. /o#r local ob,ects talk to the proxy, #sing the #s#al in7process
message sends. 2he proxy then is responsible for passing any messages on to the real ob,ect, wherever
it might reside.
?roxies are a common techni.#e #sed in networks and elsewhere. ?eople have a lot of experience #sing
proxies, knowing how they can be #sed, what advantages they can bring, their limitations, and how to
implement them. 0ethods books like this one dont disc#ss this knowledge@ all they disc#ss is how yo#
can diagram a proxy, altho#gh #sef#l, is not as #sef#l as disc#ssing the experience involving proxies.
*n the early 3DD5s, some people began to capt#re this experience. 2hey formed a comm#nity
interested in writing patterns. 2hese people sponsor conferences and have prod#ced several books.
2he most famo#s patterns book to emerge from this gro#p is FBang of %o#rG, which disc#sses 4I design
patterns in detail. *f yo# want to know abo#t proxies, this book spends ten pages on the s#b,ect, giving
details abo#t how the ob,ects work together, the benefits and limitations of the pattern, common
variations, and implementation tips.
: pattern is m#ch more than a model. : pattern m#st also incl#de the reason why it is the way it is. *t is
often said that a pattern is a sol#tion to a problem. 2he pattern m#st identify the problem clearly, explain
why it solves the problem, and also explain the circ#mstances #nder which the pattern works and doesnt
work.
?atterns are important beca#se they are the next stage beyond #nderstanding the basics of a lang#age
or a modeling techni.#e. ?atterns give yo# a series of sol#tions and also show yo# what makes a good
model and how yo# go abo#t constr#cting a model. ?atterns teach by example.
When * started o#t, * wondered why * had to invent things from scratch. Why didnt * have handbooks to
show me how to do common things8 2he patterns comm#nity is trying to b#ild these handbooks.
2here are now many patterns books o#t there, and they vary greatly in .#ality. 0y favorites are FBang
of %o#rG, F?&S:3G, F?&S:4G, F-ore C4AA ?atternsG, F?ontG, and with s#itable immodesty F%owler, :?G and
F%owler, ? of A::G. /o# can also take a look at the patterns home page!
http://www.hillside.net/patterns.
'owever confident yo# are with yo#r process when yo# begin, its essential to learn as yo# go along.
*ndeed, one of the great benefits of iterative development is that it s#pports fre.#ent process
improvement.
:t the end of each iteration, cond#ct an iteration retrospective, whereby the team assembles to
consider how things went and how they can be improved. : co#ple of ho#rs is plenty if yo#r iterations are
short. : good way to do this is to make a list with three categories!
1 Keep: things that worked well that yo# want to ens#re yo# contin#e to do
2 roblems: areas that arent working well
3 !ry: changes to yo#r process to improve it
/o# can start each iteration retrospective after the first by reviewing the items from the previo#s session
and seeing how things have changed. 6ont forget the list of things to keep@ its important to keep track of
things that are working. *f yo# dont do that, yo# can lose a sense of perspective on the pro,ect and
potentially stop paying attention to winning practices.
:t the end of a pro,ect or at a ma,or release, yo# may want to consider a more formal pro0ect
retrospective that will last a co#ple of days@ see http://www.retrospectives.com/ and F>erthG for
more details. &ne of my biggest irritations is how organi$ations consistently fail to learn from their own
experience and end #p making expensive mistakes time and time again.
Fitting the UML into a Process
When they look at graphical modeling lang#ages, people #s#ally think of them in the context of a
waterfall process. : waterfall process #s#ally has doc#ments that act as the handoffs between analysis,
design, and coding phases. Braphical models can often form a ma,or part of these doc#ments. *ndeed,
many of the str#ct#red methods from the 3DE5s and 3D;5s talk a lot abo#t analysis and design models
like this.
Whether or not yo# #se a waterfall approach, yo# still do the activities of analysis, design, coding, and
testing. /o# can r#n an iterative pro,ect with 37week iterations, with each week a miniwaterfall.
)sing the )01 doesnt necessarily imply developing doc#ments or feeding a complex -:SA tool. 0any
people draw )01 diagrams on whiteboards only d#ring a meeting to help comm#nicate their ideas.
1e)uire!ents Anaysis
2he activity of re.#irements analysis involves trying to fig#re o#t what the #sers and c#stomers of a
software effort want the system to do. : n#mber of )01 techni.#es can come in handy here!
)se cases, which describe how people interact with the system.
: class diagram drawn from the concept#al perspective, which can be a good way of b#ilding #p a
rigoro#s vocab#lary of the domain.
:n activity diagram, which can show the work flow of the organi$ation, showing how software and
h#man activities interact. :n activity diagram can show the context for #se cases and also the
details of how a complicated #se case works.
: state diagram, which can be #sef#l if a concept has an interesting life cycle, with vario#s states
and events that change that state.
When working in re.#irements analysis, remember that the most important thing is comm#nication with
yo#r #sers and c#stomers. )s#ally, they are not software people and will be #nfamiliar with the )01 or any
other techni.#e. Aven so, *ve had s#ccess #sing these techni.#es with nontechnical people. 2o do this,
remember that its important to keep the notation to a minim#m. 6ont introd#ce anything that specific to
the software implementation.
=e prepared to break the r#les of the )01 at any time if it helps yo# comm#nicate better. 2he biggest risk
with #sing the )01 in analysis is that yo# draw diagrams that the domain experts dont f#lly #nderstand.
: diagram that isnt #nderstood by the people who know the domain is worse than #seless@ all it does is
breed a false sense of confidence for the development team.
"esign
When yo# are doing design, yo# can get more technical with yo#r diagrams. /o# can #se more
notation and be more precise abo#t yo#r notation. Some #sef#l techni.#es are
-lass diagrams from a software perspective. 2hese show the classes in the software and how they
interrelate.
Se.#ence diagrams for common scenarios. : val#able approach is to pick the most important and
interesting scenarios from the #se cases and #se -"- cards or se.#ence diagrams to fig#re o#t
what happens in the software.
?ackage diagrams to show the large7scale organi$ation of the software.
State diagrams for classes with complex life histories.
6eployment diagrams to show the physical layo#t of the software.
0any of these same techni.#es can be #sed to doc#ment software once its been written. 2his may help
people find their way aro#nd the software if they have to work on it and are not familiar with the code.
With a waterfall life cycle, yo# wo#ld do these diagrams and activities as part of the phases. 2he end7of7
phase doc#ments #s#ally incl#de the appropriate )01 diagrams for that activity. : waterfall style #s#ally
implies that the )01 is #sed as a bl#eprint.
*n an iterative style, the )01 diagrams can be #sed in either a bl#eprint or a sketch style. With a
bl#eprint, the analysis diagrams will #s#ally be b#ilt in the iteration prior to the one that b#ilds the
f#nctionality. Aach iteration doesnt start from scratch@ rather, it modifies the existing body of
doc#ments, highlighting the changes in the new iteration.
=l#eprint designs are #s#ally done early in the iteration and may be done in pieces for different bits of
f#nctionality that are targeted for the iteration. :gain, iteration implies making changes to an existing
model rather than b#ilding a new model each time.
)sing the )01 in sketch mode implies a more fl#id process. &ne approach is to spend a co#ple of days
at the beginning of an iteration, sketching o#t the design for that iteration. /o# can also do short design
sessions at any point d#ring the iteration, setting #p a .#ick meeting for half an ho#r whenever a
developer starts to tackle a nontrivial f#nction.
With a bl#eprint, yo# expect the code implementation to follow the diagrams. : change from the
bl#eprint is a deviation that needs review from the designers who did the bl#eprint. : sketch is #s#ally
treated more as a first c#t at the design@ if, d#ring coding, people find that the sketch isnt exactly right,
they sho#ld feel free to change the design. 2he implementors have to #se their ,#dgment as to whether
the change needs a wider disc#ssion to #nderstand the f#ll ramifications.
&ne of my concerns with bl#eprints is my own observation that its very hard to get them right, even for a
good designer. * often find that my own designs do not s#rvive contact with coding intact. * still find )01
sketches #sef#l, b#t * dont find that they can be treated as absol#tes.
*n both modes, it makes sense to explore a n#mber of design alternatives. *ts #s#ally best to explore
alternatives in sketch mode so that yo# can .#ickly generate and change the alternatives. &nce yo# pick
a design to r#n with, yo# can either #se that sketch or detail it into a bl#eprint.
"ocu!entation
&nce yo# have b#ilt the software, yo# can #se the )01 to help doc#ment what yo# have done. %or this, *
find )01 diagrams #sef#l for getting an overall #nderstanding of a system. *n doing this, however, *
sho#ld stress that * do not believe in prod#cing detailed diagrams of the whole system. 2o .#ote Ward
-#nningham F-#nninghamG!
"arefully selected and #ell$#ritten memos can easily substitute for traditional
comprehensive design documentation% !he latter rarely shines except in isolated
spots% &levate those spots % % % and forget about the rest% 'p% ()*+
* believe that detailed doc#mentation sho#ld be generated from the codeTlike, for instance, Cava6oc. /o#
sho#ld write additional doc#mentation to highlight important concepts. 2hink of these as comprising a first
step for the reader before he or she goes into the code7based details. * like to str#ct#re these as prose
doc#ments, short eno#gh to read over a c#p of coffee, #sing )01 diagrams to help ill#strate the
disc#ssion. * prefer the diagrams as sketches that highlight the most important parts of the system.
&bvio#sly, the writer of the doc#ment needs to decide what is important and what isnt, b#t the writer is
m#ch better e.#ipped than the reader to do that.
: package diagram makes a good logical road map of the system. 2his diagram helps me #nderstand the
logical pieces of the system and see the dependencies and keep them #nder control. : deployment
diagram (see -hapter ;), which shows the high7level physical pict#re, may also prove #sef#l at this stage.
Within each package, * like to see a class diagram. * dont show every operation on every class. * show
only the important feat#res that help me #nderstand what is in there. 2his class diagram acts as a
graphical table of contents.
2he class diagram sho#ld be s#pported by a handf#l of interaction diagrams that show the most
important interactions in the system. :gain, selectivity is important here@ remember that, in this kind
of doc#ment, comprehensiveness is the enemy of comprehensibility.
*f a class has complex life7cycle behavior, * draw a state machine diagram (see -hapter 35) to describe
it. * do this only if the behavior is s#fficiently complex, which * find doesnt happen often.
*ll often incl#de some important code, written in a literate program style. *f a partic#larly complex
algorithm is involved, *ll consider #sing an activity diagram (see -hapter 33) b#t only if it gives me more
#nderstanding than the code alone.
*f * find concepts that are coming #p repeatedly, * #se patterns (page 4E) to capt#re the basic ideas.
&ne of the most important things to doc#ment is the design alternatives yo# didnt take and why yo# didnt
do them. 2hats often the most forgotten b#t most #sef#l piece of external doc#mentation yo# can provide.
Understanding Legacy Code
2he )01 can help yo# fig#re o#t a gnarly b#nch of #nfamiliar code in a co#ple of ways. =#ilding a sketch
of key facts can act as a graphical note7taking mechanism that helps yo# capt#re important information
as yo# learn abo#t it. Sketches of key classes in a package and their key interactions can help clarify
whats going on.
With modern tools, yo# can generate detailed diagrams for key parts of a system. 6ont #se these tools
to generate big paper reports@ instead, #se them to drill into key areas as yo# are exploring the code
itself. : partic#larly nice capability is that of generating a se.#ence diagram to see how m#ltiple ob,ects
collaborate in handling a complex method.
Choosing a "e(eo#!ent Process
*m strongly in favor of iterative development processes. :s *ve said in this book before! /o# sho#ld #se
iterative development only on pro,ects that yo# want to s#cceed.
?erhaps thats a bit glib, b#t as * get older, * get more aggressive abo#t #sing iterative development. 6one
well, it is an essential techni.#e, one yo# can #se to expose risk early and to obtain better control over
development. *t is not the same as having no management, altho#gh to be fair, * sho#ld point o#t that
some have #sed it that way. *t does need to be well planned. =#t it is a solid approach, and every &&
development book enco#rages #sing itTfor good reason.
/o# sho#ld not be s#rprised to hear that as one the a#thors of the 0anifesto for :gile Software
6evelopment, *m very m#ch a fan of agile approaches. *ve also had a lot of positive experiences with
Axtreme ?rogramming, and certainly yo# sho#ld consider its practices very serio#sly.
Where to Find 'ut More
=ooks on software process have always been common, and the rise of agile software development has led
to many new books. &verall, my favorite book on process in general is F0c-onnellG. 'e gives a broad and
practical coverage of many of the iss#es involved in software development and a long list of #sef#l
practices.
%rom the agile comm#nity, F-ockb#rn, agileG and F'ighsmithG provide a good overview. %or a lot of good
advice abo#t applying the )01 in an agile way, see F:mblerG.
&ne of the most pop#lar agile methods is Axtreme ?rogramming (+?), which yo# can delve into via s#ch
Web sites as http://&programming.com and http://www.e&tremeprogramming.org. +? has
spawned many books, which is why * now refer to it as the formerly lightweight methodology. 2he #s#al
starting point is F=eckG.
:ltho#gh its written for +?, F=eck and %owlerG gives more details on planning an iterative pro,ect. 0#ch
of this is also covered by the other +? books, b#t if yo#re interested only in the planning aspect, this
wo#ld be a good choice.
%or more information on the "ational )nified ?rocess, my favorite introd#ction is F>r#chtenG.
Cha#ter 3% Cass "iagra!s4 The Essentias
*f someone were to come #p to yo# in a dark alley and say, "?sst, wanna see a )01 diagram8" that
diagram wo#ld probably be a class diagram. 2he ma,ority of )01 diagrams * see are class diagrams.
2he class diagram is not only widely #sed b#t also s#b,ect to the greatest range of modeling concepts.
:ltho#gh the basic elements are needed by everyone, the advanced concepts are #sed less often.
2herefore, *ve broken my disc#ssion of class diagrams into two parts! the essentials (this chapter) and the
advanced (-hapter K).
: class diagram describes the types of ob,ects in the system and the vario#s kinds of static relationships
that exist among them. -lass diagrams also show the properties and operations of a class and the
constraints that apply to the way ob,ects are connected. 2he )01 #ses the term feature as a general
term that covers properties and operations of a class.
%ig#re I.3 shows a simple class model that wo#ld not s#rprise anyone who has worked with order
processing. 2he boxes in the diagram are classes, which are divided into three compartments! the name of
the class (in bold), its attrib#tes, and its operations. %ig#re I.3 also shows two kinds of relationships
between classes! associations and generali$ations.
Pro#erties
"roperties represent str#ct#ral feat#res of a class. :s a first approximation, yo# can think of properties
as corresponding to fields in a class. 2he reality is rather involved, as we shall see, b#t thats a
reasonable place to start.
?roperties are a single concept, b#t they appear in two .#ite distinct notations! attrib#tes and
associations. :ltho#gh they look .#ite different on a diagram, they are really the same thing.
Attri+utes
2he attribute notation describes a property as a line of text within the class box itself. 2he f#ll form of an
attrib#te is!
visibility name: type multiplicity = default {property-string}
:n example of this is!
-name: String [1] = "Untitled" {readnly}
&nly the name is necessary.
2his visibility marker indicates whether the attrib#te is p#blic (R) or private (7)@ *ll disc#ss other
visibilities on page ;I.
2he name of the attrib#teThow the class refers to the attrib#teTro#ghly corresponds to the name
of a field in a programming lang#age.
2he type of the attrib#te indicates a restriction on what kind of ob,ect may be placed in the
attrib#te. /o# can think of this as the type of a field in a programming lang#age.
*ll explain multiplicity on page I;.
2he default value is the val#e for a newly created ob,ect if the attrib#te isnt specified d#ring
creation.
2he {property-string} allows yo# to indicate additional properties for the attrib#te. *n the
example, * #sed {readnly} to indicate that clients may not modify the property. *f this is missing,
yo# can #s#ally ass#me that the attrib#te is modifiable. *ll describe other property strings as we
go.
Associations
2he other way to notate a property is as an association. 0#ch of the same information that yo# can show
on an attrib#te appears on an association. %ig#res I.4 and I.I show the same properties represented in
the two different notations.
Figure -.(. $howing properties of an order as attributes
:n association is a solid line between two classes, directed from the so#rce class to the target class. 2he
name of the property goes at the target end of the association, together with its m#ltiplicity. 2he target
end of the association links to the class that is the type of the property.
:ltho#gh most of the same information appears in both notations, some items are different. *n
partic#lar, associations can show m#ltiplicities at both ends of the line.
With two notations for the same thing, the obvio#s .#estion is, Why sho#ld yo# #se one or the other8 *n
general, * tend to #se attrib#tes for small things, s#ch as dates or =ooleansTin general, val#e types (page
EI)Tand associations for more significant classes, s#ch as c#stomers and orders. * also tend to prefer to
#se class boxes for classes that are significant for the diagram, which leads to #sing associations, and
attrib#tes for things less important for that diagram. 2he choice is m#ch more abo#t emphasis than abo#t
any #nderlying meaning.
When to Use Cass "iagra!s
-lass diagrams are the backbone of the )01, so yo# will find yo#rself #sing them all the time. 2his
chapter covers the basic concepts@ -hapter K disc#sses many of the advanced concepts.
2he tro#ble with class diagrams is that they are so rich, they can be overwhelming to #se. 'ere are a few
tips.
1 6ont try to #se all the notations available to yo#. Start with the simple st#ff in this chapter!
classes, associations, attrib#tes, generali$ation, and constraints. *ntrod#ce other notations from
-hapter K only when yo# need them.
2 *ve fo#nd concept#al class diagrams very #sef#l in exploring the lang#age of a b#siness. %or this to
work, yo# have to work hard on keeping software o#t of the disc#ssion and keeping the notation
very simple.
3 6ont draw models for everything@ instead, concentrate on the key areas. *t is better to have a few
diagrams that yo# #se and keep #p to date than to have many forgotten, obsolete models.
2he biggest danger with class diagrams is that yo# can foc#s excl#sively on str#ct#re and ignore
behavior. 2herefore, when drawing class diagrams to #nderstand software, always do them in
con,#nction with some form of behavioral techni.#e. *f yo#re going well, yo#ll find yo#rself swapping
between the techni.#es fre.#ently.
Where to Find 'ut More
:ll the general )01 books * mentioned in -hapter 3 talk abo#t class diagrams in more detail.
6ependency management is a critical feat#re of larger pro,ects. 2he best book on this topic is
F0artinG.
Muti#icity
2he multiplicity of a property is an indication of how many ob,ects may fill the property. 2he most
common m#ltiplicities yo# will see are
1 ' (:n order m#st have exactly one c#stomer.)
2 3..' (: corporate c#stomer may or may not have a single sales rep.)
4 (: c#stomer need not place an &rder and there is no #pper limit to the n#mber of &rders a
-#stomer may placeT$ero or more orders.)
0ore generally, m#ltiplicities are defined with a lower bo#nd and an #pper bo#nd, s#ch as 4..J for
players of a game of canasta. 2he lower bo#nd may be any positive n#mber or $ero@ the #pper is any
positive n#mber or Y (for #nlimited). *f the lower and #pper bo#nds are the same, yo# can #se one
n#mber@ hence, 3 is e.#ivalent to 3..3. =eca#se its a common case, Y is short for 5..Y.
*n attrib#tes, yo# come across vario#s terms that refer to the m#ltiplicity.
+ptional implies a lower bo#nd of 5.
Mandatory implies a lower bo#nd of 3 or possibly more.
$ingle-valued implies an #pper bo#nd of 3.
Multivalued implies an #pper bo#nd of more than 3! #s#ally Y.
*f * have a m#ltival#ed property, * prefer to #se a pl#ral form for its name.
=y defa#lt, the elements in a m#ltival#ed m#ltiplicity form a set, so if yo# ask a c#stomer for its orders,
they do not come back in any order. *f the ordering of the orders in association has meaning, yo# need to
add {ordered} to the association end. *f yo# want to allow d#plicates, add {nonuni!ue}. (*f yo# want to
explicitly show the defa#lt, yo# can #se {unordered} and {uni!ue}.) /o# may also see collection7
oriented names, s#ch as {bag} for #nordered, non#ni.#e.
)01 3 allowed discontin#o#s m#ltiplicities, s#ch as 4, J (meaning 4 or J, as in cars in the days
before minivans). 6iscontin#o#s m#ltiplicities werent very common and )01 4 removed them.
2he defa#lt m#ltiplicity of an attrib#te is F3G. :ltho#gh this is tr#e in the meta7model, yo# cant ass#me
that an attrib#te in a diagram thats missing a m#ltiplicity has a val#e of F3G, as the diagram may be
s#ppressing the m#ltiplicity information. :s a res#lt, * prefer to explicitly state a F3G m#ltiplicity if its
important.
Progra!!ing &nter#retation of Pro#erties
:s with anything else in the )01, theres no one way to interpret properties in code. 2he most common
software representation is that of a field or property of yo#r programming lang#age. So the &rder 1ine
class from %ig#re I.3 wo#ld correspond to something like the following in Cava!
public class rder"ine###
private int !uantity$
private %oney price$
private rder order$
private &roduct product
*n a lang#age like -H, which has properties, it wo#ld correspond to!
public class rder"ine ###
public int 'uantity$
public %oney &rice$
public rder rder$
public &roduct &roduct$
(ote that an attrib#te typically corresponds to p#blic properties in a lang#age that s#pports properties
b#t to private fields in a lang#age that does not. *n a lang#age witho#t properties, yo# may see the fields
exposed thro#gh accessor (getting and setting) methods. : read7only attrib#te will have no setting
method (with fields) or set action (for properties). (ote that if yo# dont give a name for a property, its
common to #se the name of the target class.
)sing private fields is a very implementation7foc#sed interpretation of the diagram. : more interface7
oriented interpretation might instead concentrate on the getting methods rather than the #nderlying
data. *n this case, we might see the &rder 1ines attrib#tes corresponding to the following methods!
public class rder"ine###
private int !uantity$
private &roduct product$
public int get'uantity() {
return !uantity$
C
public void set'uantity(int !uantity) {
t*is#!uantity = !uantity$
C
public %oney get&rice() {
return product#get&rice()#multiply(!uantity)$
C
*n this case, there is no data field for price@ instead, its a comp#ted val#e. =#t as far as clients of the
&rder 1ine class are concerned, it looks the same as a field. -lients cant tell what is a field and what is
comp#ted. 2his information hiding is the essence of encaps#lation.
*f an attrib#te is m#ltival#ed, this implies that the data concerned is a collection. So an &rder class wo#ld
refer to a collection of &rder 1ines. =eca#se this m#ltiplicity is ordered, that collection m#st be ordered,
(s#ch as a 1ist in Cava or an *1ist in .(A2). *f the collection is #nordered, it sho#ld, strictly, have no
meaningf#l order and th#s be implemented with a set, b#t most people implement #nordered attrib#tes
as lists as well. Some people #se arrays, b#t the )01 implies an #nlimited #pper bo#nd, so * almost
always #se a collection for data str#ct#re.
0#ltival#ed properties yield a different kind of interface to single7val#ed properties (in Cava)!
class rder {
private Set line+tems = ne, -as*Set()$
public Set get"ine+tems() {
return .ollections#unmodifiableSet(line+tems)$
C
public void add"ine+tem (rder+tem arg) {
line+tems#add (arg)$
C
public void remove"ine+tem (rder+tem arg) {
line+tems#remove(arg)$
C
*n most cases, yo# dont assign to a m#ltival#ed property@ instead, yo# #pdate with add and remove
methods. *n order to control its 1ine *tems property, the order m#st control membership of that collection@
as a res#lt, it sho#ldnt pass o#t the naked collection. *n this case, * #sed a protection proxy to provide a
read7only wrapper to the collection. /o# can also provide a non#pdatable iterator or make a copy. *ts okay
for clients to modify the member ob,ects, b#t the clients sho#ldnt directly change the collection itself.
=eca#se m#ltival#ed attrib#tes imply collections, yo# almost never see collection classes on a class
diagram. /o# wo#ld show them only in very low level implementation diagrams of collections themselves.
/o# sho#ld be very afraid of classes that are nothing b#t a collection of fields and their accessors. &b,ect7
oriented design is abo#t providing ob,ects that are able to do rich behavior, so they sho#ldnt be simply
providing data to other ob,ects. *f yo# are making repeated calls for data by #sing accessors, thats a sign
that some behavior sho#ld be moved to the ob,ect that has the data.
2hese examples also reinforce the fact that there is no hard7and7fast correspondence between the )01 and
code, yet there is a similarity. Within a pro,ect team, team conventions will lead to a closer
correspondence.
Whether a property is implemented as a field or as a calc#lated val#e, it represents something an ob,ect
can always provide. /o# sho#ldnt #se a property to model a transient relationship, s#ch as an ob,ect that
is passed as a parameter d#ring a method call and #sed only within the confines of that interaction.
Bidirectiona Associations
2he associations weve looked at so far are called #nidirectional associations. :nother common kind of
association is a bidirectional association, s#ch as %ig#re I.J.
Figure -.5. ! bidirectional association
: bidirectional association is a pair of properties that are linked together as inverses. 2he -ar class has
property o,ner:&erson[1], and the ?erson class has a property cars:.ar[/]. ((ote how * named the
cars property in the pl#ral form of the propertys type, a common b#t non7normative convention.)
2he inverse link between them implies that if yo# follow both properties, yo# sho#ld get back to a set
that contains yo#r starting point. %or example, if * begin with a partic#lar 0B 0idget, find its owner, and
then look at its owners cars, that set sho#ld contain the 0idget that * started from.
:s an alternative to labeling an association by a property, many people, partic#larly if they have a data7
modeling backgro#nd, like to label an association by #sing a verb phrase (%ig#re I.K) so that the
relationship can be #sed in a sentence. 2his is legal and yo# can add an arrow to the association to avoid
ambig#ity. 0ost ob,ect modelers prefer to #se a property name, as that corresponds better to
responsibilities and operations.
Figure -.6. Using a verb phrase to name an association
Some people name every association in some way. * choose to name an association only when doing so
improves #nderstanding. *ve seen too many associations with s#ch names as "has" or "is related to."
*n %ig#re I.J, the bidirectional nat#re of the association is made obvio#s by the navigability arrows at
both ends of the association. %ig#re I.K has no arrows@ the )01 allows yo# to #se this form either to
indicate a bidirectional association or when yo# arent showing navigability. 0y preference is to #se the
do#ble7headed arrow of %ig#re I.J when yo# want to make it clear that yo# have a bidirectional
association.
*mplementing a bidirectional association in a programming lang#age is often a little tricky beca#se yo#
have to be s#re that both properties are kept synchroni$ed. )sing -H, * #se code along these lines to
implement a bidirectional association!
class .ar###
public &erson ,ner {
get {return 0o,ner$}
set {
if (0o,ner 1= null) 0o,ner#friend.ars()#2emove(t*is)$
0o,ner = value$
if (0o,ner 1= null) 0o,ner#friend.ars()#3dd(t*is)$
}
}
private &erson 0o,ner$
###
class &erson ###
public +"ist .ars {
get {return 3rray"ist#2eadnly(0cars)$}
}
public void 3dd.ar(.ar arg) {
arg#,ner = t*is$
}
private +"ist 0cars = ne, 3rray"ist()$
internal +"ist friend.ars() {
44s*ould only be used
by .ar#,ner
return 0cars$
}
####
2he primary thing is to let one side of the associationTa single7val#ed side, if possibleTcontrol the
relationship. %or this to work, the slave end (?erson) needs to leak the encaps#lation of its data to the
master end. 2his adds to the slave class an awkward method, which sho#ldnt really be there, #nless the
lang#age has fine7grained access control. *ve #sed the naming convention of "friend" here as a nod to -R
R, where the masters setter wo#ld indeed be a friend. 1ike m#ch property code, this is pretty boilerplate
st#ff, which is why many people prefer to #se some form of code generation to prod#ce it.
*n concept#al models, navigability isnt an important iss#e, so * dont show any navigability arrows on
concept#al models.
'#erations
+perations are the actions that a class knows to carry o#t. &perations most obvio#sly correspond to the
methods on a class. (ormally, yo# dont show those operations that simply manip#late properties,
beca#se they can #s#ally be inferred.
2he f#ll )01 syntax for operations is!
visibility name (parameter-list) : return-type {property-string}
1 2his visibility marker is p#blic (R) or private (7)@ others on page ;I.
2 2he name is a string.
3 2he parameter-list is the list of parameters for the operation.
4 2he return-type is the type of the ret#rned val#e, if there is one.
5 2he property-string indicates property val#es that apply to the given operation.
2he parameters in the parameter list are notated in a similar way to attrib#tes. 2he form is!
direction name: type = default value
2he name, type, and default value are the same as for attrib#tes.
2he direction indicates whether the parameter is inp#t (in), o#tp#t (out) or both (inout). *f no
direction is shown, its ass#med to be in.
:n example operation on acco#nt might be!
5 balancen (date: 6ate) : %oney
With concept#al models, yo# sho#ldnt #se operations to specify the interface of a class. *nstead, #se
them to indicate the principal responsibilities of that class, perhaps #sing a co#ple of words
s#mmari$ing a -"- responsibility (page LK).
* often find it #sef#l to disting#ish between operations that change the state of the system and those that
dont. )01 defines a 2uery as an operation that gets a val#e from a class witho#t changing the system
stateTin other words, witho#t side effects./o# can mark s#ch an operation with the property string
{!uery}. * refer to operations that do change state as modifiers, also called commands.
Strictly, the difference between .#ery and modifiers is whether they change the observable state F0eyerG.
2he observable state is what can be perceived from the o#tside. :n operation that #pdates a cache wo#ld
alter the internal state b#t wo#ld have no effect thats observable from the o#tside.
* find it helpf#l to highlight .#eries, as yo# can change the order of exec#tion of .#eries and not change
the system behavior. : common convention is to try to write operations so that modifiers do not ret#rn a
val#e@ that way, yo# can rely on the fact that operations that ret#rn a val#e are .#eries. F0eyerG refers to
this as the -ommand79#ery separation principle. *ts sometimes awkward to do this all the time, b#t yo#
sho#ld do it as m#ch as yo# can.
&ther terms yo# sometimes see are getting methods and setting methods. : getting method ret#rns
a val#e from a field (and does nothing else). : setting method p#ts a val#e into a field (and does
nothing else). %rom the o#tside, a client sho#ld not be able to tell whether a .#ery is a getting method
or a modifier is a setting method. >nowledge of getting and setting methods is entirely internal to the
class.
:nother distinction is between operation and method. :n operation is something that is invoked on an
ob,ectTthe proced#re declarationTwhereas a method is the body of a proced#re. 2he two are different
when yo# have polymorphism. *f yo# have a s#pertype with three s#btypes, each of which overrides the
s#pertypes get&rice operation, yo# have one operation and fo#r methods that implement it.
?eople #s#ally #se the terms operation and method interchangeably, b#t there are times when it is #sef#l
to be precise abo#t the difference.
-enerai5ation
: typical example of generali7ation involves the personal and corporate c#stomers of a b#siness. 2hey
have differences b#t also many similarities. 2he similarities can be placed in a general -#stomer class
(the s#pertype), with ?ersonal -#stomer and -orporate -#stomer as s#btypes.
2his phenomenon is also s#b,ect to vario#s interpretations at the vario#s perspectives of modeling.
-oncept#ally, we can say that -orporate -#stomer is a s#btype of -#stomer if all instances of -orporate
-#stomer are also, by definition, instances of -#stomer. : -orporate -#stomer is then a special kind of
-#stomer. 2he key idea is that everything we say abo#t a -#stomerTassociations, attrib#tes, operations
Tis tr#e also for a -orporate -#stomer.
With a software perspective, the obvio#s interpretation is inheritance! 2he -orporate -#stomer is a
s#bclass of -#stomer. *n mainstream && lang#ages, the s#bclass inherits all the feat#res of the
s#perclass and may override any s#perclass methods.
:n important principle of #sing inheritance effectively is substitutability. * sho#ld be able to s#bstit#te
a -orporate -#stomer within any code that re.#ires a -#stomer, and everything sho#ld work fine.
Assentially, this means that if * write code ass#ming * have a -#stomer, * can freely #se any s#btype of
-#stomer. 2he -orporate -#stomer may respond to certain commands differently from another
-#stomer, #sing polymorphism, b#t the caller sho#ld not need to worry abo#t the difference. (%or more
on this, see the 1iskov S#bstit#tion ?rinciple (1S?) in F0artinG.)
:ltho#gh inheritance is a powerf#l mechanism, it brings in a lot of baggage that isnt always needed to
achieve s#bstit#tability. : good example of this was in the early days of Cava, when many people didnt like
the implementation of the b#ilt7in Mector class and wanted to replace it with something lighter. 'owever,
the only way they co#ld prod#ce a class that was s#bstit#table for Mector was to s#bclass it, and that
meant inheriting a lot of #nwanted data and behavior.
0any other mechanisms can be #sed to provide s#bstit#table classes. :s a res#lt, many people like to
differentiate between s#btyping, or interface inheritance, and s#bclassing, or implementation inheritance.
: class is a subtype if it is s#bstit#table for its s#pertype, whether or not it #ses inheritance.
$ubclassing is #sed as a synonym for reg#lar inheritance.
0any other mechanisms are available that allow yo# to have s#btyping witho#t s#bclassing. Axamples are
implementing an interface (page LD) and many of the standard design patterns FBang of %o#rG.
.otes and Co!!ents
(otes are comments in the diagrams. (otes can stand on their own, or they can be linked with a
dashed line to the elements they are commenting (%ig#re I.L). 2hey can appear in any kind of
diagram.
Figure -.8. ! note is used as a comment on one or more diagram elements
2he dashed line can sometimes be awkward beca#se yo# cant position exactly where this line ends. So a
common convention is to p#t a very small open circle at the end of the line. Sometimes, its #sef#l to have
an in7line comment on a diagram element. /o# can do this by prefixing the text with two dashes! 77.
"e#endency
: dependency exists between two elements if changes to the definition of one element (the supplier)
may ca#se changes to the other (the client). With classes, dependencies exist for vario#s reasons! &ne
class sends a message to another@ one class has another as part of its data@ one class mentions another as
a parameter to an operation. *f a class changes its interface, any message sent to that class may no longer
be valid.
:s comp#ter systems grow, yo# have to worry more and more abo#t controlling dependencies. *f
dependencies get o#t of control, each change to a system has a wide ripple effect as more and more things
have to change. 2he bigger the ripple, the harder it is to change anything.
2he )01 allows yo# to depict dependencies between all sorts of elements. /o# #se dependencies
whenever yo# want to show how changes in one element might alter other elements.
%ig#re I.E shows some dependencies that yo# might find in a m#ltilayered application. 2he =enefits
Window classTa #ser interface, or presentation classTis dependent on the Amployee class! a domain
ob0ect that capt#res the essential behavior of the systemTin this case, b#siness r#les. 2his means that if
the employee class changes its interface, the =enefits Window may have to change.
2he important thing here is that the dependency is in only one direction and goes from the presentation
class to the domain class. 2his way, we know that we can freely alter the =enefits Window witho#t those
changes having any effect on the Amployee or other domain ob,ects. *ve fo#nd that a strict separation of
presentation and domain logic, with the presentation depending on the domain b#t not vice versa, has
been a val#able r#le for me to follow.
: second notable thing from this diagram is that there is no direct dependency from the =enefits Window
to the two 6ata Bateway classes. *f these classes change, the Amployee class may have to change. =#t if
the change is only to the implementation of the Amployee class, not its interface, the change stops there.
2he )01 has many varieties of dependency, each with partic#lar semantics and keywords. 2he basic
dependency that *ve o#tlined here is the one * find the most #sef#l, and * #s#ally #se it witho#t keywords.
2o add more detail, yo# can add an appropriate keyword (2able I.3).
2he basic dependency is not a transitive relationship. :n example of a transitive relationship is the "larger
beard" relationship. *f Cim has a larger beard than Brady, and Brady has a larger beard than *var, we can
ded#ce that Cim has a larger beard than *var. Some kind of dependencies, s#ch as s#bstit#te, are
transitive, b#t in most cases there is a significant difference between direct and indirect dependencies, as
there is in %ig#re I.E.
0any )01 relationships imply a dependency. 2he navigable association from &rder to -#stomer in %ig#re
I.3 means that &rder is dependent on -#stomer. : s#bclass is dependent on its s#perclass b#t not vice
versa.
*able -.'. $elected ependency 9eywords
9eyword Meaning
7call8
2he so#rce calls an operation in the target.
7create8
2he so#rce creates instances of the target.
7derive8
2he so#rce is derived from the target.
7instantiate8 2he so#rce is an instance of the target. ((ote that if the so#rce is a
class, the class itself is an instance of the class class@ that is, the target
class is a metaclass).
7permit8 9*e target allo,s t*e source to access t*e target:s private
features#
7reali;e8 9*e source is an implementation of a specification or interface
defined by t*e target (page <=)#
7refine8 2efinement indicates a relations*ip bet,een different semantic
levels$ for e>ample? t*e source mig*t be a design class and t*e
target t*e corresponding analysis class#
7substitute8 9*e source is substitutable for t*e target (page @A)#
7trace8 Used to tracB suc* t*ings as re!uirements to classes or *o,
c*anges in one model /o#r general r#le sho#ld be to minimi$e
dependencies, partic#larly when they cross large areas of a system. *n
partic#lar, yo# sho#ld be wary of cycles, as they can lead to a cycle of
changes. *m not s#per strict on this. * dont mind m#t#al dependencies
between closely related classes, b#t * do try to eliminate cycles at a
broader level, partic#larly between packages.
*able -.'. $elected ependency 9eywords
9eyword Meaning
link to changes elsewhere.
7use8 2he so#rce re.#ires the target for its implementation.
T+9-,7 .' 15'? 0** .56 36=6,36,:-61 -, 0 :*011 3-07+0< -1 0, 6D6+:-16 -, 4(.-*-.9E .56+6 0+6 .'' <0,9
0,3 .569 :50,76 .'' <(:5. B6 16*6:.-/6 0,3 15'? 36=6,36,:-61 ',*9 ?56, .569 0+6 3-+6:.*9 +6*6/0,.
.' .56 =0+.-:(*0+ .'=-: .50. 9'( ?0,. .' :'<<(,-:0.6. T' (,36+1.0,3 0,3 :',.+'* 36=6,36,:-61@ 9'(
0+6 861. '44 (1-,7 .56< ?-.5 =0:2076 3-07+0<1 A=0761 "$B.
T56 <'1. :'<<', :016 I (16 4'+ 36=6,36,:-61 ?-.5 :*01161 -1 ?56, -**(1.+0.-,7 0 .+0,1-6,.
+6*0.-',15-=@ 1(:5 01 ?56, ',6 '8>6:. -1 =01163 .' 0,'.56+ 01 0 =0+0<6.6+. #'( <09 166 .5616 (163
?-.5 269?'+31 7parameter8, 7local8, and 7global8. /o# may also see these keywords on
associations in )01 3 models, in which case they indicate transient links, not properties.
2hese keywords are not part of )01 4.
6ependencies can be determined by looking at code, so tools are ideal for doing
dependency analysis. Betting a tool to reverse engineer pict#res of dependencies is the
most #sef#l way to #se this bit of the )01.
Constraint 1ues
0#ch of what yo# are doing in drawing a class diagram is indicating constraints. %ig#re I.3 indicates that
an &rder can be placed only by a single -#stomer. 2he diagram also implies that each 1ine *tem is tho#ght
of separately! /o# say "J5 brown widgets, J5 bl#e widgets, and J5 red widgets," not "345 things" on the
&rder. %#rther, the diagram says that -orporate -#stomers have credit limits b#t ?ersonal -#stomers do
not.
2he basic constr#cts of association, attrib#te, and generali$ation do m#ch to specify important constraints,
b#t they cannot indicate every constraint. 2hese constraints still need to be capt#red@ the class diagram is
a good place to do that.
2he )01 allows yo# to #se anything to describe constraints. 2he only r#le is that yo# p#t them inside
braces (Z[). /o# can #se nat#ral lang#age, a programming lang#age, or the )01s formal &b,ect
-onstraint 1ang#age (&-1) FWarmer and >leppeG, which is based on predicate calc#l#s. )sing a formal
notation avoids the risk of misinterpretation d#e to an ambig#o#s nat#ral lang#age. 'owever, it introd#ces
the risk of misinterpretation d#e to writers and readers not really #nderstanding &-1. So #nless yo# have
readers who are comfortable with predicate calc#l#s, *d s#ggest #sing nat#ral lang#age.
&ptionally, yo# can name a constraint by p#tting the name first, followed by a colon@ for example,
Zdisallow incest! h#sband and wife m#st not be siblings[.
"esign +y Contract
6esign by -ontract is a design techni.#e developed by =ertrand 0eyer F0eyerG. 2he techni.#e is a central
feat#re of the Aiffel lang#age he developed. 6esign by -ontract is not specific to Aiffel, however@ it is a
val#able techni.#e that can be #sed with any programming lang#age.
:t the heart of 6esign by -ontract is the assertion. :n assertion is a =oolean statement that sho#ld never
be false and, therefore, will be false only beca#se of a b#g. 2ypically, assertions are checked only d#ring
deb#g and are not checked d#ring prod#ction exec#tion. *ndeed, a program sho#ld never ass#me that
assertions are being checked.
6esign by -ontract #ses three partic#lar kinds of assertions! post7conditions, preconditions, and invariants.
?re7conditions and post7conditions apply to operations. : postcondition is a statement of what the world
sho#ld look like after exec#tion of an operation. %or instance, if we define the operation "s.#are root" on a
n#mber, the postcondition wo#ld take the form input , result - result, where result is the o#tp#t and input
is the inp#t val#e. 2he post7condition is a #sef#l way of saying what we do witho#t saying how we do itTin
other words, of separating interface from implementation.
: pre-condition is a statement of how we expect the world to be before we exec#te an operation. We
might define a pre7condition for the "s.#are root" operation of input . , /. S#ch a pre7condition says that
it is an error to invoke "s.#are root" on a negative n#mber and that the conse.#ences of doing so are
#ndefined.
&n first glance, this seems a bad idea, beca#se we sho#ld p#t some check somewhere to ens#re that
"s.#are root" is invoked properly. 2he important .#estion is who is responsible for doing so.
2he pre7condition makes it explicit that the caller is responsible for checking. Witho#t this explicit
statement of responsibilities, we can get either too little checkingTbeca#se both parties ass#me that the
other is responsibleTor too m#chTboth parties check. 2oo m#ch checking is a bad thing beca#se it leads
to a lot of d#plicate checking code, which can significantly increase the complexity of a program. =eing
explicit abo#t who is responsible helps to red#ce this complexity. 2he danger that the caller forgets to
check is red#ced by the fact that assertions are #s#ally checked d#ring deb#gging and testing.
%rom these definitions of pre7condition and post7condition, we can see a strong definition of the term
e&ception. :n exception occ#rs when an operation is invoked with its precondition satisfied yet cannot
ret#rn with its post7condition satisfied.
:n invariant is an assertion abo#t a class. %or instance, an :cco#nt class may have an invariant that says
that balance ,, sum'entries%amount'++. 2he invariant is "always" tr#e for all instances of the class. 'ere,
"always" means "whenever the ob,ect is available to have an operation invoked on it."
*n essence, this means that the invariant is added to pre7conditions and post7conditions associated with
all p#blic operations of the given class. 2he invariant may become false d#ring exec#tion of a method,
b#t it sho#ld be restored to tr#e by the time any other ob,ect can do anything to the receiver.
:ssertions can play a #ni.#e role in s#bclassing. &ne of the dangers of inheritance is that yo# co#ld
redefine a s#bclasss operations to be inconsistent with the s#perclasss operations. :ssertions red#ce the
chances of this. 2he invariants and post7conditions of a class m#st apply to all s#bclasses. 2he s#bclasses
can choose to strengthen these assertions b#t cannot weaken them. 2he pre7condition, on the other
hand, cannot be strengthened b#t may be weakened.
2his looks odd at first, b#t it is important to allow dynamic binding. /o# sho#ld always be able to treat a
s#bclass ob,ect as if it were an instance of the s#perclass, per the principle of s#bstit#tability. *f a s#bclass
strengthened its pre7condition, a s#perclass operation co#ld fail when applied to the s#bclass.
Cha#ter 6% Se)uence "iagra!s
#nteraction diagrams describe how gro#ps of ob,ects collaborate in some behavior. 2he )01 defines
several forms of interaction diagram, of which the most common is the se.#ence diagram.
2ypically, a se.#ence diagram capt#res the behavior of a single scenario. 2he diagram shows a n#mber of
example ob,ects and the messages that are passed between these ob,ects within the #se case.
2o begin the disc#ssion, *ll consider a simple scenario. We have an order and are going to invoke a
command on it to calc#late its price. 2o do that, the order needs to look at all the line items on the order
and determine their prices, which are based on the pricing r#les of the order lines prod#cts. 'aving done
that for all the line items, the order then needs to comp#te an overall disco#nt, which is based on r#les tied
to the c#stomer.
%ig#re J.3 is a se.#ence diagram that shows one implementation of that scenario. Se.#ence diagrams
show the interaction by showing each participant with a lifeline that r#ns vertically down the page and the
ordering of messages by reading down the page.
&ne of the nice things abo#t a se.#ence diagram is that * almost dont have to explain the notation. /o#
can see that an instance of order sends get'uantity and get&roduct messages to the order line. /o# can
also see how we show the order invoking a method on itself and how that method sends
get6iscount+nfoto an instance of c#stomer.
2he diagram, however, doesnt show everything very well. 2he se.#ence of messages get'uantity,
get&roduct, get&ricing6etails, and calculateCase&rice needs to be done for each order line on the
order, while calculate6iscounts is invoked ,#st once. /o# cant tell that from this diagram, altho#gh *ll
introd#ce some more notation to handle that later.
0ost of the time, yo# can think of the participants in an interaction diagram as ob,ects, as indeed they
were in )01 3. =#t in )01 4, their roles are m#ch more complicated, and to explain it all f#lly is beyond
this book. So * #se the term participants, a word that isnt #sed formally in the )01 spec. *n )01 3,
participants were ob,ects and so their names were #nderlined, b#t in )01 4, they sho#ld be shown
witho#t the #nderline, as *ve done here.
*n these diagrams, *ve named the participants #sing the style anrder. 2his works well most of the time.
: f#ller syntax is name : .lass, where both the name and the class are optional, b#t yo# m#st keep the
colon if yo# #se the class. (%ig#re J.J, shown on page K;, #ses this style.)
Aach lifeline has an activation bar that shows when the participant is active in the interaction. 2his
corresponds to one of the participants methods being on the stack. :ctivation bars are optional in )01,
b#t * find them extremely val#able in clarifying the behavior. 0y one exception is when exploring a design
d#ring a design session, beca#se they are awkward to draw on whiteboards.
(aming often is #sef#l to correlate participants on the diagram. 2he call get&roduct is shown ret#rning
a&roduct, which is the same name, and therefore the same participant, as the a&roduct that the
get&ricing6etailscall is sent to. (ote that *ve #sed a ret#rn arrow for only this call@ * did that to show
the correspondance. Some people #se ret#rns for all calls, b#t * prefer to #se them only where they add
information@ otherwise, they simply cl#tter things. Aven in this case, yo# co#ld probably leave the ret#rn
o#t witho#t conf#sing yo#r reader.
2he first message doesnt have a participant that sent it, as it comes from an #ndetermined so#rce. *ts
called a found message.
%or another approach to this scenario, take a look at %ig#re J.4. 2he basic problem is still the same, b#t
the way in which the participants collaborate to implement it is very different. 2he &rder asks each &rder
1ine to calc#late its own ?rice. 2he &rder 1ine itself f#rther hands off the calc#lation to the ?rod#ct@ note
how we show the passing of a parameter. Similarly, to calc#late the disco#nt, the &rder invokes a method
on the -#stomer. =eca#se it needs information from the &rder to do this, the -#stomer makes a reentrant
call (getCaseDalue) to the &rder to get the data.
2he first thing to note abo#t these two diagrams is how clearly the se.#ence diagram indicates the
differences in how the participants interact. 2his is the great strength of interaction diagrams. 2hey arent
good at showing details of algorithms, s#ch as loops and conditional behavior, b#t they make the calls
between participants crystal clear and give a really good pict#re abo#t which participants are doing which
processing.
2he second thing to note is the clear difference in styles between the two interactions. %ig#re J.3 is
centrali7ed control, with one participant pretty m#ch doing all the processing and other participants
there to s#pply data. %ig#re J.4 #ses distributed control, in which the processing is split among many
participants, each one doing a little bit of the algorithm.
=oth styles have their strengths and weaknesses. 0ost people, partic#larly those new to ob,ects, are more
#sed to centrali$ed control. *n many ways, its simpler, as all the processing is in one place@ with
distrib#ted control, in contrast, yo# have the sensation of chasing aro#nd the ob,ects, trying to find the
program.
6espite this, ob,ect bigots like me strongly prefer distrib#ted control. &ne of the main goals of good
design is to locali$e the effects of change. 6ata and behavior that accesses that data often change
together. So p#tting the data and the behavior that #ses it together in one place is the first r#le of ob,ect7
oriented design.
%#rthermore, by distrib#ting control, yo# create more opport#nities for #sing polymorphism rather than
#sing conditional logic. *f the algorithms for prod#ct pricing are different for different types of prod#ct,
the distrib#ted control mechanism allows #s to #se s#bclasses of prod#ct to handle these variations.
*n general the && style is to #se a lot of little ob,ects with a lot of little methods that give #s a lot of pl#g
points for overriding and variation. 2his style is very conf#sing to people #sed to long proced#res@ indeed,
this change is the heart of the paradigm shift of ob,ect orientation. *ts something thats very diffic#lt to
teach. *t seems that the only way to really #nderstand it is to work in an && environment with strongly
distrib#ted control for a while. 0any people then say that they get a s#dden "aha" when the style makes
sense. :t this point, their brains have been rewired, and they start thinking that decentrali$ed control is
act#ally easier.
Creating and "eeting Partici#ants
Se.#ence diagrams show some extra notation for creating and deleting participants (%ig#re J.I). 2o create
a participant, yo# draw the message arrow directly into the participant box. : message name is optional
here if yo# are #sing a constr#ctor, b#t * #s#ally mark it with "new" in any case. *f the participant
immediately does something once its created, s#ch as the .#ery command, yo# start an activation right
after the participant box.
Figure 5.-. )reation and deletion of participants
6eletion of a participant is indicated by big +. : message arrow going into the + indicates one participant
explicitly deleting another@ an + at the end of a lifeline shows a participant deleting itself.
*n a garbage7collected environment, yo# dont delete ob,ects directly, b#t its still worth #sing the + to
indicate when an ob,ect is no longer needed and is ready to be collected. *ts also appropriate for close
operations, indicating that the ob,ect isnt #sable any more.
Loo#s7 Conditionas7 and the Like
: common iss#e with se.#ence diagrams is how to show looping and conditional behavior. 2he first thing
to point o#t is that this isnt what se.#ence diagrams are good at. *f yo# want to show control str#ct#res
like this, yo# are better off with an activity diagram or indeed with code itself. 2reat se.#ence diagrams as
a vis#ali$ation of how ob,ects interact rather than as a way of modeling control logic.
2hat said, heres the notation to #se. =oth loops and conditionals #se interaction frames, which are
ways of marking off a piece of a se.#ence diagram. %ig#re J.J shows a simple algorithm based on the
following pse#docode!
Figure 5.5. #nteraction frames
procedure dispatc*
foreac* (lineitem)
if (product#value E F1GH)
careful#dispatc*
else
regular#dispatc*
end if
end for
if (needs.onfirmation) messenger#confirm
end procedure
*n general, frames consist of some region of a se.#ence diagram that is divided into one or more
fragments. Aach frame has an operator and each fragment may have a g#ard. (2able J.3 lists common
operators for interaction frames.) 2o show a loop, yo# #se the loop operand with a single fragment and
p#t the basis of the iteration in the g#ard. %or conditional logic, yo# can #se an alt operator and p#t a
condition on each fragment. &nly the fragment whose g#ard is tr#e will exec#te. *f yo# have only one
region, there is an opt operator.
*nteraction frames are new in )01 4. :s a res#lt, yo# may see diagrams prepared before )01 4 and that
#se a different approach@ also, some people dont like the frames and prefer some of the older
conventions. %ig#re J.K shows some of these #nofficial tweaks.
Figure 5.6. +lder conventions for control logic
)01 3 #sed iteration markers and g#ards. :n iteration marker is a Y added to the message name. /o#
can add some text in s.#are brackets to indicate the basis of the iteration. :uards are a conditional
expression placed in s.#are brackets and indicate that the message is sent only if the g#ard is tr#e. While
these notations have been dropped from se.#ence diagrams in )01 4, they are still legal on
comm#nication diagrams.
*able 5.'. )ommon +perators for #nteraction Frames
+perator Meaning
alt
:lternative m#ltiple fragments@ only the one whose condition is
tr#e will exec#te (%ig#re J.J). opt &ptional@ the
fragment exec#tes only if the s#pplied condition is tr#e.
A.#ivalent to an alt with only one trace (%ig#re J.J).
par ?arallel@ each fragment is r#n in parallel. loop 1oop@ the fragment may exec#te m#ltiple times, and
the g#ard indicates the basis of
iteration (%ig#re J.J). region -ritical region@ the fragment can have only one thread
exec#ting it at once. neg (egative@ the fragment shows an invalid interaction. ref "eference@ refers to an
interaction defined on another diagram. 2he frame is drawn to
cover the lifelines involved in the interaction. /o# can
define parameters and a ret#rn val#e. sd Se.#ence
diagram@ #sed to s#rro#nd an entire se.#ence diagram, if
yo# wish.
:ltho#gh iteration markers and g#ards can help, they do have weaknesses. 2he g#ards cant indicate
that a set of g#ards are m#t#ally excl#sive, s#ch as the two on %ig#re J.K. =oth notations work only with
a single message send and dont work well when several messages coming o#t of a single activation are
within the same loop or conditional block.
2o get aro#nd this last problem, an #nofficial convention thats become pop#lar is to #se a
pseudomessage, with the loop condition or the g#ard on a variation of the self7call notation. *n %ig#re
J.K, *ve shown this witho#t a message arrow@ some people incl#de a message arrow, b#t leaving it o#t
helps reinforce that this isnt a real call. Some also like to gray shade the pse#domessages activation
bar. *f yo# have alterative behavior, yo# can show that with an alternative marker between the
activations.
:ltho#gh * find activations very helpf#l, they dont add m#ch in the case of the dispatc* method,
whereby yo# send a message and nothing else happens within the receivers activation. : common
convention that *ve shown on %ig#re J.K is to drop the activation for those simple calls.
2he )01 standard has no graphic device to show passing data@ instead, its shown by parameters in the
message name and ret#rn arrows. ata tadpoles have been aro#nd in many methods to indicate the
movement of data, and many people still like to #se them with the )01.
:ll in all, altho#gh vario#s schemes can add notation for conditional logic to se.#ence diagrams, * dont
find that they work any better than code or at least pse#docode. *n partic#lar, * find the interaction
frames very heavy, obsc#ring the main point of the diagram, so * prefer pse#domessages.
Synchronous and Asynchronous Cas
*f yo#re exceptionally alert, yo#ll have noticed that the arrowheads in the last co#ple of diagrams are
different from the arrowheads earlier on. 2hat minor difference is .#ite important in )01 4. *n )01 4,
filled arrowheads show a synchrono#s message, while stick arrowheads show an asynchrono#s message.
*f a caller sends a synchronous message, it m#st wait #ntil the message is done, s#ch as invoking a
s#bro#tine. *f a caller sends an asynchronous message, it can contin#e processing and doesnt have to
wait for a response. /o# see asynchrono#s calls in m#ltithreaded applications and in message7oriented
middleware. :synchrony gives better responsiveness and red#ces the temporal co#pling b#t is harder to
deb#g.
2he arrowhead difference is very s#btle@ indeed, rather too s#btle. *ts also a backward7incompatible
change introd#ced in )01 3.J, before then an asynchrono#s message was shown with the half7stick
arrowhead, as in %ig#re J.K.
* think that this arrowhead distinction is too s#btle. *f yo# want to highlight asynchrono#s messages, *
wo#ld recommend #sing the obsolete half7stick arrowhead, which draws the eye m#ch better to an
important distinction. *f yo#re reading a se.#ence diagram, beware of making ass#mptions abo#t
synchrony from the arrowheads #nless yo#re s#re that the a#thor is intentionally making the distinction.
When to Use Se)uence "iagra!s
/o# sho#ld #se se.#ence diagrams when yo# want to look at the behavior of several ob,ects within a
single #se case. Se.#ence diagrams are good at showing collaborations among the ob,ects@ they are not
so good at precise definition of the behavior.
*f yo# want to look at the behavior of a single ob,ect across many #se cases, #se a state diagram (see
-hapter 35). *f yo# want to look at behavior across many #se cases or many threads, consider an activity
diagram (see -hapter 33).
*f yo# want to explore m#ltiple alternative interactions .#ickly, yo# may be better off with -"- cards,
as that avoids a lot of drawing and erasing. *ts often handy to have a -"- card session to explore
design alternatives and then #se se.#ence diagrams to capt#re any interactions that yo# want to refer
to later.
&ther #sef#l forms of interaction diagrams are comm#nication diagrams, for showing connections@ and
timing diagrams, for showing timing constraints.
C1C Cards
&ne of the most val#able techni.#es in coming #p with a good && design is to explore ob,ect interactions,
beca#se it foc#ses on behavior rather than data. -"- (-lass7"esponsibility7-ollaboration) diagrams,
invented by Ward -#nningham in the late 3D;5s, have stood the test of time as a highly effective way to
do this (%ig#re J.L). :ltho#gh they arent part of the )01, they are a very pop#lar techni.#e among skilled
ob,ect designers.
2o #se -"- cards, yo# and yo#r colleag#es gather aro#nd a table. 2ake vario#s scenarios and act them
o#t with the cards, picking them #p in the air when they are active and moving them to s#ggest how they
send messages to each other and pass them aro#nd. 2his techni.#e is almost impossible to describe in a
book yet is easily demonstrated@ the best way to learn it is to have someone who has done it show it to
yo#.
:n important part of -"- thinking is identifying responsibilities. : responsibility is a short sentence that
s#mmari$es something that an ob,ect sho#ld do! an action the ob,ect performs, some knowledge the
ob,ect maintains, or some important decisions the ob,ect makes. 2he idea is that yo# sho#ld be able to
take any class and s#mmari$e it with a handf#l of responsibilities. 6oing that can help yo# think more
clearly abo#t the design of yo#r classes.
2he second - refers to collaborators! the other classes that this class needs to work with. 2his gives
yo# some idea of the links between classesTstill at a high level.
&ne of the chief benefits of -"- cards is that they enco#rage animated disc#ssion among the developers.
When yo# are working thro#gh a #se case to see how classes will implement it, the interaction diagrams
in this chapter can be slow to draw. )s#ally, yo# need to consider alternatives@ with diagrams, the
alternatives can take too long to draw and r#b o#t. With -"- cards, yo# model the interaction by picking
#p the cards and moving them aro#nd. 2his allows yo# to .#ickly consider alternatives.
:s yo# do this, yo# form ideas abo#t responsibilities and write them on the cards. 2hinking abo#t
responsibilities is important, beca#se it gets yo# away from the notion of classes as d#mb data holders and
eases the team members toward #nderstanding the higher7level behavior of each class. : responsibility
may correspond to an operation, to an attrib#te, or, more likely, to an #ndetermined cl#mp of attrib#tes
and operations.
: common mistake * see people make is generating long lists of low7level responsibilities. =#t doing so
misses the point. 2he responsibilities sho#ld easily fit on one card. :sk yo#rself whether the class sho#ld
be split or whether the responsibilities wo#ld be better stated by rolling them #p into higher7level
statements.
0any people stress the importance of role playing, whereby each person on the team plays the role of
one or more classes. *ve never seen Ward -#nningham do that, and * find that role playing gets in the
way.
=ooks have been written on -"-, b#t *ve fo#nd that they never really get to the heart of the techni.#e.
2he original paper on -"-, written with >ent =eck, is F=eck and -#nninghamG. 2o learn more abo#t both
-"- cards and responsibilities in design, take a look at FWirfs7=rockG.
Cha#ter 8% Cass "iagra!s4 Ad(anced
Conce#ts
2he concepts described in -hapter I correspond to the key notations in class diagrams. 2hose concepts are
the first ones to #nderstand and become familiar with, as they will comprise D5 percent of yo#r effort in
b#ilding class diagrams.
2he class diagram techni.#e, however, has bred do$ens of notations for additional concepts. * find that *
dont #se these all the time, b#t they are handy when they are appropriate. *ll disc#ss them one at a
time and point o#t some of the iss#es in #sing them.
/o#ll probably find this chapter somewhat heavy going. 2he good news is that d#ring yo#r first pass
thro#gh the book, yo# can safely skip this chapter and come back to it later.
9eywords
&ne of the challenges of a graphical lang#age is that yo# have to remember what the symbols mean. With
too many, #sers find it very diffic#lt to remember what all the symbols mean. So the )01 often tries to
red#ce the n#mber of symbols and #se keywords instead. *f yo# find that yo# need a modeling constr#ct
that isnt in the )01 b#t is similar to something that is, #se the symbol of the existing )01 constr#ct b#t
mark it with a keyword to show that yo# have something different
:n example of this is the interface. : )01 interface (page LD) is a class that has only p#blic operations,
with no method bodies. 2his corresponds to interfaces in Cava, -&0 (-omponent &b,ect 0od#le), and
-&"=:. =eca#se its a special kind of class, it is shown #sing the class icon with the keyword 7interface8.
>eywords are #s#ally shown as text between g#illemets. :s an alternative to keywords, yo# can #se
special icons, b#t then yo# r#n into the iss#e of everyone having to remember what they mean.
Some keywords, s#ch as {abstract}, show #p in c#rly brackets. *ts never really clear what sho#ld
technically be in g#illemets and what sho#ld be in c#rlies. %ort#nately, if yo# get it wrong, only serio#s
)01 weenies will noticeTor care.
Some keywords are so common that they often get abbreviated! 7interface8 often gets abbreviated to
7+8 and {abstract} to {3}. S#ch abbreviations are very #sef#l, partic#larly on whiteboards, b#t
nonstandard, so if yo# #se them, make s#re yo# find a spot to spell o#t what they
mean.
*n )01 3, the g#illemets were #sed mainly for stereotypes. *n )01 4, stereotypes are defined very
tightly, and describing what is and isnt a stereotype is beyond the scope of this book. 'owever, beca#se of
)01 3, many people #se the term stereotype to mean the same as 0ey#ord, altho#gh that is no longer
correct.
Stereotypes are #sed as part of profiles. : profile takes a part of the )01 and extends it with a coherent
gro#p of stereotypes for a partic#lar p#rpose, s#ch as b#siness modeling. 2he f#ll semantics of profiles are
beyond this book. )nless yo# are into serio#s meta7model design, yo#re #nlikely to need to create one
yo#rself. /o#re more likely to #se one created for a specific modeling p#rpose, b#t fort#nately, #se of a
profile doesnt re.#ire yo# to know the gory details of how they are tied into the meta7model.
Cassification and -enerai5ation
* often hear people talk abo#t s#btyping as the is a relationship. * #rge yo# to beware of that way of
thinking. 2he problem is that the phrase is a can mean different things.
-onsider the following phrases.
1 Shep is a =order -ollie.
2 : =order -ollie is a 6og.
3 6ogs are :nimals.
4 : =order -ollie is a =reed.
5 6og is a Species.
(ow try combining the phrases. *f * combine phrases 3 and 4, * get "Shep is a 6og"@ 4 and I taken
together yield "=order -ollies are :nimals." :nd 3 pl#s 4 pl#s I gives me "Shep is an :nimal." So far, so
good. (ow try 3 and J! "Shep is a =reed." 2he combination of 4 and K is ": =order -ollie is a Species."
2hese are not so good.
Why can * combine some of these phrases and not others8 2he reason is that some are classification
Tthe ob,ect Shep is an instance of the type =order -ollieTand some are generali7ationTthe type
=order -ollie is a s#btype of the type 6og. Benerali$ation is transitive@ classification is not. * can
combine a classification followed by a generali$ation b#t not vice versa.
* make this point to get yo# to be wary of is a. )sing it can lead to inappropriate #se of s#bclassing and
conf#sed responsibilities. =etter tests for s#btyping in this case wo#ld be the phrases "6ogs are kinds of
:nimals" and "Avery instance of a =order -ollie is an instance of a 6og."
2he )01 #ses the generali$ation symbol to show generali$ation. *f yo# need to show classification, #se a
dependency with the 7instantiate8 keyword.
Muti#e and "yna!ic Cassification
)lassification refers to the relationship between an ob,ect and its type. 0ainstream programming
lang#ages ass#me that an ob,ect belongs to a single class. =#t there are more options to classification
than that.
*n single classification, an ob,ect belongs to a single type, which may inherit from s#pertypes. *n
multiple classification, an ob,ect may be described by several types that are not necessarily connected
by inheritance.
0#ltiple classification is different from m#ltiple inheritance. 0#ltiple inheritance says that a type may have
many s#pertypes b#t that a single type m#st be defined for each ob,ect. 0#ltiple classification allows
m#ltiple types for an ob,ect witho#t defining a specific type for the p#rpose.
%or example, consider a person s#btyped as either man or woman, doctor or n#rse, patient or not (see
%ig#re K.33). 0#ltiple classification allows an ob,ect to have any of these types assigned to it in any
allowable combination, witho#t the need for types to be defined for all the legal combinations.
*f yo# #se m#ltiple classification, yo# need to be s#re that yo# make it clear which combinations are legal.
)01 4 does this by placing each generali$ation relationship into a generali7ation set. &n the class
diagram, yo# label the generali$ation arrowhead with the name of the generali$ation set, which in )01 3
was called the discriminator. Single classification corresponds to a single generali$ation set with no name.
Benerali$ation sets are by defa#lt dis,oint! :ny instance of the s#pertype may be an instance of only one of
the s#btypes within that set. *f yo# roll #p generali$ations into a single arrow, they m#st all be part of the
same generali$ation set, as shown in %ig#re K.33. :lternatively, yo# can have several arrows with the same
text label.
2o ill#strate, note the following legal combinations of s#btypes in the diagram! (%emale, ?atient, (#rse)@
(0ale, ?hysiotherapist)@ (%emale, ?atient)@ and (%emale, 6octor, S#rgeon). 2he combination (?atient,
6octor, (#rse) is illegal beca#se it contains two types from the role generali$ation set.
:nother .#estion is whether an ob,ect may change its class. %or example, when a bank acco#nt is
overdrawn, it s#bstantially changes its behavior. Specifically, several operations, incl#ding "withdraw"
and "close," get overridden.
ynamic classification allows ob,ects to change class within the s#btyping str#ct#re@ static
classification does not. With static classification, a separation is made between types and states@
dynamic classification combines these notions.
Sho#ld yo# #se m#ltiple, dynamic classification8 * believe that it is #sef#l for concept#al modeling. %or
software perspectives, however, the distance between it and the implementations is too m#ch of a leap. *n
the vast ma,ority of )01 diagrams, yo#ll see only single static classification, so that sho#ld be yo#r
defa#lt.
Association Cass
!ssociation classes allow yo# to add attrib#tes, operations, and other feat#res to associations, as
shown in %ig#re K.34. We can see from the diagram that a person may attend many meetings. We
need to keep information abo#t how awake that person was@ we can do this by adding the attrib#te
attentiveness to the association.
%ig#re K.3I shows another way to represent this information! 0ake :ttendance a f#ll class in its own right.
(ote how the m#ltiplicities have moved.
Figure 6.'-. "romoting an association class to a full class
What benefit do yo# gain with the association class to offset the extra notation yo# have to remember8 2he
association class adds an extra constraint, in that there can be only one instance of the association class
between any two participating ob,ects. * feel the need for another example.
2ake a look at the two diagrams in %ig#re K.3J. 2hese diagrams have m#ch the same form. 'owever, we
can imagine one -ompany playing different roles in the same -ontract, b#t its harder to imagine a ?erson
having m#ltiple competencies in the same skill@ indeed, yo# wo#ld probably consider that an error.
Figure 6.'5. !ssociation class subtleties .1ole should probably not be an
association class/
*n the )01, only the latter case is legal. /o# can have only one competency for each combination of ?erson
and Skill. 2he top diagram in %ig#re K.3J wo#ld not allow a -ompany to have more than one "ole on a
single contract. *f yo# need to allow this, yo# need to make "ole a f#ll class, in the style of %ig#re K.3I.
*mplementing association classes isnt terribly obvio#s. 0y advice is to implement an association class as
if it where a f#ll class b#t to provide methods that get information to the classes linked by the
association class. So for %ig#re K.34, * wo#ld see the following methods on ?erson!
class &erson
"ist get3ttendances()
"ist get%eetings()
2his way, a client of ?erson can get hold of the people at the meeting@ if they want details, they can get
the :ttendances themselves. *f yo# do this, remember to enforce the constraint that there can be only
one :ttendance ob,ect for any pair of ?erson and 0eeting. /o# sho#ld place a check in whichever method
creates the :ttendance.
/o# often find this kind of constr#ct with historical information, s#ch as in %ig#re K.3K. 'owever, * find
that creating extra classes or association classes can make the model tricky to #nderstand, as well as tilt
the implementation in a partic#lar direction thats often #ns#itable.
Figure 6.'6. Using a class for a temporal relationship
*f * have this kind of temporal information, * #se a 7temporal8 keyword on the association (see %ig#re
K.3L). 2he model indicates that a ?erson may work for only a single -ompany at one time.
&ver time, however, a ?erson may work for several -ompanies. 2his s#ggests an interface along the lines
of!
class &erson ###
.ompany getImployer()$44get current employer
.ompany getImployer(6ate)$44get employer at a given date
void c*angeImployer(.ompany ne,Imployer?6ate c*ange6ate)$
void leaveImployer (6ate c*ange6ate)$
2he 7temporal8 keyword is not part of the )01, b#t * mention it here for two reasons. %irst, it is a notion
* have fo#nd #sef#l on several occasions in my modeling career. Second, it shows how yo# can #se
keywords to extend the )01. /o# can read a lot more abo#t this at
http://martinfowler.com/ap(/time;arrative.html.
Te!#ate :Para!eteri5ed; Cass
Several lang#ages, most noticeably -RR, have the notion of a parameteri7ed class, or template.
(2emplates are on the list to be incl#ded in Cava and -H in the near f#t#re.)
2his concept is most obvio#sly #sef#l for working with collections in a strongly typed lang#age. 2his way,
yo# can define behavior for sets in general by defining a template class Set.
class Set J9E {
void insert (9 ne,Ilement)$
void remove (9 anIlement)$
When yo# have done this, yo# can #se the general definition to make Set classes for more specific
elements!
Set JImployeeE employeeSet$
/o# declare a template class in the )01 by #sing the notation shown in %ig#re K.3E. 2he 2 in the
diagram is a placeholder for the type parameter. (/o# may have more than one.)
: #se of a parameteri$ed class, s#ch as SetJImployeeE, is called a derivation. /o# can show a derivation
in two ways. 2he first way mirrors the -RR syntax (see %ig#re K.3;). /o# describe the derivation
expression within angle brackets in the form Jparameter-name::parameter-valueE. *f theres only one
parameter, conventional #se often omits the parameter name. 2he alternative notation (see %ig#re K.3D)
reinforces the link to the template and allows yo# to rename the bo#nd element.
Figure 6.'<. ,ound element .version '/
2he 7bind8 keyword is a stereotype on the refinement relationship. 2his relationship indicates that
ImployeeSet will conform to the interface of Set. /o# can think of the ImployeeSet as a s#btype of Set.
2his fits the other way of implementing type7specific collections, which is to declare all appropriate
s#btypes.
)sing a derivation is not the same as s#btyping, however. /o# are not allowed to add feat#res to the bo#nd
element, which is completely specified by its template@ yo# are adding only restricting type information. *f
yo# want to add feat#res, yo# m#st create a s#btype.
Enu!erations
An#merations (%ig#re K.45) are #sed to show a fixed set of val#es that dont have any properties other
than their symbolic val#e. 2hey are shown as the class with the 7enumeration8 keyword.
Figure 6.(3. %numeration
Acti(e Cass
:n active class has instances, each of which exec#tes and controls its own thread of control. 0ethod
invocations may exec#te in a clients thread or in the active ob,ects thread. : good example of this is a
command processor that accepts command ob,ects from the o#tside and then exec#tes the commands
within its own thread of control.
2he notation for active classes has changed from )01 3 to )01 4, as shown in %ig#re K.43. *n )01 4, an
active class has extra vertical lines on the side@ in )01 3, it had a thick border and was called an active
ob,ect.
<isi+iity
=isibility is a s#b,ect that is simple in principle b#t has complex s#btleties. 2he simple idea is that any
class has p#blic and private elements. ?#blic elements can be #sed by any other class@ private elements
can be #sed only by the owning class. 'owever, each lang#age makes its own r#les. :ltho#gh many
lang#ages #se s#ch terms as public, private, and protected, they mean different things in different
lang#ages. 2hese differences are small, b#t they lead to conf#sion, especially for those of #s who #se
more than one lang#age.
2he )01 tries to address this witho#t getting into a horrible tangle. Assentially, within the )01, yo# can tag
any attrib#te or operation with a visibility indicator. /o# can #se any marker yo# like, and its meaning is
lang#age dependent. 'owever, the )01 provides fo#r abbreviations for visibility! > (p#blic), ? (private), \
(package), and @ (protected). 2hese fo#r levels are #sed within the )01 meta7model and are defined
within it, b#t their definitions vary s#btly from those in other lang#ages.
When yo# are #sing visibility, #se the r#les of the lang#age in which yo# are working. When yo# are
looking at a )01 model from elsewhere, be wary of the meanings of the visibility markers, and be aware
of how those meanings can change from lang#age to lang#age.
0ost of the time, * dont draw visibility markers in diagrams@ * #se them only if * need to highlight the
differences in visibility of certain feat#res. Aven then, * can mostly get away with R and ], which at least
are easy to remember.
Messages
Standard )01 does not show any information abo#t message calls on class diagrams. 'owever, *ve
sometimes seen conventional diagrams like %ig#re K.44.
2hese add arrows to the sides of associations. 2he arrows are labeled with the messages that one ob,ect
sends to another. =eca#se yo# dont need an association to a class to send a message to it, yo# may also
need to add a dependency arrow to show messages between classes that arent associated.
2his message information spans m#ltiple #se cases, so they arent n#mbered to show se.#ences, #nlike
comm#nication diagrams.
1es#onsi+iities
&ften, its handy to show responsibilities (page LI) on a class in a class diagram. 2he best way to show
them is as comment strings in their own compartment in the class (%ig#re K.3). /o# can name the
compartment, if yo# wish, b#t * #s#ally dont, as theres rarely any potential for conf#sion.
Figure 6.'. $howing responsibilities in a class diagram
Static '#erations and Attri+utes
2he )01 refers to an operation or an attrib#te that applies to a class rather than to an instance as static.
2his is e.#ivalent to static members in -7based lang#ages. Static feat#res are #nderlined on a class
diagram (see %ig#re K.4).
Aggregation and Co!#osition
&ne of the most fre.#ent so#rces of conf#sion in the )01 is aggregation and composition. *ts easy to
explain glibly! !ggregation is the part7of relationship. *ts like saying that a car has an engine and wheels
as its parts. 2his so#nds good, b#t the diffic#lt thing is considering what the difference is between
aggregation and association.
*n the pre7)01 days, people were #s#ally rather vag#e on what was aggregation and what was
association. Whether vag#e or not, they were always inconsistent with everyone else. :s a res#lt, many
modelers think that aggregation is important, altho#gh for different reasons. So the )01 incl#ded
aggregation (%ig#re K.I) b#t with hardly any semantics. :s Cim "#mba#gh says, "2hink of it as a modeling
placebo" F"#mba#gh, )01 "eferenceG.
Figure 6.-. !ggregation
:s well as aggregation, the )01 has the more defined property of composition. *n %ig#re K.J, an instance
of ?oint may be part of a polygon or may be the center of a circle, b#t it cannot be both. 2he general r#le
is that, altho#gh a class may be a component of many other classes, any instance m#st be a component of
only one owner. 2he class diagram may show m#ltiple classes of potential owners, b#t any instance has
only a single ob,ect as its owner.
Figure 6.5. )omposition
/o#ll note that * dont show the reverse m#ltiplicities in %ig#re K.J. *n most cases, as here, its 5..3. *ts
only other possible val#e is 3, for cases in which the component class is designed so that it can have only
one other class as its owner.
2he "no sharing" r#le is the key to composition. :nother ass#mption is that if yo# delete the
polygon, it sho#ld a#tomatically ens#re that any owned ?oints also are deleted.
-omposition is a good way of showing properties that own by val#e, properties to val#e ob,ects (page EI),
or properties that have a strong and somewhat excl#sive ownership of partic#lar other components.
:ggregation is strictly meaningless@ as a res#lt, * recommend that yo# ignore it in yo#r own diagrams. *f
yo# see it in other peoples diagrams, yo#ll need to dig deeper to find o#t what they mean by it. 6ifferent
a#thors and teams #se it for very different p#rposes.
"eri(ed Pro#erties
erived properties can be calc#lated based on other val#es. When we think abo#t a date range (%ig#re
K.K), we can think of three properties! the start date, the end date, and the n#mber of days in the period.
2hese val#es are linked, so we can think of the length as being derived from the other two val#es.
6erivation in software perspectives can be interpreted in a co#ple of different ways. /o# can #se derivation
to indicate the difference between a calc#lated val#e and a stored val#e. *n this case, we wo#ld interpret
%ig#re K.K as indicating that the start and end are stored b#t that the length is comp#ted. :ltho#gh this is
a common #se, *m not so keen, beca#se it reveals too m#ch of the internals of 6ate2ange.
0y preferred thinking is that it indicates a constraint between val#es. *n this case, we are saying that the
constraint among the three val#es holds, b#t it isnt important which of the three val#es is comp#ted. *n
this case, the choice of which attrib#te to mark as derived is arbitrary and strictly #nnecessary, b#t its
#sef#l to help remind people of the constraint. 2his #sage also makes sense with concept#al diagrams.
6erivation can also be applied to properties #sing association notation. *n this case, yo# simply mark
the name with a S.
&nterfaces and A+stract Casses
:n abstract class is a class that cannot be directly instantiated. *nstead, yo# instantiate an instance of a
s#bclass. 2ypically, an abstract class has one or more operations that are abstract. :n abstract operation
has no implementation@ it is p#re declaration so that clients can bind to the abstract class.
2he most common way to indicate an abstract class or operation in the )01 is to italici1e the name. /o#
can also make properties abstract, indicating an abstract property or accessor methods. *talics are tricky to
do on a whiteboards, so yo# can #se the label! {abstract}.
:n interface is a class that has no implementation@ that is, all its feat#res are abstract. *nterfaces
correspond directly to interfaces in -H and Cava and are a common idiom in other typed lang#ages. /o#
mark an interface with the keyword 7interface8.
-lasses have two kinds of relationships with interfaces! providing and re.#iring. : class provides an
interface if it is s#bstit#table for the interface. *n Cava and .(A2, a class can do that by implementing the
interface or implementing a s#btype of the interface. *n -RR, yo# s#bclass the class that is the interface.
: class re2uires an interface if it needs an instance of that interface in order to work. Assentially, this is
having a dependency on the interface.
%ig#re K.L shows these relationships in action, based on a few collection classes from Cava. * might write
an rder class that has a list of line items. =eca#se *m #sing a list, the rder class is dependent on the
"ist interface. 1ets ass#me that it #ses the methods e!uals, add, and get. When the ob,ects connect,
the rder will act#ally #se an instance of 3rray"ist b#t need not know that in order to #se those three
methods, as they are all part of the "ist interface.
Figure 6.8. ! Aava e&ample of interfaces and an abstract class
2he 3rray"ist itself is a s#bclass of the 3bstract"ist class. 3bstract"ist provides some, b#t not all,
the implementation of the "ist behavior. *n partic#lar, the get method is abstract. :s a res#lt, 3rray"ist
implements get b#t also overrides some of the other operations on 3bstract"ist. *n this case, it
overrides add b#t is happy to inherit the implementation of e!uals.
Why dont * simply avoid this and have rder #se 3rray"ist directly8 =y #sing the interface, * allow
myself the advantage of making it easier to change implementations later on if * need to. :nother
implementation may provide performance improvements, some database interaction feat#res, or other
benefits. =y programming to the interface rather than to the implementation, * avoid having to change all
the code sho#ld * need a different implementation of "ist. /o# sho#ld always try to program to an
interface like this@ always #se the most general type yo# can.
* sho#ld also point o#t a pragmatic wrinkle in this. When programmers #se a collection like this, they
#s#ally initiali$e the collection with a declaration, like this!
private "ist line+tems = ne, 3rray"ist()$
(ote that this strictly introd#ces a dependency from rder to the concrete 3rray"ist. *n theory, this is a
problem, b#t people dont worry abo#t it in practice. =eca#se the type of line+tems is declared as "ist,
no other part of the rder class is dependent on 3rray"ist. Sho#ld we change the implementation,
theres only this one line of initiali$ation code that we need to worry abo#t. *ts .#ite common to refer to
a concrete class once d#ring creation b#t to #se only the interface afterward.
2he f#ll notation of %ig#re K.L is one way to notate interfaces. %ig#re K.E shows a more compact notation.
2he fact that 3rray"ist implements "ist and .ollection is shown by having ball icons, often referred
to as lollipops, o#t of it. 2he fact that rder re.#ires a "ist interface is shown by the socket icon. 2he
connection is nicely obvio#s.
Figure 6.B. ,all-and-socket notation
68/118
2he )01 has #sed the lollipop notation for a while, b#t the socket notation is new to )01 4. (* think its my
favorite notational addition.) /o#ll probably see older diagrams #se the style of %ig#re K.;, where a
dependency stands in for the socket notation.
:ny class is a mix of an interface and an implementation. 2herefore, we may often see an ob,ect #sed
thro#gh the interface of one of its s#perclasses. Strictly, it wo#ldnt be legal to #se the lollipop notation for
a s#perclass, as the s#perclass is a class, not a p#re interface. =#t * bend these r#les for clarity.
:s well as on class diagrams, people have fo#nd lollipops #sef#l elsewhere. &ne of the perennial problems
with interaction diagrams is that they dont provide a very good vis#ali$ation for polymorphic behavior.
:ltho#gh its not normative #sage, yo# can indicate this along the lines of %ig#re K.D. 'ere, we can see
that, altho#gh we have an instance of Salesman, which is #sed as s#ch by the =on#s -alc#lator, the ?ay
?eriod ob,ect #ses the Salesman only thro#gh its Amployee interface. (/o# can do the same trick with
comm#nication diagrams.)
Figure 6.C. Using a lollipop to show polymorphism in a se2uence diagram
1ead/'ny and Fro5en
&n page IE, * described the {readnly} keyword. /o# #se this keyword to mark a property that can only
be read by clients and that cannot be #pdated. Similar yet different is the {fro;en} keyword from )01 3.
: property is fro7en if it cannot change d#ring the lifetime of an ob,ect@ s#ch properties are often called
imm#table. :ltho#gh it was dropped from )01 4, {fro;en} is a very #sef#l concept, so * wo#ld contin#e
to #se it. :s well as marking individ#al properties as fro$en, yo# can apply the keyword to a class to
indicate that all properties of all instances are fro$en. (* have heard that fro$en may well be reinstated
shortly.)
1eference '+2ects and <aue '+2ects
&ne of the common things said abo#t ob,ects is that they have identity. 2his is tr#e, b#t it is not .#ite as
simple as that. *n practice, yo# find that identity is important for reference ob,ects b#t not so important
for val#e ob,ects.
1eference ob0ects are s#ch things as -#stomer. 'ere, identity is very important beca#se yo# #s#ally
want only one software ob,ect to designate a c#stomer in the real world. :ny ob,ect that references a
-#stomer ob,ect will do so thro#gh a reference, or pointer@ all ob,ects that reference this -#stomer will
reference the same software ob,ect. 2hat way, changes to a -#stomer are available to all #sers of the
-#stomer.
*f yo# have two references to a -#stomer and wish to see whether they are the same, yo# #s#ally compare
their identities. -opies may be disallowed@ if they are allowed, they tend to be made rarely, perhaps for
archive p#rposes or for replication across a network. *f copies are made, yo# need to sort o#t how to
synchroni$e changes.
=alue ob0ects are s#ch things as 6ate. /o# often have m#ltiple val#e ob,ects representing the same
ob,ect in the real world. %or example, it is normal to have h#ndreds of ob,ects that designate 37Can75J.
2hese are all interchangeable copies. (ew dates are created and destroyed fre.#ently.
*f yo# have two dates and wish to see whether they are the same, yo# dont look at their identities b#t
rather at the val#es they represent. 2his #s#ally means that yo# have to write an e.#ality test operator,
which for dates wo#ld make a test on year, month, and dayTor whatever the internal representation is.
Aach ob,ect that references 37Can75J #s#ally has its own dedicated ob,ect, b#t yo# can also share dates.
Mal#e ob,ects sho#ld be imm#table@ in other words, yo# sho#ld not be able to take a date ob,ect of 37Can7
5J and change the same date ob,ect to be 47Can75J. *nstead, yo# sho#ld create a new 47Can5J ob,ect and
#se that instead. 2he reason is that if the date were shared, yo# wo#ld #pdate another ob,ects date in an
#npredictable way, a problem referred to as aliasing.
*n days gone by, the difference between reference ob,ects and val#e ob,ects was clearer. Mal#e ob,ects
were the b#ilt7in val#es of the type system. (ow yo# can extend the type system with yo#r own classes,
so this iss#e re.#ires more tho#ght.
2he )01 #ses the concept of data type, which is shown as a keyword on the class symbol. Strictly, data
type isnt the same as val#e ob,ect, as data types cant have identity. Mal#e ob,ects may have an identity,
b#t dont #se it for e.#ality. ?rimitives in Cava wo#ld be data types, b#t dates wo#ld not, altho#gh they
wo#ld be val#e ob,ects.
*f its important to highlight them, * #se composition when associating with a val#e ob,ect. /o# can also
#se a keyword on a val#e type@ common conventional ones * see are 7value8 or 7struct8.
=uaified Associations
: 2ualified association is the )01 e.#ivalent of a programming concept vario#sly known as associative
arrays, maps, hashes, and dictionaries. %ig#re K.35 shows a way that #ses a .#alifier to represent the
association between the &rder and &rder 1ine classes. 2he .#alifier says that in connection with an &rder,
there may be one &rder 1ine for each instance of ?rod#ct.
%rom a software perspective, this .#alified association wo#ld imply an interface along the lines of
class rder ###
public rder"ine get"ine+tem(&roduct a&roduct)$
public void add"ine+tem(Kumber amount? &roduct for&roduct)$
2h#s, all access to a given &rder 1ine re.#ires a ?rod#ct as an arg#ment, s#ggesting an
implementation #sing a key and val#e data str#ct#re.
*ts common for people to get conf#sed abo#t the m#ltiplicities of a .#alified association. *n %ig#re K.35, an
&rder may have many 1ine *tems, b#t the m#ltiplicity of the .#alified association is the m#ltiplicity in the
context of the .#alifier. So the diagram says that an &rder has 5..3 1ine *tems per ?rod#ct. : m#ltiplicity of
3 wo#ld indicate that &rder wo#ld have to have a 1ine *tem for every instance of ?rod#ct. : Y wo#ld
indicate that yo# wo#ld have m#ltiple 1ine *tems per ?rod#ct b#t that access to the 1ine *tems is indexed
by ?rod#ct.
*n concept#al modeling, * #se the .#alifier constr#ct only to show constraints along the lines of
"single &rder 1ine per ?rod#ct on &rder."
Cha#ter >% '+2ect "iagra!s
:n ob0ect diagram is a snapshot of the ob,ects in a system at a point in time. =eca#se it shows
instances rather than classes, an ob,ect diagram is often called an instance diagram.
/o# can #se an ob,ect diagram to show an example config#ration of ob,ects. (See %ig#re L.3, which shows
a set of classes, and %ig#re L.4, which shows an associated set of ob,ects.) 2his latter #se is very #sef#l
when the possible connections between ob,ects are complicated.
Figure 8.'. )lass diagram of "arty composition structure
/o# can tell that the elements in %ig#re L.4 are instances beca#se the names are #nderlined. Aach name
takes the form instance name : class name. =oth parts of the name are optional, so Lo*n, :&erson, and
a&erson are legal names. *f yo# #se only the class name, yo# m#st incl#de the colon. /o# can show val#es
for attrib#tes and links, as in %ig#re L.4.
Strictly, the elements of an ob,ect diagram are instance specifications rather than tr#e instances. 2he
reason is that its legal to leave mandatory attrib#tes empty or to show instance specifications of abstract
classes. /o# can think of an instance specification as a partly defined instance.
:nother way of looking at an ob,ect diagram is as a comm#nication diagram (page 3I3) witho#t
messages.
When to Use '+2ect "iagra!s
&b,ect diagrams are #sef#l for showing examples of ob,ects connected together. *n many sit#ations, yo#
can define a str#ct#re precisely with a class diagram, b#t the str#ct#re is still diffic#lt to #nderstand. *n
these sit#ations, a co#ple of ob,ect diagram examples can make all the difference.
Cha#ter ?% Package "iagra!s
-lasses represent the basic form of str#ct#ring an ob,ect7oriented system. :ltho#gh they are wonderf#lly
#sef#l, yo# need something more to str#ct#re large systems, which may have h#ndreds of classes.
: package is a gro#ping constr#ct that allows yo# to take any constr#ct in the )01 and gro#p its
elements together into higher7level #nits. *ts most common #se is to gro#p classes, and thats the way
*m describing it here, b#t remember that yo# can #se packages for every other bit of the )01 as well.
*n a )01 model, each class is a member of a single package. ?ackages can also be members of other
packages, so yo# are left with a hierarchic str#ct#re in which top7level packages get broken down into
s#bpackages with their own s#bpackages and so on #ntil the hierarchy bottoms o#t in classes. :
package can contain both s#bpackages and classes.
*n programming terms, packages correspond to s#ch gro#ping constr#cts as packages (in Cava) and
namespaces (in -RR and .(A2).
Aach package represents a namespace, which means that every class m#st have a #ni.#e name within
its owning package. *f * want to create a class called 6ate, and a 6ate class is already in the System
package, * can have my 6ate class as long as * p#t it in a separate package. 2o make it clear which is
which, * can #se a fully 2ualified name, that is, a name that shows the owning package str#ct#re. /o#
#se do#ble colons to show package names in )01, so the dates might be System::6ate and
%artinMo,ler::Util::6ate.
*n diagrams, packages are shown with a tabbed folder, as in %ig#re E.3. /o# can simply show the
package name or show the contents too. :t any point, yo# can #se f#lly .#alified names or simply
reg#lar names. Showing the contents with class icons allows yo# to show all the details of a class, even
to the point of showing a class diagram within the package. Simply listing the names makes sense when
all yo# want to do is indicate which classes are in which packages.
Figure B.'. Days of showing packages on diagrams
*ts .#ite common to see a class labeled something like 6ate (from Nava#util) rather than the f#lly
.#alified form. 2his style is a convention that was done a lot by "ational "ose@ it isnt part of the
standard.
2he )01 allows classes in a package to be p#blic or private. : p#blic class is part of the interface of the
package and can be #sed by classes in other packages@ a private class is hidden. 6ifferent programming
environments have different r#les abo#t visibility between their packaging constr#cts@ yo# sho#ld follow
the convention of yo#r programming environment, even if it means bending the )01s r#les.
: #sef#l techni.#e here is to red#ce the interface of the package by exporting only a small s#bset of the
operations associated with the packages p#blic classes. /o# can do this by giving all classes private
visibility, so that they can be seen only by other classes in the same package, and by adding extra p#blic
classes for the p#blic behavior. 2hese extra classes, called 2acades FBang of %o#rG, then delegate p#blic
operations to their shyer companions in the package.
'ow do yo# choose which classes to p#t in which packages8 2his is act#ally .#ite an involved .#estion that
needs a good bit of design skill to answer. 2wo #sef#l principles are the -ommon -los#re ?rinciple and
-ommon "e#se ?rinciple F0artinG. 2he -ommon -los#re ?rinciple says that the classes in a package sho#ld
need changing for similar reasons. 2he -ommon "e#se ?rinciple says that classes in a package sho#ld all
be re#sed together. 0any of the reasons for gro#ping classes in packages have to do with the
dependencies between the packages, which *ll come to next.
Packages and "e#endencies
: package diagram shows packages and their dependencies. * introd#ced the concept of dependency on
page JE. *f yo# have packages for presentation and domain, yo# have a dependency from the presentation
package to the domain package if any class in the presentation package has a dependency to any class in
the domain package. *n this way, interpackage dependencies s#mmari$e the dependencies between their
contents.
2he )01 has many varieties of dependency, each with partic#lar semantics and stereotype. * find it easier
to begin with the #nstereotyped dependency and #se the more partic#lar dependencies only if * need to,
which * hardly ever do.
*n a medi#m to large system, plotting a package diagram can be one of the most val#able things yo# can
do to control the large7scale str#ct#re of the system. *deally, this diagram sho#ld be generated from the
code base itself, so that yo# can see what is really there in the system.
: good package str#ct#re has a clear flow to the dependencies, a concept thats diffic#lt to define b#t often
easier to recogni$e. %ig#re E.4 shows a sample package diagram for an enterprise application, one that is
well7str#ct#red and has a clear flow.
Figure B.(. "ackage diagram for an enterprise application
&ften, yo# can identify a clear flow beca#se all the dependencies r#n in a single direction. :ltho#gh that
is a good indicator of a well7str#ct#red system, the data mapper packages of %ig#re E.4 show an
exception to that r#le of th#mb. 2he data mapper packages act as an ins#lating layer between the
domain and database packages, an example of the 0apper pattern F%owler, ? of A::G.
0any a#thors say that there sho#ld be no cycles in the dependencies (the :cyclic 6ependency
?rinciple F0artinG). * dont treat that as an absol#te r#le, b#t * do think that cycles sho#ld be
locali$ed and that, in partic#lar, yo# sho#ldnt have cycles that cross layers.
2he more dependencies coming into a package, the more stable the packages interface needs to be, as
any change in its interface will ripple into all the packages that are dependent on it (the Stable
6ependencies ?rinciple F0artinG). So in %ig#re E.4, the asset domain package needs a more stable
interface than the leasing data mapper package. &ften, yo#ll find that the more stable packages tend to
have a higher proportion of interfaces and abstract classes (the Stable :bstractions ?rinciple F0artinG.
2he dependency relationships are not transitive (page J;). 2o see why this is important for
dependencies, look at %ig#re E.4 again. *f a class in the asset domain package changes, we may have a
change to classes within the leasing domain package. =#t this change does not necessarily ripple
thro#gh to the leasing presentation. (*t ripples only if the leasing domain changes its interface.)
Some packages are #sed in so many places that it wo#ld be a mess to draw all the dependency lines to
them. *n this case, a convention is to #se a keyword, s#ch as 7global8, on the package.
)01 packages also define constr#cts to allow packages to import and merge classes from one package
into another, #sing dependencies with keywords to notate this. 'owever, r#les for this kind of thing vary
greatly with programming lang#ages. &n the whole, * find the general notion of dependencies to be far
more #sef#l in practice.
Package As#ects
*f yo# think abo#t %ig#re E.4, yo#ll reali$e that the diagram has two kinds of str#ct#res. &ne is a
str#ct#re of layers in the application! presentation, domain, data mapper, and database. 2he other is a
str#ct#re of s#b,ect areas! leasing and assets.
/o# can make this more apparent by separating the two aspects, as in %ig#re E.I. With this diagram, yo#
can clearly see each aspect. 'owever, these two aspects arent tr#e packages, beca#se yo# cant assign
classes to a single package. (/o# wo#ld have to pick one from each aspect.) 2his problem mirrors the
problem in the hierarchic namespaces in programming lang#ages. :ltho#gh diagrams like %ig#re E.I are
nonstandard )01, they are often very helpf#l in explaining the str#ct#re of a complex application.
&!#e!enting Packages
&ften, yo#ll see a case in which one package defines an interface that can be implemented by a n#mber of
other packages, s#ch as that of %ig#re E.J. *n this case, the reali$ation relationship indicates that the
database gateway defines an interface and that the other gateway classes provide an implementation. *n
practice, this wo#ld mean that the database gateway package contains interfaces and abstract classes that
are f#lly implemented by the other packages.
*ts .#ite common for an interface and its implementation to be in separate packages. *ndeed, a client
package often contains an interface for another package to implement! the same notion of re.#ired
interface that * disc#ssed on page E5.
*magine that we want to provide some #ser interface ()*) controls to t#rn things on and off. We want this
to work with a lot of different things, s#ch as heaters and lights. 2he )* controls need to invoke methods
on the heater, b#t we dont want the controls to have a dependency to the heater. We can avoid this
dependency by defining in the controls package an interface that is then implemented by any class that
wants to work with these controls, as in %ig#re E.K. 2his is an example of the pattern Separated *nterface
F%owler, ? of A::G.
Figure B.6. efining a re2uired interface in a client package
When to Use Package "iagra!s
* find package diagrams extremely #sef#l on larger7scale systems to get a pict#re of the dependencies
between ma,or elements of a system. 2hese diagrams correspond well to common programming
str#ct#res. ?lotting diagrams of packages and dependencies helps yo# keep an applications
dependencies #nder control.
?ackage diagrams represent a compile7time gro#ping mechanism. %or showing how ob,ects are
composed at r#ntime, #se a composite str#ct#re diagram (page 3IK).
Where to Find 'ut More
2he best disc#ssion * know of packages and how to #se them is F0artinG. "obert 0artin has long had an
almost pathological obsession with dependencies and writes well abo#t how to pay attention to
dependencies so that yo# can control and minimi$e them.
Cha#ter @% "e#oy!ent "iagra!s
6eployment diagrams show a systems physical layo#t, revealing which pieces of software r#n on what
pieces of hardware. 6eployment diagrams are really very simple@ hence the short chapter.
%ig#re ;.3 is a simple example of a deployment diagram. 2he main items on the diagram are nodes
connected by comm#nication paths. : node is something that can host some software. (odes come in two
forms. : device is hardware, it may be a comp#ter or a simpler piece of hardware connected to a system.
:n e&ecution environment is software that itself hosts or contains other software, examples are an
operating system or a container process.
2he nodes contain artifacts, which are the physical manifestations of software! #s#ally, files. 2hese files
might be exec#tables (s#ch as .exe files, binaries, 611s, C:" files, assemblies, or scripts), or data files,
config#ration files, '201 doc#ments, and so on. 1isting an artifact within a node shows that the artifact is
deployed to that node in the r#nning system.
/o# can show artifacts either as class boxes or by listing the name within a node. *f yo# show them as
class boxes, yo# can add a doc#ment icon or the 7artifact8 keyword. /o# can tag nodes or artifacts
with tagged val#es to indicate vario#s interesting information abo#t the node, s#ch as vendor, operating
system, location, or anything else that takes yo#r fancy.
&ften, yo#ll have m#ltiple physical nodes carrying o#t the same logical task. /o# can either show this
with m#ltiple node boxes or state the n#mber as a tagged val#e. *n %ig#re ;.3, * #sed the tag number
deployed to indicate three physical Web servers, b#t theres no standard tag for this.
:rtifacts are often the implementation of a component. 2o show this, yo# can #se a tagged val#e in the
artifact box.
-omm#nication paths between nodes indicate how things comm#nicate. /o# can label these paths with
information abo#t the comm#nication protocols that are #sed.
When to Use "e#oy!ent "iagra!s
6ont let the brevity of this chapter make yo# think that deployment diagrams sho#ldnt be #sed. 2hey
are very handy in showing what is deployed where, so any nontrivial deployment can make good #se of
them.
Cha#ter A% Use Cases
)se cases are a techni.#e for capt#ring the f#nctional re.#irements of a system. )se cases work by
describing the typical interactions between the #sers of a system and the system itself, providing a
narrative of how a system is #sed.
"ather than describe #se cases head7on, * find it easier to sneak #p on them from behind and start by
describing scenarios. : scenario is a se.#ence of steps describing an interaction between a #ser and a
system. So if we have a Web7based on7line store, we might have a =#y a ?rod#ct scenario that wo#ld say
this!
!he customer bro#ses the catalog and adds desired items to the shopping bas0et% 3hen
the customer #ishes to pay4 the customer describes the shipping and credit card
information and confirms the sale% !he system chec0s the authori1ation on the credit card
and confirms the sale both immediately and #ith a follo#$up e$mail.
2his scenario is one thing that can happen. 'owever, the credit card a#thori$ation might fail, and this
wo#ld be a separate scenario. *n another case, yo# may have a reg#lar c#stomer for whom yo# dont need
to capt#re the shipping and credit card information, and this is a third scenario.
:ll these scenarios are different yet similar. 2he essence of their similarity is that in all these three
scenarios, the #ser has the same goal! to b#y a prod#ct. 2he #ser doesnt always s#cceed, b#t the goal
remains. 2his #ser goal is the key to #se cases! : use case is a set of scenarios tied together by a
common #ser goal.
*n #se case]speak, the #sers are referred to as actors. :n actor is a role that a #ser plays with respect
to the system. :ctors might incl#de c#stomer, c#stomer service rep, sales manager, and prod#ct
analyst. :ctors carry o#t #se cases. : single actor may perform many #se cases@ conversely, a #se
case may have several actors performing it. )s#ally, yo# have many c#stomers, so many people can be
the c#stomer actor. :lso, one person may act as more than one actor, s#ch as a sales manager who
does c#stomer service rep tasks. :n actor doesnt have to be h#man. *f the system performs a service
for another comp#ter system, that other system is an actor.
Actor isnt really the right term@ role wo#ld be m#ch better. :pparently, there was a mistranslation from
Swedish, and actor is the term the #se case comm#nity #ses.
)se cases are well known as an important part of the )01. 'owever, the s#rprise is that in many ways,
the definition of #se cases in the )01 is rather sparse. (othing in the )01 describes how yo# sho#ld
capt#re the content of a #se case. What the )01 describes is a #se case diagram, which shows how #se
cases relate to each other. =#t almost all the val#e of #se cases lies in the content, and the diagram is of
rather limited val#e.
Content of a Use Case
2here is no standard way to write the content of a #se case, and different formats work well in different
cases. %ig#re D.3 shows a common style to #se. /o# begin by picking one of the scenarios as the main
success scenario. /o# start the body of the #se case by writing the main s#ccess scenario as a se.#ence
of n#mbered steps. /o# then take the other scenarios and write them as e&tensions, describing them in
terms of variations on the main s#ccess scenario. Axtensions can be s#ccessesT#ser achieves the goal, as
in IaTor fail#res, as in La.
Aach #se case has a primary actor, which calls on the system to deliver a service. 2he primary actor is the
actor with the goal the #se case is trying to satisfy and is #s#ally, b#t not always, the initiator of the #se
case. 2here may be other actors as well with which the system comm#nicates while carrying o#t the #se
case. 2hese are known as secondary actors.
Aach step in a #se case is an element of the interaction between an actor and the system. Aach step sho#ld
be a simple statement and sho#ld clearly show who is carrying o#t the step. 2he step sho#ld show the
intent of the actor, not the mechanics of what the actor does. -onse.#ently, yo# dont describe the #ser
interface in the #se case. *ndeed, writing the #se case #s#ally precedes designing the #ser interface.
:n extension within the #se case names a condition that res#lts in different interactions from those
described in the main s#ccess scenario (0SS) and states what those differences are. Start the extension
by naming the step at which the condition is detected and provide a short description of the condition.
%ollow the condition with n#mbered steps in the same style as the main s#ccess scenario. %inish these
steps by describing where yo# ret#rn to the main s#ccess scenario, if yo# do.
2he #se case str#ct#re is a great way to brainstorm alternatives to the main s#ccess scenario. %or each
step, ask, 'ow co#ld this go differently8 and in partic#lar, What co#ld go wrong8 *ts #s#ally best to
brainstorm all the extension conditions first, before yo# get bogged down working o#t the
conse.#ences. /o#ll probably think of more conditions this way, which translates to fewer goofs that
yo# have to pick #p later.
: complicated step in a #se case can be another #se case. *n )01 terms, we say that the first #se case
includes the second. 2heres no standard way to show an incl#ded #se case in the text, b#t * find that
#nderlining, which s#ggests a hyperlink, works very nicely and in many tools really will be a hyperlink.
2h#s in %ig#re D.3, the first step incl#des the #se case "browse catalog and select items to b#y."
*ncl#ded #se cases can be #sef#l for a complex step that wo#ld cl#tter the main scenario or for steps that
are repeated in several #se cases. 'owever, dont try to break down #se cases into s#b]#se cases and
s#bs#b]#se cases #sing f#nctional decomposition. S#ch a decomposition is a good way to waste a lot of
time.
:s well as the steps in the scenarios, yo# can add some other common information to a #se case.
1 : pre-condition describes what the system sho#ld ens#re is tr#e before the system allows the #se
case to begin. 2his is #sef#l for telling the programmers what conditions they dont have to check
for in their code.
2 : guarantee describes what the system will ens#re at the end of the #se case. S#ccess g#arantees
hold after a s#ccessf#l scenario@ minimal g#arantees hold after any scenario.
3 : trigger specifies the event that gets the #se case started.
When yo#re considering adding elements, be skeptical. *ts better to do too little than too m#ch. :lso,
work hard to keep the #se case brief and easy to read. *ve fo#nd that long, detailed #se cases dont get
read, which rather defeats the p#rpose.
2he amo#nt of detail yo# need in a #se case depends on the amo#nt of risk in that #se case. &ften, yo#
need details on only a few key #se cases early on@ others can be fleshed o#t ,#st before yo# implement
them. /o# dont have to write all the detail down@ verbal comm#nication is often very effective,
partic#larly within an iterative cycle in which needs are .#ickly met by r#nning code.
Use Case "iagra!s
:s * said earlier, the )01 is silent on the content of a #se case b#t does provide a diagram format for
showing them, as in %ig#re D.4. :ltho#gh the diagram is sometimes #sef#l, it isnt mandatory. *n yo#r #se
case work, dont p#t too m#ch effort into the diagram. *nstead, concentrate on the text#al content of the
#se cases.
Figure C.(. Use case diagram
2he best way to think of a #se case diagram is that its a graphical table of contents for the #se case set.
*ts also similar to the context diagram #sed in str#ct#red methods, as it shows the system bo#ndary and
the interactions with the o#tside world. 2he #se case diagram shows the actors, the #se cases, and the
relationships between them!
Which actors carry o#t which #se cases
Which #se cases incl#de other #se cases
2he )01 incl#des other relationships between #se cases beyond the simple incl#des, s#ch as 7e>tend8. *
strongly s#ggest that yo# ignore them. *ve seen too many sit#ations in which teams can get terribly h#ng
#p on when to #se different #se case relationships, and s#ch energy is wasted. *nstead, concentrate on the
text#al description of a #se case@ thats where the real val#e of the techni.#e lies.
Le(es of Use Cases
: common problem with #se cases is that by foc#sing on the interaction between a #ser and the system,
yo# can neglect sit#ations in which a change to a b#siness process may be the best way to deal with the
problem. &ften, yo# hear people talk abo#t system #se cases and b#siness #se cases. 2he terms are not
precise, b#t in general, a system use case is an interaction with the software, whereas a business use
case disc#sses how a b#siness responds to a c#stomer or an event.
F-ockb#rn, #se casesG s#ggests a scheme of levels of #se cases. 2he core #se cases are at "sea level."
$ea-level #se cases typically represent a discrete interaction between a primary actor and the system.
S#ch #se cases will deliver something of val#e to the primary actor and #s#ally take from a co#ple of
min#tes to half an ho#r for the primary actor to complete. )se cases that are there only beca#se they are
incl#ded by sea7level #se cases are fish level. 'igher, kite-level #se cases show how the sea7level #se
cases fit into wider b#siness interactions. >ite7level #se cases are #s#ally b#siness #se cases, whereas sea
and fish levels are system #se cases. /o# sho#ld have most of yo#r #se cases at the sea level. * prefer to
indicate the level at the top of the #se case, as in %ig#re D.3.
Use Cases and Features :or Stories;
0any approaches #se feat#res of a systemTAxtreme ?rogramming calls them #ser storiesTto help
describe re.#irements. : common .#estion is how feat#res and #se cases interrelate.
%eat#res are a good way of ch#nking #p a system for planning an iterative pro,ect, whereby each
iteration delivers a n#mber of feat#res. )se cases provide a narrative of how the actors #se the system.
'ence, altho#gh both techni.#es describe re.#irements, their p#rposes are different.
:ltho#gh yo# can go directly to describing feat#res, many people find it helpf#l to develop #se cases first
and then generate a list of feat#res. : feat#re may be a whole #se case, a scenario in a #se case, a step in
a #se case, or some variant behavior, s#ch as adding yet another depreciation method for yo#r asset
val#ations, that doesnt show #p in a #se case narrative. )s#ally, feat#res end #p being more fine grained
than #se cases.
When to Use Use Cases
)se cases are a val#able tool to help #nderstand the f#nctional re.#irements of a system. : first pass at
#se cases sho#ld be made early on. 0ore detailed versions of #se cases sho#ld be worked ,#st prior to
developing that #se case.
*t is important to remember that #se cases represent an external view of the system. :s s#ch, dont expect
any correlations between #se cases and the classes inside the system.
2he more * see of #se cases, the less val#able the #se case diagram seems to be. With #se cases,
concentrate yo#r energy on their text rather than on the diagram. 6espite the fact that the )01 has
nothing to say abo#t the #se case text, it is the text that contains all the val#e in the techni.#e.
: big danger of #se cases is that people make them too complicated and get st#ck. )s#ally, yo#ll get
less h#rt by doing too little than by doing too m#ch. : co#ple of pages per #se case is ,#st fine for most
cases. *f yo# have too little, at least yo#ll have a short, readable doc#ment thats a starting point for
.#estions. *f yo# have too m#ch, hardly anyone will read and #nderstand it.
Where to Find 'ut More
)se cases were originally pop#lari$ed by *var Cacobson in FCacobson, &&SAG.
:ltho#gh #se cases have been aro#nd for a while, theres been little standardi$ation on their #se. 2he
)01 is silent on the important contents of a #se case and has standardi$ed only the m#ch less important
diagrams. :s a res#lt, yo# can find a divergent range of opinions on #se cases.
*n the last few years, however, F-ockb#rn, #se casesG has become the standard book on the s#b,ect. *n
this chapter, *ve followed the terminology and advice of that book for the excellent reason that when weve
disagreed in the past, *ve #s#ally ended #p agreeing with :listair -ockb#rn in the end. 'e also maintains a
Web site at http://usecases.org. F-onstantine and 1ockwoodG provides a convincing process for deriving
#ser interfaces from #se cases@ also see http://foruse.com.
Cha#ter $B% State Machine "iagra!s
$tate machine diagrams are a familiar techni.#e to describe the behavior of a system. Mario#s forms
of state diagrams have been aro#nd since the 3DL5s and the earliest ob,ect7oriented techni.#es
adopted them to show behavior. *n ob,ect7oriented approaches, yo# draw a state machine diagram for a
single class to show the lifetime behavior of a single ob,ect.
Whenever people write abo#t state machines, the examples are inevitably cr#ise controls or vending
machines. :s *m a little bored with them, * decided to #se a controller for a secret panel in a Bothic castle.
*n this castle, * want to keep my val#ables in a safe thats hard to find. So to reveal the lock to the safe, *
have to remove a strategic candle from its holder, b#t this will reveal the lock only while the door is closed.
&nce * can see the lock, * can insert my key to open the safe. %or extra safety, * make s#re that * can open
the safe only if * replace the candle first. *f a thief neglects this preca#tion, *ll #nleash a nasty monster to
devo#r him.
%ig#re 35.3 shows a state machine diagram of the controller class that directs my #n#s#al sec#rity
system.2he state diagram starts with the state of the controller ob,ect when its created! in %ig#re 35.3,
the Wait state. 2he diagram indicates this with initial pseudostate, which is not a state b#t has an arrow
that points to the initial state.
2he diagram shows that the controller can be in three states! Wait, 1ock, and &pen. 2he diagram also
gives the r#les by which the controller changes from state to state. 2hese r#les are in the form of
transitions! the lines that connect the states.
2he transition indicates a movement from one state to another. Aach transition has a label that comes in
three parts! trigger-signature [guard]4activity. :ll the parts are optional. 2he trigger-signature
is #s#ally a single event that triggers a potential change of state. 2he guard, if present, is a =oolean
condition that m#st be tr#e for the transition to be taken. 2he activity is some behavior thats exec#ted
d#ring the transition. *t may be any behavioral expression. 2he f#ll form of a trigger-signaturemay
incl#de m#ltiple events and parameters. So in %ig#re 35.3, yo# read the o#tward transition from the Wait
state as "*n the Wait state if the candle is removed providing the door is open, yo# reveal the lock and
move to the 1ock state."
:ll three parts to a transition are optional. : missing activity indicates that yo# dont do anything d#ring
the transition. : missing g#ard indicates that yo# always take the transition if the event occ#rs. :
missing trigger7signat#re is rare b#t does occ#r. *t indicates that yo# take the transition immediately,
which yo# see mostly with activity states, which *ll come to in a moment.
When an event occ#rs in a state, yo# can take only one transition o#t of it. So if yo# #se m#ltiple
transitions with the same event, as in the 1ock state of %ig#re 35.3, the g#ards m#st be m#t#ally
excl#sive. *f an event occ#rs and no transition is validTfor example, a safe7closed event in the Wait state
or a candle7removed event with the door closedTthe event is ignored.
2he final state indicates that the state machine is completed, implying the deletion of the controller
ob,ect. 2h#s, if someone sho#ld be so careless as to fall for my trap, the controller ob,ect terminates, so *
wo#ld need to p#t the rabbit in its cage, mop the floor, and reboot the system.
"emember that state machines can show only what the ob,ect directly observes or activates. So
altho#gh yo# might expect me to add or remove things from the safe when its open, * dont p#t that
on the state diagram, beca#se the controller cannot tell.
When developers talk abo#t ob,ects, they often refer to the state of the ob,ects to mean the
combination of all the data in the fields of the ob,ects. 'owever, the state in a state machine diagram
is a more abstract notion of state@ essentially, different states imply a different way of reacting to
events.
&nterna Acti(ities
States can react to events witho#t transition, #sing internal activities: p#tting the event, g#ard, and
activity inside the state box itself.
%ig#re 35.4 shows a state with internal activities of the character and help events, as yo# might find on a
)* text field. :n internal activity is similar to a self-transition: a transition that loops back to the same
state. 2he syntax for internal activities follows the same logic for event, g#ard, and proced#re.
Figure '3.(. #nternal events shown with the typing state of a te&t field
Acti(ity States
*n the states *ve described so far, the ob,ect is .#iet and waiting for the next event before it does
something. 'owever, yo# can have states in which the ob,ect is doing some ongoing work.
2he Searching state in %ig#re 35.I is s#ch an activity state: 2he ongoing activity is marked with the do4@
hence the term do-activity. &nce the search is completed, any transitions witho#t an activity, s#ch as the
one to display new hardware, are taken. *f the cancel event occ#rs d#ring the activity, the do7activity is
#nceremonio#sly halted, and we go back to the )pdate 'ardware Window state.
Figure '3.-. ! state with an activity
=oth do7activities and reg#lar activities represent carrying o#t some behavior. 2he critical difference
between the two is that reg#lar activities occ#r "instantaneo#sly" and cannot be interr#pted by reg#lar
events, while do7activities can take finite time and can be interr#pted, as in %ig#re 35.I. *nstantaneo#s
will mean different things for different system@ for hard real7time systems, it might be a few machine
instr#ctions, b#t for desktop software might be several seconds.
)01 3 #sed the term action for reg#lar activities and #sed activity only for do7activities.
Su#erstates
&ften, yo#ll find that several states share common transitions and internal activities. *n these cases, yo#
can make them s#bstates and move the shared behavior into a s#perstate, as in %ig#re 35.J. Witho#t the
s#perstate, yo# wo#ld have to draw a cancel transition for all three states within the Anter -onnection
6etails state.
Concurrent States
States can be broken into several orthogonal state diagrams that r#n conc#rrently. %ig#re 35.K shows a
pathetically simple alarm clock that can play either -6s or the radio and show either the c#rrent time or
the alarm time.
2he choices -6Sradio and c#rrentSalarm time are orthogonal choices. *f yo# wanted to represent this with a
nonorthogonal state diagram, yo# wo#ld need a messy diagram that wo#ld get very m#ch o#t of hand
sho#ld yo# want more states. Separating o#t the two areas of behavior into separate state diagrams
makes it m#ch clearer.
%ig#re 35.K also incl#des a history pseudostate. 2his indicates that when the clock is switched on, the
radioS-6 choice goes back to the state the clock was in when it was t#rned off. 2he arrow from the history
pse#dostate indicates what state to be in on the first time when there is no history.
&!#e!enting State "iagra!s
: state diagram can be implemented in three main ways! nested switch, the State pattern, and state
tables. 2he most direct approach to handling a state diagram is a nested switch statement, s#ch as
%ig#re 35.L. :ltho#gh its direct, its long7winded, even for this simple case. *ts also very easy for this
approach to get o#t of control, so * dont like #sing it even for simple cases.
Figure '3.8 ! )@ nested switch to handle the state transition from Figure
public void -andleIvent (&anelIvent anIvent) {
s,itc* (.urrentState) {
case &anelState#pen :
s,itc* (anIvent) {
case &anelIvent#Safe.losed :
.urrentState = &anelState#Oait$
breaB$
C
breaB$
case &anelState#Oait :
s,itc* (anIvent) {
case &anelIvent#.andle2emoved :
if (is6oorpen) {
2eveal"ocB()$
.urrentState = &anelState#"ocB$
C
breaB$
C
breaB$
case &anelState#"ocB :
s,itc* (anIvent) {
case &anelIvent#Hey9urned :
if (is.andle+n) {
penSafe()$
.urrentState = &anelState#pen$
} else {
2eleaseHiller2abbit()$
.urrentState = &anelState#Minal$
C
breaB$
C
breaB$
C
C
C
2he $tate pattern FBang of %o#rG creates a hierarchy of state classes to handle behavior of the states.
Aach state in the diagram has one state s#bclass. 2he controller has methods for each event, which simply
forwards to the state class. 2he state diagram of %ig#re 35.3 wo#ld yield an implementation indicated by
the classes of %ig#re 35.E.
Figure '3.B. ! $tate pattern implementation for Figure '3.'
2he top of the hierarchy is an abstract class that implements all the event7handling methods to do
nothing. %or each concrete state, yo# simply override the specific event methods for which that state has
transitions.
2he state table approach capt#res the state diagram information as data. So %ig#re 35.3 might end #p
represented in a table like 2able 35.3. We then b#ild either an interpreter that #ses the state table at
r#ntime or a code generator that generates classes based on the state table.
&bvio#sly, the state table is more work to do once, b#t then yo# can #se it every time yo# have a state
problem to hold. : r#ntime state table can also be modified witho#t recompilation, which in some
contexts is .#ite handy. 2he state pattern is easier to p#t together when yo# need it, and altho#gh it
needs a new class for each state, its a small amo#nt of code to write in each case.
2hese implementations are pretty minimal, b#t they sho#ld give yo# an idea of how to go abo#t
implementing state diagrams. *n each case, implementing state models leads to very boilerplate code, so
its #s#ally best to #se some form of code generation to do it.
*able '3.'. ! $tate *able for Figure '3.'
$ource $tate *arget $tate %vent :uard "rocedure
Wait 1ock -andle removed 6oor open "eveal lock
1ock &pen >ey t#rned -andle in &pen safe
1ock %inal >ey t#rned -andle o#t "elease killer rabbit
&pen Wait Safe closed
When to Use State "iagra!s
State diagrams are good at describing the behavior of an ob,ect across several #se cases. State diagrams
are not very good at describing behavior that involves a n#mber of ob,ects collaborating. :s s#ch, it is
#sef#l to combine state diagrams with other techni.#es. %or instance, interaction diagrams (see -hapter J)
are good at describing the behavior of several ob,ects in a single #se case, and activity diagrams (see
-hapter 33) are good at showing the general se.#ence of activities for several ob,ects and #se cases.
(ot everyone finds state diagrams nat#ral. >eep an eye on how people are working with them. *t may be
that yo#r team does not find state diagrams #sef#l to its way of working. 2hat is not a big problem@ as
always, yo# sho#ld remember to #se the mix of techni.#es that works for yo#.
*f yo# do #se state diagrams, dont try to draw them for every class in the system. :ltho#gh this approach
is often #sed by high7ceremony completists, it is almost always a waste of effort. )se state diagrams only
for those classes that exhibit interesting behavior, where b#ilding the state diagram helps yo# #nderstand
what is going on. 0any people find that )* and control ob,ects have the kind of behavior that is #sef#l to
depict with a state diagram.
Where to Find 'ut More
=oth the User Guide F=ooch, )01 #serG and the Reference Manual F"#mba#gh, )01 "eferenceG have more
information on state diagrams. "eal7time designers tend to #se state models a lot, so its no s#rprise that
F6o#glassG) has a lot to say abo#t state diagrams, incl#ding information on how to implement them.
F0artinG contains a very good chapter on the vario#s ways of implementing state diagrams.
Cha#ter $$% Acti(ity "iagra!s
:ctivity diagrams are a techni.#e to describe proced#ral logic, b#siness process, and work flow. *n many
ways, they play a role similar to flowcharts, b#t the principal difference between them and flowchart
notation is that they s#pport parallel behavior.
:ctivity diagrams have seen some of the biggest changes over the versions of the )01, so they have, not
s#rprisingly, been significantly extended and altered again for )01 4. *n )01 3, activity diagrams were
seen as special cases of state diagrams. 2his ca#sed a lot of problems for people modeling work flows,
which activity diagrams are well s#ited for. *n )01 4, that tie was removed.
%ig#re 33.3 shows a simple example of an activity diagram. We begin at the initial node action and then
do the action "eceive &rder. &nce that is done, we enco#nter a fork. : fork has one incoming flow and
several o#tgoing conc#rrent flows.
%ig#re 33.3 says that %ill &rder, Send *nvoice, and the s#bse.#ent actions occ#r in parallel. Assentially, this
means that the se.#ence between them is irrelevant. * co#ld fill the order, send the invoice, deliver, and
then receive payment@ or, * co#ld send the invoice, receive the payment, fill the order, and then deliver!
/o# get the pict#re.
* can also do these actions by interleaving. * grab the first line item from stores, type #p the invoice, grab
the second line item, p#t the invoice in an envelope, and so forth. &r, * co#ld do some of this
sim#ltaneo#sly! type #p the invoice with one hand while * reach into my stores with another. :ny of
these se.#ences is correct, according to the diagram.
2he activity diagram allows whoever is doing the process to choose the order in which to do things. *n
other words, the diagram merely states the essential se.#encing r#les * have to follow. 2his is important
for b#siness modeling beca#se processes often occ#r in parallel. *ts also #sef#l for conc#rrent
algorithms, in which independent threads can do things in parallel.
When yo# have parallelism, yo#ll need to synchroni$e. We dont close the order #ntil it is delivered and
paid for. We show this with the 0oin before the -lose &rder action. With a ,oin, the o#tgoing flow is taken
only when all the incoming flows reach the ,oin. So yo# can close the order only when yo# have both
received the payment and delivered.
)01 3 had partic#lar r#les for balancing the forks and ,oins, as activity diagrams were special cases of
state diagrams. With )01 4, s#ch balancing is no longer needed.
/o#ll notice that the nodes on an activity diagram are called actions, not activities. Strictly, an activity
refers to a se.#ence of actions, so the diagram shows an activity thats made #p of actions.
-onditional behavior is delineated by decisions and merges. : decision, called branch in )01 3, has a
single incoming flow and several g#arded o#t7bo#nd flows. Aach o#tbo#nd flow has a g#ard! a =oolean
condition placed inside s.#are brackets. Aach time yo# reach a decision, yo# can take only one of the
o#tbo#nd flows, so the g#ards sho#ld be m#t#ally excl#sive. )sing [else] as a g#ard indicates that the
[else] flow sho#ld be #sed if all the other g#ards on the decision are false.
*n %ig#re 33.3, after an order is filled, there is a decision. *f yo# have a r#sh order, yo# do an
&vernight 6elivery@ otherwise, yo# do a "eg#lar 6elivery.
: merge has m#ltiple inp#t flows and a single o#tp#t. : merge marks the end of conditional
behavior started by a decision.
*n my diagrams, each action has a single flow coming in and a single flow going o#t. *n )01 3, m#ltiple
incoming flows had an implicit merge. 2hat is, yo#r action wo#ld exec#te if any flow triggered. *n )01 4,
this has changed so theres an implicit ,oin instead@ th#s, the action exec#tes only if all flows trigger. :s a
res#lt of this change, * recommend that yo# #se only a single incoming and o#tgoing flow to an action and
show all ,oins and merges explicitly@ that will avoid conf#sion.
"eco!#osing an Action
:ctions can be decomposed into s#bactivities. * can take the delivery logic of %ig#re 33.3 and define it as
its own activity (%ig#re 33.4). 2hen * can call it as an action (%ig#re 33.I on page 343).
Figure ''.(. ! subsidiary activity diagram
:ctions can be implemented either as s#bactivities or as methods on classes. /o# can show a
s#bactivity by #sing the rake symbol. /o# can show a call on a method with syntax class-
name::met*od-name. /o# can also write a code fragment into the action symbol if the invoked
behavior isnt a single method call.
And ThereCs More
* sho#ld stress that this chapter only scratches the s#rface on activity diagrams. :s with so m#ch of the
)01, yo# co#ld write a whole book on this one techni.#e alone. *ndeed, * think that activity diagrams
wo#ld make a very s#itable topic for a book that really d#g into the notation and how to #se it.
2he vital .#estion is how widely they get #sed. :ctivity diagrams arent the most widely #sed )01
techni.#e at the moment, and their flow7modeling progenitors werent very pop#lar either. 6iagrammatic
techni.#es havent yet ca#ght on m#ch for describing behavior in this kind of way. &n the other hand,
there are signs in a n#mber of comm#nities of a pent7#p demand that a standard techni.#e will help to
satisfy.
When to Use Acti(ity "iagra!s
2he great strength of activity diagrams lies in the fact that they s#pport and enco#rage parallel behavior.
2his makes them a great tool for work flow and process modeling, and indeed m#ch of the p#sh in )01 4
has come from people involved in work flow.
/o# can also #se an activity diagram as a )017compliant flowchart. :ltho#gh this allows yo# to do
flowcharts in a way that sticks with the )01, its hardly very exciting. *n principle, yo# can take
advantages of the forks and ,oins to describe parallel algorithms for conc#rrent programs. :ltho#gh *
dont travel in conc#rrent circles that m#ch, * havent seen m#ch evidence of people #sing them there. *
think the reason is that most of the complexity of conc#rrent programming is in avoiding contention on
data, and activity diagrams dont help m#ch with that.
2he main strength of doing this may come with people #sing )01 as a programming lang#age. *n this
case, activity diagrams represent an important techni.#e to represent behavioral logic.
*ve often seen activity diagrams #sed to describe a #se case. 2he danger of this approach is that often,
domain experts dont follow them easily. *f so, yo#d be better off with the #s#al text#al form.
Where to Find 'ut More
:ltho#gh activity diagrams have always been rather complicated and are even more so with )01 4, there
hasnt been a good book that describes them in depth. * hope this gap will get filled someday.
Mario#s flow7oriented techni.#es are similar in style to activity diagrams. &ne of the better knownT b#t
hardly well knownTis ?etri (ets, for which http://www.daimi.au.dk/"etri;ets/ is a good Web site.
Partitions
:ctivity diagrams tell yo# what happens, b#t they do not tell yo# who does what. *n programming, this
means that the diagram does not convey which class is responsible for each action. *n b#siness process
modeling, this does not convey which part of an organi$ation carries o#t which action. 2his isnt
necessarily a problem@ often, it makes sense to concentrate on what gets done rather than on who does
what parts of the behavior.
*f yo# want to show who does what, yo# can divide an activity diagram into partitions, which show which
actions one class or organi$ation #nit carries o#t. %ig#re 33.J (on page 344) shows a simple example of
this, showing how the actions involved in order processing can be separated among vario#s departments.
2he partitioning of %ig#re 33.J is a simple one7dimensional partitioning. 2his style is often referred to as
swim lanes, for obvio#s reasons and was the only form #sed in )01 3.x. *n )01 4, yo# can #se a two7
dimensional grid, so the swimming metaphor no longer holds water. /o# can also take each dimension and
divide the rows or col#mns hierarchically.
Signas
*n the simple example of %ig#re 33.3, activity diagrams have a clearly defined start point, which
corresponds to an invocation of a program or ro#tine. :ctions can also respond to signals.
: time signal occ#rs beca#se of the passage of time. S#ch signals might indicate the end of a month in a
financial period or each microsecond in a real7time controller.
%ig#re 33.K shows an activity that listens for two signals. : signal indicates that the activity receives an
event from an o#tside process. 2his indicates that the activity constantly listens for those signals, and the
diagram defines how the activity reacts.
*n the case of %ig#re 33.K, 4 ho#rs before my flight leaves, * need to start packing my bags. *f *m .#ick
to pack them, * still cannot leave #ntil the taxi arrives. *f the taxi arrives before my bags are packed, it
has to wait for me to finish before we go.
:s well as accepting signals, we can send them. 2his is #sef#l when we have to send a message and then
wait for a reply before we can contin#e. %ig#re 33.L shows a good example of this with a common idiom of
timing o#t. (ote that the two flows are in a race! 2he first to reach the final state will win and terminate
the other flow.
:ltho#gh accepts are #s#ally ,#st waiting for an external event, we can also show a flow going into them.
2hat indicates that we dont start listening #ntil the flow triggers the accept.
Tokens
*f yo#re s#fficiently brave to vent#re into the demonic depths of the )01 specification, yo#ll find that the
activity section of the specification talks a lot abo#t tokens and their prod#ction and cons#mption. 2he
initial node creates a token, which then passes to the next action, which exec#tes and then passes the
token to the next. :t a fork, one token comes in, and the fork prod#ces a token on each of its o#tward
flows. -onversely, on a ,oin, as each inbo#nd token arrives, nothing happens #ntil all the tokens appear at
the ,oin@ then a token is prod#ced on the o#tward flow.
/o# can vis#ali$e the tokens with coins or co#nters moving across the diagram. :s yo# get to more
complicated examples of activity diagrams, tokens often make it easier to vis#ali$e things.
Fows and Edges
)01 4 #ses the terms flow and edge synonymo#sly to describe the connections between two actions.
2he simplest kind of edge is the simple arrow between two actions. /o# can give an edge a name if yo#
like, b#t most of the time, a simple arrow will s#ffice.
*f yo#re having diffic#lty ro#ting lines, yo# can #se connectors, which simply save yo# having to draw
a line the whole distance. When yo# #se connectors, yo# m#st #se them in pairs! one with incoming
flow, one with an o#tgoing flow, and both with the same label. * tend to avoid #sing connectors if at all
possible, as they break #p the vis#ali$ation of the flow of control.
2he simplest edges pass a token that has no meaning other than to control the flow. 'owever, yo# can also
pass ob,ects along edges@ the ob,ects then play the role of tokens, as well as carry data. *f yo# are passing
an ob,ect along the edge, yo# can show that by p#tting a class box on the edge, or yo# can #se pins on the
actions, altho#gh pins imply some more s#btleties that *ll describe shortly.
:ll the styles shown in %ig#re 33.E are e.#ivalent@ yo# sho#ld #se whichever conveys best what yo# are
trying to comm#nicate. 0ost of the time, the simple arrow is .#ite eno#gh.
Pins and Transfor!ations
:ctions can have parameters, ,#st as methods do. /o# dont need to show information abo#t
parameters on the activity diagram, b#t if yo# wish, yo# can show them with pins. *f yo#re
decomposing an action, pins correspond to the parameter boxes on the decomposed diagram.
When yo#re drawing an activity diagram strictly, yo# have to ens#re that the o#tp#t parameters of an
o#tbo#nd action match the inp#t parameters of another. *f they dont match, yo# can indicate a
transformation (%ig#re 33.;) to get from one to another. 2he transformation m#st be an expression
thats free of side effects! essentially, a .#ery on the o#tp#t pin .#ary that s#pplies an ob,ect of the right
type for the inp#t pin.
/o# dont have to show pins on an activity diagram. ?ins are best when yo# want to look at the data
needed and prod#ced by the vario#s actions. *n b#siness process modeling, yo# can #se pins to show the
reso#rces prod#ced and cons#med by actions.
*f yo# #se pins, its safe to show m#ltiple flows coming into the same action. 2he pin notation
reinforces the implicit ,oin, and )01 3 didnt have pins, so theres no conf#sion with the earlier
ass#mptions.
E*#ansion 1egions
With activity diagrams, yo# often r#n into sit#ations in which one actions o#tp#t triggers m#ltiple
invocations of another action. 2here are several ways to show this, b#t the best way is to #se an
expansion region. :n e&pansion region marks an activity diagram area where actions occ#r once for
each item in a collection.
*n %ig#re 33.D, the -hoose 2opics action generates a list of topics as its o#tp#t. Aach element of this list
then becomes a token for inp#t to the Write :rticle action. Similarly, each "eview :rticle action generates a
single article thats added to the o#tp#t list of the expansion region. When all the tokens in the expansion
region end #p in the o#tp#t collection, the region generates a single token for the list thats passed to
?#blish (ewsletter.
Figure ''.C. %&pansion region
*n this case, yo# have the same n#mber of items in the o#tp#t collection as yo# do in the inp#t collection.
'owever, yo# may have fewer, in which case the expansion region acts as a filter.
*n %ig#re 33.D, all the articles are written and reviewed in parallel, which is marked by the 7concurrent8
keyword. /o# can also have an iterative expansion region. *terative regions m#st f#lly process each inp#t
element one at a time.
*f yo# have only a single action that needs m#ltiple invocation, yo# #se the shorthand of %ig#re
33.35. 2he shorthand ass#mes conc#rrent expansion, as thats the most common. 2his notation
corresponds to the )01 3 concept of dynamic conc#rrency.
Figure ''.'3. $horthand for a single action in an e&pansion region
Fow Fina
&nce yo# get m#ltiple tokens, as in an expansion region, yo# often get flows that stop even when the
activity as a whole doesnt end. : flow final indicates the end of one partic#lar flow, witho#t terminating
the whole activity.
%ig#re 33.33 shows this by modifying the example of %ig#re 33.D to allow articles to be re,ected. *f an
article is re,ected, the token is destroyed by the flow final. )nlike an activity final, the rest of the activity
can contin#e. 2his approach allows expansion regions to act as filters, whereby the o#tp#t collection is
smaller than the inp#t collection.
Figure ''.''. Flow finals in an activity
Doin S#ecifications
=y defa#lt, a ,oin lets exec#tion pass on its o#tward flow when all its inp#t flows have arrived at the ,oin.
(&r in more formal speak, it emits a token on its o#tp#t flow when a token has arrived on each inp#t flow.)
*n some cases, partic#larly when yo# have a flow with m#ltiple tokens, its #sef#l to have a more involved
r#le.
: 0oin specification is a =oolean expression attached to a ,oin. Aach time a token arrives at the ,oin, the
,oin specification is eval#ated and if tr#e, an o#tp#t token is emitted. So in %ig#re 33.34, whenever * select
a drink or insert a coin, the machine eval#ates the ,oin specification. 2he machine slakes my thirst only if
*ve p#t in eno#gh money. *f, as in this case, yo# want to indicate that yo# have received a token on each
inp#t flow, yo# label the flows and incl#de them in the ,oin specification.
Cha#ter $0% Co!!unication "iagra!s
)ommunication diagrams, a kind of interaction diagram, emphasi$e the data links between the vario#s
participants in the interaction. *nstead of drawing each participant as a lifeline and showing the se.#ence
of messages by vertical direction as the se.#ence diagrams does, the comm#nication diagram allows free
placement of participants, allows yo# to draw links to show how the participants connect, and #se
n#mbering to show the se.#ence of messages.
*n )01 3.x, these diagrams were called collaboration diagrams. 2his name st#ck well, and * s#spect
that it will be a while before people get #sed to the new name. (2hese are different from
-ollaborations Fpage 3JIG@ hence the name change.)
%ig#re 34.3 shows a comm#nication diagram for the same centrali$ed control interaction as in %ig#re
J.4. With a comm#nication diagram, we can show how the participants are linked together.
Figure '(.'. )ommunication diagram for centrali7ed control
:s well as showing links that are instances of associations, we can also show transient links, which arise
only the context of the interaction. *n this case, the 7local8 link from &rder to ?rod#ct is a local variable@
other transient links are 7parameter8 and 7global8. 2hese keywords were #sed in )01 3 b#t are missing
from )01 4. =eca#se they are #sef#l, * expect them to stay aro#nd in conventional #se.
2he n#mbering style of %ig#re 34.3 is straightforward and commonly #sed, b#t act#ally isnt legal )01. 2o
be kosher )01, yo# have to #se a nested decimal n#mbering scheme, as in %ig#re 34.4.
Figure '(.(. )ommunication diagram with nested decimal numbering
2he reason for the nested decimal n#mbers is to resolve ambig#ity with self7calls. *n %ig#re J.4, yo# can
clearly see that get6iscount+nfois called within the method calculate6iscount. With the flat n#mbering
of %ig#re 34.3, however, yo# cant tell whether get6iscount+nfois called within calculate6iscount or
within the overall calculate&rice method. 2he nested n#mbering scheme resolves this problem.
6espite its illegality, many people prefer a flat n#mbering scheme. 2he nested n#mbers can get very
tangled, partic#larly as calls get rather nested, leading to s#ch se.#ence n#mbers as 3.3.3.4.3.3. *n these
cases, the c#re for ambig#ity can be worse than the disease.
:s well as n#mbers, yo# may also see letters on messages@ these letters indicate different threads of
control. So messages :K and =4 wo#ld be in different threads@ messages 3a3 and 3b3 wo#ld be different
threads conc#rrently nested within message 3. /o# also see thread letters on se.#ence diagrams,
altho#gh this doesnt convey the conc#rrency vis#ally.
-omm#nication diagrams dont have any precise notation for control logic. 2hey do allow yo# to #se
iteration markers and g#ards (page KD), b#t they dont allow yo# to f#lly specify control logic. 2here is no
special notation for creating or deleting ob,ects, b#t the 7create8 and 7delete8 keywords are common
conventions.
When to Use Co!!unication "iagra!s
2he main .#estion with comm#nication diagrams is when to #se them rather than the more common
se.#ence diagrams. : strong part of the decision is personal preference! Some people like one over the
other. &ften, that drives the choice more than anything else. &n the whole, most people seem to prefer
se.#ence diagrams, and for once, *m with the ma,ority.
: more rational approach says that se.#ence diagrams are better when yo# want to emphasi$e the
se.#ence of calls and that comm#nication diagrams are better when yo# want to emphasi$e the links.
0any people find that comm#nication diagrams are easier to alter on a whiteboard, so they are a good
approach for exploring alternatives, altho#gh in those cases, * often prefer -"- cards.
Cha#ter $3% Co!#osite Structures
&ne of the most significant new feat#res in )01 4 is the ability to hierarchically decompose a class into
an internal str#ct#re. 2his allows yo# to take a complex ob,ect and break it down into parts.
%ig#re 3I.3 shows a 2M Miewer class with its provided and re.#ired interfaces (page LD). *ve shown this in
two ways! #sing the ball7and7socket notation and listing them internally.
Figure '-.'. *wo ways of showing a *= viewer and its interfaces
Figure '-.(. #nternal view of a component .e&ample suggested by Aim
1umbaugh/
/o# can show how many instances of a part are present. %ig#re 3I.4 says that each 2M Miewer
contains one generator part and one controls part.
2o show a part implementing an interface, yo# draw a delegating connector from that interface. Similarly,
to show that a part needs an interface, yo# show a delegating connector to that interface. /o# can also
show connectors between parts with either a simple line, as *ve done here, or with ball7and7socket
notation (page E3).
/o# can add ports (%ig#re 3I.I) to the external str#ct#re. ?orts allow yo# to gro#p the re.#ired and
provided interfaces into logical interactions that a component has with the o#tside world.
When to Use Co!#osite Structures
-omposite str#ct#res are new to )01 4, altho#gh some older methods had some similar ideas. : good way
of thinking abo#t the difference between packages and composite str#ct#res is that packages are a
compile7time gro#ping, while composite str#ct#res show r#ntime gro#pings. :s s#ch, they are a nat#ral fit
for showing components and how they are broken into parts@ hence, m#ch of this notation is #sed in
component diagrams.
=eca#se composite str#ct#res are new to the )01, its too early to tell how effective they will t#rn o#t in
practice@ many members of the )01 committee think that these diagrams will become a very val#able
addition.
Cha#ter $6% Co!#onent "iagra!s
: debate thats always ranged large in the && comm#nity is what the difference is between a component
and any reg#lar class. 2his is not a debate that * want to settle here, b#t * can show yo# the notation the
)01 #ses to disting#ish between them.
)01 3 had a distinctive symbol for a component (%ig#re 3J.3). )01 4 removed that icon b#t allows yo#
to annotate a class box with a similar7looking icon. :lternatively, yo# can #se the 7component8 keyword.
Figure '5.'. ;otation for components
103/118
&ther than the icon, components dont introd#ce any notation that we havent already seen. -omponents
are connected thro#gh implemented and re.#ired interfaces, often #sing the ball7andsocket notation
(page E3) ,#st as for class diagrams. /o# can also decompose components by #sing composite str#ct#re
diagrams.
%ig#re 3J.4 shows an example component diagram. *n this example, a sales till can connect to a sales
server component, #sing a sales message interface. =eca#se the network is #nreliable, a message .#e#e
component is set #p so the till can talk to the server when the network is #p and talk to a .#e#e when the
network is down@ the .#e#e will then talk to the server when the network becomes available. :s a res#lt,
the message .#e#e both s#pplies the sales message interface to talk with the till and re.#ires that
interface to talk with the server. 2he server is broken down into two ma,or components. 2he transaction
processor reali$es the sales message interface, and the acco#nting driver talks to the acco#nting system.
:s *ve already said, the iss#e of what is a component is the s#b,ect of endless debate. &ne of the more
helpf#l statements *ve fo#nd is this!
"omponents are not a technology% !echnology people seem to find this hard to understand%
"omponents are about ho# customers #ant to relate to soft#are% !hey #ant to be able to
buy their soft#are a piece at a time4 and to be able to upgrade it 5ust li0e they can upgrade
their stereo% !hey #ant ne# pieces to #or0 seamlessly #ith their old pieces4 and to be able
to upgrade on their o#n schedule4 not the manufacturer6s schedule% !hey #ant to be able to
mix and match pieces from various manufacturers% !his is a very reasonable re7uirement% 8t
is 5ust hard to satisfy.
"alph Cohnson, http://www.c(.com/cgi/wikiEo)omponents%&ist
2he important point is that components represent pieces that are independently p#rchasable and
#pgradeable. :s a res#lt, dividing a system into components is as m#ch a marketing decision as it is a
technical decision, for which F'ohmannG is an excellent g#ide. *ts also a reminder to beware of overly fine7
grained components, beca#se too many components are hard to manage, especially when versioning rears
its #gly head, hence "611 hell."
*n earlier versions of the )01, components were #sed to represent physical str#ct#res, s#ch as 611s.
2hats no longer tr#e@ for this task, yo# now #se artifacts (page DE).
When to Use Co!#onent "iagra!s
)se component diagrams when yo# are dividing yo#r system into components and want to show their
interrelationships thro#gh interfaces or the breakdown of components into a lower7level str#ct#re.
Cha#ter $8% Coa+orations
)nlike the other chapters in this book, this one does not correspond to an official diagram in )01 4. 2he
standard disc#sses collaborations as part of composite str#ct#res, b#t the diagram is really .#ite different
and was #sed in )01 3 witho#t any link to composite str#ct#res. So * felt it best to disc#ss collaborations
as their own chapter.
1ets consider the notion of an a#ction. *n any a#ction, we might have a seller, some b#yers, a lot of goods,
and some offers for the sale. We can describe these elements in terms of a class diagram (%ig#re 3K.3) and
perhaps some interaction diagrams (%ig#re 3K.4).
Figure '6.'. ! collaboration with its class diagram of roles
*n the interaction diagram, the participants are labeled slightly differently from the #s#al case. *n a
collaboration, the naming scheme is participant-name 4role-name : class-name. :s #s#al, all these
elements are optional.
When yo# #se a collaboration, yo# can show that by placing a collaboration occ#rrence on a class
diagram, as in %ig#re 3K.I, a class diagram of some of the classes in the application. 2he links from the
collaboration to those classes indicate how the classes play the vario#s roles defined in the collaboration.
Figure '6.-. ! collaboration occurrence
2he )01 s#ggests that yo# can #se the collaboration occ#rrence notation to show the #se of patterns,
b#t hardly any patterns a#thor has done this. Arich Bamma developed a nice alternative notation (%ig#re
3K.J). Alements of the diagram are labeled with either the pattern name or a combination of
pattern:role.
Figure '6.5. ! nonstandard way of showing pattern use in AUnit .0unit.org/
When to Use Coa+orations
-ollaborations have been aro#nd since )01 3, b#t * admit *ve hardly #sed them, even in my patterns
writing. -ollaborations do provide a way to gro#p ch#nks of interaction behavior when roles are played by
different classes. *n practice, however, *ve not fo#nd that theyve been a compelling diagram type.
Cha#ter $>% &nteraction '(er(iew "iagra!s
*nteraction overview diagrams are a grafting together of activity diagrams and se.#ence diagrams. /o# can
think of interaction overview diagrams either as activity diagrams in which the activities are
replaced by little se.#ence diagrams, or as a se.#ence diagram broken #p with activity diagram notation
#sed to show control flow. Aither way, they make a bit of an odd mixt#re.
%ig#re 3L.3 shows a simple example of one@ the notation is familiar from what yo#ve already seen in the
activity diagram and se.#ence diagram chapters. *n this diagram, we want to prod#ce and format an order
s#mmary report. *f the c#stomer is external, we get the information from +01@ if internal, we get it from a
database. Small se.#ence diagrams show the two alternatives. &nce we get the data, we format the
report@ in this case, we dont show the se.#ence diagram b#t simply reference it with a reference
interaction frame.
When to Use &nteraction '(er(iew "iagra!s
2hese are new for )01 4, and its too early to get m#ch sense of how well they will work o#t in practice.
*m not keen on them, as * think that they mix two styles that dont really mix that well. Aither draw an
activity diagram or #se a se.#ence diagram, depending on what better serves yo#r p#rpose.
Cha#ter $?% Ti!ing "iagra!s
:fter leaving secondary school, * started o#t in electronic engineering before * switched into comp#ting. So
* feel a certain ang#ished familiarity when * see the )01 define timing diagrams as one of its standard
diagrams. 2iming diagrams have been aro#nd in electronic engineering for a long time and never seemed
to need the )01s help to define their meaning. =#t since they are in the )01, they deserve a brief
mention.
2iming diagrams are another form of interaction diagram, where the foc#s is on timing constraints! either
for a single ob,ect or, more #sef#lly, for a b#nch of ob,ects. 1ets take a simple scenario based on the p#mp
and hotplate for a coffee pot. 1ets imagine a r#le that says that at least 35 seconds m#st pass between
the p#mp coming on and the hotplate coming on. When the water reservoir becomes empty, the p#mp
switches off, and the hotplate cannot stay on for more than 3K min#tes more.
%ig#res 3E.3 and 3E.4 are alternative ways of showing these timing constraints. =oth diagrams show the
same basic information. 2he main difference is that %ig#re 3E.3 shows the state changes by moving from
one hori$ontal line to another, while %ig#re 3E.4 retains the same hori$ontal position b#t shows state
changes with a cross. 2he style of %ig#re 3E.3 works better when there are ,#st a few states, as in this
case, and %ig#re 3E.4 is better when there are many states to deal with.
Figure 'B.(. *iming diagram showing states as areas
2he dashed lines that *ve #sed on the Z^35s[ constraints are optional. )se them if yo# think they help
clarify exactly what events the timing constrains.
When to Use Ti!ing "iagra!s
2iming diagrams are #sef#l for showing timing constraints between state changes on different
ob,ects. 2he diagrams are partic#larly familiar to hardware engineers.
A##endi* Changes +etween UML <ersions
When the first edition of this book appeared on the shelves, the )01 was in version 3.5. 0#ch of it
appeared to have stabili$ed and was in the process of &0B recognition. Since then, there have been a
n#mber of revisions. *n this appendix, * describe the significant changes that have occ#rred since
3.5 and how those changes affect the material in this book.
2his appendix s#mmari$es the changes so yo# can keep #p to date if yo# have an earlier printing of the
book. * have made changes to the book to keep #p with the )01, so if yo# have a later printing, it
describes the sit#ation as it was as of the print date.
1e(isions to the UML
2he earliest p#blic release of what came to be the )01 was version 5.; of the )nified 0ethod, which was
released for &&?S1: in &ctober 3DDK. 2his was the work of =ooch and "#mba#gh, as Cacobson did not ,oin
"ational #ntil aro#nd that time. *n 3DDL, "ational released versions 5.D and 5.D3, which incl#ded
Cacobsons work. :fter the latter version, they changed the name to the )01.
"ational and a gro#p of partners s#bmitted version 3.5 of the )01 to the &0B :nalysis and 6esign 2ask
%orce in Can#ary 3DDE. S#bse.#ently, the "ational partnership and the other s#bmitters combined their
work and s#bmitted a single proposal for the &0B standard in September 3DDE, for version 3.3 of the
)01. 2his was adopted by the &0B toward the end of 3DDE. 'owever, in a fit of darkest obf#scation, the
&0B called this standard version 3.5. So, now the )01 was both &0B version 3.5 and "ational version
3.3, not to be conf#sed with "ational 3.5. *n practice, everyone calls that standard version 3.3.
%rom then on, there were a n#mber of f#rther developments in the )01. )01 3.4 appeared in 3DD;,
3.I in 3DDD, 3.J in 4553, and 3.K in 4554. 0ost of the changes between the 3.x versions were fairly deep
in the )01, except for )01 3.I, which ca#sed some very visible changes, especially to #se cases and
activity diagrams.
:s the )01 3 series contin#ed, the developers of the )01 set their sights on a ma,or revision to the )01
with )01 4. 2he first "%?s ("e.#est for ?roposals) were iss#ed in 4555, b#t )01 4 didnt start to properly
stabili$e #ntil 455I.
%#rther developments in the )01 will almost certainly occ#r. 2he )01 %or#m (http://uml forum.com) is
#s#ally a good place to look for more information. * also keep some )01 information on my site
(http://martinfowler.com).
Changes in UML Distilled
:s these revisions go on, *ve been trying to keep #p by revising UML Distilled with s#bse.#ent printings.
*ve also taken the opport#nity to fix errors and make clarifications.
2he most dynamic period for keeping #p with things was d#ring the first edition of UML Distilled, when we
often had to make #pdates between printings to keep #p with the emerging )01 standard. 2he first
thro#gh fifth printings were based on )01 3.5. :ny changes to the )01 between these printings were
minor. 2he sixth printing took )01 3.3 into acco#nt.
2he seventh thro#gh tenth printings were based on )01 3.4@ the eleventh printing was the first to #se )01
3.I. ?rintings based on versions of the )01 after 3.5 have the )01 version n#mber on the front cover.
2he first tho#gh sixth printings of the second edition were based on version 3.I. 2he seventh printing was
the first to take into acco#nt the minor changes of version 3.J.
2he third edition was la#nched to #pdate the book with )01 4 (see 2able :.3). *n the rest of this appendix,
* s#mmari$e the ma,or changes in the )01 from 3.5 to 3.3, from 3.4 to 3.I, and from 3.x to 4.5. * dont
disc#ss all the changes that occ#r b#t rather only those that change something * said in UML Distilled or
that represent important feat#res that * wo#ld have disc#ssed in UML Distilled.
* am contin#ing to follow the spirit of UML Distilled! to disc#ss the key elements of )01 as they affect the
application of the )01 within real7world pro,ects. :s ever, the selections and advice are my own. *f there is
any conflict between what * say and the official )01 doc#ments, the )01 doc#ments are the ones to
follow. (=#t do let me know, so * can make corrections.)
*able !.'. UML istilled and corresponding UML versions
UML Distilled UML =ersions
'st edition UML '.3?'.-
(nd edition UML '.-?'.5
-rd edition UML (.3 onward
* have also taken the opport#nity to indicate any important errors and omissions in the
earlier printings. 2hanks to the readers who have pointed these o#t to me.
Changes fro! UML $%B to $%$
Ty#e and &!#e!entation Cass
*n the first edition of UML Distilled, * talked abo#t perspectives and how they altered the way people draw
and interpret modelsTin partic#lar, class diagrams. )01 now takes this into acco#nt by saying that all
classes on a class diagram can be speciali$ed as either types or implementation classes.
:n implementation class corresponds to a class in the software environment in which yo# are
developing. : type is rather more neb#lo#s@ it represents a less implementation7bo#nd abstraction. 2his
co#ld be a -&"=: type, a specification perspective of a class, or a concept#al perspective. *f necessary,
yo# can add stereotypes to differentiate f#rther.
/o# can state that for a partic#lar diagram, all classes follow a partic#lar stereotype. 2his is what yo#
wo#ld do when drawing a diagram from a partic#lar perspective. 2he implementation perspective wo#ld
#se implementation classes, whereas the specification and concept#al perspective wo#ld #se types.
/o# #se the reali$ation relationship to indicate that an implementation class implements one or more types.
2here is a distinction between type and interface. :n interface is intended to directly correspond to a Cava
or -&07style interface. *nterfaces th#s have only operations and no attrib#tes.
/o# may #se only single, static classification with implementation classes, b#t yo# can #se m#ltiple and
dynamic classification with types. (* ass#me that this is beca#se the ma,or && lang#ages follow single,
static classification. *f one fine day yo# #se a lang#age that s#pports m#ltiple or dynamic classification,
that restriction really sho#ld not apply.)
Co!#ete and &nco!#ete "iscri!inator Constraints
*n previo#s printings of UML Distilled, * said that the {complete} constraint on a generali$ation
indicated that all instances of the s#pertype m#st also be an instance of a s#btype within that partition.
)01 3.3 defines instead that {complete} indicates that all s#btypes within that partition have been
specified, which is not .#ite the same thing. * have fo#nd some inconsistency on the interpretation of
this constraint, so yo# sho#ld be wary of it. *f yo# do want to indicate that all instances of the s#pertype
sho#ld be an instance of one of the s#btypes, * s#ggest #sing another constraint to avoid conf#sion.
-#rrently, * am #sing {mandatory}.
Co!#osition
*n )01 3.5, #sing composition implied that the link was imm#table, or fro$en, at least for single7val#ed
components. 2hat constraint is no longer part of the definition.
&!!uta+iity and Fro5en
)01 defines the constraint {fro;en} to define imm#tability on association roles. :s its c#rrently defined,
it doesnt seem to apply it to attrib#tes or classes. *n my practice, * now #se the term fro7en instead of
imm#tability, and *m happy to apply the constraint to association roles, classes, and attrib#tes.
1eturns on Se)uence "iagra!s
*n )01 3.5, a ret#rn on a se.#ence diagram was disting#ished by #sing a stick arrowhead instead of a
solid arrowhead (see previo#s printings). 2his was something of a pain, as the distinction was too s#btle
and easy to miss. )01 3.3 #ses a dashed arrow for a ret#rn, which pleases me, as it makes ret#rns m#ch
more obvio#s. (:s * #sed dashed ret#rns in Analysis atterns F%owler, :?G, it also makes me look
infl#ential.) /o# can name what is ret#rned for later #se by #sing the form enoug*StocB := c*ecB().
Use of the Ter! E1oeE
*n )01 3.5, the term role indicated primarily a direction on an association (see previo#s printings). )01
3.3 refers to this #sage as an association role. 2here is also a collaboration role, which is a role that
an instance of a class plays in a collaboration. )01 3.3 gives a lot more emphasis to collaborations, and it
looks as tho#gh this #se of "role" may become the primary one.
Changes fro! UML $%0 :and $%$; to $%3 :and $%8;
Use Cases
2he changes to #se cases involve new relationships between #se cases. )01 3.3 has two #se case
relationships! 7uses8 and 7e>tends8, both of which are stereotypes of generali$ation. )01 3.I offers
three relationships.
1 2he 7include8 constr#ct is a stereotype of dependency. 2his indicates that the path of one #se case
is incl#ded in another. 2ypically, this occ#rs when a few #se cases share common steps. 2he
incl#ded #se case can factor o#t the common behavior. :n example from an :20 might be that
Withdraw 0oney and 0ake 2ransfer both #se Malidate -#stomer. 2his replaces the common #se of
7uses8.
2 )se case generali7ation indicates that one #se case is a variation on another. 2h#s, we might have
one #se case for Withdraw 0oneyTthe base #se caseTand a separate #se case to handle the case
when the withdrawal is ref#sed beca#se of lack of f#nds. 2he ref#sal co#ld be handled as a #se case
that speciali$es the withdrawal #se case. (/o# co#ld also handle it as simply another scenario within
the Withdraw 0oney #se case.) : speciali$ing #se case like this may change any aspect of the base
#se case.
3 2he 7e>tend8 constr#ct is a stereotype of dependency. 2his provides a more controlled form of
extension than the generali$ation relationship. 'ere, the base #se case declares a n#mber of
extension points. 2he extending #se case can alter behavior only at those extension points. So, if
yo# are b#ying a prod#ct on line, yo# might have a #se case for b#ying a prod#ct with extension
points for capt#ring the shipping information and capt#ring payment information. 2hat #se case
co#ld then be extended for a reg#lar c#stomer for which this information wo#ld be obtained in a
different way.
2here is some conf#sion abo#t the relationship between the old relationships and the new ones. 0ost
people #sed 7uses8 the way the 3.I 7includes8 is #sed, so for most people, we can say that 7includes8
replaces 7uses8. :nd most people #sed 3.3 7e>tends8 in both the controlled manner of the 3.I
7e>tends8 and as a general overriding in the style of the 3.I generali$ation. So, yo# can think that 3.3
7e>tends8 has been split into the 3.I 7e>tend8 and generali$ation.
(ow, altho#gh this explanation covers most )01 #sage that *ve seen, it isnt the strictly correct way of
#sing those old relationships. 'owever, most people didnt follow the strict #sage, and * dont really want to
get into all that here.
Acti(ity "iagra!s
When the )01 reached version 3.4, there were .#ite a few open .#estions abo#t the semantics of
activity diagrams. So, the 3.I effort involved .#ite a lot of tightening #p on these semantics.
%or conditional behavior, yo# can now #se the diamond7shaped decision activity for a merge of
behavior as well as a branch. :ltho#gh neither branches nor merges are necessary to describe
conditional behavior, it is increasingly common style to show them so that yo# can bracket
conditional behavior.
2he synchroni$ation bar is now referred to as a forkTwhen splitting controlTor as a 0oinTwhen
synchroni$ing control together. 'owever, yo# can no longer add arbitrary conditions to ,oins. :lso, yo#
m#st follow matching r#les to ens#re that forks and ,oins match #p. Assentially, this means that each fork
m#st have a corresponding ,oin that ,oins the threads started by that fork. /o# can nest fork and ,oins,
tho#gh, and yo# can eliminate forks and ,oins on the diagram when threads go directly from one fork to
another fork, or one ,oin to another ,oin.
Coins are fired only when all incoming threads complete. 'owever, yo# can have a condition on a thread
coming o#t of a fork. *f that condition is false, that thread is considered complete for ,oining p#rposes.
2he m#ltiple7trigger feat#re is no longer present. *n its place, yo# can have dynamic conc#rrency in an
activity, shown with a Y inside an activity box. S#ch an activity may be invoked several times in parallel@
all its invocations m#st complete before any o#tgoing transition can be taken. 2his is loosely e.#ivalent
to, altho#gh less flexible than, a m#ltiple trigger and matching synchroni$ation condition.
2hese r#les red#ce some of flexibility of activity diagrams b#t do ens#re that activity diagrams are tr#ly
special cases of state machines. 2he relationship between activity diagrams and state machines was a
matter of some debate in the "2%. %#t#re versions of the )01 (after 3.J) may well make activity diagrams
a completely different form of diagram.
Changes fro! UML $%3 to $%6
2he most visible change in )01 3.J is the addition of profiles, which allows a gro#p of extensions to be
collected together into a coherent set. 2he )01 doc#mentation incl#des a co#ple of example profiles.
2ogether with this, theres greater formalism involved in defining a stereotype, and model elements can
now have m#ltiple stereotypes@ they were limited to one stereotype in )01 3.I.
!rtifacts were added to the )01. :n artifact is a physical manifestation of a component, so, for example,
+erces is a component and all those copies of the +erces ,ar on my disk drive are artifacts that implement
the +erces component.
?rior to 3.I, there was nothing in the )01 meta7model to handle Cavas package visibility. (ow there
is, and the symbol is "\".
)01 3.J also made the stick arrowhead in interaction diagrams mark asynchrono#s, a rather
awkward backward7incompatible change. 2hat ca#ght o#t a few people, incl#ding me.
Changes fro! UML $%6% to $%8
2he principal change here was adding action semantics to the )01, a necessary step to make )01 a
programming lang#age. 2his was done to allow people to work on this witho#t waiting for the f#ll )01 4.
Fro! UML $%* to UML 0%B
)01 4 represents the biggest change thats happened yet to the )01. :ll sorts of things have
changed with this revision, and many changes have affected UML Distilled.
Within the )01, there have been deep changes to the )01 meta7model. :ltho#gh these changes dont
affect the disc#ssion in UML Distilled, they are very important to some gro#ps.
&ne of the most obvio#s changes is the introd#ction of new diagram types. &b,ect diagrams and package
diagrams were widely drawn before b#t werent official diagram types@ now they are. )01 4 changed the
name of collaboration diagrams to comm#nication diagrams. )01 4 has also introd#ced new diagram
types! interaction overview diagrams, timing diagrams, and composite str#ct#re diagrams.
: lot of changes havent to#ched UML Distilled. *ve left o#t disc#ssion of s#ch constr#cts as state
machine extensions, gates in interactions diagrams, and power types in class diagrams.
So for this section, *m disc#ssing only changes that make it into UML Distilled. 2hese are either
changes to things * disc#ssed in previo#s editions or new things *ve started to disc#ss with this edition.
=eca#se the changes are so widespread, *ve organi$ed them according to the chapters in this book.
Cass "iagra!s4 The Essentias :Cha#ter 3;
:ttrib#tes and #nidirectional associations are now primarily simply different notations for the same
#nderlying concept of property. 6iscontin#o#s m#ltiplicities, s#ch as F4, JG, have been dropped. 2he
fro$en property has been dropped. *ve added a list of common dependency keywords, several of which
are new to )01 4. 2he 7parameter8, and 7local8 keywords have been dropped.
Se)uence "iagra!s :Cha#ter 6;
2he big change here is the interaction frame notation for se.#ence diagrams to handle iterative,
conditional, and vario#s other controls of behavior. 2his now allows yo# to express algorithms pretty
completely in se.#ence diagrams, altho#gh *m not convinced that these are any clearer than code. 2he old
iteration markers and g#ards on messages have been dropped from se.#ence diagrams. 2he heads of the
lifelines are no longer instances@ * #se the term participant to refer to them. 2he collaboration diagrams
of )01 3 were renamed to comm#nication diagrams for )01 4.
Cass "iagra!s4 Conce#ts :Cha#ter 8;
Stereotypes are now more tightly defined. :s a res#lt, * now refer to words in g#illemets as keywords,
only some of which are stereotypes. *nstances on ob,ect diagrams are now instance specifications. -lasses
can now re.#ire interfaces as well as provide them. 0#ltiple classification #ses generali$ation sets to
gro#p generali$ations into gro#ps. -omponents are no longer drawn with their special symbol. :ctive
ob,ects have do#ble vertical lines instead of thick lines.
State Machine "iagra!s :Cha#ter $B;
)01 3 separated short7lived actions from long7lived activities. )01 4 calls both activities and #ses the
term do7activity for the long7lived activities.
Acti(ity "iagra!s :Cha#ter $$;
)01 3 treated activity diagrams as a special case of state diagram. )01 4 broke that link and as a res#lt
removed the r#les of matching forks and ,oins that )01 4 activity diagrams had to keep to. :s a res#lt,
they are best #nderstood by token flow rather than by state transition. : whole b#nch of new notation th#s
appeared, incl#ding time and accept signals, parameters, ,oin specifications, pins, flow transformations,
s#bdiagram rakes, expansion regions, and flow finals.
: simple b#t awkward change is that )01 3 treated m#ltiple incoming flows to an activity as an implicit
merge, while )01 4 treats them as an implicit ,oin. %or this reason, * advise #sing an explicit merge or ,oin
when doing activity diagrams.
Swim lanes can now be m#ltidimensional and are generally called partitions.
Bi+iogra#hy
F!mblerG Scott :mbler, Agile Modeling, Wiley, 4554. F,eckG >ent =eck, &xtreme rogramming &xplained:
&mbrace "hange, :ddison7Wesley, 4555. F,eck and FowlerG >ent =eck and 0artin %owler, lanning
&xtreme rogramming, :ddison7Wesley,
4555. F,eck and )unninghamG >ent =eck and Ward -#nningham, ": 1aboratory for 2eaching &b,ect7
&riented 2hinking," roceedings of 99:LA );, 4J (35)! 3]L.
http://c(.com/doc/oopsla<C/paper.html
F,oochH ++!G Brady =ooch, 9b5ect$9riented Analysis and Design #ith Applications4 :econd
&dition. :ddison7Wesley, 3DDJ. F,oochH UML userG Brady =ooch, Cim "#mba#gh, and *var Cacobson, UML
User Guide, :ddison7Wesley, 3DDD.
F)oadH ++!G ?eter -oad and Adward /o#rdon, 9b5ect$9riented Analysis, /o#rdon ?ress, 3DD3. F)oadH
++G ?eter -oad and Adward /o#rdon, 9b5ect$9riented Design, /o#rdon ?ress, 3DD3. F)ockburnH
agileG :listair -ockb#rn, Agile :oft#are Development, :ddison7Wesley, 4553. F)ockburnH use casesG
:listair -ockb#rn, 3riting &ffective Use "ases, :ddison7Wesley, 4553. F)onstantine and LockwoodG
1arry -onstantine and 1#cy 1ockwood, :oft#are for Use, :ddison7
Wesley, 4555.
F)ook and anielsG Steve -ook and Cohn 6aniels, Designing 9b5ect :ystems: 9b5ect$9riented Modeling
#ith :yntropy, ?rentice7'all, 3DDJ. F)ore A(%% "atternsG 6eepak :l#r, Cohn -r#pi, and 6an 0alks, "ore
<=&& atterns, ?rentice7'all,
4553. F)unninghamG Ward -#nningham, "A?*S&6AS! : ?attern 1ang#age of -ompetitive 6evelopment."
*n attern Languages of rogram Design =, Mlissides, -oplien, and >erth, :ddison7Wesley, 3DDL, pp. IE3]
I;;. FouglassG =r#ce ?owel 6o#glass, Real$!ime UML, :ddison7Wesley, 3DDD. FFowlerH !"G 0artin
%owler, Analysis atterns: Reusable 9b5ect Models, :ddison7Wesley, 3DDE. FFowlerH new methodologyG
0artin %owler, "2he (ew 0ethodology,"
http://martinfowler.com/articles/newMethodology.html
FFowler and FoemmelG 0artin %owler and 0atthew %oemmel, "-ontin#o#s *ntegration,"
http://martinfowler.com/articles/continuous#ntegration.html
FFowlerH " of %!!G 0artin %owler, atterns of &nterprise Application Architecture, :ddison7Wesley, 455I.
FFowlerH refactoringG 0artin %owler, Refactoring: 8mproving the Design of &xisting rograms,
:ddison7Wesley, 3DDD.
F:ang of FourG Arich Bamma, "ichard 'elm, "alph Cohnson, and Cohn Mlissides, Design atterns:
&lements of Reusable 9b5ect$9riented :oft#are, :ddison7Wesley, 3DDK. FIighsmithG Cim 'ighsmith, Agile
:oft#are Development &cosystems, :ddison7Wesley, 4554.
FIohmannG 1#ke 'ohmann, >eyond :oft#are Architecture, :ddison7Wesley, 455I. FAacobsonH
++$%G *var Cacobson, 0agn#s -hristerson, ?atrik Consson, and B#nnar Qvergaard, 9b5ect$9riented
:oft#are &ngineering: A Use "ase Driven Approach, :ddison7Wesley, 3DD4.
FAacobsonH U"G *var Cacobson, 0aria Aricsson, and :gneta Cacobson, !he 9b5ect Advantage:
>usiness rocess Reengineering #ith 9b5ect !echnology, :ddison7Wesley, 3DDK. F9erthG (orm
>erth, ro5ect Retrospectives, 6orset 'o#se, 4553
F9leppe et al.G :nneke >leppe, Cos Warmer, and Wim =ast, MDA &xplained, :ddison7Wesley, 455I.
F9ruchtenG ?hilippe >r#chten, !he Rational Unified rocess: An 8ntroduction, :ddison7Wesley, 3DDD.
FLarmanG -raig 1arman, Applying UML and atterns, 4d ed., ?rentice7'all, 4553.
FMartinG "obert -ecil 0artin, !he rinciples4 atterns4 and ractices of Agile :oft#are Development,
?rentice7'all, 455I. FMc)onnellG Steve 0c-onnell, Rapid Development: !aming 3ild :oft#are :chedules,
0icrosoft
?ress, 3DDL. FMellor and ,alcerG Steve 0ellor and 0arc =alcer, &xecutable UML, :ddison7Wesley, 4554.
FMeyerG =ertrand 0eyer, 9b5ect$9riented :oft#are "onstruction. ?rentice7'all, 4555. F+dellG Cames
0artin and Cames C. &dell, 9b5ect$9riented Methods: A 2oundation 'UML &dition+,
?rentice 'all, 3DD;. F"ontG 0ichael ?ont, atterns for !ime$!riggered &mbedded :ystems, :ddison7
Wesley, 4553. F"+$!'G %rank =#schmann, "egine 0e#nier, 'ans "ohnert, ?eter Sommerlad, and
0ichael Stal,
attern$9riented :oft#are Architecture: A :ystem of atterns, Wiley, 3DDL.
F"+$!(G 6o#glas Schmidt, 0ichael Stal, 'ans "ohnert, and %rank =#schmann, attern$9riented :oft#are
Archtecture ?olume =: atterns for "oncurrent and @et#or0ed 9b5ects, Wiley, 4555. F1umbaughH
insightsG Cames "#mba#gh, 9M! 8nsights, S*BS =ooks, 3DDL. F1umbaughH +M*G Cames "#mba#gh,
0ichael =laha, William ?remerlani, %rederick Addy, and
William 1oren$en, 9b5ect$9riented Modeling and Design, ?rentice7'all, 3DD3.
F1umbaughH UML 1eferenceG Cames "#mba#gh, *var Cacobson, and Brady =ooch, !he Unified
Modeling Language Reference Manual, :ddison7Wesley, 3DDD. F$hlaer and MellorH dataG Sally Shlaer
and Stephen C. 0ellor, 9b5ect$9riented :ystems Analysis:
Modeling the 3orld in Data, /o#rdon ?ress, 3D;D. F$hlaer and MellorH statesG Sally Shlaer and
Stephen C. 0ellor, 9b5ect Lifecycles: Modeling the 3orld in :tates. /o#rdon ?ress, 3DD3.
FDarmer and 9leppeG Cos Warmer and :nneke >leppe, !he 9b5ect "onstraint Language: recise
Modeling #ith UML, :ddison7Wesley, 3DD;.
FDirfs-,rockG "ebecca Wirfs7=rock and :lan 0c>ean, 9b5ect Design: Roles Responsibilities and
"ollaborations. ?rentice7'all, 455I.