UML Distilled: A Brief Guide to the Standard Object Modeling Language (2nd Edition) [2nd ed.] 020165783X, 9780201657838

Citation preview

1/ 118

FOREWORD TO THE THIRD EDITION ................................................................................................................................... 4 FOREWORD TO THE FIRST EDITION.................................................................................................................................... 5 PREFACE ........................................................................................................................................................................... 5 Why Bother with the UML?........................................................................................................................................ 6 Structure of the Book.................................................................................................................................................. 7 Changes for the Third Edition.................................................................................................................................... 7 Acknowledgments ...................................................................................................................................................... 7 DIAGRAMS ....................................................................................................................................................................... 10 CHAPTER 1. INTRODUCTION ............................................................................................................................................ 14 What Is the UML?..................................................................................................................................................... 14 Where to Find Out More .......................................................................................................................................... 14 Ways of Using the UML ........................................................................................................................................... 15 How We Got to the UML .......................................................................................................................................... 18 Notations and Meta-Models..................................................................................................................................... 20 UML Diagrams.......................................................................................................................................................... 21 What Is Legal UML?................................................................................................................................................. 23 The Meaning of UML................................................................................................................................................ 24 UML Is Not Enough.................................................................................................................................................. 24 Where to Start with the UML.................................................................................................................................... 25 CHAPTER 2. DEVELOPMENT PROCESS ............................................................................................................................ 26 Iterative and Waterfall Processes............................................................................................................................ 26 Predictive and Adaptive Planning............................................................................................................................ 28 Agile Processes........................................................................................................................................................ 29 Rational Unified Process.......................................................................................................................................... 30 Fitting a Process to a Project................................................................................................................................... 30 Fitting the UML into a Process ................................................................................................................................ 32 Choosing a Development Process.......................................................................................................................... 35 Where to Find Out More .......................................................................................................................................... 35 CHAPTER 3. CLASS DIAGRAMS: THE ESSENTIALS ........................................................................................................... 35 Properties.................................................................................................................................................................. 36 When to Use Class Diagrams ................................................................................................................................. 38 Where to Find Out More .......................................................................................................................................... 38 Multiplicity.................................................................................................................................................................. 38 Programming Interpretation of Properties .............................................................................................................. 39 Bidirectional Associations........................................................................................................................................ 41 Operations................................................................................................................................................................. 42 Generalization........................................................................................................................................................... 43 Notes and Comments .............................................................................................................................................. 44 Dependency.............................................................................................................................................................. 44 Constraint Rules....................................................................................................................................................... 46 CHAPTER 4. SEQUENCE DIAGRAMS ................................................................................................................................. 47 Creating and Deleting Participants.......................................................................................................................... 50 Loops, Conditionals, and the Like........................................................................................................................... 51 Synchronous and Asynchronous Calls................................................................................................................... 54 When to Use Sequence Diagrams.......................................................................................................................... 54 CHAPTER 5. CLASS DIAGRAMS: ADVANCED CONCEPTS .................................................................................................. 56 Keywords .................................................................................................................................................................. 56 Classification and Generalization............................................................................................................................ 57 Multiple and Dynamic Classification........................................................................................................................ 57 Association Class ..................................................................................................................................................... 58 Template (Parameterized) Class............................................................................................................................. 61 Enumerations............................................................................................................................................................ 62 Active Class .............................................................................................................................................................. 63 Visibility ..................................................................................................................................................................... 63 Messages.................................................................................................................................................................. 64 Responsibilities......................................................................................................................................................... 64 Static Operations and Attributes.............................................................................................................................. 65 Aggregation and Composition................................................................................................................................. 65 Derived Properties.................................................................................................................................................... 66 Interfaces and Abstract Classes.............................................................................................................................. 67 Read-Only and Frozen............................................................................................................................................. 70 Reference Objects and Value Objects.................................................................................................................... 70 Qualified Associations.............................................................................................................................................. 71 CHAPTER 6. OBJECT DIAGRAMS ...................................................................................................................................... 72 2/ 118

When to Use Object Diagrams................................................................................................................................ 72 CHAPTER 7. PACKAGE DIAGRAMS ................................................................................................................................... 73 Packages and Dependencies.................................................................................................................................. 74 Package Aspects...................................................................................................................................................... 76 Implementing Packages........................................................................................................................................... 76 When to Use Package Diagrams............................................................................................................................ 77 Where to Find Out More .......................................................................................................................................... 78 CHAPTER 8. DEPLOYMENT DIAGRAMS ............................................................................................................................. 78 When to Use Deployment Diagrams....................................................................................................................... 79 CHAPTER 9. USE CASES ................................................................................................................................................. 79 Content of a Use Case............................................................................................................................................. 80 Use Case Diagrams ................................................................................................................................................. 81 Levels of Use Cases ................................................................................................................................................ 82 Use Cases and Features (or Stories) ..................................................................................................................... 82 When to Use Use Cases.......................................................................................................................................... 83 Where to Find Out More .......................................................................................................................................... 83 CHAPTER 10. STATE MACHINE DIAGRAMS ...................................................................................................................... 83 Internal Activities ...................................................................................................................................................... 85 Activity States ........................................................................................................................................................... 85 Superstates............................................................................................................................................................... 86 Concurrent States..................................................................................................................................................... 86 Implementing State Diagrams................................................................................................................................. 87 When to Use State Diagrams.................................................................................................................................. 89 Where to Find Out More .......................................................................................................................................... 89 CHAPTER 11. ACTIVITY DIAGRAMS .................................................................................................................................. 89 Decomposing an Action........................................................................................................................................... 91 And There's More..................................................................................................................................................... 93 When to Use Activity Diagrams............................................................................................................................... 93 Where to Find Out More .......................................................................................................................................... 93 Partitions ................................................................................................................................................................... 93 Signals....................................................................................................................................................................... 94 Tokens....................................................................................................................................................................... 95 Flows and Edges...................................................................................................................................................... 96 Pins and Transformations........................................................................................................................................ 96 Expansion Regions .................................................................................................................................................. 97 Flow Final.................................................................................................................................................................. 98 Join Specifications.................................................................................................................................................... 99 CHAPTER 12. COMMUNICATION DIAGRAMS ................................................................................................................... 100 When to Use Communication Diagrams............................................................................................................... 101 CHAPTER 13. COMPOSITE STRUCTURES ....................................................................................................................... 101 When to Use Composite Structures...................................................................................................................... 103 CHAPTER 14. COMPONENT DIAGRAMS .......................................................................................................................... 103 When to Use Component Diagrams ..................................................................................................................... 105 CHAPTER 15. COLLABORATIONS ................................................................................................................................... 105 When to Use Collaborations.................................................................................................................................. 107 CHAPTER 16. INTERACTION OVERVIEW DIAGRAMS ........................................................................................................ 107 When to Use Interaction Overview Diagrams ...................................................................................................... 108 CHAPTER 17. TIMING DIAGRAMS ................................................................................................................................... 109 When to Use Timing Diagrams.............................................................................................................................. 110 APPENDIX CHANGES BETWEEN UML VERSIONS ............................................................................................................ 110 Revisions to the UML............................................................................................................................................. 110 Changes in UML Distilled....................................................................................................................................... 111 Changes from UML 1.0 to 1.1 ............................................................................................................................... 112 Changes from UML 1.2 (and 1.1) to 1.3 (and 1.5)............................................................................................... 113 Changes from UML 1.3 to 1.4 ............................................................................................................................... 114 Changes from UML 1.4. to 1.5 .............................................................................................................................. 114 From UML 1.x to UML 2.0...................................................................................................................................... 114 BIBLIOGRAPHY............................................................................................................................................................... 116

3/ 118

Foreword to the Third Edition Since ancient t im es, t he m ost t alent ed archit ects and t he m ost gift ed designers have known t he law of parsim ony. Whet her it is st at ed as a paradox ( " less is m ore" ) , or a koan ( "Zen m ind is beginner's m ind" ) , it s wisdom is t im eless: Reduce everyt hing t o it s essence so t hat form harm onizes wit h funct ion. From the pyram ids t o t he Sydney Opera House, from von Neum ann archit ect ures t o UNI X and Sm allt alk, t he best archit ect s and designers have st rived t o follow this universal and et ernal principle. Recognizing t he value of shaving wit h Occam 's Razor, when I archit ect and read I seek proj ect s and books t hat adhere t o t he law of parsim ony. Consequent ly, I applaud t he book you are reading now. You m ay find m y last rem ark surprising at first . I am frequent ly associat ed wit h t he volum inous and dense specificat ions that define t he Unified Modeling Language (UML) . These specificat ions allow t ool vendors t o im plem ent t he UML and m et hodologist s t o apply it . For seven years, I have chaired large int ernat ional st andardizat ion t eam s t o specify UML 1.1 and UML 2.0, as well as several m inor revisions in bet ween. During t his tim e, the UML has m at ured in expressiveness and precision, but it has also added grat uit ous com plexit y as a result of t he st andardizat ion process. Regret t ably, st andardizat ion processes are bet t er known for design- by-com m it t ee com prom ises than parsim onious elegance. What can a UML expert fam iliar wit h t he arcane m inut iae of the specificat ion learn from Mart in's dist illat ion of UML 2.0? Quit e a bit , as can you. To st art wit h, Mart in adroit ly reduces a large and com plex language int o a pragm at ic subset t hat he has proven effect ive in his pract ice. He has resist ed t he easy rout e of t acking on addit ional pages t o t he last edit ion of his book. As t he language has grown, Mart in has kept t rue t o his goal of seeking t he " fract ion of UML that is m ost useful" and t elling you j ust t hat . The fraction he refers t o is t he m yt hical 20 percent of UML that helps you do 80 percent of your work. Capt uring and t am ing t his elusive beast is no m ean accom plishm ent ! I t is even m ore im pressive t hat Mart in achieves t his goal while writ ing in a wonderfully engaging conversat ional st yle. By sharing his opinions and anecdot es wit h us, he m akes t his book fun t o read and rem inds us t hat archit ect ing and designing syst em s should be bot h creat ive and product ive. I f we pursue t he parsim ony koan t o it s full int ent , we should find UML m odeling proj ect s t o be as enj oyable as we found finger- paint ing and drawing classes in gram m ar school. UML should be a light ning rod for our creat ivit y as well as a laser for precisely specifying syst em blueprint s so t hat t hird part ies can bid and build t hose syst em s. The lat t er is t he acid t est for any bona fide blueprint language. So, while t his m ay be a sm all book, it is not a t rivial one. You can learn as m uch from Mart in's approach t o m odeling as you can learn from his explanat ions of UML 2.0. I have enj oyed working wit h Martin t o im prove the select ion and correct ness of t he UML 2.0 language feat ures explained in t his revision. We need t o keep in m ind t hat all living languages, bot h nat ural and synt het ic, m ust evolve or perish. Mart in's choices of new feat ures, along wit h your preferences and t hose of ot her pract it ioners, are a crucial part of t he UML revision process. They keep t he language vit al and help it evolve via nat ural select ion in the m arket place. Much challenging work rem ains before m odel- driven developm ent becom es m ainst ream , but I am encouraged by books like t his t hat explain UML m odeling basics clearly and apply them pragm at ically. I hope you will learn from it as I have and will use your new insight s t o im prove your own soft ware m odeling pract ices. Cris Kobryn Chair, U2 Part ners' UML 2.0 Subm ission Team Chief Technologist , Telelogic

4/ 118

Foreword to the First Edition When we began t o craft t he Unified Modeling Language, we hoped t hat we could produce a st andard m eans of expressing design t hat would not only reflect t he best practices of indust ry, but would also help dem yst ify the process of soft ware syst em m odeling. We believed t hat the availabilit y of a st andard m odeling language would encourage m ore developers t o m odel t heir soft ware syst em s before building t hem . The rapid and widespread adopt ion of t he UML dem onst rat es t hat t he benefit s of m odeling are indeed well known t o t he developer com m unit y. The creat ion of the UML was it self an it erat ive and increm ent al process very sim ilar t o t he m odeling of a large soft ware syst em . The end result is a st andard built on, and reflect ive of, t he m any ideas and cont ribut ions m ade by num erous individuals and com panies from t he obj ect com m unit y. We began t he UML effort , but m any ot hers helped bring it t o a successful conclusion; we are grat eful for t heir cont ribut ion. Creat ing and agreeing on a st andard m odeling language is a significant challenge by it self. Educat ing t he developm ent com m unit y, and present ing t he UML in a m anner that is bot h accessible and in t he cont ext of t he soft ware developm ent process, is also a significant challenge. I n t his decept ively short book, updat ed t o reflect the m ost recent changes t o t he UML, Mart in Fowler has m ore t han m et t his challenge. I n a clear and friendly st yle, Mart in not only int roduces t he key aspect s of UML, but also clearly dem onst rat es t he role UML plays in t he developm ent process. Along the way, we are t reat ed t o abundant nugget s of m odeling insight and wisdom drawn from Mart in's 12- plus years of design and m odeling experience. The result is a book t hat has int roduced m any t housands of developers t o UML, whet t ing t heir appet it e t o further explore t he m any benefit s of m odeling wit h t his now st andard m odeling language. We recom m end t he book t o any m odeler or developer int erest ed in get t ing a first look at UML and in gaining a perspective on t he key role it plays in t he developm ent process. Grady Booch I var Jacobson Jam es Rum baugh

Preface I 've been lucky in a lot of ways in m y life; one of m y great st rokes of fort une was being in t he right place wit h the right knowledge t o writ e t he first edit ion of t his book in 1997. Back t hen, t he chaot ic world of obj ect - orient ed (OO) m odeling was just beginning t o unify under t he Unified Modeling Language ( UML) . Since t hen, t he UML has becom e t he st andard for t he graphical m odeling of soft ware, not j ust for obj ect s. My fort une is that t his book has been t he m ost popular book on the UML, selling m ore t han a quart er of a m illion copies. Well, that 's very nice for m e, but should you buy t his book? I like t o st ress t hat t his is a brief book. I t 's not int ended t o give you t he det ails on every facet of t he UML, which has grown and grown over t he years. My int ent ion is t o find that fraction of t he UML t hat is m ost useful and t ell you j ust t hat . Alt hough a bigger book gives you m ore det ail, it also t akes longer t o read. And your t im e is t he biggest invest m ent you'll m ake in a book. By keeping t his book sm all, I 've spent the t im e select ing t he best bit s t o save you from having t o do t hat select ion yourself. ( Sadly, being sm aller doesn't m ean proport ionat ely cheaper; t here is a cert ain fixed cost t o producing a qualit y t echnical book.) 5/ 118

One reason t o have t his book is t o begin t o learn about the UML. Because t his is a short book, it will quickly get you up t o speed on t he essent ials of t he UML. Wit h t hat under your belt , you can go int o m ore det ail on t he UML wit h the bigger books, such as t he User Guide [ Booch, UML user] or t he Reference Manual [ Rum baugh, UML Reference] . This book can also act as a handy reference t o t he m ost com m on part s of t he UML. Alt hough t he book doesn't cover everyt hing, it 's a lot light er to carry around t han m ost ot her UML books. I t 's also an opinionat ed book. I 've been working wit h obj ect s for a long t im e now, and I have definit e ideas about what works and what doesn't . Any book reflect s t he opinions of the aut hor, and I don't t ry t o hide m ine. So if you're looking for som et hing that has a flavor of obj ect ivit y, you m ight want t o t ry som et hing else. Alt hough m any people have t old m e that this book is a good int roduct ion t o obj ect s, I didn't writ e it wit h t hat in m ind. I f you are aft er an int roduct ion t o OO design, I suggest Craig Larm an's book [ Larm an] . Many people who are int erest ed in t he UML are using t ools. This book concent rat es on t he st andard and on convent ional usage of t he UML and doesn't get int o t he det ails of what various t ools support . Alt hough t he UML did resolve t he t ower of Babel of pre-UML not at ions, m any annoying differences rem ain bet ween what t ools show and allow when drawing UML diagram s. I don't say m uch in t his book about Model Driven Archit ecture ( MDA) . Alt hough m any people consider the t wo t o be t he sam e t hing, m any developers use the UML wit hout being int erest ed in MDA. I f you want t o learn m ore about MDA, I would st art wit h this book t o get an overview of the UML first and t hen m ove on t o a book that 's m ore specific about MDA. Alt hough t he m ain point of t his book is t he UML, I 've also added bit s of ot her m at erial about t echniques, such as CRC cards, that are valuable for OO design. The UML is j ust a part of what you need t o succeed wit h obj ect s, and I t hink that it 's im port ant t o int roduce you t o som e ot her t echniques. I n a brief book like t his, it 's im possible t o go int o det ail about how t he UML relat es t o source code, part icularly as t here is no st andard way of m aking t hat correspondence. However, I do point out com m on coding t echniques for im plem ent ing pieces of t he UML. My code exam ples are in Java and C# , as I 've found t hat t hese languages are usually t he m ost widely underst ood. Don't assum e that I prefer t hose languages; I 've done t oo m uch Sm allt alk for t hat !

Why Bother with the UML? Graphical design not at ions have been wit h us for a while. For m e, t heir prim ary value is in com m unicat ion and underst anding. A good diagram can oft en help com m unicat e ideas about a design, part icularly when you want t o avoid a lot of det ails. Diagram s can also help you underst and eit her a soft ware syst em or a business process. As part of a t eam t rying t o figure out som et hing, diagram s bot h help underst anding and com m unicat e that underst anding throughout a t eam . Alt hough t hey aren't , at least yet , a replacem ent for t ext ual program m ing languages, t hey are a helpful assist ant . Many people believe t hat in the fut ure, graphical t echniques will play a dom inant role in soft ware developm ent . I 'm m ore skept ical of t hat , but it 's cert ainly useful t o have an appreciat ion of what t hese not at ions can and can't do. Of t hese graphical not at ions, t he UML's im port ance com es from it s wide use and st andardizat ion wit hin t he OO developm ent com m unit y. The UML has becom e not only t he dom inant graphical not at ion wit hin t he OO world but also a popular t echnique in non- OO circles.

6/ 118

Structure of the Book Chapt er 1 gives an int roduct ion t o t he UML: what it is, t he different m eanings it has t o different people, and where it cam e from . Chapt er 2 t alks about soft ware process. Alt hough t his is st rict ly independent of t he UML, I t hink t hat it 's essent ial t o underst and process in order t o see t he cont ext of som et hing like t he UML. I n part icular, it 's im port ant t o underst and the role of it erat ive developm ent , which has been t he underlying approach t o process for m ost of t he OO com m unit y. I 've organized t he rest of t he book around the diagram t ypes wit hin t he UML. Chapt ers 3 and 4 discuss t he t wo m ost useful part s of the UML: class diagram s ( core) and sequence diagram s. Even t hough t his book is slim , I believe t hat you can get t he m ost value out of t he UML by using t he t echniques that I t alk about in t hese chapt ers. The UML is a large and growing beast , but you don't need all of it . Chapt er 5 goes int o det ail on t he less essent ial but st ill useful part s of class diagram s. Chapt ers 6 t hrough 8 describe t hree useful diagram s t hat shed further light on t he st ruct ure of a syst em : obj ect diagram s, package diagram s, and deploym ent diagram s. Chapt ers 9 t hrough 11 show t hree furt her useful behavioral t echniques: use cases, st at e diagram s ( alt hough officially known as st at e m achine diagram s, t hey are generally called st at e diagram s) , and act ivit y diagram s. Chapt ers 12 t hrough 17 are very brief and cover diagram s t hat are generally less im port ant , so for t hese, I 've only provided a quick exam ple and explanat ion. The inside covers sum m arize t he m ost useful part s of t he not at ion. I 've oft en heard people say t hat t hese covers are the m ost valuable part of t he book. You'll probably find it handy t o refer t o t hem as you're reading som e of t he ot her part s of t he book.

Changes for the Third Edition I f you have earlier edit ions of this book, you're probably wondering what is different and, m ore im port ant , whet her you should buy the new edit ion. The prim ary t rigger for t he third edit ion was t he appearance of UML 2. UML 2 has added a lot of new st uff, including several new diagram t ypes. Even fam iliar diagram s have a lot of new not at ion, such as int eract ion fram es in sequence diagram s. I f you want t o be aware of what 's happened but don't want t o wade t hrough the specificat ion ( I cert ainly don't recom m end t hat ! ) , this book should give you a good overview. I 've also t aken t his opport unit y t o com plet ely rewrit e m ost of t he book, bringing t he t ext and exam ples up t o dat e. I 've incorporat ed m uch t hat I 've learned in t eaching and using t he UML over t he past five years. So alt hough t he spirit of t his ult rat hin UML book is int act , m ost of t he words are new. Over the years, I 've worked hard t o keep t his book as current as is possible. As t he UML has gone t hrough it s changes, I 've done m y best t o keep pace. This book is based on t he UML 2 draft s t hat were accept ed by t he relevant com m it t ee in June 2003. I t 's unlikely t hat furt her changes will occur bet ween t hat vot e and m ore form al vot es, so I feel that UML 2 is now st able enough for m y revision t o go int o print . I 'll post inform at ion any furt her updat es on m y Web sit e ( h t t p:/ / m a rt in fow le r .com ) .

Acknowledgments 7/ 118

Over m any years, m any people have been part of t he success of t his book. My first t hanks go Cart er Shanklin and Kendall Scot t . Cart er was t he edit or at Addison-Wesley who suggest ed this book t o m e. Kendall Scot t helped m e put t oget her t he first t wo edit ions, working over t he t ext and graphics. Bet ween them , t hey pulled off t he im possible in get t ing t he first edit ion out in an im possibly short t im e, while keeping up t he high qualit y t hat people expect from Addison-Wesley. They also kept pushing out changes during the early days of the UML when not hing seem ed st able. Jim Odell has been m y m ent or and guide for m uch of t he early part of m y career. He's also been deeply involved wit h t he t echnical and personal issues of m aking opinionat ed m et hodologist s set t le t heir differences and agree t o a com m on st andard. His cont ribut ion t o t his book is bot h profound and difficult t o m easure, and I bet it 's t he sam e for t he UML t oo. The UML is a creat ure of st andards, but I 'm allergic t o st andards bodies. So t o know what 's going on, I need a net work of spies who can keep m e up t o dat e on all t he m achinat ions of t he com m it t ees. Wit hout these spies, including Conrad Bock, St eve Cook, Cris Kobryn, Jim Odell, Guus Ram ackers, and Jim Rum baugh, I would be sunk. They've all given m e useful tips and answered st upid quest ions. Grady Booch, I var Jacobson, and Jim Rum baugh are known as the Three Am igos. Despit e t he playful j ibes I 've given them over the years, they have given m e m uch support and encouragem ent wit h t his book. Never forget t hat m y j abs usually sprout from fond appreciat ion. Reviewers are t he key t o a book's qualit y, and I learned from Cart er t hat you can never have t oo m any reviewers. The reviewers of the previous edit ions of this book were Sim m i Kochhar Bhargava, Grady Booch, Eric Evans, Tom Hadfield, I var Jacobson, Ronald E. Jeffries, Joshua Kerievsky, Helen Klein, Jim Odell, Jim Rum baugh, and Vivek Salgar. The t hird edit ion also had a fine group of reviewers: Conrad Bock

Craig Larm an

Andy Carm ichael

St eve Mellor

Alist air Cockburn

Jim Odell

St eve Cook

Alan O'Callaghan

Luke Hohm ann

Guus Ram ackers

Pavel Hruby

Jim Rum baugh

Jon Kern

Tim Selt zer

Cris Kobryn All t hese reviewers spent t im e reading t he m anuscript , and every one of t hem found at least one em barrassing howler. My sincere t hanks t o all of t hem . Any howlers t hat rem ain are ent irely m y responsibilit y. I will post an errat a sheet t o t he books sect ion of m a r t in fow le r .com when I find t hem . The core t eam t hat designed and wrot e the UML specificat ion are Don Baisley, Morgan Bj örkander, Conrad Bock, St eve Cook, Philippe Desfray, Nat han Dykm an, Anders Ek, David Frankel, Eran Gery, Øyst ein Haugen, Sridhar I yengar, Cris Kobryn, Birger Møller- Pedersen, Jam es Odell, Gunnar Övergaard, Karin Palm kvist , Guus Ram ackers, Jim Rum baugh, Bran Selic, Thom as Weigert , and Larry William s. Wit hout t hem , I would have not hing t o writ e about . Pavel Hruby developed som e excellent Visio t em plat es t hat I use a lot for UML diagram s; you can get t hem at h t t p:/ / ph r u by.com . Many people have cont act ed m e on t he Net and in person wit h suggest ions and quest ions and t o point out errors. I haven't been able t o keep t rack of you all, but m y t hanks are no less sincere. 8/ 118

The people at m y favorit e t echnical bookst ore, Soft Pro in Burlingt on, Massachuset t s, let m e spend m any hours t here looking at t heir st ock t o find how people use t he UML in pract ice and fed m e good coffee while I was t here. For t he t hird edit ion, t he acquisit ion edit or was Mike Hendrickson. Kim Arney Mulcahy m anaged t he proj ect , as well as did t he layout and clean-up of t he diagram s. John Fuller, at Addison-Wesley, was t he product ion edit or, while Evelyn Pyle and Rebecca Rider helped wit h t he copyedit ing and proofreading of t he book. I t hank t hem all. Cindy has st ayed wit h m e while I persist in writ ing books. She t hen plant s t he proceeds in t he garden. My parent s st art ed m e off wit h a good educat ion, from which all else springs. Mart in Fowler Melrose, Massachuset t s h t t p:/ / m a r t in fow le r .com

9/ 118

Diagrams

10/ 118

11/ 118

12/ 118

13/ 118

Chapter 1. Introduction What I s the UML? Ways of Using t he UML How We Got t o t he UML Not at ions and Met a- Models UML Diagram s What I s Legal UML? The Meaning of UML UML I s Not Enough Where t o St art wit h the UML Where t o Find Out More

What Is the UML? The Unified Modeling Language (UML) is a fam ily of graphical not at ions, backed by single m et am odel, t hat help in describing and designing soft ware syst em s, part icularly soft ware syst em s built using t he obj ect - orient ed (OO) st yle. That 's a som ewhat sim plified definit ion. I n fact , t he UML is a few different t hings t o different people. This com es bot h from it s own hist ory and from t he different views t hat people have about what m akes an effect ive soft ware engineering process. As a result , m y t ask in m uch of t his chapt er is t o set t he scene for t his book by explaining t he different ways in which people see and use t he UML. Graphical m odeling languages have been around in t he soft ware indust ry for a long t im e. The fundam ent al driver behind t hem all is t hat program m ing languages are not at a high enough level of abst raction t o facilit at e discussions about design. Despit e t he fact that graphical m odeling languages have been around for a long t im e, t here is an enorm ous am ount of disput e in the soft ware indust ry about t heir role. These disput es play direct ly int o how people perceive t he role of t he UML it self. The UML is a relat ively open st andard, cont rolled by t he Obj ect Managem ent Group ( OMG) , an open consort ium of com panies. The OMG was form ed t o build st andards that support ed int eroperabilit y, specifically the int eroperabilit y of obj ect - orient ed syst em s. The OMG is perhaps best known for the CORBA ( Com m on Obj ect Request Broker Archit ect ure) st andards. The UML was born out of the unificat ion of the m any obj ect - orient ed graphical m odeling languages t hat t hrived in t he lat e 1980s and early 1990s. Since it s appearance in 1997, it has relegat ed t hat part icular t ower of Babel t o hist ory. That 's a service I , and m any ot her developers, am deeply t hankful for.

Where to Find Out More 14/ 118

This book is not a com plet e and definit ive reference t o t he UML, let alone OO analysis and design. A lot of words are out t here and a lot of wort hwhile t hings t o read. As I discuss t he individual t opics, I also m ent ion ot her books you should go t o for m ore in- dept h inform at ion t here. Here are som e general books on the UML and obj ect - orient ed design. As wit h all book recom m endat ions, you m ay need t o check which version of the UML t hey are writ t en for. As of June 2003, no published book uses UML 2.0, which is hardly surprising, as t he ink is barely dry on t he st andard. The books I suggest are good books, but I can't t ell whet her or when t hey will be updat ed t o t he UML 2 st andard. I f you are new t o obj ect s, I recom m end m y current favorit e int roduct ory book: [ Larm an] . The aut hor's st rong responsibilit y- driven approach t o design is wort h following. For t he conclusive word on t he UML, you should look t o t he official st andards docum ent s; but rem em ber, t hey are writ t en for consent ing m et hodologist s in the privacy of t heir own cubicles. For a m uch m ore digestible version of t he st andard, take a look at [ Rum baugh, UML Reference] . For m ore det ailed advice on obj ect - orient ed design, you'll learn m any good t hings from [ Mart in] . I also suggest t hat you read books on pat t erns for m at erial t hat will t ake you beyond t he basics. Now t hat t he m et hods war is over, pat t erns ( page 27) are where m ost of t he int erest ing m at erial about analysis and design appears.

Ways of Using the UML At the heart of t he role of t he UML in soft ware developm ent are t he different ways in which people want t o use it , differences t hat carry over from ot her graphical m odeling languages. These differences lead t o long and difficult argum ent s about how t he UML should be used. To unt angle t his, St eve Mellor and I independent ly cam e up wit h a charact erizat ion of t he t hree m odes in which people use t he UML: sket ch, blueprint , and program m ing language. By far t he m ost com m on of t he t hree, at least t o m y biased eye, is UML a s sk e tch. I n t his usage, developers use t he UML t o help com m unicat e som e aspect s of a syst em . As wit h blueprint s, you can use sket ches in a forward- engineering or reverse- engineering direct ion. For w ar d e n gin ee r in g draws a UML diagram before you writ e code, while r e ve rse en gin e e r in g builds a UML diagram from exist ing code in order t o help underst and it . The essence of sket ching is select ivit y. Wit h forward sket ching, you rough out som e issues in code you are about t o writ e, usually discussing t hem wit h a group of people on your t eam . Your aim is t o use the sket ches t o help com m unicat e ideas and alt ernat ives about what you're about t o do. You don't t alk about all t he code you are going t o work on, only im port ant issues t hat you want t o run past your colleagues first or sect ions of the design t hat you want t o visualize before you begin program m ing. Sessions like t his can be very short : a 10- m inut e session t o discuss a few hours of program m ing or a day t o discuss a 2- week it erat ion. Wit h reverse engineering, you use sket ches t o explain how som e part of a syst em works. You don't show every class, sim ply t hose t hat are int erest ing and wort h t alking about before you dig int o t he code. Because sket ching is pret t y inform al and dynam ic, you need t o do it quickly and collaborat ively, so a com m on m edium is a whit eboard. Sket ches are also useful in docum ent s, in which case t he focus is com m unicat ion rat her t han com plet eness. The tools used for sket ching are light weight drawing t ools, and oft en people aren't t oo particular about keeping t o every st rict rule of t he UML. Most UML diagram s shown in books, such as m y ot her books, are sket ches. Their em phasis is on select ive com m unicat ion rat her t han com plet e specificat ion.

15/ 118

I n cont rast , UM L a s blu e pr in t is about com plet eness. I n forward engineering, t he idea is t hat blueprint s are developed by a designer whose j ob is t o build a det ailed design for a program m er t o code up. That design should be sufficient ly com plet e in that all design decisions are laid out , and t he program m er should be able t o follow it as a pret t y st raight forward act ivit y t hat requires lit t le t hought . The designer m ay be t he sam e person as t he program m er, but usually t he designer is a m ore senior developer who designs for a t eam of program m ers. The inspirat ion for t his approach is ot her form s of engineering in which professional engineers creat e engineering drawings t hat are handed over t o const ruct ion com panies t o build. Blueprint ing m ay be used for all det ails, or a designer m ay draw blueprint s t o a part icular area. A com m on approach is for a designer t o develop blueprint - level m odels as far as int erfaces of subsyst em s but then let developers work out the det ails of im plem ent ing t hose det ails. I n reverse engineering, blueprint s aim t o convey det ailed inform at ion about the code eit her in paper docum ent s or as an int eract ive graphical browser. The blueprint s can show every det ail about a class in a graphical form that 's easier for developers t o underst and. Blueprint s require m uch m ore sophist icat ed t ools t han sket ches do in order t o handle the det ails required for t he t ask. Specialized CASE ( com put er- aided soft ware engineering) t ools fall int o t his cat egory, alt hough t he t erm CASE has becom e a dirt y word, and vendors t ry t o avoid it now. Forward- engineering t ools support diagram drawing and back it up wit h a reposit ory t o hold t he inform at ion. Reverse- engineering t ools read source code and int erpret from it int o t he reposit ory and generat e diagram s. Tools t hat can do bot h forward and reverse engineering like t his are referred t o as r oun d- t r ip t ools. Som e t ools use t he source code it self as t he reposit ory and use diagram s as a graphic viewport on t he code. These t ools tie m uch m ore closely int o program m ing and oft en int egrat e direct ly wit h program m ing edit ors. I like t o t hink of t hese as t r iple ss t ools. The line bet ween blueprint s and sket ches is som ewhat blurry, but the dist inct ion, I t hink, rest s on t he fact that sket ches are deliberat ely incom plet e, highlight ing im port ant inform at ion, while blueprint s int end t o be com prehensive, oft en wit h t he aim of reducing program m ing t o a sim ple and fairly m echanical act ivit y. I n a sound bit e, I 'd say t hat sket ches are explorat ive, while blueprint s are definit ive. As you do m ore and m ore in t he UML and t he program m ing get s increasingly m echanical, it becom es obvious t hat the program m ing should be aut om at ed. I ndeed, m any CASE t ools do som e form of code generat ion, which aut om at es building a significant part of a syst em . Event ually, however, you reach t he point at which all t he syst em can be specified in t he UML, and you reach UM L a s progr a m m in g la n gu a ge. I n t his environm ent , developers draw UML diagram s t hat are com piled direct ly t o execut able code, and t he UML becom es t he source code. Obviously, this usage of UML dem ands part icularly sophist icat ed t ooling. ( Also, t he not ions of forward and reverse engineering don't m ake any sense for t his m ode, as t he UML and source code are t he sam e t hing.)

Model Driven Arquitecture and Executable UML When people t alk about t he UML, t hey also oft en t alk about M ode l D r ive n Ar ch it ect ur e ( M DA) [ Kleppe et al.] . Essent ially, MDA is a st andard approach t o using t he UML as a program m ing language; the st andard is cont rolled by the OMG, as is t he UML. By producing a m odeling environm ent t hat conform s t o t he MDA, vendors can creat e m odels t hat can also work wit h ot her MDA- com pliant environm ent s. MDA is oft en t alked about in t he sam e breat h as t he UML because MDA uses t he UML as it s basic m odeling language. But , of course, you don't have t o be using MDA t o use t he UML. MDA divides developm ent work int o t wo m ain areas. Modelers represent a part icular applicat ion by creat ing a Pla t for m I n de pen den t M ode l ( PI M ) . The PI M is a UML m odel t hat is independent of any particular t echnology. Tools can t hen t urn a PI M int o a Pla t for m Spe cific M ode l ( PSM ) . The PSM is a m odel of a syst em t arget ed t o a specific 16/ 118

execut ion environm ent . Furt her t ools t hen t ake t he PSM and generat e code for t hat plat form . The PSM could be UML but doesn't have t o be. So if you want t o build a warehousing syst em using MDA, you would st art by creat ing a single PI M of your warehousing syst em . I f you t hen want ed this warehousing syst em t o run on J2EE and .NET, you would use som e vendor t ools t o creat e t wo PSMs: one for each plat form . Then further t ools would generat e code for t he t wo plat form s. I f t he process of going from PI M t o PSM t o final code is com plet ely aut om at ed, we have t he UML as program m ing language. I f any of t he st eps is m anual, we have blueprint s. St eve Mellor has long been act ive in t his kind of work and has recent ly used t he t erm Ex e cu t a ble UML [ Mellor and Balcer] . Execut able UML is sim ilar t o MDA but uses slight ly different t erm s. Sim ilarly, you begin wit h a plat form - independent m odel t hat is equivalent t o MDA's PI M. However, the next st ep is t o use a Model Com piler t o t urn t hat UML m odel int o a deployable syst em in a single st ep; hence, t here's no need for t he PSM. As t he t erm com piler suggest s, t his st ep is com plet ely aut om at ic. The m odel com pilers are based on reusable archet ypes. An a r ch e t ype describes how t o t ake an execut able UML m odel and t urn it int o a part icular program m ing plat form . So for t he warehousing exam ple, you would buy a m odel com piler and t wo archet ypes ( J2EE and .NET) . Run each archet ype on your execut able UML m odel, and you have your t wo versions of t he warehousing syst em . Execut able UML does not use t he full UML st andard; m any const ruct s of UML are considered t o be unnecessary and are t herefore not used. As a result , Execut able UML is sim pler t han full UML. All t his sounds good, but how realist ic is it ? I n m y view, t here are t wo issues here. First is t he quest ion of t he t ools: whet her t hey are m at ure enough t o do t he j ob. This is som et hing that changes over t im e; cert ainly, as I writ e t his, t hey aren't widely used, and I haven't seen m uch of t hem in act ion. A m ore fundam ent al issue is t he whole not ion of t he UML as a program m ing language. I n m y view, it 's wort h using t he UML as a program m ing language only if it result s in som et hing that 's significant ly m ore productive than using anot her program m ing language. I 'm not convinced that it is, based on various graphical developm ent environm ent s I 've worked wit h in the past . Even if it is m ore product ive, it st ill needs t o get a cri t ical m ass of users for it t o m ake t he m ainst ream . That 's a big hurdle in it self. Like m any old Sm allt alkers, I consider Sm allt alk t o be m uch m ore productive than current m ainst ream languages. But as Sm allt alk is now only a niche language, I don't see m any proj ect s using it . To avoid Sm allt alk's fat e, t he UML has t o be luckier, even if it is superior.

One of t he int erest ing quest ions around the UML as program m ing language is how t o m odel behavioral logic. UML 2 offers t hree ways of behavioral m odeling: int eract ion diagram s, st at e diagram s, and act ivit y diagram s. All have t heir proponent s for program m ing in. I f the UML does gain popularit y as a program m ing language, it will be int erest ing t o see which of t hese t echniques becom e successful. Anot her way in which people look at t he UML is t he range bet ween using it for concept ual and for soft ware m odeling. Most people are fam iliar wit h t he UML used for soft ware m odeling. I n t his soft w ar e pe rspe ct ive, t he elem ent s of t he UML m ap pret t y direct ly t o elem ent s in a soft ware syst em . As we shall see, t he m apping is by no m eans prescript ive, but when we use t he UML, we are t alking about soft ware elem ent s. Wit h t he con ce pt u a l pe r spe ct ive, the UML represent s a descript ion of t he concept s of a dom ain of st udy. Here, we aren't t alking about soft ware elem ent s so m uch as we are building a vocabulary t o t alk about a part icular dom ain. 17/ 118

There are no hard- and- fast rules about perspective; as it t urns out , t here's really quit e a large range of usage. Som e t ools aut om at ically t urn source code int o t he UML diagram s, t reat ing t he UML as an alt ernat ive view of t he source. That 's very m uch a soft ware perspect ive. I f you use UML diagram s t o t ry and underst and t he various m eanings of t he t erm s asset pool wit h a bunch of account ant s, you are in a m uch m ore concept ual fram e of m ind. I n previous edit ions of t his book, I split t he soft ware perspect ive int o specificat ion (int erface) and im plem ent at ion. I n practice, I found t hat it was t oo hard t o draw a precise line bet ween t he t wo, so I feel that t he dist inct ion is no longer wort h m aking a fuss about . However, I 'm always inclined t o em phasize int erface rat her than im plem ent at ion in m y diagram s. These different ways of using the UML lead t o a host of argum ent s about what UML diagram s m ean and what their relat ionship is t o t he rest of t he world. I n particular, it affect s the relat ionship bet ween t he UML and source code. Som e people hold t he view t hat t he UML should be used t o creat e a design t hat is independent of t he program m ing language t hat 's used for im plem ent at ion. Ot hers believe t hat language-independent design is an oxym oron, wit h a st rong em phasis on the m oron. Anot her difference in viewpoint s is what t he essence of t he UML is. I n m y view, m ost users of t he UML, part icularly sket chers, see t he essence of t he UML t o be t he diagram s. However, t he creat ors of t he UML see t he diagram s as secondary; t he essence of t he UML is the m et a-m odel. Diagram s are sim ply a present at ion of the m et a-m odel. This view also m akes sense t o blueprint ers and UML program m ing language users. So whenever you read anyt hing involving t he UML, it 's im port ant t o underst and t he point of view of t he aut hor. Only t hen can you m ake sense of t he oft en fierce argum ent s t hat t he UML encourages. Having said all that , I need t o m ake m y biases clear. Alm ost all t he t im e, m y use of t he UML is as sket ches. I find t he UML sket ches useful wit h forward and reverse engineering and in bot h concept ual and soft ware perspect ives. I 'm not a fan of det ailed forward- engineered blueprint s; I believe t hat it 's t oo difficult t o do well and slows down a developm ent effort . Blueprint ing t o a level of subsyst em int erfaces is reasonable, but even t hen you should expect t o change t hose int erfaces as developers im plem ent the int eract ions across t he int erface. The value of reverse- engineered blueprint s is dependent on how t he t ool works. I f it 's used as a dynam ic browser, it can be very helpful; if it generat es a large docum ent , all it does is kill t rees. I see t he UML as program m ing language as a nice idea but doubt t hat it will ever see significant usage. I 'm not convinced t hat graphical form s are m ore product ive t han t ext ual form s for m ost program m ing t asks and t hat even if t hey are, it 's very difficult for a language t o be widely accept ed. As a result of m y biases, t his book focuses m uch m ore on using t he UML for sket ching. Fort unat ely, t his m akes sense for a brief guide. I can't do j ust ice t o t he UML in it s ot her m odes in a book t his size, but a book this size m akes a good int roduct ion t o ot her books t hat can. So if you're int erest ed in t he UML in it s ot her m odes, I 'd suggest t hat you t reat t his book as an int roduct ion and m ove on t o ot her books as you need t hem . I f you're int erest ed only in sket ches, t his book m ay well be all you need.

How We Got to the UML I 'll adm it , I 'm a hist ory buff. My favorit e idea of light reading is a good hist ory book. But I also know t hat it 's not everybody's idea of fun. I t alk about hist ory here because I think t hat in m any ways, it 's hard t o underst and where t he UML is wit hout underst anding t he hist ory of how it got here.

18/ 118

I n the 1980s, obj ect s began t o m ove away from t he research labs and t ook their first st eps t oward t he " real" world. Sm allt alk st abilized int o a plat form t hat people could use, and C+ + was born. At t hat t im e, various people st art ed t hinking about obj ect - orient ed graphical design languages. The key books about obj ect - orient ed graphical m odeling languages appeared bet ween 1988 and 1992. Leading figures included Grady Booch [ Booch, OOAD] ; Pet er Coad [ Coad, OOA] , [ Coad, OOD] ; I var Jacobson (Obj ect ory) [ Jacobson, OOSE] ; Jim Odell [ Odell] ; Jim Rum baugh ( OMT) [ Rum baugh, insight s] , [ Rum baugh, OMT] ; Sally Shlaer and St eve Mellor [ Shlaer and Mellor, dat a] , [ Shlaer and Mellor, st at es] ; and Rebecca Wirfs-Brock ( Responsibilit y Driven Design) [ Wirfs- Brock] . Each of those aut hors was now inform ally leading a group of pract it ioners who liked t hose ideas. All t hese m et hods were very sim ilar, yet t hey cont ained a num ber of oft en annoying m inor differences am ong t hem . The sam e basic concept s would appear in very different not at ions, which caused confusion t o m y client s. During that heady t im e, st andardizat ion was as t alked about as it was ignored. A t eam from t he OMG t ried t o look at st andardizat ion but got only an open let t er of prot est from all t he key m et hodologist s. ( This rem inds m e of an old j oke. Quest ion: What is t he difference bet ween a m et hodologist and a t errorist ? Answer: You can negot iat e wit h a t errorist .) The cat aclysm ic event t hat first init iat ed the UML was when Jim Rum baugh left GE t o j oin Grady Booch at Rat ional ( now a part of I BM) . The Booch/ Rum baugh alliance was seen from t he beginning as one t hat could get a crit ical m ass of m arket share. Grady and Jim proclaim ed t hat " t he m et hods war is over we won," basically declaring t hat they were going t o achieve st andardizat ion "t he Microsoft way." A num ber of ot her m et hodologist s suggest ed form ing an Ant i- Booch Coalit ion. By OOPSLA '95, Grady and Jim had prepared t heir first public descript ion of t heir m erged m et hod: version 0.8 of t he Unified Met hod docum ent at ion. Even m ore significant , t hey announced t hat Rat ional Soft ware had bought Obj ect ory and t hat t herefore, I var Jacobson would be j oining t he Unified t eam . Rat ional held a well- at t ended party t o celebrat e t he release of t he 0.8 draft . ( The highlight of t he part y was t he first public display of Jim Rum baugh's singing; we all hope it 's also t he last .) The next year saw a m ore open process em erge. The OMG, which had m ost ly st ood on t he sidelines, now t ook an act ive role. Rat ional had t o incorporat e I var's ideas and also spent t im e wit h ot her part ners. More im port ant , t he OMG decided t o t ake a m aj or role. At this point , it 's im port ant t o realize why the OMG got involved. Met hodologist s, like book aut hors, like t o t hink t hat t hey are im port ant . But I don't t hink that t he scream s of book aut hors would even be heard by t he OMG. What got t he OMG involved were the scream s of t ools vendors, all of which were fright ened t hat a st andard cont rolled by Rat ional would give Rat ional t ools an unfair com pet it ive advant age. As a result , t he vendors energized t he OMG t o do som et hing about it , under t he banner of CASE t ool int eroperabilit y. This banner was im port ant , as t he OMG was all about int eroperabilit y. The idea was t o creat e a UML t hat would allow CASE t ools t o freely exchange m odels. Mary Loom is and Jim Odell chaired the init ial t ask force. Odell m ade it clear t hat he was prepared t o give up his m et hod t o a st andard, but he did not want a Rat ional-im posed st andard. I n January 1997, various organizat ions subm it t ed proposals for a m et hods st andard t o facilit at e the int erchange of m odels. Rat ional collaborat ed wit h a num ber of ot her organizat ions and released version 1.0 of t he UML docum ent at ion as their proposal, t he first anim al t o answer t o t he nam e Unified Modeling Language. Then followed a short period of arm t wist ing while t he various proposals were m erged. The OMG adopt ed t he result ing 1.1 as an official OMG st andard. Som e revisions were m ade lat er on. Revision 1.2 was ent irely cosm et ic. Revision 1.3 was m ore significant . Revision 1.4 added a num ber of det ailed concept s around com ponent s and profiles. Revision 1.5 added act ion sem ant ics. When people t alk about t he UML, t hey credit m ainly Grady Booch, I var Jacobson, and Jim Rum baugh as it s creat ors. They are generally referred t o as t he Three Am igos, alt hough wags like t o 19/ 118

drop t he first syllable of t he second word. Alt hough t hey are m ost credit ed wit h the UML, I think it som ewhat unfair t o give t hem t he dom inant credit . The UML not at ion was first form ed in t he Booch/ Rum baugh Unified Met hod. Since t hen, m uch of the work has been led by OMG com m it t ees. During these lat er st ages, Jim Rum baugh is t he only one of t he t hree t o have m ade a heavy com m it m ent . My view is that it 's t hese m em bers of t he UML com m it t ee process t hat deserve t he principal credit for t he UML.

Notations and Meta-Models The UML, in it s current st at e, defines a not at ion and a m et a- m odel. The n ot a t ion is the graphical st uff you see in m odels; it is t he graphical synt ax of t he m odeling language. For inst ance, class diagram not at ion defines how it em s and concept s, such as class, associat ion, and m ult iplicit y, are represent ed. Of course, this leads t o t he quest ion of what exact ly is m eant by an associat ion or m ult iplicit y or even a class. Com m on usage suggest s som e inform al definit ions, but m any people want m ore rigor t han t hat . The idea of rigorous specificat ion and design languages is m ost prevalent in t he field of form al m et hods. I n such t echniques, designs and specificat ions are represent ed using som e derivat ive of predicat e calculus. Such definit ions are m at hem at ically rigorous and allow no am biguit y. However, t he value of t hese definit ions is by no m eans universal. Even if you can prove that a program sat isfies a m at hem at ical specificat ion, t here is no way t o prove t hat the m at hem at ical specificat ion m eet s t he real requirem ent s of t he syst em . Most graphical m odeling languages have very lit t le rigor; t heir not at ion appeals t o int uit ion rat her t han t o form al definit ion. On t he whole, t his does not seem t o have done m uch harm . These m et hods m ay be inform al, but m any people st ill find t hem useful—and it is usefulness that count s. However, m et hodologist s are looking for ways to im prove t he rigor of m et hods wit hout sacrificing t heir usefulness. One way t o do t his is t o define a m e t a - m ode l: a diagram , usually a class diagram , t hat defines t he concept s of the language. Figure 1.1, a sm all piece of t he UML m et a-m odel, shows t he relat ionship am ong feat ures. ( The ext ract is t here t o give you a flavor of what m et a- m odels are like. I 'm not even going t o t ry t o explain it .)

Figu r e 1 .1 . A sm a ll pie ce of t h e UM L m e t a - m ode l

20/ 118

How m uch does t he m et a- m odel affect a user of t he m odeling not at ion? The answer depends m ost ly on t he m ode of usage. A sket cher usually doesn't care t oo m uch; a blueprint er should care rat her m ore. I t 's vit ally im port ant t o t hose who use the UML as a program m ing language, as it defines t he abst ract synt ax of that language. Many of t he people who are involved in t he ongoing developm ent of t he UML are int erest ed prim arily in t he m et a- m odel, part icularly as t his is im port ant t o t he usage of t he UML and a program m ing language. Not at ional issues oft en run second place, which is im port ant t o bear in m ind if you ever t ry t o get fam iliar wit h the st andards docum ent s t hem selves. As you get deeper int o t he m ore det ailed usage of t he UML, you realize t hat you need m uch m ore t han t he graphical not at ion. This is why UML t ools are so com plex. I am not rigorous in t his book. I prefer t he t radit ional m et hods pat h and appeal m ainly t o your int uit ion. That 's nat ural for a sm all book like t his writ t en by an aut hor who's inclined m ost ly t o a sket ch usage. I f you want m ore rigor, you should t urn t o m ore det ailed t om es.

UML Diagrams UML 2 describes 13 official diagram t ypes list ed in Table 1.1 and classified as indicat ed on Figure 1.2. Alt hough t hese diagram t ypes are t he way m any people approach t he UML and how I 've organized t his book, the UML's aut hors do not see diagram s as the cent ral part of the UML. As a result , t he diagram t ypes are not part icularly rigid. Oft en, you can legally use elem ent s from one diagram t ype on anot her diagram . The UML st andard indicat es t hat cert ain elem ent s are t ypically drawn on cert ain diagram t ypes, but t his is not a prescript ion.

Figu r e 1 .2 . Cla ssifica t ion of UM L dia gr a m t y pe s

21/ 118

Ta ble 1 .1 . Officia l D ia gr a m Ty pe s of t h e UM L Book Ch a pt e r s

D ia gr a m

Pu r pose

Lin e a ge

Act ivit y

11

Procedural and parallel behavior

I n UML 1

Class

3, 5

Class, feat ures, and relat ionships

I n UML 1

Com m unicat ion

12

I nt eraction bet ween obj ect s; em phasis on links

UML 1 collaborat ion diagram

Com ponent

14

St ruct ure and connect ions of com ponent s

I n UML 1

Com posit e st ruct ure

13

Runt im e decom posit ion of a class

New t o UML 2

Deploym ent

8

Deploym ent of art ifact s t o nodes

I n UML 1

22/ 118

Ta ble 1 .1 . Officia l D ia gr a m Ty pe s of t h e UM L Book Ch a pt e r s

D ia gr a m

Pu r pose

Lin e a ge

I nt eraction overview

16

Mix of sequence and act ivit y diagram

New t o UML 2

Obj ect

6

Exam ple configurat ions of inst ances

Unofficially in UML 1

Package

7

Com pile- t im e hierarchic st ruct ure

Unofficially in UML 1

Sequence

4

I nt eraction bet ween obj ect s; em phasis on sequence

I n UML 1

St at e m achine

10

How event s change an obj ect over it s life

I n UML 1

Tim ing

17

I nt eraction bet ween obj ect s; em phasis on t im ing

New t o UML 2

Use case

9

How users int eract wit h a syst em

I n UML 1

What Is Legal UML? At first blush, t his should be a sim ple question to answer: Legal UML is what is defined as well form ed in t he specificat ion. I n pract ice, however, t he answer is a bit m ore com plicat ed. An im port ant part of this quest ion is whet her t he UML has descript ive or prescript ive rules. A language wit h pr e scr ipt ive r u le s is cont rolled by an official body t hat st at es what is or isn't legal in t he language and what m eaning you give t o ut t erances in t hat language. A language wit h de scr ipt ive r u les is one in which you underst and it s rules by looking at how people use t he language in pract ice. Program m ing languages t end t o have prescript ive rules set by a st andards com m it t ee or dom inant vendor, while nat ural languages, such as English, t end t o have descript ive rules whose m eaning is set by convent ion. UML is quit e a precise language, so you m ight expect it t o have prescript ive rules. But UML is oft en considered t o be t he soft ware equivalent of t he blueprint s in ot her engineering disciplines, and these blueprint s are not prescript ive not at ions. No com m it t ee says what t he legal sym bols are on a st ruct ural engineering drawing; the not at ion has been accept ed by convent ion, sim ilarly t o a nat ural language. Sim ply having a st andards body doesn't do t he t rick eit her, because people in t he field m ay not follow everyt hing t he st andards body says; j ust ask t he French about t he Académ ie Française. I n addit ion, t he UML is so com plex t hat t he st andard is oft en open t o m ult iple int erpret at ions. Even the UML leaders who reviewed t his book would disagree on int erpret at ion of t he UML st andard. This issue is im port ant bot h for m e writ ing t his book and for you using the UML. I f you want t o underst and a UML diagram , it 's im port ant t o realize t hat underst anding t he UML st andard is not t he whole pict ure. People do adopt convent ions, bot h in t he indust ry widely and wit hin a part icular proj ect . As a result , alt hough t he UML st andard can be t he prim ary source of inform at ion on the UML, it can't be t he only one. My at t it ude is that , for m ost people, the UML has descript ive rules. The UML st andard is t he biggest single influence on what UML m eans, but it isn't t he only one. I t hink t hat t his will becom e part icularly t rue wit h UML 2, which int roduces som e not at ional convent ions t hat conflict wit h eit her UML 1's definit ion or t he convent ional usage of UML, as well as adds yet m ore com plexit y t o t he UML. I n t his book, therefore, I 'm t rying t o sum m arize t he UML as I find it : bot h t he st andards and t he convent ional usage. When I have t o m ake a dist inct ion in this book, I 'll use t he t erm con ven t ion a l use t o indicat e som et hing t hat isn't in t he st andard but that I think is widely used. For som et hing t hat conform s t o t he st andard, I 'll use the t erm s st a n da r d or nor m a t ive. ( Norm at ive is t he t erm st andards people use t o m ean a st at em ent t hat you m ust conform t o be

23/ 118

valid in the st andard. So non- norm at ive UML is a fancy way of saying t hat som et hing is st rict ly illegal according t o t he UML st andard.) When you are looking at a UML diagram , you should bear in m ind t hat a general principle in the UML is t hat any inform at ion m ay be su ppr e sse d for a part icular diagram . This suppression can occur eit her generally—hide all at t ribut es—or specifically—don't show t hese t hree classes. I n a diagram , t herefore, you can never infer anyt hing by it s absence. I f a m ult iplicit y is m issing, you cannot infer what value it m ight be. Even if t he UML m et a-m odel has a default , such as [ 1] for at t ribut es, if you don't see t he inform at ion on the diagram , it m ay be because it 's t he default or because it 's suppressed. Having said t hat , t here are som e general convent ions, such as m ult ivalued propert ies being set s. I n t he t ext , I 'll point out t hese default convent ions. I t 's im port ant t o not put t oo m uch em phasis on having legal UML if you're a sket cher or blueprint er. I t 's m ore im port ant t o have a good design for your syst em , and I would rat her have a good design in illegal UML t han a legal but poor design. Obviously, good and legal is best , but you're bet t er off put t ing your energy int o having a good design than worrying about t he arcana of UML. ( Of course, you have t o be legal in UML as program m ing language, or your program won't run properly! )

The Meaning of UML One of t he awkward issues about t he UML is t hat , alt hough t he specificat ion describes in great det ail what well- form ed UML is, it doesn't have m uch t o say about what t he UML m eans out side of t he rarefied world of the UML m et a- m odel. No form al definit ion exist s of how t he UML m aps t o any part icular program m ing language. You cannot look at a UML diagram and say exact ly what t he equivalent code would look like. However, you can get a rough idea of what t he code would look like. I n pract ice, t hat 's enough t o be useful. Developm ent t eam s oft en form t heir local convent ions for t hese, and you'll need t o be fam iliar wit h the ones in use.

UML Is Not Enough Alt hough t he UML provides quit e a considerable body of various diagram s t hat help t o define an applicat ion, it 's by no m eans a com plet e list of all the useful diagram s t hat you m ight want t o use. I n m any places, different diagram s can be useful, and you shouldn't hesit at e t o use a non-UML diagram if no UML diagram suit s your purpose. Figure 1.3, a screen flow diagram , shows t he various screens on a user int erface and how you m ove bet ween t hem . I 've seen and used these screen flow diagram s for m any years. I 've never seen m ore t han a very rough definit ion of what t hey m ean; t here isn't anyt hing like it in t he UML, yet I 've found it a very useful diagram .

Figu r e 1 .3 . An in for m a l scr e e n flow dia gr a m for pa r t of t h e w ik i ( h t t p:/ / c2 .com / cgi/ w ik i)

24/ 118

Table 1.2 shows anot her favorit e: t he decision table. Decision t ables are a good way t o show com plicat ed logical condit ions. You can do t his wit h an act ivit y diagram , but once you get beyond sim ple cases, t he t able is bot h m ore com pact and m ore clear. Again, m any form s of decision t ables are out t here. Table 1.2 divides t he t able int o t wo sect ions: condit ions above t he double line and consequences below it . Each colum n shows how a part icular com binat ion of condit ions leads t o a part icular set of consequences.

Ta ble 1 .2 . A D e cision Ta ble Prem ium cust om er

X

X

Y

Y

N

N

Priorit y order

Y

N

Y

N

Y

N

I nt ernat ional order

Y

Y

N

N

N

N

Fee

$150

$100

$70

$50

$80

$60

Alert rep

•

•

•

You'll run int o various kinds of t hese t hings in various books. Don't hesit at e t o t ry out t echniques t hat seem appropriat e for your proj ect . I f t hey work well, use them . I f not , discard t hem . ( This is, of course, t he sam e advice as for UML diagram s.)

Where to Start with the UML Nobody, not even t he creat ors of t he UML, underst and or use all of it . Most people use a sm all subset of t he UML and work wit h t hat . You have t o find t he subset of t he UML t hat works for you and your colleagues. I f you are st art ing out , I suggest t hat you concent rat e first on t he basic form s of class diagram s and sequence diagram s. These are the m ost com m on and, in m y view, t he m ost useful diagram t ypes.

25/ 118

Once you've got t he hang of t hose, you can st art using som e of t he m ore advanced class diagram not at ion and t ake a look at t he ot her diagram s t ypes. Experim ent wit h the diagram s and see how helpful they are t o you. Don't be afraid t o drop any that don't seem be useful t o your work.

Chapter 2. Development Process As I 've already m ent ioned, t he UML grew out of a bunch of OO analysis and design m et hods. To som e ext ent , all of t hem m ixed a graphical m odeling language wit h a process t hat described how t o go about developing soft ware. I nt erest ingly, as t he UML was form ed, t he various players discovered t hat alt hough t hey could agree on a m odeling language, t hey m ost cert ainly could not agree on a process. As a result , they agreed t o leave any agreem ent on process unt il lat er and t o confine t he UML t o being a m odeling language. The t it le of t his book is UML Dist illed, so I could have safely ignored process. However, I don't believe that m odeling t echniques m ake any sense wit hout knowing how they fit int o a process. The way you use t he UML depends a lot on the st yle of process you use. As a result , I t hink t hat it 's im port ant t o t alk about process first so t hat you can see t he cont ext for using t he UML. I 'm not going t o go int o great det ail on any part icular process; I sim ply want t o give you enough inform at ion t o see t his cont ext and point ers t o where you can find out m ore. When you hear people discuss t he UML, you oft en hear t hem t alk about t he Rat ional Unified Process ( RUP) . RUP is one process—or, m ore st rict ly, a process fram ework—t hat you can use wit h t he UML. But ot her t han t he com m on involvem ent of various people from Rat ional and t he nam e "unified," it doesn't have any special relat ionship t o t he UML. The UML can be used wit h any process. RUP is a popular approach and is discussed on page 25.

Iterative and Waterfall Processes One of t he biggest debat es about process is t hat bet ween wat erfall and it erat ive st yles. The t erm s oft en get m isused, part icularly as it erat ive is seen as fashionable, while t he wat erfall process seem s t o wear plaid t rousers. As a result , m any proj ects claim t o do it erat ive developm ent but are really doing wat erfall. The essent ial difference bet ween t he t wo is how you break up a proj ect int o sm aller chunks. I f you have a proj ect t hat you t hink will t ake a year, few people are com fort able t elling t he t eam t o go away for a year and t o com e back when done. Som e breakdown is needed so t hat people can approach t he problem and t rack progress. The w a t er fa ll st yle breaks down a proj ect based on activit y. To build soft ware, you have t o do cert ain act ivit ies: requirem ent s analysis, design, coding, and t est ing. Our 1- year proj ect m ight t hus have a 2-m ont h analysis phase, followed by a 4- m ont h design phase, followed by a 3-m ont h coding phase, followed by a 3-m ont h t est ing phase. The it e r a t ive st yle breaks down a proj ect by subset s of funct ionalit y. You m ight t ake a year and break it int o 3-m ont h it erat ions. I n the first it erat ion, you'd t ake a quart er of t he requirem ent s and do t he com plet e soft ware life cycle for t hat quart er: analysis, design, code, and t est . At t he end of t he first it erat ion, you'd have a syst em t hat does a quart er of t he needed funct ionalit y. Then you'd do a second it erat ion so t hat at t he end of 6 m ont hs, you'd have a syst em t hat does half t he funct ionalit y.

26/ 118

Of course, the above is a sim plified descript ion, but it is the essence of t he difference. I n pract ice, of course, som e im purit ies leak int o t he process. Wit h wat erfall developm ent , t here is usually som e form of form al handoff bet ween each phase, but t here are oft en backflows. During coding, som et hing m ay com e up that causes you t o revisit the analysis and design. You cert ainly should not assum e t hat all design is finished when coding begins. I t 's inevit able t hat analysis and design decisions will have t o be revisit ed in lat er phases. However, t hese backflows are except ions and should be m inim ized as m uch as possible. Wit h it erat ion, you usually see som e form of explorat ion act ivit y before t he t rue it erat ions begin. At t he very least , t his will get a high- level view of t he requirem ent s: at least enough t o break t he requirem ent s down int o t he it erat ions t hat will follow. Som e high- level design decisions m ay occur during explorat ion t oo. At t he ot her end, alt hough each it erat ion should produce product ion- ready int egrat ed soft ware, it oft en doesn't quit e get t o t hat point and needs a st abilizat ion period t o iron out the last bugs. Also, som e act ivit ies, such as user t raining, are left t o t he end. You m ay well not put t he syst em int o product ion at t he end of each it erat ion, but be of product ion qualit y. Oft en, however, you can put t he syst em int o product ion int ervals; t his is good because you get value from t he syst em earlier and you get feedback. I n t his sit uat ion, you oft en hear of a proj ect having m ult iple r e le ase s, broken down int o several it er a t ions.

t he syst em should at regular bet t er- qualit y each of which is

I t erat ive developm ent has com e under m any nam es: increm ent al, spiral, evolut ionary, and j acuzzi spring t o m ind. Various people m ake distinctions am ong t hem , but t he dist inct ions are neit her widely agreed on nor t hat im port ant com pared to t he it erat ive/ wat erfall dichot om y. You can have hybrid approaches. [ McConnell] describes the st a ge d de live r y life cycle whereby analysis and high-level design are done first , in a wat erfall st yle, and t hen t he coding and t est ing are divided up int o it erat ions. Such a proj ect m ight have 4 m ont hs of analysis and design followed by four 2- m ont h it erat ive builds of t he syst em . Most writ ers on soft ware process in the past few years, especially in t he obj ect - orient ed com m unit y, dislike t he wat erfall approach. Of the m any reasons for t his, t he m ost fundam ent al is t hat it 's very difficult t o t ell whet her t he proj ect is t ruly on t rack wit h a wat erfall process. I t 's t oo easy t o declare vict ory wit h early phases and hide a schedule slip. Usually, the only way you can really t ell whet her you are on t rack is t o produce t est ed, int egrat ed soft ware. By doing this repeat edly, an it erat ive st yle gives you bet t er warning if som et hing is going awry. For t hat reason alone, I st rongly recom m end that proj ect s do not use a pure wat erfall approach. You should at least use st aged delivery, if not a m ore pure it erat ive t echnique. The OO com m unit y has long been in favor of it erat ive developm ent , and it 's safe t o say t hat pret t y m uch everyone involved in building the UML is in favor of at least som e form of it erat ive developm ent . My sense of indust rial pract ice is that wat erfall developm ent is st ill t he m ore com m on approach, however. One reason for t his is what I refer t o as pseudoit erat ive developm ent : People claim t o be doing it erat ive developm ent but are in fact doing wat erfall. Com m on sym pt om s of this are: • •

" We are doing one analysis it erat ion followed by t wo design it erat ions. . . ." " This it erat ion's code is very buggy, but we'll clean it up at the end."

I t is part icularly im port ant t hat each it erat ion produces t est ed, int egrat ed code t hat is as close to product ion qualit y as possible. Test ing and int egrat ion are t he hardest act ivit ies t o est im at e, so it 's im port ant not t o have an open- ended act ivit y like t hat at t he end of t he proj ect . The t est should be t hat any it erat ion t hat 's not scheduled t o be released could be released wit hout subst ant ial ext ra developm ent work. A com m on t echnique wit h it erat ions is t o use t im e box in g. This forces an it erat ion t o be a fixed lengt h of tim e. I f it appears t hat you can't build all you int ended t o build during an it erat ion, you m ust decide t o slip som e functionalit y from the it erat ion; you m ust not slip the dat e of t he it erat ion. 27/ 118

Most proj ect s t hat use it erat ive developm ent use t he sam e it erat ion lengt h t hroughout t he proj ect ; t hat way, you get a regular rhyt hm of builds. I like t im e boxing because people usually have difficult y slipping funct ionalit y. By pract icing slipping funct ion regularly, t hey are in a bet t er posit ion to m ake an int elligent choice at a big release bet ween slipping a dat e and slipping funct ion. Slipping funct ion during it erat ions is also effect ive at helping people learn what t he real requirem ent s priorit ies are. One of t he m ost com m on concerns about it erat ive developm ent is the issue of rework. I t erat ive developm ent explicit ly assum es t hat you will be reworking and delet ing exist ing code during t he lat er it erat ions of a proj ect . I n m any dom ains, such as m anufact uring, rework is seen as a wast e. But soft ware isn't like m anufact uring; as a result , it oft en is m ore efficient t o rework existing code t han t o pat ch around code t hat was poorly designed. A num ber of t echnical pract ices can great ly help m ake rework be m ore efficient . •

•

•

Au t om at e d r e gre ssion t e st s help by allowing you t o quickly det ect any defect s t hat m ay have been int roduced when you are changing t hings. The xUnit fam ily of t esting fram eworks is a part icularly valuable t ool for building aut om at ed unit t est s. St arting wit h t he original JUnit h t t p:/ / j un it .or g, t here are now port s t o alm ost every language im aginable ( see h t t p:/ / w w w .x pr ogra m m in g.com / soft w a re .h t m ) . A good rule of t hum b is t hat t he size of your unit t est code should be about t he sam e size as your product ion code. Re fact or in g is a disciplined t echnique for changing exist ing soft ware [ Fowler, refact oring] . Refact oring works by using a series of sm all behavior- preserving t ransform at ions t o t he code base. Many of these t ransform at ions can be aut om at ed (see h t t p:/ / w w w .r efa ctor in g.com ) . Con t in u ou s in t e gra t ion keeps a t eam in sync t o avoid painful int egrat ion cycles [ Fowler and Foem m el] . At the heart of t his lies a fully aut om at ed build process t hat can be kicked off aut om at ically whenever any m em ber of t he t eam checks code int o t he code base. Developers are expect ed t o check in daily, so aut om at ed builds are done m any t im es a day. The build process includes running a large block of aut om at ed regression t est s so t hat any inconsist encies are caught quickly so t hey can be fixed easily.

All t hese t echnical pract ices have been popularized recent ly by Ext rem e Program m ing [ Beck] , alt hough t hey were used before and can, and should, be used whet her or not you use XP or any ot her agile process.

Predictive and Adaptive Planning One reason t hat t he wat erfall endures is t he desire for predict abilit y in soft ware developm ent . Not hing is m ore frust rat ing t han not having a clear idea how m uch it will cost t o build som e soft ware and how long it will t ake t o build it . A predict ive approach looks t o do work early in the proj ect in order t o yield a great er underst anding of what has t o be done lat er. This way, you can reach a point where the lat t er part of t he proj ect can be est im at ed wit h a reasonable degree of accuracy. Wit h pr e dict ive pla n n in g, a proj ect has t wo st ages. The first st age com es up wit h plans and is difficult t o predict , but t he second st age is m uch m ore predict able because the plans are in place. This isn't necessarily a black- and- whit e affair. As t he proj ect goes on, you gradually get m ore predict abilit y. And even once you have a predictive plan, t hings will go wrong. You sim ply expect t hat t he deviat ions becom e less significant once a solid plan is in place. However, there is a considerable debat e about whet her m any soft ware proj ect s can ever be predict able. At the heart of t his quest ion is requirem ent s analysis. One of t he unique sources of com plexit y in soft ware proj ect s is t he difficult y in underst anding t he requirem ent s for a soft ware syst em . The m aj orit y of soft ware proj ect s experience significant r e qu ire m e n ts chu r n : changes in requirem ent s in t he lat er st ages of t he proj ect . These changes shat t er t he foundat ions of a 28/ 118

predictive plan. You can com bat t hese changes by freezing the requirem ent s early on and not perm it t ing changes, but t his runs t he risk of delivering a syst em t hat no longer m eet s t he needs of it s users. This problem leads t o t wo very different react ions. One rout e is t o put m ore effort int o t he requirem ent s process it self. This way, you m ay get a m ore accurat e set of requirem ent s, which will reduce t he churn. Anot her school cont ends t hat requirem ent s churn is unavoidable, t hat it 's t oo difficult for m any proj ect s t o st abilize requirem ent s sufficient ly t o use a predict ive plan. This m ay be eit her owing t o t he sheer difficult y of envisioning what soft ware can do or because m arket condit ions force unpredict able changes. This school of t hought advocat es a da pt ive pla n n in g, whereby predict ivit y is seen as an illusion. I nst ead of fooling ourselves wit h illusory predict abilit y, we should face t he realit y of const ant change and use a planning approach t hat t reat s change as a const ant in a soft ware proj ect . This change is cont rolled so t hat t he proj ect delivers the best soft ware it can; but alt hough t he proj ect is cont rollable, it is not predict able. The difference bet ween a predict ive proj ect and an adapt ive proj ect surfaces in m any ways t hat people t alk about how t he proj ect goes. When people t alk about a proj ect t hat 's doing well because it 's going according t o plan, t hat 's a predict ive form of t hinking. You can't say " according t o plan" in an adapt ive environm ent , because the plan is always changing. This doesn't m ean that adapt ive proj ect s don't plan; t hey usually plan a lot , but the plan is t reat ed as a baseline t o assess t he consequences of change rat her than as a prediction of t he fut ure. Wit h a predict ive plan, you can develop a fixed-price/ fixed- scope cont ract . Such a cont ract says exact ly what should be built , how m uch it will cost , and when it will be delivered. Such fixing isn't possible wit h an adapt ive plan. You can fix a budget and a t im e for delivery, but you can't fix what funct ionalit y will be delivered. An adapt ive cont ract assum es t hat t he users will collaborat e wit h t he developm ent t eam t o regularly reassess what funct ionalit y needs t o be built and will cancel t he proj ect if progress ends up being t oo slow. As such, an adapt ive planning process can be fixed price/ variable scope. Nat urally, t he adapt ive approach is less desirable, as anyone would prefer great er predict abilit y in a soft ware proj ect . However, predict abilit y depends on a precise, accurat e, and st able set of requirem ent s. I f you cannot st abilize your requirem ent s, t he predict ive plan is based on sand and t he chances are high that t he proj ect goes off course. This leads t o t wo im port ant pieces of advice. 1. Don't m ake a predict ive plan unt il you have precise and accurat e requirem ent s and are confident that t hey won't significant ly change. 2. I f you can't get precise, accurat e, and st able requirem ent s, use an adapt ive planning st yle. Predict ivit y and adapt ivit y feed int o t he choice of life cycle. An adapt ive plan absolut ely requires an it erat ive process. Predict ive planning can be done eit her way, alt hough it 's easier t o see how it works wit h wat erfall or a st aged delivery approach.

Agile Processes I n the past few years, there's been a lot of int erest in agile soft ware processes. Agile is an um brella t erm t hat covers m any processes t hat share a com m on set of values and principles as defined by t he Manifest o of Agile Soft ware Developm ent ( ht t p:/ / a gile M an ife sto.or g) . Exam ples of t hese processes are Ext rem e Program m ing (XP) , Scrum , Feat ure Driven Developm ent ( FDD) , Cryst al, and DSDM ( Dynam ic Syst em s Developm ent Met hod). I n t erm s of our discussion, agile processes are st rongly adapt ive in t heir nat ure. They are also very m uch people- orient ed processes. Agile approaches assum e t hat t he m ost im port ant fact or in a proj ect 's success is t he qualit y of the people on t he proj ect and how well t hey work t oget her in hum an t erm s. Which process they use and which t ools t hey use are st rictly second- order effect s. 29/ 118

Agile m et hods t end t o use short , t im e- boxed it erat ions, m ost oft en of a m ont h or less. Because t hey don't at t ach m uch weight t o docum ent s, agile approaches disdain using t he UML in blueprint m ode. Most use the UML in sket ch m ode, wit h a few advocat ing using it as a program m ing language. Agile processes t end t o be low in ce re m on y . A high- cerem ony, or heavyweight , process has a lot of docum ent s and cont rol point s during t he proj ect . Agile processes consider t hat cerem ony m akes it harder t o m ake changes and works against the grain of t alent ed people. As a result , agile processes are oft en charact erized as ligh t w e igh t. I t 's im port ant t o realize t hat t he lack of cerem ony is a consequence of adapt ivit y and people orient at ion rat her t han a fundam ent al propert y.

Rational Unified Process Alt hough t he Rat ional Unified Process ( RUP) is independent of the UML, t he t wo are oft en t alked about t oget her. So I t hink it 's wort h saying a few t hings about it here. Alt hough RUP is called a process, it act ually is a process fram ework, providing a vocabulary and loose st ruct ure t o t alk about processes. When you use RUP, t he first t hing you need t o do is choose a de ve lopm e n t ca se: t he process you are going t o use in t he proj ect . Developm ent cases can vary widely, so don't assum e t hat your developm ent case will look t hat m uch like any ot her developm ent case. Choosing a developm ent case needs som eone early on who is very fam iliar wit h RUP: som eone who can t ailor RUP for a part icular proj ect 's needs. Alt ernat ively, t here is a growing body of packaged developm ent cases t o st art from . What ever the developm ent case, RUP is essent ially an it erat ive process. A wat erfall st yle isn't com pat ible wit h t he philosophy of RUP, alt hough sadly it 's not uncom m on t o run int o proj ect s t hat use a wat erfall-st yle process and dress it up in RUP's clot hes. All RUP proj ect s should follow four phases. 1. I n ce pt ion m akes an init ial evaluat ion of a proj ect . Typically in incept ion, you decide whet her t o com m it enough funds t o do an elaborat ion phase. 2. Ela bor a t ion ident ifies the prim ary use cases of t he proj ect and builds soft ware in it erat ions in order t o shake out t he archit ect ure of t he syst em . At t he end of elaborat ion, you should have a good sense of t he requirem ent s and a skelet al working syst em t hat act s as t he seed of developm ent . I n part icular, you should have found and resolved the m aj or risks t o t he proj ect . 3. Con st r uct ion cont inues t he building process, developing enough funct ionalit y t o release. 4. Tr a nsit ion includes various lat e-st age act ivit ies t hat you don't do it erat ively. These m ay include deploym ent int o t he dat a cent er, user t raining, and t he like. There's a fair am ount of fuzziness bet ween t he phases, especially bet ween elaborat ion and const ruct ion. For som e, t he shift t o const ruction is t he point at which you can m ove int o a predict ive planning m ode. For ot hers, it m erely indicat es t he point at which you have a broad vision of requirem ent s and an archit ecture that you t hink is going t o last the rest of t he proj ect . Som et im es, RUP is referred t o as the Unified Process ( UP) . This is usually done by organizat ions t hat wish t o use t he t erm inology and overall st yle of RUP wit hout using the licensed product s of Rat ional Soft ware. You can t hink of RUP as Rat ional's product offering based on t he UP, or you can t hink of RUP and UP as t he sam e t hing. Eit her way, you'll find people who agree wit h you.

Fitting a Process to a Project Soft ware proj ect s differ great ly from one anot her. The way you go about soft ware developm ent depends on m any fact ors: t he kind of syst em you're building, t he t echnology you're using, t he size and dist ribut ion of t he t eam , the nat ure of t he risks, t he consequences of failure, t he working st yles

30/ 118

of t he t eam , and t he cult ure of t he organizat ion. As a result , you should never expect t here t o be a one- size- fit s- all process t hat will work for all proj ect s. Consequent ly, you always have t o adapt a process t o fit your part icular environm ent . One of the first things you need t o do is look at your proj ect and consider which processes seem close t o a fit . This should give you a short list of processes t o consider. You should then consider what adapt at ions you need t o m ake t o fit t hem t o your proj ect . You have t o be som ewhat careful wit h t his. Many processes are difficult t o fully appreciat e unt il you've worked wit h t hem . I n t hese cases, it 's oft en wort h using t he process out of t he box for a couple of it erat ions unt il you learn how it works. Then you can st art m odifying t he process. I f from the beginning you are m ore fam iliar wit h how a process works, you can m odify it from t he beginning. Rem em ber t hat it 's usually easier t o st art wit h t oo lit t le and add t hings t han it is t o st art wit h t oo m uch and t ake t hings away.

Patterns The UML t ells you how t o express an obj ect - orient ed design. Pat t erns look, inst ead, at the result s of t he process: exam ple designs. Many people have com m ent ed t hat proj ect s have problem s because the people involved were not aware of designs t hat are well known t o t hose wit h m ore experience. Pat t erns describe com m on ways of doing t hings and are collect ed by people who spot repeat ing t hem es in designs. These people t ake each t hem e and describe it so t hat ot her people can read t he pat t ern and see how t o apply it . Let 's look at an exam ple. Say t hat you have som e obj ect s running in a process on your deskt op and t hat t hey need t o com m unicat e wit h ot her obj ect s running in anot her process. Perhaps t his process is also on your deskt op; perhaps it resides elsewhere. You don't want t he obj ect s in your syst em t o have t o worry about finding ot her obj ect s on t he net work or execut ing rem ot e procedure calls. What you can do is creat e a proxy obj ect wit hin your local process for t he rem ot e obj ect . The proxy has t he sam e int erface as t he rem ot e obj ect . Your local obj ect s t alk t o t he proxy, using the usual in- process m essage sends. The proxy t hen is responsible for passing any m essages on t o t he real obj ect , wherever it m ight reside. Proxies are a com m on t echnique used in net works and elsewhere. People have a lot of experience using proxies, knowing how t hey can be used, what advant ages t hey can bring, t heir lim it at ions, and how t o im plem ent them . Met hods books like t his one don't discuss t his knowledge; all t hey discuss is how you can diagram a proxy, alt hough useful, is not as useful as discussing t he experience involving proxies. I n the early 1990s, som e people began t o capt ure t his experience. They form ed a com m unit y int erest ed in writ ing pat t erns. These people sponsor conferences and have produced several books. The m ost fam ous pat t erns book t o em erge from t his group is [ Gang of Four] , which discusses 23 design pat t erns in det ail. I f you want t o know about proxies, t his book spends t en pages on t he subj ect , giving det ails about how t he obj ect s work t oget her, t he benefit s and lim it at ions of t he pat t ern, com m on variat ions, and im plem ent at ion t ips. A pat t ern is m uch m ore t han a m odel. A pat t ern m ust also include t he reason why it is t he way it is. I t is oft en said t hat a pat t ern is a solut ion t o a problem . The pat t ern m ust ident ify t he problem clearly, explain why it solves t he problem , and also explain the circum st ances under which t he pat t ern works and doesn't work. Pat t erns are im port ant because t hey are the next st age beyond underst anding t he basics of a language or a m odeling t echnique. Pat t erns give you a series of solut ions and also 31/ 118

show you what m akes a good m odel and how you go about const ruct ing a m odel. Pat t erns t each by exam ple. When I st art ed out , I wondered why I had t o invent t hings from scrat ch. Why didn't I have handbooks t o show m e how t o do com m on things? The pat t erns com m unit y is t rying t o build t hese handbooks. There are now m any pat t erns books out t here, and t hey vary great ly in qualit y. My favorit es are [ Gang of Four] , [ POSA1] , [ POSA2] , [ Core J2EE Pat t erns] , [ Pont ] , and wit h suit able im m odest y [ Fowler, AP] and [ Fowler, P of EAA] . You can also t ake a look at t he pat t erns hom e page: h t t p:/ / w w w .h illside .n et / pa t t e r ns.

However confident you are wit h your process when you begin, it 's essent ial t o learn as you go along. I ndeed, one of t he great benefit s of it erat ive developm ent is that it support s frequent process im provem ent . At the end of each it erat ion, conduct an it e ra t ion r e t r ospe ct ive, whereby t he t eam assem bles t o consider how t hings went and how they can be im proved. A couple of hours is plent y if your it erat ions are short . A good way t o do t his is t o m ake a list wit h t hree cat egories: 1. Keep: t hings t hat worked well t hat you want t o ensure you cont inue t o do 2. Problem s: areas t hat aren't working well 3. Try: changes t o your process t o im prove it You can st art each it erat ion ret rospect ive aft er t he first by reviewing the it em s from t he previous session and seeing how t hings have changed. Don't forget t he list of t hings t o keep; it 's im port ant t o keep t rack of things that are working. I f you don't do t hat , you can lose a sense of perspect ive on t he proj ect and pot ent ially st op paying at t ent ion t o winning pract ices. At the end of a proj ect or at a m aj or release, you m ay want t o consider a m ore form al pr oj e ct r e t r ospe ct ive t hat will last a couple of days; see h t t p:/ / w w w .re t r ospe ct ives.com / and [ Kert h] for m ore det ails. One of m y biggest irrit at ions is how organizat ions consist ent ly fail t o learn from t heir own experience and end up m aking expensive m ist akes t im e and t im e again.

Fitting the UML into a Process When t hey look at graphical m odeling languages, people usually t hink of t hem in t he cont ext of a wat erfall process. A wat erfall process usually has docum ent s t hat act as t he handoffs bet ween analysis, design, and coding phases. Graphical m odels can oft en form a m aj or part of t hese docum ent s. I ndeed, m any of t he st ruct ured m et hods from t he 1970s and 1980s t alk a lot about analysis and design m odels like t his. Whet her or not you use a wat erfall approach, you st ill do t he act ivit ies of analysis, design, coding, and t est ing. You can run an it erat ive proj ect wit h 1- week it erat ions, wit h each week a m iniwat erfall. Using the UML doesn't necessarily im ply developing docum ent s or feeding a com plex CASE t ool. Many people draw UML diagram s on whit eboards only during a m eet ing t o help com m unicat e t heir ideas.

Requirements Analysis The act ivit y of requirem ent s analysis involves t rying t o figure out what t he users and cust om ers of a soft ware effort want t he syst em t o do. A num ber of UML t echniques can com e in handy here: • •

Use cases, which describe how people int eract wit h t he syst em . A class diagram drawn from t he concept ual perspect ive, which can be a good way of building up a rigorous vocabulary of t he dom ain. 32/ 118

• •

An act ivit y diagram , which can show t he work flow of t he organizat ion, showing how soft ware and hum an act ivit ies int eract . An act ivit y diagram can show t he cont ext for use cases and also t he det ails of how a com plicat ed use case works. A st at e diagram , which can be useful if a concept has an int erest ing life cycle, wit h various st at es and event s t hat change t hat st at e.

When working in requirem ent s analysis, rem em ber t hat t he m ost im port ant thing is com m unicat ion wit h your users and cust om ers. Usually, they are not soft ware people and will be unfam iliar wit h t he UML or any ot her t echnique. Even so, I 've had success using t hese t echniques wit h nont echnical people. To do t his, rem em ber t hat it 's im port ant t o keep t he not at ion t o a m inim um . Don't int roduce anyt hing t hat specific t o t he soft ware im plem ent at ion. Be prepared t o break t he rules of the UML at any t im e if it helps you com m unicat e bet t er. The biggest risk wit h using the UML in analysis is t hat you draw diagram s that t he dom ain expert s don't fully underst and. A diagram t hat isn't underst ood by t he people who know t he dom ain is worse than useless; all it does is breed a false sense of confidence for t he developm ent t eam .

Design When you are doing design, you can get m ore technical wit h your diagram s. You can use m ore not at ion and be m ore precise about your not at ion. Som e useful t echniques are • • • • •

Class diagram s from a soft ware perspect ive. These show t he classes in t he soft ware and how t hey int errelat e. Sequence diagram s for com m on scenarios. A valuable approach is t o pick t he m ost im port ant and int erest ing scenarios from t he use cases and use CRC cards or sequence diagram s t o figure out what happens in t he soft ware. Package diagram s t o show t he large-scale organizat ion of t he soft ware. St at e diagram s for classes wit h com plex life hist ories. Deploym ent diagram s t o show t he physical layout of t he soft ware.

Many of t hese sam e t echniques can be used t o docum ent soft ware once it 's been writ t en. This m ay help people find t heir way around t he soft ware if t hey have t o work on it and are not fam iliar wit h t he code. Wit h a wat erfall life cycle, you would do t hese diagram s and act ivit ies as part of t he phases. The end- of- phase docum ent s usually include the appropriat e UML diagram s for t hat activit y. A wat erfall st yle usually im plies t hat t he UML is used as a blueprint . I n an it erat ive st yle, t he UML diagram s can be used in eit her a blueprint or a sket ch st yle. Wit h a blueprint , t he analysis diagram s will usually be built in the it erat ion prior t o t he one t hat builds t he funct ionalit y. Each it erat ion doesn't st art from scrat ch; rat her, it m odifies t he exist ing body of docum ent s, highlight ing t he changes in t he new it erat ion. Blueprint designs are usually done early in t he it erat ion and m ay be done in pieces for different bit s of funct ionalit y t hat are t arget ed for t he it erat ion. Again, it erat ion im plies m aking changes t o an existing m odel rat her t han building a new m odel each t im e. Using the UML in sket ch m ode im plies a m ore fluid process. One approach is t o spend a couple of days at t he beginning of an it erat ion, sket ching out the design for t hat it erat ion. You can also do short design sessions at any point during t he it erat ion, set t ing up a quick m eet ing for half an hour whenever a developer st art s t o t ackle a nont rivial funct ion. Wit h a blueprint , you expect t he code im plem ent at ion t o follow t he diagram s. A change from t he blueprint is a deviat ion that needs review from the designers who did t he blueprint . A sket ch is usually t reat ed m ore as a first cut at t he design; if, during coding, people find t hat t he sket ch isn't exact ly right , t hey should feel free t o change t he design. The im plem ent ors have t o use t heir j udgm ent as t o whet her t he change needs a wider discussion t o underst and t he full ram ificat ions.

33/ 118

One of m y concerns wit h blueprint s is m y own observat ion t hat it 's very hard t o get t hem right , even for a good designer. I oft en find t hat m y own designs do not survive cont act wit h coding int act . I st ill find UML sket ches useful, but I don't find t hat t hey can be t reat ed as absolut es. I n bot h m odes, it m akes sense t o explore a num ber of design alt ernat ives. I t 's usually best t o explore alt ernat ives in sket ch m ode so t hat you can quickly generat e and change t he alt ernat ives. Once you pick a design t o run wit h, you can eit her use t hat sket ch or det ail it int o a blueprint .

Documentation Once you have built t he soft ware, you can use the UML t o help docum ent what you have done. For t his, I find UML diagram s useful for get t ing an overall underst anding of a syst em . I n doing t his, however, I should st ress t hat I do not believe in producing det ailed diagram s of t he whole syst em . To quot e Ward Cunningham [ Cunningham ] : Carefully select ed and well- writ t en m em os can easily substit ut e for t radit ional com prehensive design docum ent at ion. The lat t er rarely shines except in isolat ed spot s. Elevat e t hose spot s . . . and forget about t he rest . ( p. 384) I believe t hat det ailed docum ent at ion should be generat ed from t he code—like, for inst ance, JavaDoc. You should writ e addit ional docum ent at ion t o highlight im port ant concept s. Think of t hese as com prising a first st ep for t he reader before he or she goes int o t he code-based det ails. I like t o st ruct ure t hese as prose docum ent s, short enough t o read over a cup of coffee, using UML diagram s t o help illust rat e t he discussion. I prefer t he diagram s as sket ches t hat highlight t he m ost im port ant part s of t he syst em . Obviously, t he writ er of t he docum ent needs t o decide what is im port ant and what isn't , but t he writ er is m uch bet t er equipped t han t he reader t o do t hat . A package diagram m akes a good logical road m ap of t he syst em . This diagram helps m e underst and t he logical pieces of t he syst em and see t he dependencies and keep t hem under cont rol. A deploym ent diagram ( see Chapt er 8) , which shows t he high- level physical pict ure, m ay also prove useful at t his st age. Wit hin each package, I like t o see a class diagram . I don't show every operat ion on every class. I show only t he im port ant feat ures t hat help m e underst and what is in t here. This class diagram act s as a graphical t able of cont ent s. The class diagram should be support ed by a handful of int eract ion diagram s t hat show t he m ost im port ant int eract ions in the syst em . Again, select ivit y is im port ant here; rem em ber t hat , in t his kind of docum ent , com prehensiveness is t he enem y of com prehensibilit y. I f a class has com plex life-cycle behavior, I draw a st at e m achine diagram (see Chapt er 10) t o describe it . I do t his only if t he behavior is sufficient ly com plex, which I find doesn't happen oft en. I 'll oft en include som e im port ant code, writ t en in a lit erat e program st yle. I f a part icularly com plex algorit hm is involved, I 'll consider using an act ivit y diagram ( see Chapt er 11) but only if it gives m e m ore underst anding t han t he code alone. I f I find concept s that are com ing up repeat edly, I use pat t erns ( page 27) t o capt ure t he basic ideas. One of t he m ost im port ant t hings t o docum ent is t he design alt ernat ives you didn't t ake and why you didn't do t hem . That 's oft en t he m ost forgot t en but m ost useful piece of ext ernal docum ent at ion you can provide.

Understanding Legacy Code The UML can help you figure out a gnarly bunch of unfam iliar code in a couple of ways. Building a sket ch of key fact s can act as a graphical not e- t aking m echanism t hat helps you capt ure im portant inform at ion as you learn about it . Sket ches of key classes in a package and t heir key int eract ions can help clarify what 's going on. 34/ 118

Wit h m odern t ools, you can generat e det ailed diagram s for key part s of a syst em . Don't use these t ools t o generat e big paper report s; inst ead, use t hem t o drill int o key areas as you are exploring t he code it self. A part icularly nice capabilit y is t hat of generat ing a sequence diagram t o see how m ult iple obj ect s collaborat e in handling a com plex m et hod.

Choosing a Development Process I 'm st rongly in favor of it erat ive developm ent processes. As I 've said in t his book before: You should use it erat ive developm ent only on proj ect s t hat you want t o succeed. Perhaps t hat 's a bit glib, but as I get older, I get m ore aggressive about using it erat ive developm ent . Done well, it is an essent ial t echnique, one you can use t o expose risk early and to obt ain bet t er cont rol over developm ent . I t is not t he sam e as having no m anagem ent , alt hough t o be fair, I should point out t hat som e have used it t hat way. I t does need t o be well planned. But it is a solid approach, and every OO developm ent book encourages using it —for good reason. You should not be surprised t o hear t hat as one t he aut hors of t he Manifest o for Agile Soft ware Developm ent , I 'm very m uch a fan of agile approaches. I 've also had a lot of posit ive experiences wit h Ext rem e Program m ing, and cert ainly you should consider it s pract ices very seriously.

Where to Find Out More Books on soft ware process have always been com m on, and t he rise of agile soft ware developm ent has led t o m any new books. Overall, m y favorit e book on process in general is [ McConnell] . He gives a broad and pract ical coverage of m any of t he issues involved in soft ware developm ent and a long list of useful practices. From t he agile com m unit y, [ Cockburn, agile] and [ Highsm it h] provide a good overview. For a lot of good advice about applying t he UML in an agile way, see [ Am bler] . One of t he m ost popular agile m et hods is Ext rem e Program m ing ( XP) , which you can delve int o via such Web sit es as h t t p:/ / x pr ogra m m in g.com and h t t p:/ / w w w .e x tr e m e progr a m m in g.or g. XP has spawned m any books, which is why I now refer t o it as t he form erly light weight m et hodology. The usual st art ing point is [ Beck] . Alt hough it 's writ t en for XP, [ Beck and Fowler] gives m ore det ails on planning an it erat ive proj ect . Much of t his is also covered by t he ot her XP books, but if you're int erest ed only in t he planning aspect , t his would be a good choice. For m ore inform at ion on t he Rat ional Unified Process, m y favorit e int roduction is [ Krucht en] .

Chapter 3. Class Diagrams: The Essentials I f som eone were t o com e up t o you in a dark alley and say, " Psst , wanna see a UML diagram ?" that diagram would probably be a class diagram . The m aj orit y of UML diagram s I see are class diagram s. The class diagram is not only widely used but also subj ect t o t he great est range of m odeling concept s. Alt hough t he basic elem ent s are needed by everyone, the advanced concept s are used less oft en. Therefore, I 've broken m y discussion of class diagram s int o t wo part s: t he essent ials ( t his chapt er) and the advanced ( Chapt er 5) .

35/ 118

A class dia gr a m describes t he t ypes of obj ect s in t he syst em and t he various kinds of st at ic relat ionships t hat exist am ong them . Class diagram s also show t he propert ies and operat ions of a class and t he const raint s t hat apply t o t he way obj ect s are connect ed. The UML uses the t erm fe a t ur e as a general t erm t hat covers propert ies and operat ions of a class. Figure 3.1 shows a sim ple class m odel that would not surprise anyone who has worked wit h order processing. The boxes in the diagram are classes, which are divided int o t hree com part m ent s: t he nam e of t he class ( in bold) , it s at t ribut es, and it s operat ions. Figure 3.1 also shows t wo kinds of relat ionships bet ween classes: associat ions and generalizat ions.

Figu r e 3 .1 . A sim ple cla ss dia gr a m

Properties Pr oper t ie s represent st ructural feat ures of a class. As a first approxim at ion, you can t hink of propert ies as corresponding t o fields in a class. The realit y is rat her involved, as we shall see, but t hat 's a reasonable place t o st art . Propert ies are a single concept , but t hey appear in t wo quit e dist inct not at ions: at t ribut es and associat ions. Alt hough t hey look quit e different on a diagram , t hey are really t he sam e t hing.

Attributes The a t t r ibu t e not at ion describes a propert y as a line of t ext wit hin the class box it self. The full form of an at t ribut e is:

36/ 118

visibility name: type multiplicity = default {property-string} An exam ple of t his is:

- name: String [1] = "Untitled" {readOnly} Only t he name is necessary. • • • • • •

This visibility m arker indicat es whet her t he at t ribut e is public ( + ) or privat e ( - ) ; I 'll discuss ot her visibilit ies on page 83. The name of t he at t ribut e—how the class refers t o t he at t ribut e—roughly corresponds t o t he nam e of a field in a program m ing language. The type of t he at t ribut e indicat es a rest rict ion on what kind of obj ect m ay be placed in t he at t ribut e. You can t hink of this as t he t ype of a field in a program m ing language. I 'll explain multiplicity on page 38. The default value is t he value for a newly creat ed obj ect if t he at t ribut e isn't specified during creat ion. The {property-string} allows you t o indicat e addit ional properties for t he at t ribut e. I n t he exam ple, I used {readOnly} t o indicat e t hat client s m ay not m odify t he propert y. I f t his is m issing, you can usually assum e t hat t he at t ribut e is m odifiable. I 'll describe ot her propert y st rings as we go.

Associations The ot her way t o not at e a propert y is as an associat ion. Much of t he sam e inform at ion t hat you can show on an at t ribut e appears on an associat ion. Figures 3.2 and 3.3 show t he sam e propert ies represent ed in t he t wo different not at ions.

Figu r e 3 .2 . Sh ow in g pr ope r t ie s of a n or de r a s a t t r ibu t e s

Figu r e 3 .3 . Sh ow in g pr ope r t ie s of a n or de r a s a ssocia t ion s

An a ssocia t ion is a solid line bet ween t wo classes, direct ed from t he source class t o t he t arget class. The nam e of t he propert y goes at t he t arget end of t he associat ion, t oget her wit h it s m ult iplicit y. The t arget end of t he associat ion links t o t he class t hat is t he t ype of t he propert y.

37/ 118

Alt hough m ost of t he sam e inform at ion appears in bot h not at ions, som e it em s are different . I n part icular, associat ions can show m ult iplicit ies at bot h ends of t he line. Wit h t wo not at ions for t he sam e t hing, t he obvious question is, Why should you use one or the ot her? I n general, I t end t o use at t ribut es for sm all t hings, such as dat es or Booleans—in general, value t ypes ( page 73) —and associat ions for m ore significant classes, such as cust om ers and orders. I also t end t o prefer t o use class boxes for classes t hat are significant for t he diagram , which leads t o using associat ions, and at t ribut es for t hings less im port ant for t hat diagram . The choice is m uch m ore about em phasis t han about any underlying m eaning.

When to Use Class Diagrams Class diagram s are t he backbone of t he UML, so you will find yourself using t hem all t he t im e. This chapt er covers t he basic concept s; Chapt er 5 discusses m any of t he advanced concept s. The t rouble wit h class diagram s is t hat t hey are so rich, they can be overwhelm ing t o use. Here are a few t ips. • • •

Don't t ry t o use all t he not at ions available t o you. St art wit h t he sim ple st uff in t his chapt er: classes, associat ions, at t ribut es, generalizat ion, and const raint s. I nt roduce ot her not at ions from Chapt er 5 only when you need t hem . I 've found concept ual class diagram s very useful in exploring t he language of a business. For t his t o work, you have t o work hard on keeping soft ware out of the discussion and keeping t he not at ion very sim ple. Don't draw m odels for everyt hing; inst ead, concent rat e on the key areas. I t is bet t er t o have a few diagram s t hat you use and keep up t o dat e t han t o have m any forgot t en, obsolet e m odels.

The biggest danger wit h class diagram s is t hat you can focus exclusively on st ruct ure and ignore behavior. Therefore, when drawing class diagram s t o underst and soft ware, always do t hem in conj unct ion wit h som e form of behavioral t echnique. I f you're going well, you'll find yourself swapping bet ween t he t echniques frequent ly.

Where to Find Out More All t he general UML books I m ent ioned in Chapt er 1 t alk about class diagram s in m ore det ail. Dependency m anagem ent is a crit ical feat ure of larger proj ect s. The best book on t his t opic is [ Mart in] .

Multiplicity The m u lt iplicit y of a propert y is an indicat ion of how m any obj ect s m ay fill t he propert y. The m ost com m on m ult iplicit ies you will see are • • •

1 ( An order m ust have exact ly one cust om er.) 0 ..1 (A corporat e cust om er m ay or m ay not have a single sales rep.) * ( A cust om er need not place an Order and t here is no upper lim it t o t he num ber of Orders a Cust om er m ay place—zero or m ore orders.)

More generally, m ult iplicit ies are defined wit h a lower bound and an upper bound, such as 2..4 for players of a gam e of canast a. The lower bound m ay be any posit ive num ber or zero; t he upper is 38/ 118

any posit ive num ber or * ( for unlim it ed) . I f t he lower and upper bounds are the sam e, you can use one num ber; hence, 1 is equivalent t o 1..1. Because it 's a com m on case, * is short for 0..* . I n at t ribut es, you com e across various t erm s t hat refer t o t he m ult iplicit y. • • • •

Opt ion a l im plies a lower bound of 0. M a n da t or y im plies a lower bound of 1 or possibly m ore. Sin gle - va lu e d im plies an upper bound of 1. M u lt iva lu e d im plies an upper bound of m ore than 1: usually * .

I f I have a m ult ivalued propert y, I prefer t o use a plural form for it s nam e. By default , t he elem ent s in a m ult ivalued m ult iplicit y form a set , so if you ask a cust om er for it s orders, t hey do not com e back in any order. I f the ordering of t he orders in associat ion has m eaning, you need t o add {ordered} t o t he associat ion end. I f you want t o allow duplicat es, add {nonunique}. ( I f you want t o explicit ly show t he default , you can use {unordered} and {unique}.) You m ay also see collect ion- orient ed nam es, such as {bag} for unordered, nonunique. UML 1 allowed discont inuous m ult iplicit ies, such as 2, 4 (m eaning 2 or 4, as in cars in t he days before m inivans) . Discont inuous m ult iplicit ies weren't very com m on and UML 2 rem oved t hem . The default m ult iplicit y of an at t ribut e is [ 1] . Alt hough t his is t rue in t he m et a-m odel, you can't assum e t hat an at t ribut e in a diagram t hat 's m issing a m ult iplicit y has a value of [ 1] , as t he diagram m ay be suppressing the m ult iplicit y inform at ion. As a result , I prefer t o explicit ly st at e a [ 1] m ult iplicit y if it 's im port ant .

Programming Interpretation of Properties As wit h anyt hing else in t he UML, there's no one way t o int erpret propert ies in code. The m ost com m on soft ware represent at ion is t hat of a field or propert y of your program m ing language. So t he Order Line class from Figure 3.1 would correspond t o som et hing like t he following in Java:

public class OrderLine... private int quantity; private Money price; private Order order; private Product product I n a language like C# , which has propert ies, it would correspond t o:

public class OrderLine ... public int Quantity; public Money Price; public Order Order; public Product Product; Not e t hat an at t ribut e t ypically corresponds t o public propert ies in a language t hat support s propert ies but t o privat e fields in a language t hat does not . I n a language wit hout propert ies, you m ay see t he fields exposed through accessor ( get t ing and set t ing) m et hods. A read- only at t ribut e will have no set t ing m et hod ( wit h fields) or set act ion (for propert ies) . Not e t hat if you don't give a nam e for a propert y, it 's com m on t o use t he nam e of the t arget class. Using privat e fields is a very im plem ent at ion-focused int erpret at ion of t he diagram . A m ore int erface- orient ed int erpret at ion m ight inst ead concent rat e on t he get t ing m et hods rat her than the

39/ 118

underlying dat a. I n this case, we m ight see t he Order Line's at t ribut es corresponding t o t he following m et hods:

public class OrderLine... private int quantity; private Product product; public int getQuantity() { return quantity; } public void setQuantity(int quantity) { this.quantity = quantity; } public Money getPrice() { return product.getPrice().multiply(quantity); } I n this case, t here is no dat a field for price; inst ead, it 's a com put ed value. But as far as client s of t he Order Line class are concerned, it looks t he sam e as a field. Client s can't t ell what is a field and what is com put ed. This inform at ion hiding is t he essence of encapsulat ion. I f an at t ribut e is m ult ivalued, t his im plies that t he dat a concerned is a collect ion. So an Order class would refer t o a collection of Order Lines. Because t his m ult iplicit y is ordered, that collect ion m ust be ordered, (such as a List in Java or an I List in .NET) . I f t he collect ion is unordered, it should, st rict ly, have no m eaningful order and t hus be im plem ent ed wit h a set , but m ost people im plem ent unordered at t ribut es as list s as well. Som e people use arrays, but the UML im plies an unlim it ed upper bound, so I alm ost always use a collect ion for dat a st ruct ure. Mult ivalued propert ies yield a different kind of int erface t o single-valued propert ies ( in Java) :

class Order { private Set lineItems = new HashSet(); public Set getLineItems() { return Collections.unmodifiableSet(lineItems); } public void addLineItem (OrderItem arg) { lineItems.add (arg); } public void removeLineItem (OrderItem arg) { lineItems.remove(arg); } I n m ost cases, you don't assign t o a m ult ivalued propert y; inst ead, you updat e wit h add and rem ove m et hods. I n order t o cont rol it s Line I t em s propert y, t he order m ust cont rol m em bership of that collect ion; as a result , it shouldn't pass out t he naked collect ion. I n this case, I used a prot ection proxy t o provide a read- only wrapper t o t he collect ion. You can also provide a nonupdat able it erat or or m ake a copy. I t 's okay for client s t o m odify the m em ber obj ect s, but t he client s shouldn't direct ly change t he collect ion it self. Because m ult ivalued at t ribut es im ply collect ions, you alm ost never see collect ion classes on a class diagram . You would show t hem only in very low level im plem ent at ion diagram s of collect ions t hem selves. You should be very afraid of classes t hat are not hing but a collect ion of fields and their accessors. Obj ect - orient ed design is about providing obj ect s t hat are able t o do rich behavior, so t hey shouldn't be sim ply providing dat a t o ot her obj ect s. I f you are m aking repeat ed calls for dat a by using accessors, t hat 's a sign t hat som e behavior should be m oved t o t he obj ect t hat has t he dat a. These exam ples also reinforce t he fact that t here is no hard- and-fast correspondence bet ween t he UML and code, yet there is a sim ilarit y. Wit hin a proj ect t eam , t eam convent ions will lead t o a closer correspondence. 40/ 118

Whet her a propert y is im plem ent ed as a field or as a calculat ed value, it represent s som et hing an obj ect can always provide. You shouldn't use a propert y t o m odel a t ransient relat ionship, such as an obj ect t hat is passed as a param et er during a m et hod call and used only wit hin t he confines of t hat int eract ion.

Bidirectional Associations The associat ions we've looked at so far are called unidirect ional associat ions. Anot her com m on kind of associat ion is a bidirect ional associat ion, such as Figure 3.4.

Figu r e 3 .4 . A bidir e ct ion a l a ssocia t ion

A bidirect ional associat ion is a pair of propert ies t hat are linked t oget her as inverses. The Car class has propert y owner:Person[1], and t he Person class has a propert y cars:Car[*]. ( Not e how I nam ed t he cars propert y in t he plural form of t he propert y's t ype, a com m on but non-norm at ive convent ion.) The inverse link bet ween t hem im plies t hat if you follow bot h propert ies, you should get back t o a set that cont ains your st art ing point . For exam ple, if I begin wit h a part icular MG Midget , find it s owner, and t hen look at it s owner's cars, t hat set should cont ain t he Midget that I st art ed from . As an alt ernat ive t o labeling an associat ion by a propert y, m any people, part icularly if t hey have a dat a- m odeling background, like t o label an associat ion by using a verb phrase ( Figure 3.5) so t hat t he relat ionship can be used in a sent ence. This is legal and you can add an arrow t o t he associat ion t o avoid am biguit y. Most obj ect m odelers prefer t o use a propert y nam e, as t hat corresponds bet t er t o responsibilit ies and operat ions.

Figu r e 3 .5 . Usin g a v e r b ph r a se t o na m e a n a ssocia t ion

Som e people nam e every associat ion in som e way. I choose t o nam e an associat ion only when doing so im proves underst anding. I 've seen t oo m any associat ions wit h such nam es as "has" or "is relat ed t o." I n Figure 3.4, t he bidirect ional nat ure of t he associat ion is m ade obvious by t he n a viga bilit y a r r ow s at bot h ends of t he associat ion. Figure 3.5 has no arrows; t he UML allows you t o use t his form eit her t o indicat e a bidirect ional associat ion or when you aren't showing navigabilit y. My preference is t o use t he double-headed arrow of Figure 3.4 when you want t o m ake it clear t hat you have a bidirect ional associat ion. I m plem ent ing a bidirectional associat ion in a program m ing language is oft en a lit t le t ricky because you have t o be sure that bot h properties are kept synchronized. Using C# , I use code along these lines t o im plem ent a bidirect ional associat ion:

class Car... 41/ 118

public Person Owner { get {return _owner;} set { if (_owner != null) _owner.friendCars().Remove(this); _owner = value; if (_owner != null) _owner.friendCars().Add(this); } } private Person _owner; ... class Person ... public IList Cars { get {return ArrayList.ReadOnly(_cars);} } public void AddCar(Car arg) { arg.Owner = this; } private IList _cars = new ArrayList(); internal IList friendCars() { //should only be used by Car.Owner return _cars; } .... The prim ary t hing is t o let one side of t he associat ion—a single- valued side, if possible—cont rol the relat ionship. For t his t o work, t he slave end ( Person) needs t o leak t he encapsulat ion of it s dat a t o t he m ast er end. This adds t o t he slave class an awkward m et hod, which shouldn't really be t here, unless t he language has fine- grained access cont rol. I 've used t he nam ing convent ion of " friend" here as a nod t o C+ + , where the m ast er's set t er would indeed be a friend. Like m uch propert y code, t his is pret t y boilerplat e st uff, which is why m any people prefer t o use som e form of code generat ion t o produce it . I n concept ual m odels, navigabilit y isn't an im port ant issue, so I don't show any navigabilit y arrows on concept ual m odels.

Operations Ope r a t ion s are t he act ions that a class knows t o carry out . Operat ions m ost obviously correspond t o t he m et hods on a class. Norm ally, you don't show t hose operat ions t hat sim ply m anipulat e propert ies, because t hey can usually be inferred. The full UML synt ax for operat ions is:

visibility name (parameter-list) : return-type {property-string} • • • • •

This visibility m arker is public ( + ) or privat e ( - ) ; ot hers on page 83. The name is a st ring. The parameter-list is t he list of param et ers for t he operat ion. The return-type is t he t ype of t he ret urned value, if there is one. The property-string indicat es propert y values t hat apply t o t he given operat ion.

The param et ers in t he param et er list are not at ed in a sim ilar way t o at t ribut es. The form is:

direction name: type = default value • •

The name, type, and default value are t he sam e as for at t ribut es. The direction indicat es whet her t he param et er is input ( in) , out put ( out) or bot h ( inout) . I f no direct ion is shown, it 's assum ed t o be in. 42/ 118

An exam ple operat ion on account m ight be:

+ balanceOn (date: Date) : Money Wit h concept ual m odels, you shouldn't use operat ions t o specify t he int erface of a class. I nst ead, use them t o indicat e t he principal responsibilit ies of t hat class, perhaps using a couple of words sum m arizing a CRC responsibilit y ( page 65) . I oft en find it useful t o dist inguish bet ween operat ions t hat change the st at e of t he syst em and t hose t hat don't . UML defines a qu e r y as an operat ion t hat get s a value from a class wit hout changing t he syst em st at e—in ot her words, wit hout side effect s.You can m ark such an operat ion wit h t he propert y st ring {query}. I refer t o operat ions t hat do change st at e as m odifier s, also called com m ands. St rict ly, t he difference bet ween query and m odifiers is whet her t hey change t he observable st at e [ Meyer] . The observable st at e is what can be perceived from the out side. An operat ion t hat updat es a cache would alt er t he int ernal st at e but would have no effect t hat 's observable from t he out side. I find it helpful t o highlight queries, as you can change t he order of execut ion of queries and not change t he syst em behavior. A com m on convent ion is t o t ry t o writ e operat ions so t hat m odifiers do not ret urn a value; t hat way, you can rely on t he fact t hat operat ions t hat ret urn a value are queries. [ Meyer] refers t o t his as t he Com m and-Query separat ion principle. I t 's som et im es awkward t o do t his all t he tim e, but you should do it as m uch as you can. Ot her t erm s you som et im es see are get t ing m et hods and set t ing m et hods. A ge t t in g m e t h od ret urns a value from a field ( and does not hing else) . A se t t in g m e th od put s a value int o a field ( and does not hing else) . From t he out side, a client should not be able t o t ell whet her a query is a get t ing m et hod or a m odifier is a set t ing m et hod. Knowledge of get t ing and set t ing m et hods is ent irely int ernal t o t he class. Anot her dist inct ion is bet ween operat ion and m et hod. An oper a t ion is som et hing that is invoked on an obj ect —t he procedure declarat ion—whereas a m e t h od is t he body of a procedure. The t wo are different when you have polym orphism . I f you have a supert ype wit h t hree subt ypes, each of which overrides t he supert ype's getPrice operat ion, you have one operat ion and four m et hods t hat im plem ent it . People usually use t he t erm s operat ion and m et hod int erchangeably, but there are tim es when it is useful t o be precise about t he difference.

Generalization A t ypical exam ple of gen e r a liza t ion involves t he personal and corporat e cust om ers of a business. They have differences but also m any sim ilarit ies. The sim ilarit ies can be placed in a general Cust om er class (t he supert ype) , wit h Personal Cust om er and Corporat e Cust om er as subt ypes. This phenom enon is also subj ect t o various int erpret at ions at t he various perspect ives of m odeling. Concept ually, we can say that Corporat e Cust om er is a subt ype of Cust om er if all inst ances of Corporat e Cust om er are also, by definit ion, instances of Cust om er. A Corporat e Cust om er is t hen a special kind of Cust om er. The key idea is t hat everyt hing we say about a Cust om er—associat ions, at t ribut es, operat ions—is t rue also for a Corporat e Cust om er. Wit h a soft ware perspect ive, t he obvious int erpret at ion is inherit ance: The Corporat e Cust om er is a subclass of Cust om er. I n m ainst ream OO languages, t he subclass inherit s all t he feat ures of t he superclass and m ay override any superclass m et hods. An im port ant principle of using inherit ance effect ively is su bst it u t a bilit y. I should be able t o subst it ut e a Corporat e Cust om er wit hin any code t hat requires a Cust om er, and everyt hing should work fine. Essent ially, this m eans t hat if I writ e code assum ing I have a Cust om er, I can freely use any subt ype of Cust om er. The Corporat e Cust om er m ay respond t o cert ain com m ands different ly 43/ 118

from anot her Cust om er, using polym orphism , but t he caller should not need t o worry about t he difference. ( For m ore on this, see t he Liskov Subst it ut ion Principle ( LSP) in [ Mart in] .) Alt hough inherit ance is a powerful m echanism , it brings in a lot of baggage that isn't always needed t o achieve substit ut abilit y. A good exam ple of t his was in the early days of Java, when m any people didn't like t he im plem ent at ion of t he built -in Vect or class and want ed t o replace it wit h som et hing light er. However, the only way they could produce a class t hat was subst it ut able for Vect or was t o subclass it , and t hat m eant inherit ing a lot of unwant ed dat a and behavior. Many ot her m echanism s can be used t o provide subst it ut able classes. As a result , m any people like t o different iat e bet ween subt yping, or int erface inherit ance, and subclassing, or im plem ent at ion inherit ance. A class is a su bt ype if it is subst it ut able for it s supert ype, whet her or not it uses inherit ance. Su bcla ssin g is used as a synonym for regular inherit ance. Many ot her m echanism s are available that allow you t o have subt yping wit hout subclassing. Exam ples are im plem ent ing an int erface ( page 69) and m any of t he st andard design pat t erns [ Gang of Four] .

Notes and Comments Not es are com m ent s in the diagram s. Not es can st and on t heir own, or t hey can be linked wit h a dashed line t o t he elem ent s t hey are com m ent ing ( Figure 3.6) . They can appear in any kind of diagram .

Figu r e 3 .6 . A n ot e is u se d a s a com m e n t on on e or m or e dia gr a m e le m e n t s

The dashed line can som et im es be awkward because you can't posit ion exactly where t his line ends. So a com m on convent ion is t o put a very sm all open circle at the end of t he line. Som et im es, it 's useful t o have an in-line com m ent on a diagram elem ent . You can do t his by prefixing the t ext wit h t wo dashes: - - .

Dependency A de pen de ncy exist s bet ween t wo elem ent s if changes t o t he definit ion of one elem ent ( t he su pplie r) m ay cause changes t o t he ot her (t he clie n t ) . Wit h classes, dependencies exist for various reasons: One class sends a m essage t o anot her; one class has anot her as part of it s dat a; one class m ent ions anot her as a param et er t o an operat ion. I f a class changes it s int erface, any m essage sent t o t hat class m ay no longer be valid. As com put er syst em s grow, you have t o worry m ore and m ore about cont rolling dependencies. I f dependencies get out of cont rol, each change t o a syst em has a wide ripple effect as m ore and m ore t hings have t o change. The bigger t he ripple, t he harder it is t o change anyt hing. The UML allows you t o depict dependencies bet ween all sort s of elem ent s. You use dependencies whenever you want t o show how changes in one elem ent m ight alt er ot her elem ent s. Figure 3.7 shows som e dependencies t hat you m ight find in a m ult ilayered applicat ion. The Benefit s Window class—a user int erface, or pre sen t a t ion class—is dependent on t he Em ployee class: a 44/ 118

dom a in obj ect t hat capt ures t he essent ial behavior of t he syst em —in this case, business rules. This m eans t hat if the em ployee class changes it s int erface, the Benefit s Window m ay have t o change.

Figu r e 3 .7 . Ex a m ple de pe n de n cie s

The im port ant t hing here is that the dependency is in only one direct ion and goes from t he present at ion class t o t he dom ain class. This way, we know t hat we can freely alt er t he Benefit s Window wit hout t hose changes having any effect on t he Em ployee or ot her dom ain obj ect s. I 've found t hat a st rict separat ion of present at ion and dom ain logic, wit h t he present at ion depending on t he dom ain but not vice versa, has been a valuable rule for m e t o follow. A second not able thing from this diagram is t hat t here is no direct dependency from t he Benefit s Window t o t he t wo Dat a Gat eway classes. I f t hese classes change, t he Em ployee class m ay have t o change. But if t he change is only t o t he im plem ent at ion of the Em ployee class, not it s int erface, t he change st ops there. The UML has m any variet ies of dependency, each wit h part icular sem ant ics and keywords. The basic dependency t hat I 've out lined here is the one I find t he m ost useful, and I usually use it wit hout keywords. To add m ore det ail, you can add an appropriat e keyword ( Table 3.1) . The basic dependency is not a t ransit ive relat ionship. An exam ple of a t ra n sit ive relat ionship is t he " larger beard" relat ionship. I f Jim has a larger beard t han Grady, and Grady has a larger beard than I var, we can deduce t hat Jim has a larger beard t han I var. Som e kind of dependencies, such as subst it ut e, are t ransit ive, but in m ost cases t here is a significant difference bet ween direct and indirect dependencies, as t here is in Figure 3.7. Many UML relat ionships im ply a dependency. The navigable associat ion from Order t o Cust om er in Figure 3.1 m eans t hat Order is dependent on Cust om er. A subclass is dependent on it s superclass but not vice versa.

Ta ble 3 .1 . Se le ct e d D e pe n de n cy Ke yw or ds Ke yw or d

M e a n in g

«call»

The source calls an operat ion in t he t arget .

«create»

The source creat es inst ances of t he t arget .

«derive»

The source is derived from the t arget .

«instantiate» The source is an inst ance of the t arget . ( Not e t hat if t he source is a class, t he class it self is an inst ance of t he class class; that is, t he t arget class is a m et aclass) . «permit»

The t arget allows t he source t o access t he t arget 's privat e feat ures.

«realize»

The source is an im plem ent at ion of a specificat ion or int erface defined by the t arget ( page 69) .

«refine»

Refinem ent indicat es a relat ionship bet ween different sem ant ic levels; for exam ple, t he source m ight be a design class and t he t arget t he corresponding analysis class.

«substitute»

The source is subst it ut able for the t arget ( page 45) .

«trace»

Used t o t rack such t hings as requirem ent s t o classes or how changes in one m odel 45/ 118

Ta ble 3 .1 . Se le ct e d D e pe n de n cy Ke yw or ds Ke yw or d

M e a n in g link t o changes elsewhere.

«use»

The source requires t he t arget for it s im plem ent at ion.

Your general rule should be t o m inim ize dependencies, part icularly when they cross large areas of a syst em . I n part icular, you should be wary of cycles, as t hey can lead t o a cycle of changes. I 'm not super st rict on this. I don't m ind m ut ual dependencies bet ween closely relat ed classes, but I do t ry t o elim inat e cycles at a broader level, particularly bet ween packages. Trying t o show all t he dependencies in a class diagram is an exercise in fut ilit y; t here are t oo m any and t hey change t oo m uch. Be selective and show dependencies only when t hey are directly relevant t o t he part icular t opic that you want t o com m unicat e. To underst and and cont rol dependencies, you are best off using t hem wit h package diagram s ( pages 89) . The m ost com m on case I use for dependencies wit h classes is when illust rat ing a t ransient relat ionship, such as when one obj ect is passed t o anot her as a param et er. You m ay see t hese used wit h keywords «parameter», «local», and «global». You m ay also see these keywords on associat ions in UML 1 m odels, in which case t hey indicat e t ransient links, not propert ies. These keywords are not part of UML 2. Dependencies can be det erm ined by looking at code, so t ools are ideal for doing dependency analysis. Get t ing a t ool t o reverse engineer pictures of dependencies is t he m ost useful way t o use t his bit of the UML.

Constraint Rules Much of what you are doing in drawing a class diagram is indicat ing const raint s. Figure 3.1 indicat es t hat an Order can be placed only by a single Cust om er. The diagram also im plies t hat each Line I t em is thought of separat ely: You say " 40 brown widget s, 40 blue widget s, and 40 red widget s," not " 120 t hings" on the Order. Furt her, t he diagram says t hat Corporat e Cust om ers have credit lim it s but Personal Cust om ers do not . The basic const ruct s of associat ion, at t ribut e, and generalizat ion do m uch t o specify im port ant const raint s, but t hey cannot indicat e every const raint . These const raint s st ill need t o be capt ured; t he class diagram is a good place t o do t hat . The UML allows you t o use anyt hing t o describe const raint s. The only rule is that you put t hem inside braces ({ } ) . You can use nat ural language, a program m ing language, or t he UML's form al Obj ect Const raint Language ( OCL) [ Warm er and Kleppe] , which is based on predicat e calculus. Using a form al not at ion avoids the risk of m isint erpret at ion due t o an am biguous nat ural language. However, it int roduces the risk of m isint erpret at ion due t o writ ers and readers not really underst anding OCL. So unless you have readers who are com fort able wit h predicat e calculus, I 'd suggest using nat ural language. Opt ionally, you can nam e a const raint by put t ing t he nam e first , followed by a colon; for exam ple, { disallow incest : husband and wife m ust not be siblings} .

Design by Contract Design by Cont ract is a design t echnique developed by Bert rand Meyer [ Meyer] . The t echnique is a cent ral feat ure of the Eiffel language he developed. Design by Cont ract is not specific t o Eiffel, however; it is a valuable t echnique that can be used wit h any program m ing language. At the heart of Design by Cont ract is t he assert ion. An asse r t ion is a Boolean st at em ent 46/ 118

t hat should never be false and, therefore, will be false only because of a bug. Typically, assert ions are checked only during debug and are not checked during product ion execut ion. I ndeed, a program should never assum e t hat assert ions are being checked. Design by Cont ract uses t hree part icular kinds of assert ions: post - condit ions, precondit ions, and invariant s. Pre- condit ions and post - condit ions apply t o operat ions. A post con dit ion is a st at em ent of what t he world should look like aft er execut ion of an operat ion. For inst ance, if we define t he operat ion " square root " on a num ber, t he post condit ion would t ake t he form input = result * result , where result is t he out put and input is t he input value. The post - condit ion is a useful way of saying what we do wit hout saying how we do it —in ot her words, of separat ing int erface from im plem ent at ion. A pr e - con dit ion is a st at em ent of how we expect t he world t o be before we execut e an operat ion. We m ight define a pre- condit ion for t he " square root " operat ion of input > = 0 . Such a pre-condit ion says t hat it is an error t o invoke " square root " on a negat ive num ber and t hat t he consequences of doing so are undefined. On first glance, this seem s a bad idea, because we should put som e check som ewhere t o ensure t hat " square root " is invoked properly. The im port ant question is who is responsible for doing so. The pre- condit ion m akes it explicit t hat t he caller is responsible for checking. Wit hout t his explicit st at em ent of responsibilit ies, we can get eit her t oo lit t le checking—because bot h part ies assum e that t he ot her is responsible—or t oo m uch—bot h part ies check. Too m uch checking is a bad thing because it leads t o a lot of duplicat e checking code, which can significant ly increase t he com plexit y of a program . Being explicit about who is responsible helps t o reduce t his com plexit y. The danger that t he caller forget s t o check is reduced by t he fact that assertions are usually checked during debugging and t est ing. From t hese definit ions of pre- condit ion and post - condit ion, we can see a st rong definit ion of t he t erm e xce pt ion. An except ion occurs when an operat ion is invoked wit h it s precondit ion sat isfied yet cannot ret urn wit h it s post - condit ion sat isfied. An in va r ia n t is an assert ion about a class. For inst ance, an Account class m ay have an invariant t hat says that balance = = sum ( ent ries.am ount ( ) ) . The invariant is " always" t rue for all inst ances of the class. Here, " always" m eans " whenever t he obj ect is available t o have an operat ion invoked on it ." I n essence, t his m eans t hat t he invariant is added t o pre- condit ions and post - condit ions associat ed wit h all public operat ions of t he given class. The invariant m ay becom e false during execut ion of a m et hod, but it should be rest ored t o t rue by t he t im e any ot her obj ect can do anyt hing t o t he receiver. Assert ions can play a unique role in subclassing. One of t he dangers of inherit ance is t hat you could redefine a subclass's operat ions t o be inconsist ent wit h the superclass's operat ions. Assert ions reduce t he chances of t his. The invariant s and post - condit ions of a class m ust apply t o all subclasses. The subclasses can choose t o st rengt hen these assert ions but cannot weaken t hem . The pre- condit ion, on t he ot her hand, cannot be st rengt hened but m ay be weakened. This looks odd at first , but it is im port ant t o allow dynam ic binding. You should always be able t o t reat a subclass obj ect as if it were an inst ance of t he superclass, per the principle of subst it ut abilit y. I f a subclass st rengt hened it s pre- condit ion, a superclass operat ion could fail when applied t o t he subclass.

Chapter 4. Sequence Diagrams 47/ 118

I n t e r act ion dia gr a m s describe how groups of obj ect s collaborat e in som e behavior. The UML defines several form s of int eract ion diagram , of which the m ost com m on is the sequence diagram . Typically, a sequence diagram capt ures t he behavior of a single scenario. The diagram shows a num ber of exam ple obj ect s and t he m essages that are passed bet ween t hese obj ect s wit hin t he use case. To begin t he discussion, I 'll consider a sim ple scenario. We have an order and are going t o invoke a com m and on it t o calculat e it s price. To do t hat , t he order needs t o look at all the line it em s on t he order and det erm ine t heir prices, which are based on the pricing rules of the order line's product s. Having done t hat for all t he line it em s, t he order t hen needs t o com put e an overall discount , which is based on rules t ied t o t he cust om er. Figure 4.1 is a sequence diagram that shows one im plem ent at ion of t hat scenario. Sequence diagram s show t he int eract ion by showing each part icipant wit h a lifeline t hat runs vert ically down t he page and the ordering of m essages by reading down t he page.

Figu r e 4 .1 . A se qu e n ce dia gr a m for ce n t r a lize d con t r ol

One of t he nice t hings about a sequence diagram is t hat I alm ost don't have t o explain t he not at ion. You can see that an inst ance of order sends getQuantity and getProduct m essages t o t he order line. You can also see how we show the order invoking a m et hod on it self and how t hat m et hod sends getDiscountInfo t o an inst ance of cust om er. The diagram , however, doesn't show everyt hing very well. The sequence of m essages getQuantity, getProduct, getPricingDetails, and calculateBasePrice needs t o be done for each order line on t he order, while calculateDiscounts is invoked j ust once. You can't t ell t hat from t his diagram , alt hough I 'll int roduce som e m ore not at ion t o handle t hat lat er. Most of t he t im e, you can think of t he part icipant s in an int eract ion diagram as obj ect s, as indeed t hey were in UML 1. But in UML 2, t heir roles are m uch m ore com plicat ed, and t o explain it all fully is beyond t his book. So I use t he t erm par t icipa n t s, a word t hat isn't used form ally in t he UML

48/ 118

spec. I n UML 1, part icipant s were obj ect s and so t heir nam es were underlined, but in UML 2, t hey should be shown wit hout the underline, as I 've done here. I n these diagram s, I 've nam ed the part icipant s using t he st yle anOrder. This works well m ost of t he t im e. A fuller synt ax is name : Class, where bot h t he nam e and t he class are opt ional, but you m ust keep the colon if you use the class. ( Figure 4.4, shown on page 58, uses this st yle.) Each lifeline has an activat ion bar that shows when t he part icipant is act ive in t he int eract ion. This corresponds t o one of t he part icipant 's m et hods being on t he st ack. Act ivat ion bars are opt ional in UML, but I find t hem ext rem ely valuable in clarifying t he behavior. My one except ion is when exploring a design during a design session, because they are awkward t o draw on whit eboards. Nam ing oft en is useful t o correlat e part icipant s on t he diagram . The call getProduct is shown ret urning aProduct, which is t he sam e nam e, and t herefore t he sam e part icipant , as t he aProduct t hat t he getPricingDetails call is sent t o. Not e t hat I 've used a ret urn arrow for only t his call; I did t hat t o show t he correspondance. Som e people use ret urns for all calls, but I prefer t o use t hem only where t hey add inform at ion; ot herwise, t hey sim ply clut t er t hings. Even in this case, you could probably leave t he ret urn out wit hout confusing your reader. The first m essage doesn't have a participant t hat sent it , as it com es from an undet erm ined source. I t 's called a fou n d m e ssa ge. For anot her approach t o t his scenario, t ake a look at Figure 4.2. The basic problem is st ill t he sam e, but t he way in which t he part icipant s collaborat e t o im plem ent it is very different . The Order asks each Order Line t o calculat e it s own Price. The Order Line it self furt her hands off the calculat ion to t he Product ; not e how we show t he passing of a param et er. Sim ilarly, t o calculat e t he discount , t he Order invokes a m et hod on t he Cust om er. Because it needs inform at ion from t he Order t o do t his, t he Cust om er m akes a reent rant call ( getBaseValue) t o t he Order t o get t he dat a.

Figu r e 4 .2 . A se qu e n ce dia gr a m for dist r ibu t e d con t r ol

The first t hing t o not e about t hese t wo diagram s is how clearly t he sequence diagram indicat es the differences in how t he part icipant s int eract . This is t he great st rengt h of int eract ion diagram s. They aren't good at showing det ails of algorit hm s, such as loops and condit ional behavior, but they m ake t he calls bet ween part icipant s cryst al clear and give a really good pict ure about which part icipant s are doing which processing. The second t hing t o not e is t he clear difference in st yles bet ween t he t wo int eractions. Figure 4.1 is ce n t ra lize d con tr ol, wit h one part icipant pret t y m uch doing all t he processing and ot her part icipant s t here t o supply dat a. Figure 4.2 uses dist r ibu t e d con t rol, in which t he processing is split am ong m any part icipant s, each one doing a lit t le bit of t he algorit hm . 49/ 118

Bot h st yles have t heir st rengt hs and weaknesses. Most people, part icularly t hose new t o obj ect s, are m ore used t o cent ralized cont rol. I n m any ways, it 's sim pler, as all t he processing is in one place; wit h dist ribut ed cont rol, in cont rast , you have t he sensat ion of chasing around t he obj ect s, t rying t o find t he program . Despit e t his, obj ect bigot s like m e st rongly prefer dist ribut ed cont rol. One of the m ain goals of good design is t o localize the effect s of change. Dat a and behavior t hat accesses that dat a oft en change t oget her. So put t ing the dat a and t he behavior t hat uses it t oget her in one place is the first rule of obj ect - orient ed design. Furt herm ore, by dist ribut ing cont rol, you creat e m ore opport unit ies for using polym orphism rat her t han using condit ional logic. I f t he algorit hm s for product pricing are different for different t ypes of product , t he dist ribut ed cont rol m echanism allows us t o use subclasses of product t o handle t hese variat ions. I n general t he OO st yle is t o use a lot of lit t le obj ect s wit h a lot of lit t le m et hods t hat give us a lot of plug point s for overriding and variat ion. This st yle is very confusing t o people used t o long procedures; indeed, t his change is t he heart of the par a digm sh ift of obj ect orient at ion. I t 's som et hing that 's very difficult t o t each. I t seem s t hat the only way t o really underst and it is t o work in an OO environm ent wit h st rongly dist ribut ed cont rol for a while. Many people then say t hat they get a sudden " aha" when t he st yle m akes sense. At t his point , t heir brains have been rewired, and t hey st art t hinking that decent ralized cont rol is act ually easier.

Creating and Deleting Participants Sequence diagram s show som e ext ra not at ion for creat ing and delet ing part icipant s ( Figure 4.3) . To creat e a participant , you draw the m essage arrow direct ly int o t he part icipant box. A m essage nam e is opt ional here if you are using a const ruct or, but I usually m ark it wit h " new" in any case. I f t he part icipant im m ediat ely does som et hing once it 's creat ed, such as t he query com m and, you st art an act ivat ion right aft er t he part icipant box.

Figu r e 4 .3 . Cr e a t ion a n d de le t ion of pa r t icipa n t s

50/ 118

Delet ion of a part icipant is indicat ed by big X. A m essage arrow going int o t he X indicat es one part icipant explicit ly delet ing anot her; an X at t he end of a lifeline shows a part icipant delet ing it self. I n a garbage-collect ed environm ent , you don't delet e obj ect s directly, but it 's st ill wort h using the X t o indicat e when an obj ect is no longer needed and is ready t o be collect ed. I t 's also appropriat e for close operat ions, indicat ing t hat t he obj ect isn't usable any m ore.

Loops, Conditionals, and the Like A com m on issue wit h sequence diagram s is how t o show looping and condit ional behavior. The first t hing t o point out is t hat t his isn't what sequence diagram s are good at . I f you want t o show cont rol st ruct ures like this, you are bet t er off wit h an act ivit y diagram or indeed wit h code it self. Treat sequence diagram s as a visualizat ion of how obj ect s int eract rat her than as a way of m odeling cont rol logic. That said, here's t he not at ion t o use. Bot h loops and condit ionals use in t er a ct ion fr a m e s, which are ways of m arking off a piece of a sequence diagram . Figure 4.4 shows a sim ple algorit hm based on t he following pseudocode:

Figu r e 4 .4 . I n t e r a ct ion fr a m e s

51/ 118

procedure dispatch foreach (lineitem) if (product.value > $10K) careful.dispatch else regular.dispatch end if end for if (needsConfirmation) messenger.confirm end procedure I n general, fram es consist of som e region of a sequence diagram t hat is divided int o one or m ore fragm ent s. Each fram e has an operat or and each fragm ent m ay have a guard. ( Table 4.1 list s com m on operat ors for int eract ion fram es.) To show a loop, you use t he loop operand wit h a single fragm ent and put the basis of t he it erat ion in t he guard. For condit ional logic, you can use an alt operat or and put a condit ion on each fragm ent . Only t he fragm ent whose guard is t rue will execut e. I f you have only one region, t here is an opt operat or. I nt eraction fram es are new in UML 2. As a result , you m ay see diagram s prepared before UML 2 and t hat use a different approach; also, som e people don't like t he fram es and prefer som e of t he older convent ions. Figure 4.5 shows som e of t hese unofficial t weaks.

Figu r e 4 .5 . Olde r con v e n t ions for con t r ol logic

52/ 118

UML 1 used it erat ion m arkers and guards. An ite r a t ion m a r ke r is a * added t o t he m essage nam e. You can add som e t ext in square bracket s t o indicat e t he basis of t he it erat ion. Gu ar ds are a condit ional expression placed in square bracket s and indicat e t hat t he m essage is sent only if the guard is t rue. While these not at ions have been dropped from sequence diagram s in UML 2, they are st ill legal on com m unicat ion diagram s.

Ta ble 4 .1 . Com m on Ope r a t or s for I n t e r a ct ion Fr a m e s M e a n in g

Ope r a tor alt

Alt ernat ive m ult iple fragm ent s; only t he one whose condit ion is t rue will execut e ( Figure

4.4 ) . opt

Opt ional; t he fragm ent execut es only if the supplied condit ion is t rue. Equivalent t o an alt wit h only one t race ( Figure 4.4 ) .

par

Parallel; each fragm ent is run in parallel.

loop

Loop; t he fragm ent m ay execut e m ult iple t im es, and the guard indicat es t he basis of it erat ion ( Figure 4.4 ) .

region

Crit ical region; t he fragm ent can have only one t hread execut ing it at once.

neg

Negat ive; t he fragm ent shows an invalid int eract ion.

ref

Reference; refers t o an int eract ion defined on anot her diagram . The fram e is drawn t o cover t he lifelines involved in the int eract ion. You can define param et ers and a ret urn value.

sd

Sequence diagram ; used t o surround an ent ire sequence diagram , if you wish.

Alt hough it erat ion m arkers and guards can help, t hey do have weaknesses. The guards can't indicat e t hat a set of guards are m ut ually exclusive, such as t he t wo on Figure 4.5. Bot h not at ions work only wit h a single m essage send and don't work well when several m essages com ing out of a single act ivat ion are wit hin t he sam e loop or condit ional block. To get around t his last problem , an unofficial convent ion t hat 's becom e popular is t o use a pse u dom essa ge, wit h t he loop condit ion or t he guard on a variat ion of t he self-call not at ion. I n Figure 4.5, I 've shown t his wit hout a m essage arrow; som e people include a m essage arrow, but 53/ 118

leaving it out helps reinforce that this isn't a real call. Som e also like t o gray shade t he pseudom essage's act ivat ion bar. I f you have alt erat ive behavior, you can show t hat wit h an alt ernat ive m arker bet ween t he act ivat ions. Alt hough I find act ivat ions very helpful, t hey don't add m uch in t he case of t he dispatch m et hod, whereby you send a m essage and not hing else happens wit hin the receiver's act ivat ion. A com m on convent ion t hat I 've shown on Figure 4.5 is t o drop t he activat ion for those sim ple calls. The UML st andard has no graphic device t o show passing dat a; inst ead, it 's shown by param et ers in t he m essage nam e and ret urn arrows. D a t a t a dpole s have been around in m any m et hods t o indicat e t he m ovem ent of dat a, and m any people st ill like t o use t hem wit h t he UML. All in all, alt hough various schem es can add not at ion for condit ional logic t o sequence diagram s, I don't find t hat t hey work any bet t er than code or at least pseudocode. I n part icular, I find the int eraction fram es very heavy, obscuring t he m ain point of t he diagram , so I prefer pseudom essages.

Synchronous and Asynchronous Calls I f you're except ionally alert , you'll have not iced t hat t he arrowheads in t he last couple of diagram s are different from the arrowheads earlier on. That m inor difference is quit e im port ant in UML 2. I n UML 2, filled arrowheads show a synchronous m essage, while st ick arrowheads show an asynchronous m essage. I f a caller sends a synch ronou s m e ssa ge , it m ust wait unt il t he m essage is done, such as invoking a subrout ine. I f a caller sends an a synch ron ous m e ssa ge , it can cont inue processing and doesn't have t o wait for a response. You see asynchronous calls in m ult it hreaded applicat ions and in m essage- orient ed m iddleware. Asynchrony gives bet t er responsiveness and reduces t he t em poral coupling but is harder t o debug. The arrowhead difference is very subt le; indeed, rat her t oo subt le. I t 's also a backward-incom pat ible change int roduced in UML 1.4, before t hen an asynchronous m essage was shown wit h t he half-st ick arrowhead, as in Figure 4.5. I t hink t hat t his arrowhead dist inct ion is t oo subt le. I f you want t o highlight asynchronous m essages, I would recom m end using t he obsolet e half- stick arrowhead, which draws t he eye m uch bet t er to an im port ant dist inct ion. I f you're reading a sequence diagram , beware of m aking assum pt ions about synchrony from t he arrowheads unless you're sure t hat t he aut hor is int ent ionally m aking the dist inct ion.

When to Use Sequence Diagrams You should use sequence diagram s when you want t o look at t he behavior of several obj ect s wit hin a single use case. Sequence diagram s are good at showing collaborat ions am ong t he obj ect s; they are not so good at precise definit ion of t he behavior. I f you want t o look at t he behavior of a single obj ect across m any use cases, use a st at e diagram ( see Chapt er 10) . I f you want t o look at behavior across m any use cases or m any threads, consider an act ivit y diagram (see Chapt er 11) . I f you want t o explore m ult iple alt ernat ive int eract ions quickly, you m ay be bet t er off wit h CRC cards, as t hat avoids a lot of drawing and erasing. I t 's oft en handy t o have a CRC card session t o explore design alt ernat ives and t hen use sequence diagram s t o capt ure any int eract ions t hat you want t o refer t o lat er. Ot her useful form s of int eract ion diagram s are com m unicat ion diagram s, for showing connect ions; and t im ing diagram s, for showing t im ing const raint s.

54/ 118

CRC Cards One of t he m ost valuable t echniques in com ing up wit h a good OO design is t o explore obj ect int eract ions, because it focuses on behavior rat her than dat a. CRC ( ClassResponsibilit y- Collaborat ion) diagram s, invent ed by Ward Cunningham in t he lat e 1980s, have st ood t he t est of tim e as a highly effect ive way t o do t his ( Figure 4.6 ) . Alt hough t hey aren't part of the UML, t hey are a very popular t echnique am ong skilled obj ect designers.

Figu r e 4 .6 . A sa m ple CRC ca r d

To use CRC cards, you and your colleagues gat her around a t able. Take various scenarios and act t hem out wit h t he cards, picking them up in t he air when t hey are act ive and m oving t hem t o suggest how t hey send m essages t o each ot her and pass t hem around. This t echnique is alm ost im possible t o describe in a book yet is easily dem onst rat ed; t he best way t o learn it is t o have som eone who has done it show it t o you. An im port ant part of CRC thinking is ident ifying responsibilit ies. A r e spon sibilit y is a short sent ence t hat sum m arizes som et hing that an obj ect should do: an action the obj ect perform s, som e knowledge t he obj ect m aint ains, or som e im port ant decisions t he obj ect m akes. The idea is that you should be able t o t ake any class and sum m arize it wit h a handful of responsibilit ies. Doing that can help you t hink m ore clearly about t he design of your classes. The second C refers t o colla bor a t or s: t he ot her classes t hat t his class needs t o work wit h. This gives you som e idea of the links bet ween classes—st ill at a high level. One of t he chief benefit s of CRC cards is t hat they encourage anim at ed discussion am ong t he developers. When you are working t hrough a use case t o see how classes will im plem ent it , the int eract ion diagram s in t his chapt er can be slow t o draw. Usually, you need t o consider alt ernat ives; wit h diagram s, t he alt ernat ives can t ake t oo long t o draw and rub out . Wit h CRC cards, you m odel t he int eract ion by picking up t he cards and m oving t hem around. This allows you t o quickly consider alt ernat ives. As you do t his, you form ideas about responsibilit ies and writ e them on the cards. Thinking about responsibilit ies is im port ant , because it get s you away from t he not ion of classes as dum b dat a holders and eases t he t eam m em bers t oward underst anding t he higher-level behavior of each class. A responsibilit y m ay correspond t o an operat ion, t o an at t ribut e, or, m ore likely, t o an undet erm ined clum p of at t ribut es and operat ions. A com m on m ist ake I see people m ake is generat ing long list s of low- level responsibilit ies. But doing so m isses t he point . The responsibilit ies should easily fit on one card. Ask yourself whet her the class should be split or whet her t he responsibilit ies would be bet t er 55/ 118

st at ed by rolling them up int o higher-level st at em ent s. Many people st ress t he im port ance of role playing, whereby each person on t he t eam plays t he role of one or m ore classes. I 've never seen Ward Cunningham do t hat , and I find t hat role playing get s in t he way. Books have been writ t en on CRC, but I 've found t hat they never really get t o t he heart of t he t echnique. The original paper on CRC, writ t en wit h Kent Beck, is [ Beck and Cunningham ] . To learn m ore about bot h CRC cards and responsibilit ies in design, t ake a look at [ Wirfs- Brock] .

Chapter 5. Class Diagrams: Advanced Concepts The concept s described in Chapt er 3 correspond t o t he key not at ions in class diagram s. Those concept s are t he first ones t o underst and and becom e fam iliar wit h, as t hey will com prise 90 percent of your effort in building class diagram s. The class diagram t echnique, however, has bred dozens of not at ions for addit ional concept s. I find t hat I don't use t hese all t he t im e, but t hey are handy when t hey are appropriat e. I 'll discuss t hem one at a t im e and point out som e of t he issues in using t hem . You'll probably find this chapt er som ewhat heavy going. The good news is t hat during your first pass t hrough t he book, you can safely skip t his chapt er and com e back t o it lat er.

Keywords One of t he challenges of a graphical language is t hat you have t o rem em ber what t he sym bols m ean. Wit h t oo m any, users find it very difficult t o rem em ber what all t he sym bols m ean. So t he UML oft en t ries t o reduce t he num ber of sym bols and use keywords inst ead. I f you find t hat you need a m odeling const ruct t hat isn't in t he UML but is sim ilar t o som et hing t hat is, use t he sym bol of t he exist ing UML const ruct but m ark it wit h a keyword t o show t hat you have som et hing different An exam ple of t his is t he int erface. A UML in te rfa ce ( page 69) is a class t hat has only public operat ions, wit h no m et hod bodies. This corresponds t o int erfaces in Java, COM ( Com ponent Obj ect Module) , and CORBA. Because it 's a special kind of class, it is shown using t he class icon wit h the keyword «interface». Keywords are usually shown as t ext bet ween guillem et s. As an alt ernat ive t o keywords, you can use special icons, but t hen you run int o t he issue of everyone having t o rem em ber what t hey m ean. Som e keywords, such as {abstract}, show up in curly bracket s. I t 's never really clear what should t echnically be in guillem et s and what should be in curlies. Fort unat ely, if you get it wrong, only serious UML weenies will not ice—or care. Som e keywords are so com m on that t hey oft en get abbreviat ed: «interface» oft en get s abbreviat ed t o «I» and {abstract} t o {A}. Such abbreviat ions are very useful, part icularly on whit eboards, but nonst andard, so if you use t hem , m ake sure you find a spot t o spell out what they m ean. I n UML 1, t he guillem et s were used m ainly for st e r e ot ypes. I n UML 2, st ereot ypes are defined very t ight ly, and describing what is and isn't a st ereot ype is beyond t he scope of t his book. However,

56/ 118

because of UML 1, m any people use t he t erm st ereot ype t o m ean t he sam e as keyword, alt hough t hat is no longer correct . St ereot ypes are used as part of profiles. A pr ofile t akes a part of t he UML and ext ends it wit h a coherent group of st ereot ypes for a particular purpose, such as business m odeling. The full sem ant ics of profiles are beyond this book. Unless you are int o serious m et a-m odel design, you're unlikely t o need t o creat e one yourself. You're m ore likely t o use one creat ed for a specific m odeling purpose, but fort unat ely, use of a profile doesn't require you t o know the gory det ails of how they are t ied int o t he m et a-m odel.

Classification and Generalization I oft en hear people t alk about subt yping as the is a relat ionship. I urge you t o beware of that way of t hinking. The problem is t hat t he phrase is a can m ean different things. Consider t he following phrases. 1. 2. 3. 4. 5.

Shep is a Border Collie. A Border Collie is a Dog. Dogs are Anim als. A Border Collie is a Breed. Dog is a Species.

Now t ry com bining t he phrases. I f I com bine phrases 1 and 2, I get " Shep is a Dog" ; 2 and 3 t aken t oget her yield " Border Collies are Anim als." And 1 plus 2 plus 3 gives m e "Shep is an Anim al." So far, so good. Now t ry 1 and 4: " Shep is a Breed." The com binat ion of 2 and 5 is " A Border Collie is a Species." These are not so good. Why can I com bine som e of t hese phrases and not ot hers? The reason is t hat som e are cla ssifica t ion—t he obj ect Shep is an inst ance of t he t ype Border Collie—and som e are ge n e r a liza t ion—t he t ype Border Collie is a subt ype of t he t ype Dog. Generalizat ion is t ransit ive; classificat ion is not . I can com bine a classificat ion followed by a generalizat ion but not vice versa. I m ake t his point t o get you t o be wary of is a. Using it can lead t o inappropriat e use of subclassing and confused responsibilit ies. Bet t er t est s for subt yping in t his case would be t he phrases " Dogs are kinds of Anim als" and " Every inst ance of a Border Collie is an inst ance of a Dog." The UML uses t he generalizat ion sym bol t o show generalizat ion. I f you need t o show classificat ion, use a dependency wit h t he «instantiate» keyword.

Multiple and Dynamic Classification Cla ssifica t ion refers t o t he relat ionship bet ween an obj ect and it s t ype. Mainst ream program m ing languages assum e t hat an obj ect belongs t o a single class. But there are m ore opt ions t o classificat ion t han t hat . I n sin gle cla ssifica t ion, an obj ect belongs t o a single t ype, which m ay inherit from supert ypes. I n m u lt iple cla ssifica t ion, an obj ect m ay be described by several t ypes t hat are not necessarily connect ed by inherit ance. Mult iple classificat ion is different from m ult iple inherit ance. Mult iple inherit ance says t hat a t ype m ay have m any supert ypes but t hat a single t ype m ust be defined for each obj ect . Mult iple classificat ion allows m ult iple t ypes for an obj ect wit hout defining a specific t ype for the purpose. 57/ 118

For exam ple, consider a person subt yped as eit her m an or wom an, doct or or nurse, pat ient or not ( see Figure 5.11) . Mult iple classificat ion allows an obj ect t o have any of t hese t ypes assigned t o it in any allowable com binat ion, wit hout t he need for t ypes t o be defined for all t he legal com binat ions.

Figu r e 5 .1 1 . M u lt iple cla ssifica t ion

I f you use m ult iple classificat ion, you need t o be sure t hat you m ake it clear which com binat ions are legal. UML 2 does t his by placing each generalizat ion relat ionship int o a ge n er a liza t ion se t. On t he class diagram , you label t he generalizat ion arrowhead wit h t he nam e of t he generalizat ion set , which in UML 1 was called t he discrim inat or. Single classificat ion corresponds t o a single generalizat ion set wit h no nam e. Generalizat ion set s are by default disj oint : Any inst ance of the supert ype m ay be an inst ance of only one of the subt ypes wit hin t hat set . I f you roll up generalizat ions int o a single arrow, t hey m ust all be part of t he sam e generalizat ion set , as shown in Figure 5.11. Alt ernat ively, you can have several arrows wit h t he sam e t ext label. To illust rat e, not e t he following legal com binat ions of subt ypes in t he diagram : ( Fem ale, Pat ient , Nurse) ; ( Male, Physiot herapist ) ; ( Fem ale, Pat ient ) ; and ( Fem ale, Doct or, Surgeon) . The com binat ion ( Pat ient , Doct or, Nurse) is illegal because it cont ains t wo t ypes from the role generalizat ion set . Anot her quest ion is whet her an obj ect m ay change it s class. For exam ple, when a bank account is overdrawn, it subst ant ially changes it s behavior. Specifically, several operat ions, including " wit hdraw" and " close," get overridden. D yn a m ic cla ssifica t ion allows obj ect s t o change class wit hin t he subt yping st ruct ure; sta t ic cla ssifica t ion does not . Wit h st at ic classificat ion, a separat ion is m ade bet ween t ypes and st at es; dynam ic classificat ion com bines these not ions. Should you use m ult iple, dynam ic classificat ion? I believe t hat it is useful for concept ual m odeling. For soft ware perspect ives, however, t he dist ance bet ween it and t he im plem ent at ions is t oo m uch of a leap. I n t he vast m aj orit y of UML diagram s, you'll see only single st at ic classificat ion, so t hat should be your default .

Association Class Associa t ion cla sse s allow you t o add at t ribut es, operat ions, and ot her feat ures t o associat ions, as shown in Figure 5.12. We can see from t he diagram t hat a person m ay at t end m any m eet ings. We 58/ 118

need t o keep inform at ion about how awake t hat person was; we can do t his by adding t he at t ribut e at t ent iveness t o t he associat ion.

Figu r e 5 .1 2 . Associa t ion cla ss

Figure 5.13 shows anot her way t o represent this inform at ion: Make At t endance a full class in it s own right . Not e how t he m ult iplicit ies have m oved.

Figu r e 5 .1 3 . Pr om ot in g a n a ssocia t ion cla ss t o a fu ll cla ss

What benefit do you gain wit h t he associat ion class t o offset the ext ra not at ion you have t o rem em ber? The associat ion class adds an ext ra const raint , in t hat there can be only one inst ance of t he associat ion class bet ween any t wo part icipat ing obj ect s. I feel t he need for anot her exam ple. Take a look at t he t wo diagram s in Figure 5.14. These diagram s have m uch t he sam e form . However, we can im agine one Com pany playing different roles in the sam e Cont ract , but it 's harder t o im agine a Person having m ult iple com pet encies in the sam e skill; indeed, you would probably consider that an error.

Figu r e 5 .1 4 . Associa t ion cla ss su bt le t ie s ( Role sh ou ld pr oba bly n ot be a n a ssocia t ion cla ss)

59/ 118

I n the UML, only t he lat t er case is legal. You can have only one com pet ency for each com binat ion of Person and Skill. The t op diagram in Figure 5.14 would not allow a Com pany t o have m ore t han one Role on a single cont ract . I f you need t o allow this, you need t o m ake Role a full class, in the st yle of Figure 5.13. I m plem ent ing associat ion classes isn't t erribly obvious. My advice is t o im plem ent an associat ion class as if it where a full class but t o provide m et hods t hat get inform at ion t o t he classes linked by t he associat ion class. So for Figure 5.12 , I would see the following m et hods on Person:

class Person List getAttendances() List getMeetings() This way, a client of Person can get hold of t he people at t he m eet ing; if t hey want det ails, t hey can get t he Att endances t hem selves. I f you do t his, rem em ber t o enforce t he const raint t hat t here can be only one At t endance obj ect for any pair of Person and Meet ing. You should place a check in whichever m et hod creat es the At t endance. You oft en find t his kind of const ruct wit h hist orical inform at ion, such as in Figure 5.15. However, I find t hat creat ing ext ra classes or associat ion classes can m ake t he m odel t ricky t o underst and, as well as t ilt t he im plem ent at ion in a part icular direct ion that 's oft en unsuit able.

Figu r e 5 .1 5 . Usin g a cla ss for a t e m por a l r e la t ion sh ip

I f I have this kind of t em poral inform at ion, I use a «temporal» keyword on t he associat ion ( see Figure 5.16) . The m odel indicat es t hat a Person m ay work for only a single Com pany at one t im e.

60/ 118

Over t im e, however, a Person m ay work for several Com panies. This suggest s an int erface along t he lines of:

Figu r e 5 .1 6 . «Temporal» k e yw or d for a ssocia t ion s

class Person ... Company getEmployer();//get current employer Company getEmployer(Date);//get employer at a given date void changeEmployer(Company newEmployer,Date changeDate); void leaveEmployer (Date changeDate); The «temporal» keyword is not part of t he UML, but I m ent ion it here for t wo reasons. First , it is a not ion I have found useful on several occasions in m y m odeling career. Second, it shows how you can use keywords t o ext end t he UML. You can read a lot m ore about this at h t t p:/ / m a r t in fow le r .com / a p2 / t im e N a r r a t ive .h t m l.

Template (Parameterized) Class Several languages, m ost not iceably C+ + , have the not ion of a pa ra m e t er ize d cla ss, or t e m pla t e. ( Tem plat es are on t he list t o be included in Java and C# in t he near fut ure.) This concept is m ost obviously useful for working wit h collect ions in a st rongly t yped language. This way, you can define behavior for set s in general by defining a t em plat e class Set.

class Set { void insert (T newElement); void remove (T anElement); When you have done t his, you can use t he general definit ion t o m ake Set classes for m ore specific elem ent s:

Set employeeSet; You declare a t em plat e class in t he UML by using t he not at ion shown in Figure 5.17. The T in the diagram is a placeholder for t he t ype param et er. ( You m ay have m ore t han one.)

Figu r e 5 .1 7 . Te m pla t e cla ss

A use of a param et erized class, such as Set, is called a de r iva t ion. You can show a derivat ion in t wo ways. The first way m irrors t he C+ + synt ax ( see Figure 5.18) . You describe t he derivat ion expression wit hin angle bracket s in t he form . I f 61/ 118

t here's only one param et er, convent ional use oft en om it s t he param et er nam e. The alt ernat ive not at ion ( see Figure 5.19 ) reinforces t he link t o t he t em plat e and allows you t o renam e t he bound elem ent .

Figu r e 5 .1 8 . Bou n d e le m e n t ( v e rsion 1 )

Figu r e 5 .1 9 . Bou n d e le m e n t ( v e rsion 2 )

The «bind» keyword is a st ereot ype on t he refinem ent relat ionship. This relat ionship indicat es t hat EmployeeSet will conform t o t he int erface of Set. You can t hink of t he EmployeeSet as a subt ype of Set. This fit s t he ot her way of im plem ent ing t ype- specific collect ions, which is t o declare all appropriat e subt ypes. Using a derivat ion is not t he sam e as subt yping, however. You are not allowed t o add feat ures to t he bound elem ent , which is com plet ely specified by it s t em plat e; you are adding only rest rict ing t ype inform at ion. I f you want t o add feat ures, you m ust creat e a subt ype.

Enumerations Enum erat ions ( Figure 5.20) are used t o show a fixed set of values t hat don't have any propert ies ot her t han t heir sym bolic value. They are shown as t he class wit h t he «enumeration» keyword.

Figu r e 5 .2 0 . En um e r a t ion

62/ 118

Active Class An a ct ive class has inst ances, each of which execut es and cont rols it s own thread of cont rol. Met hod invocat ions m ay execut e in a client 's t hread or in the active obj ect 's thread. A good exam ple of t his is a com m and processor t hat accept s com m and obj ect s from t he out side and then execut es t he com m ands wit hin it s own t hread of cont rol. The not at ion for act ive classes has changed from UML 1 t o UML 2, as shown in Figure 5.21. I n UML 2, an act ive class has ext ra vertical lines on t he side; in UML 1, it had a t hick border and was called an act ive obj ect .

Figu r e 5 .2 1 . Act iv e cla ss

Visibility Visibilit y is a subj ect t hat is sim ple in principle but has com plex subt let ies. The sim ple idea is that any class has public and privat e elem ent s. Public elem ent s can be used by any ot her class; privat e elem ent s can be used only by t he owning class. However, each language m akes it s own rules. Alt hough m any languages use such t erm s as public, privat e, and prot ect ed, t hey m ean different t hings in different languages. These differences are sm all, but they lead t o confusion, especially for t hose of us who use m ore t han one language. The UML t ries t o address this wit hout get t ing int o a horrible t angle. Essent ially, wit hin t he UML, you can t ag any at t ribut e or operat ion wit h a visibilit y indicat or. You can use any m arker you like, and it s m eaning is language dependent . However, t he UML provides four abbreviat ions for visibilit y: + ( public) , – ( privat e) , ~ ( package) , and # ( prot ect ed) . These four levels are used wit hin t he UML m et a-m odel and are defined wit hin it , but t heir definit ions vary subt ly from t hose in ot her languages. When you are using visibilit y, use t he rules of t he language in which you are working. When you are looking at a UML m odel from elsewhere, be wary of t he m eanings of the visibilit y m arkers, and be aware of how t hose m eanings can change from language t o language.

63/ 118

Most of t he t im e, I don't draw visibilit y m arkers in diagram s; I use t hem only if I need t o highlight t he differences in visibilit y of cert ain feat ures. Even t hen, I can m ost ly get away wit h + and –, which at least are easy t o rem em ber.

Messages St andard UML does not show any inform at ion about m essage calls on class diagram s. However, I 've som et im es seen convent ional diagram s like Figure 5.22 .

Figu r e 5 .2 2 . Cla sse s w it h m e ssa ge s

These add arrows t o t he sides of associat ions. The arrows are labeled wit h t he m essages that one obj ect sends t o anot her. Because you don't need an associat ion t o a class t o send a m essage t o it , you m ay also need t o add a dependency arrow to show m essages bet ween classes that aren't associat ed. This m essage inform at ion spans m ult iple use cases, so t hey aren't num bered t o show sequences, unlike com m unicat ion diagram s.

Responsibilities Oft en, it 's handy t o show responsibilit ies ( page 63) on a class in a class diagram . The best way t o show t hem is as com m ent st rings in t heir own com part m ent in t he class ( Figure 5.1) . You can nam e t he com partm ent , if you wish, but I usually don't , as there's rarely any pot ent ial for confusion.

Figu r e 5 .1 . Sh ow in g r espon sibilit ie s in a cla ss dia gr a m

64/ 118

Static Operations and Attributes The UML refers t o an operat ion or an at t ribut e that applies t o a class rat her t han t o an inst ance as st a t ic. This is equivalent t o st at ic m em bers in C- based languages. St at ic feat ures are underlined on a class diagram ( see Figure 5.2 ) .

Figu r e 5 .2 . St a t ic n ot a t ion

Aggregation and Composition One of t he m ost frequent sources of confusion in t he UML is aggregat ion and com posit ion. I t 's easy t o explain glibly: Aggr e ga t ion is t he part - of relat ionship. I t 's like saying t hat a car has an engine and wheels as it s part s. This sounds good, but the difficult thing is considering what t he difference is bet ween aggregat ion and associat ion. I n the pre- UML days, people were usually rat her vague on what was aggregat ion and what was associat ion. Whet her vague or not , they were always inconsist ent wit h everyone else. As a result , m any m odelers t hink t hat aggregat ion is im port ant , alt hough for different reasons. So t he UML included aggregat ion ( Figure 5.3 ) but wit h hardly any sem ant ics. As Jim Rum baugh says, " Think of it as a m odeling placebo" [ Rum baugh, UML Reference] .

Figu r e 5 .3 . Aggr e ga t ion

65/ 118

As well as aggregat ion, t he UML has t he m ore defined propert y of com posit ion . I n Figure 5.4 , an inst ance of Point m ay be part of a polygon or m ay be t he cent er of a circle, but it cannot be bot h. The general rule is t hat , alt hough a class m ay be a com ponent of m any ot her classes, any inst ance m ust be a com ponent of only one owner. The class diagram m ay show m ult iple classes of pot ent ial owners, but any inst ance has only a single obj ect as it s owner.

Figu r e 5 .4 . Com posit ion

You'll not e that I don't show t he reverse m ult iplicit ies in Figure 5.4. I n m ost cases, as here, it 's 0..1. I t s only ot her possible value is 1, for cases in which the com ponent class is designed so t hat it can have only one ot her class as it s owner. The " no sharing" rule is t he key t o com posit ion. Anot her assum pt ion is t hat if you delet e t he polygon, it should aut om at ically ensure t hat any owned Point s also are delet ed. Com posit ion is a good way of showing propert ies t hat own by value, properties t o value obj ect s ( page 73) , or propert ies t hat have a st rong and som ewhat exclusive ownership of part icular ot her com ponent s. Aggregat ion is st rict ly m eaningless; as a result , I recom m end that you ignore it in your own diagram s. I f you see it in ot her people's diagram s, you'll need t o dig deeper t o find out what t hey m ean by it . Different aut hors and t eam s use it for very different purposes.

Derived Properties D e r ive d pr oper t ie s can be calculat ed based on ot her values. When we think about a dat e range ( Figure 5.5) , we can t hink of t hree propert ies: the st art dat e, t he end dat e, and t he num ber of days in t he period. These values are linked, so we can t hink of t he lengt h as being derived from t he ot her t wo values.

Figu r e 5 .5 . D e r iv e d a t t r ibu t e in a t im e pe r iod

Derivat ion in soft ware perspectives can be int erpret ed in a couple of different ways. You can use derivat ion t o indicat e t he difference bet ween a calculat ed value and a st ored value. I n this case, we would int erpret Figure 5.5 as indicat ing t hat t he st art and end are st ored but t hat t he lengt h is com put ed. Alt hough t his is a com m on use, I 'm not so keen, because it reveals t oo m uch of the int ernals of DateRange. My preferred t hinking is t hat it indicat es a const raint bet ween values. I n t his case, we are saying t hat t he const raint am ong t he t hree values holds, but it isn't im port ant which of t he t hree values is com put ed. I n t his case, t he choice of which at t ribut e t o m ark as derived is arbit rary and st rict ly unnecessary, but it 's useful t o help rem ind people of t he const raint . This usage also m akes sense wit h concept ual diagram s.

66/ 118

Derivat ion can also be applied t o propert ies using associat ion not at ion. I n this case, you sim ply m ark the nam e wit h a / .

Interfaces and Abstract Classes An a bst r act cla ss is a class t hat cannot be direct ly inst ant iat ed. I nst ead, you inst ant iat e an inst ance of a subclass. Typically, an abst ract class has one or m ore operat ions t hat are abst ract . An a bst r a ct ope r a t ion has no im plem ent at ion; it is pure declarat ion so t hat client s can bind t o t he abst ract class. The m ost com m on way t o indicat e an abst ract class or operat ion in t he UML is t o it alicize t he nam e. You can also m ake propert ies abst ract , indicat ing an abst ract propert y or accessor m et hods. I t alics are t ricky t o do on a whit eboards, so you can use t he label: {abstract}. An int erface is a class t hat has no im plem ent at ion; t hat is, all it s feat ures are abst ract . I nt erfaces correspond direct ly t o int erfaces in C# and Java and are a com m on idiom in ot her t yped languages. You m ark an int erface wit h t he keyword «interface». Classes have t wo kinds of relat ionships wit h int erfaces: providing and requiring. A class provides a n in t e r fa ce if it is subst it ut able for t he int erface. I n Java and .NET, a class can do t hat by im plem ent ing the int erface or im plem ent ing a subt ype of t he int erface. I n C+ + , you subclass t he class t hat is t he int erface. A class r e qu ir e s a n in te r face if it needs an inst ance of that int erface in order t o work. Essent ially, t his is having a dependency on t he int erface. Figure 5.6 shows these relat ionships in act ion, based on a few collect ion classes from Java. I m ight writ e an Order class t hat has a list of line it em s. Because I 'm using a list , t he Order class is dependent on t he List int erface. Let 's assum e that it uses t he m et hods equals, add, and get. When t he obj ect s connect , t he Order will actually use an inst ance of ArrayList but need not know t hat in order t o use t hose three m et hods, as t hey are all part of t he List int erface.

Figu r e 5 .6 . A Ja v a e x a m ple of in t e r f a ce s a n d a n a bst r a ct cla ss

67/ 118

The ArrayList it self is a subclass of the AbstractList class. AbstractList provides som e, but not all, the im plem ent at ion of t he List behavior. I n part icular, the get m et hod is abst ract . As a result , ArrayList im plem ent s get but also overrides som e of t he ot her operat ions on AbstractList. I n t his case, it overrides add but is happy t o inherit t he im plem ent at ion of equals. Why don't I sim ply avoid t his and have Order use ArrayList direct ly? By using t he int erface, I allow m yself t he advant age of m aking it easier t o change im plem ent at ions lat er on if I need t o. Anot her im plem ent at ion m ay provide perform ance im provem ent s, som e dat abase int eract ion feat ures, or ot her benefit s. By program m ing t o t he int erface rat her t han t o t he im plem ent at ion, I avoid having t o change all t he code should I need a different im plem ent at ion of List. You should always t ry t o program t o an int erface like t his; always use the m ost general t ype you can. I should also point out a pragm at ic wrinkle in this. When program m ers use a collect ion like t his, t hey usually init ialize t he collect ion wit h a declarat ion, like t his:

private List lineItems = new ArrayList(); Not e t hat t his st rict ly int roduces a dependency from Order t o t he concret e ArrayList. I n t heory, t his is a problem , but people don't worry about it in pract ice. Because t he t ype of lineItems is declared as List, no ot her part of t he Order class is dependent on ArrayList. Should we change t he im plem ent at ion, t here's only t his one line of init ializat ion code t hat we need t o worry about . I t 's quit e com m on t o refer t o a concret e class once during creat ion but t o use only the int erface aft erward. The full not at ion of Figure 5.6 is one way t o not at e int erfaces. Figure 5.7 shows a m ore com pact not at ion. The fact t hat ArrayList im plem ent s List and Collection is shown by having ball icons, oft en referred t o as lollipops, out of it . The fact that Order requires a List int erface is shown by t he socket icon. The connection is nicely obvious.

Figu r e 5 .7 . Ba ll- a n d- sock e t n ot a t ion 68/ 118

The UML has used t he lollipop not at ion for a while, but t he socket not at ion is new t o UML 2. (I think it 's m y favorit e not at ional addit ion.) You'll probably see older diagram s use t he st yle of Figure 5.8 , where a dependency st ands in for t he socket not at ion.

Figu r e 5 .8 . Olde r de pe n de n cie s w it h lollipops

Any class is a m ix of an int erface and an im plem ent at ion. Therefore, we m ay oft en see an obj ect used t hrough the int erface of one of it s superclasses. St rictly, it wouldn't be legal t o use the lollipop not at ion for a superclass, as the superclass is a class, not a pure int erface. But I bend t hese rules for clarit y. As well as on class diagram s, people have found lollipops useful elsewhere. One of t he perennial problem s wit h int eraction diagram s is that t hey don't provide a very good visualizat ion for polym orphic behavior. Alt hough it 's not norm at ive usage, you can indicat e t his along the lines of Figure 5.9. Here, we can see that , alt hough we have an inst ance of Salesm an, which is used as such by t he Bonus Calculat or, t he Pay Period obj ect uses t he Salesm an only t hrough it s Em ployee int erface. (You can do t he sam e t rick wit h com m unicat ion diagram s.)

Figu r e 5 .9 . Usin g a lollipop t o sh ow poly m or ph ism in a se qu e n ce dia gr a m

69/ 118

Read-Only and Frozen On page 37, I described t he {readOnly} keyword. You use t his keyword t o m ark a propert y that can only be read by client s and t hat cannot be updat ed. Sim ilar yet different is t he {frozen} keyword from UML 1. A propert y is fr oze n if it cannot change during t he lifet im e of an obj ect ; such propert ies are oft en called im m ut able. Alt hough it was dropped from UML 2, {frozen} is a very useful concept , so I would cont inue t o use it . As well as m arking individual propert ies as frozen, you can apply t he keyword t o a class t o indicat e t hat all propert ies of all inst ances are frozen. (I have heard that frozen m ay well be reinst at ed short ly.)

Reference Objects and Value Objects One of t he com m on t hings said about obj ect s is t hat t hey have ident it y. This is t rue, but it is not quit e as sim ple as t hat . I n pract ice, you find t hat ident it y is im port ant for reference obj ect s but not so im port ant for value obj ect s. Re fer e nce obj e cts are such t hings as Cust om er. Here, ident it y is very im port ant because you usually want only one soft ware obj ect t o designat e a cust om er in t he real world. Any obj ect t hat references a Cust om er obj ect will do so t hrough a reference, or point er; all obj ect s t hat reference t his Cust om er will reference t he sam e soft ware obj ect . That way, changes t o a Cust om er are available t o all users of t he Cust om er. I f you have t wo references t o a Cust om er and wish t o see whet her t hey are t he sam e, you usually com pare t heir ident it ies. Copies m ay be disallowed; if t hey are allowed, t hey t end t o be m ade rarely, perhaps for archive purposes or for replicat ion across a net work. I f copies are m ade, you need to sort out how t o synchronize changes. Va lu e obj ect s are such things as Dat e. You oft en have m ult iple value obj ect s represent ing t he sam e obj ect in t he real world. For exam ple, it is norm al t o have hundreds of obj ect s t hat designat e 1- Jan-04. These are all int erchangeable copies. New dat es are creat ed and dest royed frequent ly.

70/ 118

I f you have t wo dat es and wish t o see whet her t hey are t he sam e, you don't look at t heir ident it ies but rat her at t he values t hey represent . This usually m eans that you have t o writ e an equalit y t est operat or, which for dat es would m ake a t est on year, m ont h, and day—or what ever t he int ernal represent at ion is. Each obj ect t hat references 1-Jan- 04 usually has it s own dedicat ed obj ect , but you can also share dat es. Value obj ect s should be im m ut able; in ot her words, you should not be able t o t ake a dat e obj ect of 1- Jan-04 and change t he sam e dat e obj ect t o be 2- Jan- 04. I nst ead, you should creat e a new 2-Jan04 obj ect and use t hat inst ead. The reason is that if t he dat e were shared, you would updat e anot her obj ect 's dat e in an unpredict able way, a problem referred t o as a lia sin g. I n days gone by, t he difference bet ween reference obj ect s and value obj ect s was clearer. Value obj ect s were t he built -in values of t he t ype syst em . Now you can ext end the t ype syst em wit h your own classes, so t his issue requires m ore t hought . The UML uses t he concept of da t a t ype, which is shown as a keyword on t he class sym bol. St rict ly, dat a t ype isn't t he sam e as value obj ect , as dat a t ypes can't have ident it y. Value obj ect s m ay have an ident it y, but don't use it for equalit y. Prim it ives in Java would be dat a t ypes, but dat es would not , alt hough t hey would be value obj ect s. I f it 's im port ant t o highlight t hem , I use com posit ion when associat ing wit h a value obj ect . You can also use a keyword on a value t ype; com m on convent ional ones I see are «value» or «struct».

Qualified Associations A qu a lifie d a ssocia t ion is t he UML equivalent of a program m ing concept variously known as associat ive arrays, m aps, hashes, and dict ionaries. Figure 5.10 shows a way t hat uses a qualifier t o represent t he associat ion bet ween t he Order and Order Line classes. The qualifier says t hat in connect ion wit h an Order, t here m ay be one Order Line for each inst ance of Product .

Figu r e 5 .1 0 . Qu a lifie d a ssocia t ion

From a soft ware perspect ive, t his qualified associat ion would im ply an int erface along t he lines of

class Order ... public OrderLine getLineItem(Product aProduct); public void addLineItem(Number amount, Product forProduct); Thus, all access t o a given Order Line requires a Product as an argum ent , suggest ing an im plem ent at ion using a key and value dat a st ruct ure. I t 's com m on for people t o get confused about t he m ult iplicit ies of a qualified associat ion. I n Figure 5.10, an Order m ay have m any Line I t em s, but t he m ult iplicit y of the qualified associat ion is t he m ult iplicit y in t he cont ext of t he qualifier. So t he diagram says that an Order has 0..1 Line I t em s per Product . A m ult iplicit y of 1 would indicat e that Order would have t o have a Line I t em for every inst ance of Product . A * would indicat e t hat you would have m ult iple Line I t em s per Product but t hat access t o t he Line I t em s is indexed by Product . I n concept ual m odeling, I use the qualifier const ruct only t o show const raint s along t he lines of " single Order Line per Product on Order."

71/ 118

Chapter 6. Object Diagrams An obj ect dia gr a m is a snapshot of t he obj ect s in a syst em at a point in tim e. Because it shows inst ances rat her t han classes, an obj ect diagram is oft en called an inst ance diagram . You can use an obj ect diagram t o show an exam ple configurat ion of obj ect s. ( See Figure 6.1, which shows a set of classes, and Figure 6.2, which shows an associat ed set of obj ect s.) This lat t er use is very useful when t he possible connect ions bet ween obj ect s are com plicat ed.

Figu r e 6 .1 . Cla ss dia gr a m of Pa r t y com posit ion st r u ct u r e

Figu r e 6 .2 . Obj e ct dia gr a m sh ow in g e x a m ple in st a n ce s of Pa r t y

You can t ell t hat t he elem ent s in Figure 6.2 are inst ances because t he nam es are underlined. Each nam e t akes the form instance name : class name. Bot h part s of t he nam e are opt ional, so John, :Person, and aPerson are legal nam es. I f you use only the class nam e, you m ust include t he colon. You can show values for at t ribut es and links, as in Figure 6.2. St rict ly, t he elem ent s of an obj ect diagram are inst ance specificat ions rat her t han t rue inst ances. The reason is t hat it 's legal t o leave m andat ory at t ribut es em pt y or t o show inst ance specificat ions of abst ract classes. You can t hink of an in st an ce spe cifica t ion as a part ly defined inst ance. Anot her way of looking at an obj ect diagram is as a com m unicat ion diagram ( page 131) wit hout m essages.

When to Use Object Diagrams 72/ 118

Obj ect diagram s are useful for showing exam ples of obj ect s connect ed t oget her. I n m any sit uat ions, you can define a st ruct ure precisely wit h a class diagram , but t he st ruct ure is still difficult t o underst and. I n t hese sit uat ions, a couple of obj ect diagram exam ples can m ake all the difference.

Chapter 7. Package Diagrams Classes represent t he basic form of st ruct uring an obj ect - orient ed syst em . Alt hough t hey are wonderfully useful, you need som et hing m ore t o st ructure large syst em s, which m ay have hundreds of classes. A pa cka ge is a grouping const ruct t hat allows you t o t ake any const ruct in the UML and group it s elem ent s t oget her int o higher-level unit s. I t s m ost com m on use is t o group classes, and t hat 's the way I 'm describing it here, but rem em ber t hat you can use packages for every ot her bit of t he UML as well. I n a UML m odel, each class is a m em ber of a single package. Packages can also be m em bers of ot her packages, so you are left wit h a hierarchic st ructure in which t op- level packages get broken down int o subpackages wit h t heir own subpackages and so on unt il the hierarchy bot t om s out in classes. A package can cont ain bot h subpackages and classes. I n program m ing t erm s, packages correspond t o such grouping const ruct s as packages ( in Java) and nam espaces ( in C+ + and .NET) . Each package represent s a n a m espa ce , which m eans t hat every class m ust have a unique nam e wit hin it s owning package. I f I want t o creat e a class called Dat e, and a Dat e class is already in t he Syst em package, I can have m y Dat e class as long as I put it in a separat e package. To m ake it clear which is which, I can use a fu lly qu a lifie d n a m e, t hat is, a nam e t hat shows t he owning package st ruct ure. You use double colons t o show package nam es in UML, so t he dat es m ight be System::Date and MartinFowler::Util::Date. I n diagram s, packages are shown wit h a t abbed folder, as in Figure 7.1. You can sim ply show t he package nam e or show t he cont ent s t oo. At any point , you can use fully qualified nam es or sim ply regular nam es. Showing the cont ent s wit h class icons allows you t o show all the det ails of a class, even t o t he point of showing a class diagram wit hin t he package. Sim ply list ing t he nam es m akes sense when all you want t o do is indicat e which classes are in which packages.

Figu r e 7 .1 . W a y s of sh ow in g pa ck a ge s on dia gr a m s

73/ 118

I t 's quit e com m on t o see a class labeled som et hing like Date (from java.util) rat her t han the fully qualified form . This st yle is a convent ion t hat was done a lot by Rat ional Rose; it isn't part of t he st andard. The UML allows classes in a package t o be public or privat e. A public class is part of t he int erface of t he package and can be used by classes in ot her packages; a privat e class is hidden. Different program m ing environm ent s have different rules about visibilit y bet ween t heir packaging const ruct s; you should follow t he convent ion of your program m ing environm ent , even if it m eans bending t he UML's rules. A useful t echnique here is t o reduce the int erface of t he package by export ing only a sm all subset of t he operat ions associat ed wit h the package's public classes. You can do t his by giving all classes privat e visibilit y, so t hat they can be seen only by ot her classes in t he sam e package, and by adding ext ra public classes for t he public behavior. These ext ra classes, called Facades [ Gang of Four] , t hen delegat e public operat ions t o t heir shyer com panions in t he package. How do you choose which classes t o put in which packages? This is actually quit e an involved quest ion t hat needs a good bit of design skill t o answer. Two useful principles are t he Com m on Closure Principle and Com m on Reuse Principle [ Mart in] . The Com m on Closure Principle says that t he classes in a package should need changing for sim ilar reasons. The Com m on Reuse Principle says t hat classes in a package should all be reused t oget her. Many of t he reasons for grouping classes in packages have t o do wit h t he dependencies bet ween t he packages, which I 'll com e t o next .

Packages and Dependencies A pa cka ge dia gr a m shows packages and t heir dependencies. I int roduced t he concept of dependency on page 47. I f you have packages for present at ion and dom ain, you have a dependency from t he present at ion package t o t he dom ain package if any class in t he present at ion package has a dependency t o any class in t he dom ain package. I n t his way, int erpackage dependencies sum m arize t he dependencies bet ween their cont ent s. The UML has m any variet ies of dependency, each wit h part icular sem ant ics and st ereot ype. I find it easier t o begin wit h the unst ereot yped dependency and use t he m ore part icular dependencies only if I need t o, which I hardly ever do.

74/ 118

I n a m edium t o large syst em , plot t ing a package diagram can be one of the m ost valuable t hings you can do t o cont rol t he large- scale st ruct ure of t he syst em . I deally, t his diagram should be generat ed from t he code base it self, so t hat you can see what is really t here in t he syst em . A good package st ruct ure has a clear flow t o t he dependencies, a concept that 's difficult t o define but oft en easier t o recognize. Figure 7.2 shows a sam ple package diagram for an ent erprise applicat ion, one t hat is well- st ruct ured and has a clear flow.

Figu r e 7 .2 . Pa ck a ge dia gr a m for a n e n t e r pr ise a pplica t ion

Oft en, you can ident ify a clear flow because all the dependencies run in a single direct ion. Alt hough t hat is a good indicat or of a well- st ruct ured syst em , t he dat a m apper packages of Figure 7.2 show an except ion t o t hat rule of t hum b. The dat a m apper packages act as an insulat ing layer bet ween t he dom ain and dat abase packages, an exam ple of t he Mapper pat t ern [ Fowler, P of EAA] . Many aut hors say t hat t here should be no cycles in t he dependencies (t he Acyclic Dependency Principle [ Martin] ) . I don't t reat t hat as an absolut e rule, but I do t hink t hat cycles should be localized and that , in part icular, you shouldn't have cycles t hat cross layers. The m ore dependencies com ing int o a package, t he m ore st able t he package's int erface needs t o be, as any change in it s int erface will ripple int o all the packages t hat are dependent on it ( t he St able Dependencies Principle [ Mart in] ) . So in Figure 7.2 , t he asset dom ain package needs a m ore st able int erface than t he leasing dat a m apper package. Oft en, you'll find that t he m ore st able packages t end t o have a higher proport ion of int erfaces and abst ract classes ( t he St able Abst ract ions Principle [ Mart in] . The dependency relat ionships are not t ransit ive ( page 48) . To see why t his is im port ant for dependencies, look at Figure 7.2 again. I f a class in t he asset dom ain package changes, we m ay have a change t o classes wit hin t he leasing dom ain package. But t his change does not necessarily ripple t hrough t o t he leasing present at ion. ( I t ripples only if the leasing dom ain changes it s int erface.) 75/ 118

Som e packages are used in so m any places that it would be a m ess t o draw all t he dependency lines t o t hem . I n t his case, a convent ion is t o use a keyword, such as «global», on the package. UML packages also define const ruct s t o allow packages t o im port and m erge classes from one package int o anot her, using dependencies wit h keywords t o not at e t his. However, rules for t his kind of t hing vary great ly wit h program m ing languages. On t he whole, I find t he general not ion of dependencies t o be far m ore useful in pract ice.

Package Aspects I f you t hink about Figure 7.2 , you'll realize t hat t he diagram has t wo kinds of st ruct ures. One is a st ruct ure of layers in t he applicat ion: present at ion, dom ain, dat a m apper, and dat abase. The ot her is a st ruct ure of subj ect areas: leasing and asset s. You can m ake t his m ore apparent by separat ing t he t wo aspect s, as in Figure 7.3 . Wit h t his diagram , you can clearly see each aspect . However, t hese t wo aspect s aren't t rue packages, because you can't assign classes t o a single package. ( You would have t o pick one from each aspect .) This problem m irrors t he problem in the hierarchic nam espaces in program m ing languages. Alt hough diagram s like Figure 7.3 are nonst andard UML, t hey are oft en very helpful in explaining t he st ruct ure of a com plex applicat ion.

Figu r e 7 .3 . Se pa r a t in g Figur e 7 .2 int o t w o a spe ct s

Implementing Packages Oft en, you'll see a case in which one package defines an int erface t hat can be im plem ent ed by a num ber of ot her packages, such as t hat of Figure 7.4. I n t his case, the realizat ion relat ionship indicat es t hat t he dat abase gat eway defines an int erface and t hat t he ot her gat eway classes provide an im plem ent at ion. I n practice, t his would m ean t hat the dat abase gat eway package cont ains int erfaces and abst ract classes t hat are fully im plem ent ed by t he ot her packages. 76/ 118

Figu r e 7 .4 . A pa ck a ge im ple m e n t e d by ot h e r pa ck a ge s

I t 's quit e com m on for an int erface and it s im plem ent at ion t o be in separat e packages. I ndeed, a client package oft en cont ains an int erface for anot her package t o im plem ent : t he sam e not ion of required int erface t hat I discussed on page 70. I m agine t hat we want t o provide som e user int erface (UI ) cont rols t o t urn things on and off. We want this t o work wit h a lot of different t hings, such as heat ers and light s. The UI cont rols need t o invoke m et hods on t he heat er, but we don't want t he cont rols t o have a dependency t o t he heat er. We can avoid t his dependency by defining in t he cont rols package an int erface that is t hen im plem ent ed by any class t hat want s t o work wit h t hese cont rols, as in Figure 7.5. This is an exam ple of t he pat t ern Separat ed I nt erface [ Fowler, P of EAA] .

Figu r e 7 .5 . D e fin in g a r e qu ir e d in t e rfa ce in a clie n t pa ck a ge

When to Use Package Diagrams 77/ 118

I find package diagram s ext rem ely useful on larger- scale syst em s t o get a pict ure of the dependencies bet ween m aj or elem ent s of a system . These diagram s correspond well t o com m on program m ing st ruct ures. Plot t ing diagram s of packages and dependencies helps you keep an applicat ion's dependencies under cont rol. Package diagram s represent a com pile-t im e grouping m echanism . For showing how obj ect s are com posed at runt im e, use a com posit e st ruct ure diagram ( page 135) .

Where to Find Out More The best discussion I know of packages and how t o use them is [ Mart in] . Robert Martin has long had an alm ost pat hological obsession wit h dependencies and writ es well about how t o pay at t ent ion t o dependencies so t hat you can cont rol and m inim ize t hem .

Chapter 8. Deployment Diagrams Deploym ent diagram s show a syst em 's physical layout , revealing which pieces of soft ware run on what pieces of hardware. Deploym ent diagram s are really very sim ple; hence t he short chapt er. Figure 8.1 is a sim ple exam ple of a deploym ent diagram . The m ain it em s on t he diagram are nodes connect ed by com m unicat ion pat hs. A n ode is som et hing t hat can host som e soft ware. Nodes com e in t wo form s. A de vice is hardware, it m ay be a com put er or a sim pler piece of hardware connect ed t o a syst em . An e xe cut ion e n viron m en t is soft ware t hat it self host s or cont ains ot her soft ware, exam ples are an operat ing syst em or a cont ainer process.

Figu r e 8 .1 . Ex a m ple de ploy m e n t dia gr a m

78/ 118

The nodes cont ain a r t ifact s, which are the physical m anifest at ions of soft ware: usually, files. These files m ight be execut ables (such as .exe files, binaries, DLLs, JAR files, assem blies, or script s) , or dat a files, configurat ion files, HTML docum ent s, and so on. List ing an art ifact wit hin a node shows t hat t he art ifact is deployed t o t hat node in t he running syst em . You can show artifact s eit her as class boxes or by list ing the nam e wit hin a node. I f you show t hem as class boxes, you can add a docum ent icon or t he «artifact» keyword. You can t ag nodes or art ifact s wit h t agged values t o indicat e various int erest ing inform at ion about the node, such as vendor, operat ing syst em , locat ion, or anyt hing else t hat t akes your fancy. Oft en, you'll have m ult iple physical nodes carrying out the sam e logical t ask. You can eit her show t his wit h m ult iple node boxes or st at e t he num ber as a t agged value. I n Figure 8.1, I used t he t ag number deployed t o indicat e t hree physical Web servers, but t here's no st andard t ag for t his. Art ifact s are oft en the im plem ent at ion of a com ponent . To show this, you can use a t agged value in t he art ifact box. Com m unicat ion pat hs bet ween nodes indicat e how t hings com m unicat e. You can label t hese pat hs wit h inform at ion about t he com m unicat ion prot ocols t hat are used.

When to Use Deployment Diagrams Don't let t he brevit y of t his chapt er m ake you t hink t hat deploym ent diagram s shouldn't be used. They are very handy in showing what is deployed where, so any nont rivial deploym ent can m ake good use of t hem .

Chapter 9. Use Cases Use cases are a t echnique for capt uring t he funct ional requirem ent s of a syst em . Use cases work by describing t he t ypical int eract ions bet ween the users of a syst em and t he syst em it self, providing a narrat ive of how a syst em is used. Rat her t han describe use cases head- on, I find it easier t o sneak up on t hem from behind and start by describing scenarios. A scen a r io is a sequence of st eps describing an int eract ion bet ween a user and a syst em . So if we have a Web- based on-line st ore, we m ight have a Buy a Product scenario t hat would say this: The cust om er browses t he cat alog and adds desired it em s t o t he shopping basket . When t he cust om er wishes t o pay, t he cust om er describes t he shipping and credit card inform at ion and confirm s t he sale. The system checks t he aut horizat ion on the credit card and confirm s t he sale bot h im m ediat ely and wit h a follow- up e-m ail . This scenario is one t hing that can happen. However, t he credit card aut horizat ion m ight fail, and t his would be a separat e scenario. I n anot her case, you m ay have a regular cust om er for whom you don't need t o capt ure the shipping and credit card inform at ion, and this is a t hird scenario. All t hese scenarios are different yet sim ilar. The essence of t heir sim ilarit y is t hat in all these t hree scenarios, the user has t he sam e goal: t o buy a product . The user doesn't always succeed, but t he goal rem ains. This user goal is t he key t o use cases: A use case is a set of scenarios tied t oget her by a com m on user goal. I n use case–speak, t he users are referred t o as act ors. An a ctor is a role t hat a user plays wit h respect t o t he syst em . Act ors m ight include custom er, cust om er service rep, sales m anager, and 79/ 118

product analyst . Act ors carry out use cases. A single act or m ay perform m any use cases; conversely, a use case m ay have several act ors perform ing it . Usually, you have m any cust om ers, so m any people can be t he cust om er act or. Also, one person m ay act as m ore than one act or, such as a sales m anager who does cust om er service rep t asks. An act or doesn't have t o be hum an. I f t he syst em perform s a service for anot her com put er syst em , t hat ot her syst em is an act or. Act or isn't really t he right t erm ; role would be m uch bet t er. Apparent ly, t here was a m ist ranslat ion from Swedish, and act or is t he t erm the use case com m unit y uses. Use cases are well known as an im port ant part of t he UML. However, t he surprise is t hat in m any ways, t he definit ion of use cases in t he UML is rat her sparse. Not hing in t he UML describes how you should capt ure t he cont ent of a use case. What t he UML describes is a use case diagram , which shows how use cases relat e t o each ot her. But alm ost all the value of use cases lies in t he cont ent , and t he diagram is of rat her lim it ed value.

Content of a Use Case There is no st andard way t o writ e t he cont ent of a use case, and different form at s work well in different cases. Figure 9.1 shows a com m on st yle t o use. You begin by picking one of the scenarios as t he m a in su ccess sce n a r io. You st art t he body of t he use case by writ ing t he m ain success scenario as a sequence of num bered st eps. You t hen t ake t he ot her scenarios and writ e t hem as e x t e n sion s, describing t hem in t erm s of variat ions on t he m ain success scenario. Ext ensions can be successes—user achieves t he goal, as in 3a—or failures, as in 6a.

Figu r e 9 .1 . Ex a m ple u se ca se t e x t

Each use case has a prim ary act or, which calls on t he syst em t o deliver a service. The prim ary act or is t he act or wit h t he goal t he use case is t rying t o sat isfy and is usually, but not always, the init iat or of t he use case. There m ay be ot her act ors as well wit h which t he syst em com m unicat es while carrying out t he use case. These are known as secondary act ors. Each st ep in a use case is an elem ent of t he int eract ion bet ween an act or and t he syst em . Each st ep should be a sim ple st at em ent and should clearly show who is carrying out t he st ep. The st ep should show t he int ent of t he act or, not t he m echanics of what t he act or does. Consequent ly, you don't describe t he user int erface in t he use case. I ndeed, writ ing the use case usually precedes designing t he user int erface. 80/ 118

An ext ension wit hin t he use case nam es a condit ion t hat result s in different int eract ions from t hose described in t he m ain success scenario ( MSS) and st at es what t hose differences are. St art t he ext ension by nam ing t he st ep at which the condit ion is det ect ed and provide a short descript ion of t he condit ion. Follow t he condit ion wit h num bered st eps in t he sam e st yle as t he m ain success scenario. Finish t hese st eps by describing where you ret urn t o t he m ain success scenario, if you do. The use case st ruct ure is a great way t o brainstorm alt ernat ives t o t he m ain success scenario. For each st ep, ask, How could t his go different ly? and in part icular, What could go wrong? I t 's usually best t o brainst orm all t he ext ension condit ions first , before you get bogged down working out t he consequences. You'll probably t hink of m ore condit ions t his way, which t ranslat es t o fewer goofs t hat you have t o pick up lat er. A com plicat ed st ep in a use case can be anot her use case. I n UML t erm s, we say t hat the first use case inclu de s t he second. There's no st andard way t o show an included use case in t he t ext , but I find t hat underlining, which suggest s a hyperlink, works very nicely and in m any t ools really will be a hyperlink. Thus in Figure 9.1 , t he first st ep includes t he use case " browse cat alog and select it em s t o buy." I ncluded use cases can be useful for a com plex st ep that would clut t er t he m ain scenario or for st eps t hat are repeat ed in several use cases. However, don't t ry t o break down use cases int o sub–use cases and subsub–use cases using funct ional decom posit ion. Such a decom posit ion is a good way t o wast e a lot of t im e. As well as the st eps in the scenarios, you can add som e ot her com m on inform at ion t o a use case. • • •

A pr e - con dit ion describes what t he syst em should ensure is t rue before the syst em allows t he use case t o begin. This is useful for t elling the program m ers what condit ions they don't have t o check for in their code. A gu ar a n t ee describes what t he syst em will ensure at t he end of t he use case. Success guarant ees hold aft er a successful scenario; m inim al guarant ees hold aft er any scenario. A t r igge r specifies t he event t hat get s the use case st art ed.

When you're considering adding elem ent s, be skept ical. I t 's bet t er t o do t oo lit t le t han t oo m uch. Also, work hard t o keep t he use case brief and easy t o read. I 've found t hat long, det ailed use cases don't get read, which rat her defeat s the purpose. The am ount of det ail you need in a use case depends on t he am ount of risk in t hat use case. Often, you need det ails on only a few key use cases early on; ot hers can be fleshed out j ust before you im plem ent t hem . You don't have t o writ e all t he det ail down; verbal com m unicat ion is oft en very effective, particularly wit hin an it erat ive cycle in which needs are quickly m et by running code.

Use Case Diagrams As I said earlier, the UML is silent on t he cont ent of a use case but does provide a diagram form at for showing t hem , as in Figure 9.2. Alt hough t he diagram is som et im es useful, it isn't m andat ory. I n your use case work, don't put t oo m uch effort int o t he diagram . I nst ead, concent rat e on t he t ext ual cont ent of the use cases.

Figu r e 9 .2 . Use ca se dia gr a m

81/ 118

The best way t o t hink of a use case diagram is t hat it 's a graphical t able of cont ent s for t he use case set . I t 's also sim ilar t o t he cont ext diagram used in st ruct ured m et hods, as it shows the syst em boundary and t he int eract ions wit h the out side world. The use case diagram shows t he act ors, t he use cases, and t he relat ionships bet ween t hem : • •

Which act ors carry out which use cases Which use cases include ot her use cases

The UML includes ot her relat ionships bet ween use cases beyond t he sim ple includes, such as «extend». I st rongly suggest t hat you ignore t hem . I 've seen t oo m any sit uat ions in which t eam s can get t erribly hung up on when t o use different use case relat ionships, and such energy is wast ed. I nst ead, concent rat e on t he t ext ual descript ion of a use case; that 's where t he real value of t he t echnique lies.

Levels of Use Cases A com m on problem wit h use cases is that by focusing on t he int eraction bet ween a user and the syst em , you can neglect sit uat ions in which a change t o a business process m ay be t he best way t o deal wit h t he problem . Oft en, you hear people talk about syst em use cases and business use cases. The t erm s are not precise, but in general, a syst e m u se case is an int eract ion wit h t he soft ware, whereas a busin e ss u se ca se discusses how a business responds t o a cust om er or an event . [ Cockburn, use cases] suggest s a schem e of levels of use cases. The core use cases are at "sea level." Se a - le ve l use cases t ypically represent a discret e int eract ion bet ween a prim ary act or and t he syst em . Such use cases will deliver som et hing of value t o t he prim ary act or and usually t ake from a couple of m inut es t o half an hour for t he prim ary act or t o com plet e. Use cases t hat are t here only because t hey are included by sea-level use cases are fish le ve l. Higher, k it e - le ve l use cases show how t he sea- level use cases fit int o wider business int eract ions. Kit e-level use cases are usually business use cases, whereas sea and fish levels are syst em use cases. You should have m ost of your use cases at the sea level. I prefer t o indicat e t he level at t he t op of t he use case, as in Figure 9.1.

Use Cases and Features (or Stories) Many approaches use feat ures of a syst em —Extrem e Program m ing calls t hem user st ories—t o help describe requirem ent s. A com m on quest ion is how feat ures and use cases int errelat e. 82/ 118

Feat ures are a good way of chunking up a syst em for planning an it erat ive proj ect , whereby each it erat ion delivers a num ber of feat ures. Use cases provide a narrat ive of how t he act ors use the syst em . Hence, alt hough bot h t echniques describe requirem ent s, t heir purposes are different . Alt hough you can go directly t o describing feat ures, m any people find it helpful t o develop use cases first and then generat e a list of feat ures. A feat ure m ay be a whole use case, a scenario in a use case, a st ep in a use case, or som e variant behavior, such as adding yet anot her depreciat ion m et hod for your asset valuat ions, t hat doesn't show up in a use case narrat ive. Usually, feat ures end up being m ore fine grained t han use cases.

When to Use Use Cases Use cases are a valuable t ool t o help underst and t he funct ional requirem ent s of a syst em . A first pass at use cases should be m ade early on. More det ailed versions of use cases should be worked j ust prior t o developing t hat use case. I t is im port ant t o rem em ber t hat use cases represent an ext ernal view of t he syst em . As such, don't expect any correlat ions bet ween use cases and t he classes inside t he syst em . The m ore I see of use cases, the less valuable t he use case diagram seem s t o be. Wit h use cases, concent rat e your energy on t heir t ext rat her than on t he diagram . Despit e t he fact that t he UML has not hing t o say about t he use case t ext , it is t he t ext t hat cont ains all t he value in t he t echnique. A big danger of use cases is t hat people m ake them t oo com plicat ed and get st uck. Usually, you'll get less hurt by doing t oo lit t le t han by doing t oo m uch. A couple of pages per use case is j ust fine for m ost cases. I f you have t oo lit t le, at least you'll have a short , readable docum ent t hat 's a st art ing point for quest ions. I f you have t oo m uch, hardly anyone will read and underst and it .

Where to Find Out More Use cases were originally popularized by I var Jacobson in [ Jacobson, OOSE] . Alt hough use cases have been around for a while, t here's been lit t le st andardizat ion on their use. The UML is silent on t he im port ant cont ent s of a use case and has st andardized only t he m uch less im port ant diagram s. As a result , you can find a divergent range of opinions on use cases. I n the last few years, however, [ Cockburn, use cases] has becom e t he st andard book on t he subj ect . I n this chapt er, I 've followed t he t erm inology and advice of t hat book for t he excellent reason that when we've disagreed in the past , I 've usually ended up agreeing wit h Alist air Cockburn in t he end. He also m aint ains a Web sit e at h t t p:/ / u se case s.or g. [ Const ant ine and Lockwood] provides a convincing process for deriving user int erfaces from use cases; also see h t t p:/ / for use .com .

Chapter 10. State Machine Diagrams St a t e m a ch in e dia gr a m s are a fam iliar t echnique t o describe t he behavior of a syst em . Various form s of st at e diagram s have been around since t he 1960s and t he earliest obj ect - orient ed t echniques adopt ed them t o show behavior. I n obj ect - orient ed approaches, you draw a st at e m achine diagram for a single class t o show t he lifet im e behavior of a single obj ect . Whenever people writ e about st at e m achines, t he exam ples are inevit ably cruise cont rols or vending m achines. As I 'm a lit t le bored wit h t hem , I decided t o use a cont roller for a secret panel in a Got hic 83/ 118

cast le. I n t his cast le, I want t o keep m y valuables in a safe t hat 's hard t o find. So t o reveal t he lock t o t he safe, I have t o rem ove a st rat egic candle from it s holder, but t his will reveal the lock only while t he door is closed. Once I can see the lock, I can insert m y key t o open t he safe. For ext ra safet y, I m ake sure t hat I can open t he safe only if I replace t he candle first . I f a t hief neglect s this precaut ion, I 'll unleash a nast y m onst er t o devour him . Figure 10.1 shows a st at e m achine diagram of t he cont roller class t hat direct s m y unusual securit y syst em .The st at e diagram st art s wit h t he st at e of t he cont roller obj ect when it 's creat ed: in Figure 10.1, t he Wait st at e. The diagram indicat es t his wit h in it ia l pse u dost a t e, which is not a st at e but has an arrow t hat point s t o t he init ial st at e.

Figu r e 1 0 .1 . A sim ple st a t e m a ch in e dia gr a m

The diagram shows that t he cont roller can be in t hree st at es: Wait , Lock, and Open. The diagram also gives t he rules by which t he cont roller changes from st at e t o st at e. These rules are in t he form of t ransit ions: t he lines that connect t he st at es. The t r a nsit ion indicat es a m ovem ent from one st at e t o anot her. Each t ransit ion has a label t hat com es in t hree part s: trigger-signature [guard]/activity. All t he part s are opt ional. The trigger-signature is usually a single event t hat t riggers a pot ent ial change of st at e. The guard, if present , is a Boolean condit ion t hat m ust be t rue for t he t ransit ion t o be t aken. The activity is som e behavior t hat 's execut ed during t he t ransit ion. I t m ay be any behavioral expression. The full form of a trigger-signature m ay include m ult iple event s and param et ers. So in Figure 10.1 , you read t he out ward t ransit ion from t he Wait st at e as " I n t he Wait st at e if t he candle is rem oved providing t he door is open, you reveal t he lock and m ove t o t he Lock st at e." All t hree part s t o a t ransit ion are opt ional. A m issing act ivit y indicat es t hat you don't do anything during t he t ransit ion. A m issing guard indicat es t hat you always t ake t he t ransit ion if t he event occurs. A m issing t rigger- signat ure is rare but does occur. I t indicat es t hat you t ake the t ransit ion im m ediat ely, which you see m ost ly wit h act ivit y st at es, which I 'll com e t o in a m om ent . When an event occurs in a st at e, you can t ake only one t ransit ion out of it . So if you use m ult iple t ransit ions wit h the sam e event , as in t he Lock st at e of Figure 10.1, t he guards m ust be m ut ually exclusive. I f an event occurs and no t ransit ion is valid—for exam ple, a safe- closed event in the Wait st at e or a candle-rem oved event wit h t he door closed—t he event is ignored. The final st at e indicat es that t he st at e m achine is com plet ed, im plying t he delet ion of t he cont roller obj ect . Thus, if som eone should be so careless as t o fall for m y t rap, t he cont roller obj ect t erm inat es, so I would need t o put t he rabbit in it s cage, m op t he floor, and reboot the syst em . 84/ 118

Rem em ber t hat st at e m achines can show only what t he obj ect directly observes or act ivat es. So alt hough you m ight expect m e t o add or rem ove t hings from t he safe when it 's open, I don't put t hat on t he st at e diagram , because t he cont roller cannot t ell. When developers t alk about obj ect s, t hey oft en refer t o t he st at e of the obj ect s t o m ean t he com binat ion of all the dat a in t he fields of t he obj ect s. However, t he st at e in a st at e m achine diagram is a m ore abst ract not ion of st at e; essent ially, different st at es im ply a different way of react ing t o event s.

Internal Activities St at es can react t o event s wit hout t ransit ion, using in t e rn a l a ct ivit ie s: put t ing t he event , guard, and act ivit y inside the st at e box it self. Figure 10.2 shows a st at e wit h int ernal activit ies of t he charact er and help event s, as you m ight find on a UI t ext field. An int ernal act ivit y is sim ilar to a se lf- tr a n sit ion : a t ransit ion t hat loops back t o t he sam e st at e. The synt ax for int ernal act ivit ies follows t he sam e logic for event , guard, and procedure.

Figu r e 1 0 .2 . I n t e rn a l e v e n t s sh ow n w it h t h e t ypin g st a t e of a t e x t fie ld

Figure 10.2 also shows t wo special act ivit ies: t he ent ry and exit act ivit ies. The e n tr y a ct ivit y is execut ed whenever you ent er a st at e; t he e x it a ct ivit y, whenever you leave. However, int ernal act ivit ies do not t rigger t he ent ry and exit activit ies; that is t he difference bet ween int ernal act ivit ies and self-t ransit ions.

Activity States I n the st at es I 've described so far, t he obj ect is quiet and wait ing for t he next event before it does som et hing. However, you can have st at es in which the obj ect is doing som e ongoing work. The Searching st at e in Figure 10.3 is such an a ct ivit y st a t e : The ongoing act ivit y is m arked wit h t he do/; hence the t erm do- a ct ivit y. Once t he search is com plet ed, any t ransit ions wit hout an act ivit y, such as the one t o display new hardware, are t aken. I f t he cancel event occurs during t he act ivit y, the do- act ivit y is uncerem oniously halt ed, and we go back t o t he Updat e Hardware Window st at e.

Figu r e 1 0 .3 . A st a t e w it h a n a ct iv it y

85/ 118

Bot h do- act ivit ies and regular activit ies represent carrying out som e behavior. The crit ical difference bet ween t he t wo is t hat regular act ivit ies occur "inst ant aneously" and cannot be int errupt ed by regular event s, while do- act ivit ies can t ake finit e t im e and can be int errupt ed, as in Figure 10.3. I nst ant aneous will m ean different t hings for different syst em ; for hard real- t im e syst em s, it m ight be a few m achine inst ruct ions, but for deskt op soft ware m ight be several seconds. UML 1 used t he t erm a ct ion for regular act ivit ies and used activit y only for do- act ivit ies.

Superstates Oft en, you'll find t hat several st at es share com m on t ransit ions and int ernal act ivit ies. I n t hese cases, you can m ake t hem subst at es and m ove t he shared behavior int o a superst at e, as in Figure 10.4. Wit hout t he superst at e, you would have t o draw a cancel t ransit ion for all t hree st at es wit hin t he Ent er Connect ion Det ails st at e.

Figu r e 1 0 .4 . Su pe r st a t e w it h n e st e d su bst a t e s

Concurrent States St at es can be broken int o several ort hogonal st at e diagram s t hat run concurrent ly. Figure 10.5 shows a pat het ically sim ple alarm clock t hat can play eit her CDs or t he radio and show eit her the current t im e or t he alarm t im e.

86/ 118

Figu r e 1 0 .5 . Con cu r r e n t or t h ogon a l st a t e s

The choices CD/ radio and current / alarm t im e are ort hogonal choices. I f you want ed t o represent t his wit h a nonorthogonal st at e diagram , you would need a m essy diagram that would get very m uch out of hand should you want m ore st at es. Separat ing out t he t wo areas of behavior int o separat e stat e diagram s m akes it m uch clearer. Figure 10.5 also includes a h ist or y pse u dost a te. This indicat es t hat when t he clock is swit ched on, t he radio/ CD choice goes back t o t he st at e t he clock was in when it was t urned off. The arrow from t he hist ory pseudost at e indicat es what st at e t o be in on t he first t im e when t here is no hist ory.

Implementing State Diagrams A st at e diagram can be im plem ent ed in t hree m ain ways: nest ed swit ch, t he St at e pat t ern, and st at e t ables. The m ost direct approach t o handling a st at e diagram is a nest ed swit ch st at em ent , such as Figure 10.6. Alt hough it 's direct , it 's long- winded, even for t his sim ple case. I t 's also very easy for t his approach t o get out of cont rol, so I don't like using it even for sim ple cases.

Figu r e 1 0 .6 A C# n e st e d sw it ch t o ha n dle t h e st a t e t r a n sit ion fr om Figur e 1 0 .1 public void HandleEvent (PanelEvent anEvent) { switch (CurrentState) { case PanelState.Open : switch (anEvent) { case PanelEvent.SafeClosed : CurrentState = PanelState.Wait; break; } break; case PanelState.Wait : 87/ 118

switch (anEvent) { case PanelEvent.CandleRemoved : if (isDoorOpen) { RevealLock(); CurrentState = PanelState.Lock; } break; } break; case PanelState.Lock : switch (anEvent) { case PanelEvent.KeyTurned : if (isCandleIn) { OpenSafe(); CurrentState = PanelState.Open; } else { ReleaseKillerRabbit(); CurrentState = PanelState.Final; } break; } break; } } } The St a t e pa t te r n [ Gang of Four] creat es a hierarchy of st at e classes t o handle behavior of t he st at es. Each st at e in t he diagram has one st at e subclass. The cont roller has m et hods for each event , which sim ply forwards t o t he st at e class. The stat e diagram of Figure 10.1 would yield an im plem ent at ion indicat ed by t he classes of Figure 10.7.

Figu r e 1 0 .7 . A St a t e pa t t e r n im ple m e n t a t ion for Figu r e 1 0 .1

The t op of t he hierarchy is an abst ract class t hat im plem ent s all t he event -handling m et hods t o do not hing. For each concret e st at e, you sim ply override t he specific event m et hods for which t hat st at e has t ransit ions. The st a t e t a ble approach capt ures the st at e diagram inform at ion as dat a. So Figure 10.1 m ight end up represent ed in a t able like Table 10.1. We t hen build eit her an int erpret er t hat uses t he st at e t able at runt im e or a code generat or t hat generat es classes based on t he st at e t able. Obviously, t he st at e t able is m ore work t o do once, but then you can use it every t im e you have a st at e problem t o hold. A runt im e st at e t able can also be m odified wit hout recom pilat ion, which in 88/ 118

som e cont ext s is quit e handy. The st at e pat t ern is easier t o put t oget her when you need it , and alt hough it needs a new class for each st at e, it 's a sm all am ount of code t o writ e in each case. These im plem ent at ions are pret t y m inim al, but they should give you an idea of how t o go about im plem ent ing st at e diagram s. I n each case, im plem ent ing st at e m odels leads t o very boilerplat e code, so it 's usually best t o use som e form of code generat ion t o do it .

Ta ble 1 0 .1 . A St a t e Ta ble for Figu r e 1 0 .1 Sou rce Sta t e

Ta r ge t Sta t e

Eve n t

Gu a r d

Pr oce du re

Wait

Lock

Candle rem oved

Door open

Reveal lock

Lock

Open

Key t urned

Candle in

Open safe

Lock

Final

Key t urned

Candle out

Release killer rabbit

Open

Wait

Safe closed

When to Use State Diagrams St at e diagram s are good at describing t he behavior of an obj ect across several use cases. St at e diagram s are not very good at describing behavior t hat involves a num ber of obj ect s collaborat ing. As such, it is useful t o com bine st at e diagram s wit h ot her t echniques. For inst ance, int eract ion diagram s ( see Chapt er 4) are good at describing t he behavior of several obj ect s in a single use case, and act ivit y diagram s ( see Chapt er 11) are good at showing the general sequence of act ivit ies for several obj ect s and use cases. Not everyone finds st at e diagram s nat ural. Keep an eye on how people are working wit h them . I t m ay be t hat your t eam does not find st at e diagram s useful t o it s way of working. That is not a big problem ; as always, you should rem em ber t o use t he m ix of t echniques t hat works for you. I f you do use st at e diagram s, don't t ry t o draw them for every class in t he syst em . Alt hough t his approach is oft en used by high- cerem ony com plet ist s, it is alm ost always a wast e of effort . Use st at e diagram s only for t hose classes t hat exhibit int erest ing behavior, where building t he st at e diagram helps you underst and what is going on. Many people find t hat UI and cont rol obj ect s have t he kind of behavior that is useful t o depict wit h a st at e diagram .

Where to Find Out More Bot h t he User Guide [ Booch, UML user] and t he Reference Manual [ Rum baugh, UML Reference] have m ore inform at ion on st at e diagram s. Real-t im e designers t end t o use st at e m odels a lot , so it 's no surprise t hat [ Douglass] ) has a lot t o say about st at e diagram s, including inform at ion on how t o im plem ent t hem . [ Mart in] cont ains a very good chapt er on t he various ways of im plem ent ing st at e diagram s.

Chapter 11. Activity Diagrams Act ivit y diagram s are a t echnique t o describe procedural logic, business process, and work flow. I n m any ways, t hey play a role sim ilar t o flowchart s, but t he principal difference bet ween t hem and flowchart not at ion is t hat t hey support parallel behavior. Act ivit y diagram s have seen som e of t he biggest changes over t he versions of the UML, so t hey have, not surprisingly, been significant ly ext ended and alt ered again for UML 2. I n UML 1, act ivit y 89/ 118

diagram s were seen as special cases of st at e diagram s. This caused a lot of problem s for people m odeling work flows, which act ivit y diagram s are well suit ed for. I n UML 2, t hat t ie was rem oved. Figure 11.1 shows a sim ple exam ple of an act ivit y diagram . We begin at t he in it ia l n ode act ion and t hen do t he act ion Receive Order. Once that is done, we encount er a fork. A for k has one incom ing flow and several out going concurrent flows.

Figu r e 1 1 .1 . A sim ple a ct iv it y dia gr am

Figure 11.1 says t hat Fill Order, Send I nvoice, and t he subsequent act ions occur in parallel. Essent ially, t his m eans t hat the sequence bet ween t hem is irrelevant . I could fill t he order, send t he invoice, deliver, and t hen receive paym ent ; or, I could send the invoice, receive t he paym ent , fill t he order, and t hen deliver: You get t he picture. I can also do t hese act ions by int erleaving. I grab t he first line it em from st ores, t ype up t he invoice, grab t he second line it em , put t he invoice in an envelope, and so fort h. Or, I could do som e of t his 90/ 118

sim ult aneously: t ype up the invoice wit h one hand while I reach int o m y st ores wit h anot her. Any of t hese sequences is correct , according t o t he diagram . The act ivit y diagram allows whoever is doing the process t o choose t he order in which t o do t hings. I n ot her words, t he diagram m erely st at es t he essent ial sequencing rules I have t o follow. This is im port ant for business m odeling because processes oft en occur in parallel. I t 's also useful for concurrent algorit hm s, in which independent t hreads can do t hings in parallel. When you have parallelism , you'll need t o synchronize. We don't close t he order unt il it is delivered and paid for. We show t his wit h t he j oin before t he Close Order act ion. Wit h a j oin, t he out going flow is t aken only when all t he incom ing flows reach t he j oin. So you can close t he order only when you have bot h received t he paym ent and delivered. UML 1 had part icular rules for balancing t he forks and j oins, as act ivit y diagram s were special cases of st at e diagram s. Wit h UML 2, such balancing is no longer needed. You'll not ice that the nodes on an activit y diagram are called act ions, not activit ies. St rictly, an act ivit y refers t o a sequence of act ions, so t he diagram shows an act ivit y t hat 's m ade up of act ions. Condit ional behavior is delineat ed by decisions and m erges. A de cision, called branch in UML 1, has a single incom ing flow and several guarded out -bound flows. Each out bound flow has a guard: a Boolean condit ion placed inside square bracket s. Each t im e you reach a decision, you can t ake only one of the out bound flows, so t he guards should be m ut ually exclusive. Using [else] as a guard indicat es t hat t he [else] flow should be used if all the ot her guards on t he decision are false. I n Figure 11.1, aft er an order is filled, t here is a decision. I f you have a rush order, you do an Overnight Delivery; ot herwise, you do a Regular Delivery. A m e r ge has m ult iple input flows and a single out put . A m erge m arks t he end of condit ional behavior st art ed by a decision. I n m y diagram s, each act ion has a single flow com ing in and a single flow going out . I n UML 1, m ult iple incom ing flows had an im plicit m erge. That is, your act ion would execut e if any flow t riggered. I n UML 2, t his has changed so t here's an im plicit j oin inst ead; t hus, the action execut es only if all flows t rigger. As a result of this change, I recom m end t hat you use only a single incom ing and out going flow t o an act ion and show all j oins and m erges explicit ly; t hat will avoid confusion.

Decomposing an Action Act ions can be decom posed int o subact ivit ies. I can t ake t he delivery logic of Figure 11.1 and define it as it s own act ivit y ( Figure 11.2 ) . Then I can call it as an act ion ( Figure 11.3 on page 121) .

Figu r e 1 1 .2 . A su bsidia r y a ct iv it y dia gr a m

91/ 118

Figu r e 1 1 .3 . Th e a ct iv it y of Figu r e 1 1 .1 m odifie d t o in v ok e t h e a ct iv it y in Figu r e 1 1 .2

92/ 118

Act ions can be im plem ent ed eit her as subact ivit ies or as m et hods on classes. You can show a subact ivit y by using t he rake sym bol. You can show a call on a m et hod wit h synt ax classname::method-name. You can also writ e a code fragm ent int o t he action sym bol if the invoked behavior isn't a single m et hod call.

And There's More I should st ress that this chapt er only scrat ches the surface on activit y diagram s. As wit h so m uch of t he UML, you could writ e a whole book on t his one t echnique alone. I ndeed, I t hink t hat act ivit y diagram s would m ake a very suit able t opic for a book t hat really dug int o t he not at ion and how t o use it . The vit al quest ion is how widely t hey get used. Act ivit y diagram s aren't t he m ost widely used UML t echnique at t he m om ent , and t heir flow- m odeling progenit ors weren't very popular eit her. Diagram m at ic t echniques haven't yet caught on m uch for describing behavior in t his kind of way. On t he ot her hand, t here are signs in a num ber of com m unit ies of a pent - up dem and t hat a st andard t echnique will help t o sat isfy.

When to Use Activity Diagrams The great st rengt h of act ivit y diagram s lies in t he fact t hat t hey support and encourage parallel behavior. This m akes t hem a great t ool for work flow and process m odeling, and indeed m uch of t he push in UML 2 has com e from people involved in work flow. You can also use an act ivit y diagram as a UML-com pliant flowchart . Alt hough t his allows you t o do flowchart s in a way that st icks wit h the UML, it 's hardly very excit ing. I n principle, you can t ake advant ages of t he forks and j oins t o describe parallel algorit hm s for concurrent program s. Alt hough I don't t ravel in concurrent circles that m uch, I haven't seen m uch evidence of people using them t here. I t hink t he reason is that m ost of the com plexit y of concurrent program m ing is in avoiding cont ent ion on dat a, and act ivit y diagram s don't help m uch wit h t hat . The m ain st rengt h of doing t his m ay com e wit h people using UML as a program m ing language. I n t his case, act ivit y diagram s represent an im port ant t echnique t o represent behavioral logic. I 've oft en seen act ivit y diagram s used t o describe a use case. The danger of t his approach is t hat oft en, dom ain expert s don't follow t hem easily. I f so, you'd be bet t er off wit h the usual t ext ual form .

Where to Find Out More Alt hough act ivit y diagram s have always been rat her com plicat ed and are even m ore so wit h UML 2, t here hasn't been a good book t hat describes t hem in dept h. I hope t his gap will get filled som eday. Various flow- orient ed t echniques are sim ilar in st yle t o act ivit y diagram s. One of t he bet t er known— but hardly well known—is Pet ri Net s, for which ht t p:/ / w w w .da im i.a u .dk / Pe t r iN e ts/ is a good Web sit e.

Partitions Act ivit y diagram s t ell you what happens, but t hey do not t ell you who does what . I n program m ing, t his m eans that t he diagram does not convey which class is responsible for each act ion. I n business 93/ 118

process m odeling, t his does not convey which part of an organizat ion carries out which act ion. This isn't necessarily a problem ; oft en, it m akes sense t o concent rat e on what get s done rat her t han on who does what part s of t he behavior. I f you want t o show who does what , you can divide an activit y diagram int o par t it ion s, which show which act ions one class or organizat ion unit carries out . Figure 11.4 ( on page 122) shows a sim ple exam ple of t his, showing how t he act ions involved in order processing can be separat ed am ong various depart m ent s.

Figu r e 1 1 .4 . Pa r t it ions on a n a ct iv it y dia gr a m

The part it ioning of Figure 11.4 is a sim ple one- dim ensional part it ioning. This st yle is oft en referred t o as sw im la n e s, for obvious reasons and was t he only form used in UML 1.x. I n UML 2, you can use a t wo- dim ensional grid, so t he swim m ing m et aphor no longer holds wat er. You can also t ake each dim ension and divide t he rows or colum ns hierarchically.

Signals I n the sim ple exam ple of Figure 11.1 , act ivit y diagram s have a clearly defined st art point , which corresponds t o an invocat ion of a program or rout ine. Act ions can also respond t o signals.

94/ 118

A t im e sign a l occurs because of the passage of t im e. Such signals m ight indicat e the end of a m ont h in a financial period or each m icrosecond in a real-t im e cont roller. Figure 11.5 shows an act ivit y t hat list ens for t wo signals. A sign a l indicat es t hat t he act ivit y receives an event from an out side process. This indicat es t hat t he act ivit y const ant ly list ens for t hose signals, and the diagram defines how t he act ivit y react s.

Figu r e 1 1 .5 . Sign a ls on a n a ct iv it y dia gr a m

I n the case of Figure 11.5, 2 hours before m y flight leaves, I need t o st art packing m y bags. I f I 'm quick t o pack t hem , I st ill cannot leave unt il t he t axi arrives. I f t he t axi arrives before m y bags are packed, it has t o wait for m e t o finish before we go. As well as accept ing signals, we can send t hem . This is useful when we have t o send a m essage and t hen wait for a reply before we can cont inue. Figure 11.6 shows a good exam ple of t his wit h a com m on idiom of t im ing out . Not e t hat t he t wo flows are in a race: The first t o reach t he final stat e will win and t erm inat e t he ot her flow.

Figu r e 1 1 .6 . Sen din g a n d r e ce iv in g sign a ls

Alt hough accept s are usually j ust wait ing for an ext ernal event , we can also show a flow going int o t hem . That indicat es that we don't st art list ening unt il t he flow t riggers t he accept .

Tokens I f you're sufficient ly brave t o vent ure int o t he dem onic dept hs of t he UML specificat ion, you'll find t hat t he act ivit y sect ion of t he specificat ion t alks a lot about t okens and their product ion and consum pt ion. The init ial node creat es a t oken, which then passes t o t he next act ion, which execut es and t hen passes t he t oken t o t he next . At a fork, one t oken com es in, and t he fork produces a t oken 95/ 118

on each of it s out ward flows. Conversely, on a j oin, as each inbound t oken arrives, not hing happens unt il all t he t okens appear at the j oin; t hen a t oken is produced on t he out ward flow. You can visualize t he t okens wit h coins or count ers m oving across the diagram . As you get t o m ore com plicat ed exam ples of act ivit y diagram s, t okens oft en m ake it easier t o visualize t hings.

Flows and Edges UML 2 uses t he t erm s flow and e dge synonym ously t o describe t he connect ions bet ween t wo act ions. The sim plest kind of edge is t he sim ple arrow bet ween t wo act ions. You can give an edge a nam e if you like, but m ost of the t im e, a sim ple arrow will suffice. I f you're having difficult y rout ing lines, you can use connect ors, which sim ply save you having to draw a line t he whole dist ance. When you use connect ors, you m ust use them in pairs: one wit h incom ing flow, one wit h an out going flow, and bot h wit h the sam e label. I t end t o avoid using connect ors if at all possible, as t hey break up the visualizat ion of t he flow of cont rol. The can you you

sim plest edges pass a t oken t hat has no m eaning ot her t han t o cont rol t he flow. However, you also pass obj ect s along edges; t he obj ect s t hen play t he role of t okens, as well as carry dat a. I f are passing an obj ect along t he edge, you can show t hat by put t ing a class box on the edge, or can use pins on the actions, alt hough pins im ply som e m ore subt let ies t hat I 'll describe short ly.

All t he st yles shown in Figure 11.7 are equivalent ; you should use whichever conveys best what you are t rying t o com m unicat e. Most of the t im e, t he sim ple arrow is quit e enough.

Figu r e 1 1 .7 . Four w a y s of sh ow in g an e dge

Pins and Transformations Act ions can have param et ers, j ust as m et hods do. You don't need t o show inform at ion about param et ers on t he act ivit y diagram , but if you wish, you can show t hem wit h pin s. I f you're decom posing an act ion, pins correspond t o t he param et er boxes on t he decom posed diagram . When you're drawing an act ivit y diagram st rict ly, you have t o ensure t hat t he out put param et ers of an out bound act ion m at ch t he input param et ers of anot her. I f t hey don't m at ch, you can indicat e a 96/ 118

t r a n sfor m a t ion ( Figure 11.8 ) t o get from one to anot her. The t ransform at ion m ust be an expression t hat 's free of side effect s: essent ially, a query on t he out put pin quary t hat supplies an obj ect of t he right t ype for t he input pin.

Figu r e 1 1 .8 . Tr a n sfor m a t ion on a flow

You don't have t o show pins on an act ivit y diagram . Pins are best when you want t o look at t he dat a needed and produced by t he various act ions. I n business process m odeling, you can use pins t o show t he resources produced and consum ed by act ions. I f you use pins, it 's safe t o show m ult iple flows com ing int o t he sam e act ion. The pin not at ion reinforces t he im plicit j oin, and UML 1 didn't have pins, so t here's no confusion wit h t he earlier assum pt ions.

Expansion Regions Wit h act ivit y diagram s, you oft en run int o sit uat ions in which one act ion's out put t riggers m ult iple invocat ions of anot her act ion. There are several ways t o show this, but the best way is t o use an expansion region. An e x pan sion re gion m arks an act ivit y diagram area where act ions occur once for each it em in a collect ion. I n Figure 11.9, t he Choose Topics act ion generat es a list of t opics as it s out put . Each elem ent of t his list then becom es a t oken for input t o t he Writ e Art icle act ion. Sim ilarly, each Review Art icle act ion generat es a single art icle that 's added t o t he out put list of the expansion region. When all t he t okens in t he expansion region end up in t he out put collect ion, t he region generat es a single t oken for t he list that 's passed t o Publish Newslet t er.

Figu r e 1 1 .9 . Ex pa n sion r e gion

97/ 118

I n this case, you have the sam e num ber of it em s in t he out put collect ion as you do in the input collect ion. However, you m ay have fewer, in which case the expansion region act s as a filt er. I n Figure 11.9, all t he art icles are writ t en and reviewed in parallel, which is m arked by the «concurrent» keyword. You can also have an it erat ive expansion region. I t erat ive regions m ust fully process each input elem ent one at a t im e. I f you have only a single act ion that needs m ult iple invocat ion, you use t he short hand of Figure 11.10. The short hand assum es concurrent expansion, as t hat 's t he m ost com m on. This not at ion corresponds t o t he UML 1 concept of dynam ic concurrency.

Figu r e 1 1 .1 0 . Sh or t h a n d for a sin gle a ct ion in a n e x p a n sion r e gion

Flow Final Once you get m ult iple t okens, as in an expansion region, you oft en get flows t hat st op even when t he act ivit y as a whole doesn't end. A flow fin a l indicat es t he end of one particular flow, wit hout t erm inat ing t he whole act ivit y. Figure 11.11 shows t his by m odifying t he exam ple of Figure 11.9 t o allow art icles t o be rej ect ed. I f an art icle is rej ect ed, the t oken is dest royed by the flow final. Unlike an act ivit y final, the rest of t he act ivit y can cont inue. This approach allows expansion regions t o act as filt ers, whereby t he out put collect ion is sm aller than t he input collect ion.

Figu r e 1 1 .1 1 . Flow fin a ls in a n a ct iv it y

98/ 118

Join Specifications By default , a j oin let s execut ion pass on it s out ward flow when all it s input flows have arrived at t he j oin. ( Or in m ore form al speak, it em it s a t oken on it s out put flow when a t oken has arrived on each input flow.) I n som e cases, part icularly when you have a flow wit h m ult iple t okens, it 's useful t o have a m ore involved rule. A j oin spe cifica t ion is a Boolean expression at t ached t o a j oin. Each t im e a t oken arrives at t he j oin, t he j oin specificat ion is evaluat ed and if t rue, an out put t oken is em it t ed. So in Figure 11.12, whenever I select a drink or insert a coin, the m achine evaluat es t he j oin specificat ion. The m achine slakes m y t hirst only if I 've put in enough m oney. I f, as in t his case, you want t o indicat e t hat you have received a t oken on each input flow, you label t he flows and include them in t he j oin specificat ion.

Figu r e 1 1 .1 2 . Join spe cifica t ion

99/ 118

Chapter 12. Communication Diagrams Com m u n ica t ion dia gr a m s, a kind of int eract ion diagram , em phasize the dat a links bet ween t he various participant s in t he int eract ion. I nst ead of drawing each part icipant as a lifeline and showing t he sequence of m essages by vert ical direct ion as t he sequence diagram s does, t he com m unicat ion diagram allows free placem ent of part icipant s, allows you t o draw links t o show how t he part icipant s connect , and use num bering t o show the sequence of m essages. I n UML 1.x, t hese diagram s were called colla bor a t ion dia gr a m s. This nam e stuck well, and I suspect t hat it will be a while before people get used t o t he new nam e. ( These are different from Collaborat ions [ page 143] ; hence t he nam e change.) Figure 12.1 shows a com m unicat ion diagram for t he sam e cent ralized cont rol int eract ion as in Figure 4.2. Wit h a com m unicat ion diagram , we can show how t he part icipant s are linked t oget her.

Figu r e 1 2 .1 . Com m u n ica t ion dia gr a m for ce n t r a lize d con t r ol

As well as showing links that are inst ances of associat ions, we can also show t ransient links, which arise only t he cont ext of t he int eract ion. I n this case, t he «local» link from Order t o Product is a local variable; ot her t ransient links are «parameter» and «global». These keywords were used in UML 1 but are m issing from UML 2. Because t hey are useful, I expect t hem t o st ay around in convent ional use. The num bering st yle of Figure 12.1 is st raight forward and com m only used, but actually isn't legal UML. To be kosher UML, you have t o use a nest ed decim al num bering schem e, as in Figure 12.2 .

Figu r e 1 2 .2 . Com m u n ica t ion dia gr a m w it h n e st e d de cim a l n u m be r in g

100/ 118

The reason for t he nest ed decim al num bers is t o resolve am biguit y wit h self-calls. I n Figure 4.2 , you can clearly see t hat getDiscountInfo is called wit hin t he m et hod calculateDiscount. Wit h t he flat num bering of Figure 12.1 , however, you can't t ell whet her getDiscountInfo is called wit hin calculateDiscount or wit hin t he overall calculatePrice m et hod. The nest ed num bering schem e resolves t his problem . Despit e it s illegalit y, m any people prefer a flat num bering schem e. The nest ed num bers can get very t angled, particularly as calls get rat her nest ed, leading t o such sequence num bers as 1.1.1.2.1.1. I n t hese cases, the cure for am biguit y can be worse t han t he disease. As well as num bers, you m ay also see let t ers on m essages; t hese let t ers indicat e different threads of cont rol. So m essages A5 and B2 would be in different threads; m essages 1a1 and 1b1 would be different threads concurrent ly nest ed wit hin m essage 1. You also see t hread let t ers on sequence diagram s, alt hough t his doesn't convey t he concurrency visually. Com m unicat ion diagram s don't have any precise not at ion for cont rol logic. They do allow you t o use it erat ion m arkers and guards ( page 59) , but t hey don't allow you t o fully specify cont rol logic. There is no special not at ion for creat ing or delet ing obj ect s, but t he «create» and «delete» keywords are com m on convent ions.

When to Use Communication Diagrams The m ain quest ion wit h com m unicat ion diagram s is when t o use t hem rat her t han the m ore com m on sequence diagram s. A st rong part of t he decision is personal preference: Som e people like one over t he ot her. Oft en, that drives t he choice m ore than anyt hing else. On the whole, m ost people seem t o prefer sequence diagram s, and for once, I 'm wit h t he m aj orit y. A m ore rat ional approach says t hat sequence diagram s are bet t er when you want t o em phasize t he sequence of calls and that com m unicat ion diagram s are bet t er when you want t o em phasize t he links. Many people find t hat com m unicat ion diagram s are easier t o alt er on a whit eboard, so t hey are a good approach for exploring alt ernat ives, alt hough in t hose cases, I oft en prefer CRC cards.

Chapter 13. Composite Structures One of t he m ost significant new feat ures in UML 2 is t he abilit y t o hierarchically decom pose a class int o an int ernal st ruct ure. This allows you t o t ake a com plex obj ect and break it down int o part s. Figure 13.1 shows a TV Viewer class wit h it s provided and required int erfaces ( page 69) . I 've shown t his in t wo ways: using t he ball- and- socket not at ion and list ing them int ernally. 101/ 118

Figu r e 1 3 .1 . Tw o w a y s of sh ow in g a TV v ie w e r a n d it s in t e r fa ce s

Figure 13.2 shows how t his class is decom posed int ernally int o t wo part s and which part s support and require the different int erfaces. Each part is nam ed in t he form name : class, wit h bot h elem ent s individually opt ional. Part s are not inst ance specificat ions, so t hey are bolded rat her than underlined.

Figu r e 1 3 .2 . I n t e rn a l v ie w of a com pon e n t ( e x a m ple su gge st e d by Jim Ru m ba u gh )

102/ 118

You can show how m any inst ances of a part are present . Figure 13.2 says that each TV Viewer cont ains one generat or part and one cont rols part . To show a part im plem ent ing an int erface, you draw a delegat ing connect or from t hat int erface. Sim ilarly, t o show t hat a part needs an int erface, you show a delegat ing connect or t o t hat int erface. You can also show connect ors bet ween part s wit h eit her a sim ple line, as I 've done here, or wit h ball- and- socket not at ion ( page 71) . You can add port s ( Figure 13.3) t o t he ext ernal st ruct ure. Port s allow you t o group t he required and provided int erfaces int o logical int eract ions t hat a com ponent has wit h the out side world.

Figu r e 1 3 .3 . A com pon e n t w it h m u lt iple por t s

When to Use Composite Structures Com posit e st ruct ures are new t o UML 2, alt hough som e older m et hods had som e sim ilar ideas. A good way of t hinking about t he difference bet ween packages and com posit e st ruct ures is that packages are a com pile- t im e grouping, while com posit e st ruct ures show runt im e groupings. As such, t hey are a nat ural fit for showing com ponent s and how t hey are broken int o part s; hence, m uch of t his not at ion is used in com ponent diagram s. Because com posit e st ruct ures are new t o t he UML, it 's t oo early t o t ell how effective they will t urn out in practice; m any m em bers of t he UML com m it t ee t hink t hat t hese diagram s will becom e a very valuable addit ion.

Chapter 14. Component Diagrams A debat e t hat 's always ranged large in the OO com m unit y is what the difference is bet ween a com ponent and any regular class. This is not a debat e that I want t o set t le here, but I can show you t he not at ion t he UML uses t o dist inguish bet ween t hem . UML 1 had a dist inct ive sym bol for a com ponent ( Figure 14.1) . UML 2 rem oved t hat icon but allows you t o annot at e a class box wit h a sim ilar-looking icon. Alt ernat ively, you can use t he «component» keyword.

Figu r e 1 4 .1 . N ot a t ion for com pon e n t s 103/ 118

Ot her t han the icon, com ponent s don't int roduce any not at ion that we haven't already seen. Com ponent s are connect ed t hrough im plem ent ed and required int erfaces, oft en using t he ball- andsocket not at ion ( page 71) j ust as for class diagram s. You can also decom pose com ponent s by using com posit e st ruct ure diagram s. Figure 14.2 shows an exam ple com ponent diagram . I n t his exam ple, a sales t ill can connect t o a sales server com ponent , using a sales m essage int erface. Because t he net work is unreliable, a m essage queue com ponent is set up so t he t ill can t alk t o t he server when t he net work is up and t alk t o a queue when t he net work is down; t he queue will t hen t alk t o t he server when t he net work becom es available. As a result , t he m essage queue bot h supplies t he sales m essage int erface t o t alk wit h t he t ill and requires t hat int erface t o t alk wit h t he server. The server is broken down int o t wo m aj or com ponent s. The t ransact ion processor realizes t he sales m essage int erface, and t he account ing driver t alks t o t he account ing syst em .

Figu r e 1 4 .2 . An e x a m ple com pon e n t dia gr a m

As I 've already said, t he issue of what is a com ponent is the subj ect of endless debat e. One of the m ore helpful st at em ent s I 've found is t his: Com ponent s are not a t echnology. Technology people seem t o find t his hard t o underst and. Com ponent s are about how cust om ers want t o relat e t o soft ware. They want t o be able t o buy t heir soft ware a piece at a t im e, and t o be able t o upgrade it j ust like t hey can upgrade t heir st ereo. They want new pieces t o work seam lessly wit h t heir old pieces, and t o be able t o upgrade on their own schedule, not t he m anufacturer's schedule. They want t o be able to m ix and m at ch pieces from various m anufacturers. This is a very reasonable requirem ent . I t is j ust hard t o sat isfy . Ralph Johnson, h t t p:/ / w w w .c2 .com / cgi/ w ik i?D oCom pon e n tsEx ist The im port ant point is t hat com ponent s represent pieces that are independent ly purchasable and upgradeable. As a result , dividing a syst em int o com ponent s is as m uch a m arket ing decision as it is a t echnical decision, for which [ Hohm ann] is an excellent guide. I t 's also a rem inder t o beware of 104/ 118

overly fine- grained com ponent s, because t oo m any com ponent s are hard t o m anage, especially when versioning rears it s ugly head, hence " DLL hell." I n earlier versions of t he UML, com ponent s were used t o represent physical st ruct ures, such as DLLs. That 's no longer t rue; for t his t ask, you now use art ifact s ( page 97) .

When to Use Component Diagrams Use com ponent diagram s when you are dividing your syst em int o com ponent s and want t o show t heir int errelat ionships through int erfaces or t he breakdown of com ponent s int o a lower-level st ruct ure.

Chapter 15. Collaborations Unlike t he ot her chapt ers in t his book, t his one does not correspond t o an official diagram in UML 2. The st andard discusses collaborat ions as part of com posit e st ruct ures, but t he diagram is really quit e different and was used in UML 1 wit hout any link t o com posit e st ruct ures. So I felt it best t o discuss collaborat ions as t heir own chapt er. Let 's consider the not ion of an auct ion. I n any auct ion, we m ight have a seller, som e buyers, a lot of goods, and som e offers for t he sale. We can describe t hese elem ent s in t erm s of a class diagram ( Figure 15.1) and perhaps som e int eract ion diagram s ( Figure 15.2) .

Figu r e 1 5 .1 . A colla bor a t ion w it h it s cla ss dia gr a m of r ole s

Figu r e 1 5 .2 . A se qu e n ce dia gr a m for t h e a u ct ion colla b or a t ion

105/ 118

Figure 15.1 is not quit e a regular class diagram . For a st art , it 's surrounded by t he dashed ellipse, which represent s t he auct ion collaborat ion. Second, t he so- called classes in t he collaborat ion are not classes but role s that will be realized as t he collaborat ion is applied—hence t he fact that t heir nam es aren't capit alized. I t 's not unusual t o see act ual int erfaces or classes t hat correspond t o t he collaborat ion roles, but you don't have t o have t hem . I n the int eract ion diagram , t he part icipant s are labeled slight ly different ly from t he usual case. I n a collaborat ion, t he nam ing schem e is participant-name /role-name : class-name. As usual, all t hese elem ent s are opt ional. When you use a collaborat ion, you can show t hat by placing a collaborat ion occurrence on a class diagram , as in Figure 15.3, a class diagram of som e of t he classes in t he applicat ion. The links from t he collaborat ion t o t hose classes indicat e how the classes play t he various roles defined in t he collaborat ion.

Figu r e 1 5 .3 . A colla bor a t ion occu r r e n ce

106/ 118

The UML suggest s t hat you can use t he collaborat ion occurrence not at ion t o show t he use of pat t erns, but hardly any pat t erns aut hor has done t his. Erich Gam m a developed a nice alt ernat ive not at ion ( Figure 15.4) . Elem ent s of t he diagram are labeled wit h eit her t he pat t ern nam e or a com binat ion of pattern:role.

Figu r e 1 5 .4 . A n onst a n da r d w a y of sh ow in g pa t t e r n u se in JUn it ( j u n it .or g)

When to Use Collaborations Collaborat ions have been around since UML 1, but I adm it I 've hardly used t hem , even in m y pat t erns writ ing. Collaborat ions do provide a way t o group chunks of int eraction behavior when roles are played by different classes. I n pract ice, however, I 've not found that they've been a com pelling diagram t ype.

Chapter 16. Interaction Overview Diagrams I nt eraction overview diagram s are a graft ing t oget her of act ivit y diagram s and sequence diagram s. You can think of int eraction overview diagram s eit her as act ivit y diagram s in which t he act ivit ies are 107/ 118

replaced by lit t le sequence diagram s, or as a sequence diagram broken up wit h act ivit y diagram not at ion used t o show cont rol flow. Eit her way, they m ake a bit of an odd m ixt ure. Figure 16.1 shows a sim ple exam ple of one; the not at ion is fam iliar from what you've already seen in t he act ivit y diagram and sequence diagram chapt ers. I n t his diagram , we want t o produce and form at an order sum m ary report . I f t he cust om er is ext ernal, we get the inform at ion from XML; if int ernal, we get it from a dat abase. Sm all sequence diagram s show the t wo alt ernat ives. Once we get t he dat a, we form at t he report ; in t his case, we don't show t he sequence diagram but sim ply reference it wit h a reference int eract ion fram e.

Figu r e 1 6 .1 . I n t e r a ct ion su m m a ry dia gr a m

When to Use Interaction Overview Diagrams These are new for UML 2, and it 's t oo early t o get m uch sense of how well t hey will work out in pract ice. I 'm not keen on t hem , as I t hink t hat they m ix t wo st yles that don't really m ix t hat well. Eit her draw an act ivit y diagram or use a sequence diagram , depending on what bet t er serves your purpose.

108/ 118

Chapter 17. Timing Diagrams Aft er leaving secondary school, I st art ed out in elect ronic engineering before I swit ched int o com put ing. So I feel a cert ain anguished fam iliarit y when I see t he UML define t im ing diagram s as one of it s st andard diagram s. Tim ing diagram s have been around in elect ronic engineering for a long t im e and never seem ed t o need t he UML's help to define their m eaning. But since t hey are in the UML, t hey deserve a brief m ent ion. Tim ing diagram s are anot her form of int eract ion diagram , where the focus is on t im ing const raint s: eit her for a single obj ect or, m ore usefully, for a bunch of obj ect s. Let 's t ake a sim ple scenario based on t he pum p and hot plat e for a coffee pot . Let 's im agine a rule t hat says t hat at least 10 seconds m ust pass bet ween the pum p com ing on and t he hot plat e com ing on. When the wat er reservoir becom es em pt y, the pum p swit ches off, and the hot plat e cannot st ay on for m ore t han 15 m inut es m ore. Figures 17.1 and 17.2 are alt ernat ive ways of showing t hese tim ing const raint s. Bot h diagram s show t he sam e basic inform at ion. The m ain difference is t hat Figure 17.1 shows t he st at e changes by m oving from one horizont al line t o anot her, while Figure 17.2 ret ains t he sam e horizont al posit ion but shows st at e changes wit h a cross. The st yle of Figure 17.1 works bet t er when t here are j ust a few st at es, as in t his case, and Figure 17.2 is bet t er when t here are m any st at es t o deal wit h.

Figu r e 1 7 .1 . Tim in g dia gr a m sh ow ing st a t e s a s lin e s

Figu r e 1 7 .2 . Tim in g dia gr a m sh ow ing st a t e s a s a r e a s

109/ 118

The dashed lines t hat I 've used on t he { > 10s} const raint s are opt ional. Use t hem if you t hink t hey help clarify exact ly what event s t he t im ing constrains.

When to Use Timing Diagrams Tim ing diagram s are useful for showing t im ing const raint s bet ween st at e changes on different obj ect s. The diagram s are particularly fam iliar t o hardware engineers.

Appendix Changes between UML Versions When t he first edit ion of t his book appeared on the shelves, t he UML was in version 1.0. Much of it appeared t o have st abilized and was in t he process of OMG recognit ion. Since t hen, t here have been a num ber of revisions. I n t his appendix, I describe t he significant changes t hat have occurred since 1.0 and how t hose changes affect t he m at erial in t his book. This appendix sum m arizes t he changes so you can keep up t o dat e if you have an earlier print ing of t he book. I have m ade changes t o t he book t o keep up wit h t he UML, so if you have a lat er print ing, it describes t he sit uat ion as it was as of the print dat e.

Revisions to the UML The earliest public release of what cam e t o be the UML was version 0.8 of t he Unified Met hod, which was released for OOPSLA in Oct ober 1995. This was t he work of Booch and Rum baugh, as Jacobson did not j oin Rat ional unt il around t hat t im e. I n 1996, Rat ional released versions 0.9 and 0.91, which included Jacobson's work. Aft er t he lat t er version, t hey changed t he nam e t o t he UML. Rat ional and a group of partners subm it t ed version 1.0 of the UML t o t he OMG Analysis and Design Task Force in January 1997. Subsequent ly, t he Rat ional part nership and t he ot her subm it t ers com bined their work and subm it t ed a single proposal for t he OMG st andard in Sept em ber 1997, for version 1.1 of t he UML. This was adopt ed by t he OMG t oward the end of 1997. However, in a fit of darkest obfuscat ion, t he OMG called t his st andard version 1.0. So, now t he UML was bot h OMG 110/ 118

version 1.0 and Rat ional version 1.1, not t o be confused wit h Rat ional 1.0. I n pract ice, everyone calls t hat st andard version 1.1. From t hen on, t here were a num ber of further developm ent s in t he UML. UML 1.2 appeared in 1998, 1.3 in 1999, 1.4 in 2001, and 1.5 in 2002. Most of t he changes bet ween t he 1.x versions were fairly deep in the UML, except for UML 1.3, which caused som e very visible changes, especially t o use cases and act ivit y diagram s. As t he UML 1 series cont inued, t he developers of t he UML set their sight s on a m aj or revision t o t he UML wit h UML 2. The first RFPs ( Request for Proposals) were issued in 2000, but UML 2 didn't st art t o properly st abilize unt il 2003. Furt her developm ent s in t he UML will alm ost cert ainly occur. The UML Forum ( h t t p:/ / u m lfor u m .com ) is usually a good place t o look for m ore inform at ion. I also keep som e UML inform at ion on m y sit e ( h t t p:/ / m a r t infow le r .com ) .

Changes in UML Distilled As t hese revisions go on, I 've been t rying t o keep up by revising UML Dist illed wit h subsequent print ings. I 've also t aken t he opport unit y t o fix errors and m ake clarificat ions. The m ost dynam ic period for keeping up wit h t hings was during the first edit ion of UML Dist illed, when we oft en had t o m ake updat es bet ween print ings t o keep up wit h t he em erging UML st andard. The first t hrough fift h print ings were based on UML 1.0. Any changes t o t he UML bet ween these print ings were m inor. The sixth print ing t ook UML 1.1 int o account . The sevent h t hrough t ent h print ings were based on UML 1.2; t he elevent h print ing was t he first t o use UML 1.3. Print ings based on versions of t he UML aft er 1.0 have t he UML version num ber on t he front cover. The first t hough sixt h print ings of t he second edit ion were based on version 1.3. The sevent h print ing was t he first t o t ake int o account t he m inor changes of version 1.4. The t hird edit ion was launched t o updat e t he book wit h UML 2 ( see Table A.1) . I n t he rest of t his appendix, I sum m arize t he m aj or changes in the UML from 1.0 t o 1.1, from 1.2 t o 1.3, and from 1.x t o 2.0. I don't discuss all t he changes t hat occur but rat her only t hose t hat change som et hing I said in UML Dist illed or t hat represent im port ant feat ures t hat I would have discussed in UML Distilled. I am cont inuing t o follow t he spirit of UML Distilled: t o discuss t he key elem ent s of UML as t hey affect t he applicat ion of t he UML wit hin real- world proj ect s. As ever, t he select ions and advice are m y own. I f t here is any conflict bet ween what I say and t he official UML docum ent s, t he UML docum ent s are t he ones t o follow. ( But do let m e know, so I can m ake correct ions.)

Ta ble A.1 . UM L D ist ille d a n d cor r e spon din g UM L ve r sion s UM L D ist ille d

UM L Ver sions

1 st e dit ion

UM L 1 .0 – 1 .3

2 n d e dit ion

UM L 1 .3 – 1 .4

3 r d e dit ion

UM L 2 .0 on w ar d

I have also t aken the opport unit y t o indicat e any im port ant errors and om issions in t he earlier print ings. Thanks t o t he readers who have point ed t hese out t o m e.

111/ 118

Changes from UML 1.0 to 1.1 Type and Implementation Class I n the first edit ion of UML Dist illed, I t alked about perspect ives and how t hey alt ered t he way people draw and int erpret m odels—in part icular, class diagram s. UML now t akes t his int o account by saying t hat all classes on a class diagram can be specialized as eit her t ypes or im plem ent at ion classes. An im ple m e n t a t ion cla ss corresponds t o a class in t he soft ware environm ent in which you are developing. A t ype is rat her m ore nebulous; it represent s a less im plem ent at ion- bound abst raction. This could be a CORBA t ype, a specificat ion perspect ive of a class, or a concept ual perspect ive. I f necessary, you can add st ereot ypes t o different iat e further. You can st at e that for a part icular diagram , all classes follow a part icular st ereot ype. This is what you would do when drawing a diagram from a part icular perspect ive. The im plem ent at ion perspect ive would use im plem ent at ion classes, whereas t he specificat ion and concept ual perspect ive would use t ypes. You use t he realizat ion relat ionship t o indicat e that an im plem ent at ion class im plem ent s one or m ore t ypes. There is a distinction bet ween t ype and int erface. An int erface is int ended t o direct ly correspond t o a Java or COM- st yle int erface. I nt erfaces t hus have only operat ions and no at t ribut es. You m ay use only single, st at ic classificat ion wit h im plem ent at ion classes, but you can use m ult iple and dynam ic classificat ion wit h t ypes. ( I assum e t hat this is because t he m aj or OO languages follow single, st at ic classificat ion. I f one fine day you use a language t hat support s m ult iple or dynam ic classificat ion, t hat rest riction really should not apply.)

Complete and Incomplete Discriminator Constraints I n previous print ings of UML Dist illed, I said that t he {complete} const raint on a generalizat ion indicat ed t hat all inst ances of t he supert ype m ust also be an inst ance of a subt ype wit hin t hat part it ion. UML 1.1 defines inst ead t hat {complete} indicat es t hat all subt ypes wit hin t hat part it ion have been specified, which is not quit e t he sam e t hing. I have found som e inconsist ency on t he int erpret at ion of this const raint , so you should be wary of it . I f you do want t o indicat e t hat all inst ances of t he supert ype should be an inst ance of one of t he subt ypes, I suggest using anot her const raint t o avoid confusion. Current ly, I am using {mandatory}.

Composition I n UML 1.0, using com posit ion im plied that t he link was im m ut able, or frozen, at least for singlevalued com ponent s. That const raint is no longer part of t he definit ion.

Immutability and Frozen UML defines t he const raint {frozen} t o define im m ut abilit y on associat ion roles. As it 's current ly defined, it doesn't seem t o apply it t o at t ribut es or classes. I n m y pract ice, I now use the t erm fr oze n inst ead of im m ut abilit y, and I 'm happy to apply the const raint t o associat ion roles, classes, and at t ribut es.

Returns on Sequence Diagrams I n UML 1.0, a ret urn on a sequence diagram was dist inguished by using a st ick arrowhead inst ead of a solid arrowhead ( see previous print ings) . This was som et hing of a pain, as t he dist inct ion was t oo subt le and easy t o m iss. UML 1.1 uses a dashed arrow for a ret urn, which pleases m e, as it m akes ret urns m uch m ore obvious. (As I used dashed ret urns in Analysis Pat t erns [ Fowler, AP] , it also 112/ 118

m akes m e look influent ial.) You can nam e what is ret urned for lat er use by using t he form enoughStock := check().

Use of the Term "Role" I n UML 1.0, t he t erm r ole indicat ed prim arily a direct ion on an associat ion ( see previous print ings) . UML 1.1 refers t o t his usage as an a ssocia t ion r ole . There is also a colla bora t ion role, which is a role t hat an inst ance of a class plays in a collaborat ion. UML 1.1 gives a lot m ore em phasis t o collaborat ions, and it looks as t hough t his use of " role" m ay becom e t he prim ary one.

Changes from UML 1.2 (and 1.1) to 1.3 (and 1.5) Use Cases The changes t o use cases involve new relat ionships bet ween use cases. UML 1.1 has t wo use case relat ionships: «uses» and «extends», bot h of which are st ereot ypes of generalizat ion. UML 1.3 offers three relat ionships. •

•

•

The «include» const ruct is a st ereot ype of dependency. This indicat es t hat t he pat h of one use case is included in anot her. Typically, t his occurs when a few use cases share com m on st eps. The included use case can fact or out t he com m on behavior. An exam ple from an ATM m ight be t hat Wit hdraw Money and Make Transfer bot h use Validat e Cust om er. This replaces t he com m on use of «uses». Use case ge n er a liza t ion indicat es t hat one use case is a variat ion on anot her. Thus, we m ight have one use case for Wit hdraw Money—t he base use case—and a separat e use case t o handle t he case when t he wit hdrawal is refused because of lack of funds. The refusal could be handled as a use case t hat specializes t he wit hdrawal use case. (You could also handle it as sim ply anot her scenario wit hin t he Wit hdraw Money use case.) A specializing use case like t his m ay change any aspect of t he base use case. The «extend» const ruct is a st ereot ype of dependency. This provides a m ore cont rolled form of ext ension t han t he generalizat ion relat ionship. Here, t he base use case declares a num ber of ext ension point s. The ext ending use case can alt er behavior only at t hose ext ension point s. So, if you are buying a product on line, you m ight have a use case for buying a product wit h ext ension point s for capt uring t he shipping inform at ion and capt uring paym ent inform at ion. That use case could t hen be ext ended for a regular cust om er for which t his inform at ion would be obt ained in a different way.

There is som e confusion about t he relat ionship bet ween t he old relat ionships and t he new ones. Most people used «uses» t he way t he 1.3 «includes» is used, so for m ost people, we can say that «includes» replaces «uses». And m ost people used 1.1 «extends» in bot h t he cont rolled m anner of t he 1.3 «extends» and as a general overriding in t he st yle of t he 1.3 generalizat ion. So, you can t hink t hat 1.1 «extends» has been split int o t he 1.3 «extend» and generalizat ion. Now, alt hough t his explanat ion covers m ost UML usage t hat I 've seen, it isn't t he st rict ly correct way of using t hose old relat ionships. However, m ost people didn't follow the st rict usage, and I don't really want t o get int o all t hat here.

Activity Diagrams When t he UML reached version 1.2, t here were quit e a few open quest ions about t he sem ant ics of act ivit y diagram s. So, t he 1.3 effort involved quit e a lot of t ight ening up on t hese sem ant ics. For condit ional behavior, you can now use the diam ond- shaped decision activit y for a m erge of behavior as well as a branch. Alt hough neit her branches nor m erges are necessary t o describe condit ional behavior, it is increasingly com m on st yle t o show t hem so t hat you can bracket condit ional behavior. 113/ 118

The synchronizat ion bar is now referred t o as a for k —when split t ing cont rol—or as a j oin—when synchronizing cont rol t oget her. However, you can no longer add arbit rary condit ions t o j oins. Also, you m ust follow m at ching rules t o ensure t hat forks and j oins m at ch up. Essent ially, t his m eans t hat each fork m ust have a corresponding j oin t hat j oins t he threads st art ed by t hat fork. You can nest fork and j oins, t hough, and you can elim inat e forks and j oins on t he diagram when threads go direct ly from one fork t o anot her fork, or one j oin t o anot her j oin. Joins are fired only when all incom ing t hreads com plet e. However, you can have a condit ion on a t hread com ing out of a fork. I f t hat condit ion is false, t hat thread is considered com plet e for j oining purposes. The m ult iple-t rigger feat ure is no longer present . I n it s place, you can have dynam ic concurrency in an act ivit y, shown wit h a * inside an act ivit y box. Such an act ivit y m ay be invoked several t im es in parallel; all it s invocat ions m ust com plet e before any out going t ransit ion can be t aken. This is loosely equivalent t o, alt hough less flexible than, a m ult iple t rigger and m at ching synchronizat ion condit ion. These rules reduce som e of flexibilit y of activit y diagram s but do ensure t hat act ivit y diagram s are t ruly special cases of st at e m achines. The relat ionship bet ween act ivit y diagram s and st at e m achines was a m at t er of som e debat e in t he RTF. Fut ure versions of t he UML ( aft er 1.4) m ay well m ake act ivit y diagram s a com plet ely different form of diagram .

Changes from UML 1.3 to 1.4 The m ost visible change in UML 1.4 is t he addit ion of profile s, which allows a group of ext ensions t o be collect ed t oget her int o a coherent set . The UML docum ent at ion includes a couple of exam ple profiles. Toget her wit h this, t here's great er form alism involved in defining a st ereot ype, and m odel elem ent s can now have m ult iple st ereot ypes; t hey were lim it ed t o one st ereot ype in UML 1.3. Ar t ifact s were added t o t he UML. An artifact is a physical m anifest at ion of a com ponent , so, for exam ple, Xerces is a com ponent and all t hose copies of t he Xerces j ar on m y disk drive are art ifact s t hat im plem ent t he Xerces com ponent . Prior t o 1.3, t here was not hing in t he UML m et a-m odel t o handle Java's pack a ge visibilit y. Now t here is, and t he sym bol is " ~ " . UML 1.4 also m ade t he st ick arrowhead in int eract ion diagram s m ark asynchronous, a rat her awkward backward- incom pat ible change. That caught out a few people, including m e.

Changes from UML 1.4. to 1.5 The principal change here was adding act ion sem ant ics t o t he UML, a necessary st ep t o m ake UML a program m ing language. This was done t o allow people t o work on t his wit hout wait ing for t he full UML 2.

From UML 1.x to UML 2.0 UML 2 represent s t he biggest change t hat 's happened yet t o t he UML. All sort s of t hings have changed wit h t his revision, and m any changes have affect ed UML Dist illed. Wit hin t he UML, there have been deep changes t o t he UML m et a-m odel. Alt hough t hese changes don't affect t he discussion in UML Dist illed, t hey are very im port ant t o som e groups. 114/ 118

One of t he m ost obvious changes is the int roduct ion of new diagram t ypes. Obj ect diagram s and package diagram s were widely drawn before but weren't official diagram t ypes; now t hey are. UML 2 changed t he nam e of collaborat ion diagram s t o com m unicat ion diagram s. UML 2 has also int roduced new diagram t ypes: int eract ion overview diagram s, t im ing diagram s, and com posit e st ructure diagram s. A lot of changes haven't t ouched UML Distilled. I 've left out discussion of such const ruct s as st at e m achine ext ensions, gat es in int eract ions diagram s, and power t ypes in class diagram s. So for t his section, I 'm discussing only changes t hat m ake it int o UML Distilled. These are eit her changes t o t hings I discussed in previous edit ions or new t hings I 've st art ed t o discuss wit h t his edit ion. Because t he changes are so widespread, I 've organized t hem according t o t he chapt ers in t his book.

Class Diagrams: The Essentials (Chapter 3) At t ribut es and unidirect ional associat ions are now prim arily sim ply different not at ions for the sam e underlying concept of propert y. Discont inuous m ult iplicit ies, such as [ 2, 4] , have been dropped. The frozen propert y has been dropped. I 've added a list of com m on dependency keywords, several of which are new t o UML 2. The «parameter», and «local» keywords have been dropped.

Sequence Diagrams (Chapter 4) The big change here is the int eract ion fram e not at ion for sequence diagram s t o handle it erat ive, condit ional, and various ot her cont rols of behavior. This now allows you t o express algorit hm s pret t y com plet ely in sequence diagram s, alt hough I 'm not convinced that t hese are any clearer t han code. The old it erat ion m arkers and guards on m essages have been dropped from sequence diagram s. The heads of t he lifelines are no longer inst ances; I use the t erm pa r t icipa n t t o refer t o t hem . The collaborat ion diagram s of UML 1 were renam ed t o com m unicat ion diagram s for UML 2.

Class Diagrams: Concepts (Chapter 5) St ereot ypes are now m ore t ight ly defined. As a result , I now refer t o words in guillem et s as keywords, only som e of which are st ereot ypes. I nst ances on obj ect diagram s are now inst ance specificat ions. Classes can now require int erfaces as well as provide t hem . Mult iple classificat ion uses generalizat ion set s t o group generalizat ions int o groups. Com ponent s are no longer drawn wit h t heir special sym bol. Act ive obj ect s have double vert ical lines inst ead of t hick lines.

State Machine Diagrams (Chapter 10) UML 1 separat ed short - lived act ions from long-lived act ivit ies. UML 2 calls bot h act ivit ies and uses t he t erm do- act ivit y for t he long-lived act ivit ies.

Activity Diagrams (Chapter 11) UML 1 t reat ed act ivit y diagram s as a special case of st at e diagram . UML 2 broke t hat link and as a result rem oved the rules of m at ching forks and j oins t hat UML 2 activit y diagram s had t o keep t o. As a result , t hey are best underst ood by t oken flow rat her t han by st at e t ransit ion. A whole bunch of new not at ion t hus appeared, including t im e and accept signals, param et ers, j oin specificat ions, pins, flow t ransform at ions, subdiagram rakes, expansion regions, and flow finals. A sim ple but awkward change is t hat UML 1 t reat ed m ult iple incom ing flows t o an act ivit y as an im plicit m erge, while UML 2 t reat s t hem as an im plicit j oin. For t his reason, I advise using an explicit m erge or j oin when doing act ivit y diagram s. Swim lanes can now be m ult idim ensional and are generally called part it ions.

115/ 118

Bibliography [ Am ble r] Scot t Am bler, Agile Modeling, Wiley, 2002. [ Be ck] Kent Beck, Ext rem e Program m ing Explained: Em brace Change, Addison- Wesley, 2000. [ Be ck an d Fow le r] Kent Beck and Mart in Fowler, Planning Ext rem e Program m ing, Addison-Wesley, 2000. [ Be ck an d Cu n n in gha m ] Kent Beck and Ward Cunningham , "A Laborat ory for Teaching Obj ectOrient ed Thinking," Proceedings of OOPSLA 89 , 24 (10) : 1–6. h t t p:/ / c2 .com / doc/ oopsla 8 9 / pa pe r .h t m l [ Booch , OOAD] Grady Booch, Obj ect - Orient ed Analysis and Design wit h Applicat ions, Second Edit ion. Addison-Wesley, 1994. [ Booch , UM L u se r ] Grady Booch, Jim Rum baugh, and I var Jacobson, UML User Guide, AddisonWesley, 1999. [ Coa d, OOA] Pet er Coad and Edward Yourdon, Obj ect - Orient ed Analysis, Yourdon Press, 1991. [ Coa d, OOD ] Pet er Coad and Edward Yourdon, Obj ect - Orient ed Design, Yourdon Press, 1991. [ Cock bur n , a gile ] Alist air Cockburn, Agile Soft ware Developm ent , Addison-Wesley, 2001. [ Cock bur n , u se ca se s] Alist air Cockburn, Writ ing Effect ive Use Cases, Addison-Wesley, 2001. [ Con st an t in e a n d Lockw ood] Larry Const ant ine and Lucy Lockwood, Soft ware for Use, AddisonWesley, 2000. [ Cook a n d Da n ie ls] St eve Cook and John Daniels, Designing Obj ect Syst em s: Obj ect -Orient ed Modeling wit h Synt ropy , Prent ice-Hall, 1994. [ Cor e J2 EE Pa t t e rn s] Deepak Alur, John Crupi, and Dan Malks, Core J2EE Pat t erns, Prent ice-Hall, 2001. [ Cu n n in gha m ] Ward Cunningham , "EPI SODES: A Pat t ern Language of Com pet it ive Developm ent ." I n Pat t ern Languages of Program Design 2 , Vlissides, Coplien, and Kert h, Addison-Wesley, 1996, pp. 371–388. [ D ou glass] Bruce Powel Douglass, Real- Tim e UML, Addison-Wesley, 1999. [ Fow le r , AP] Mart in Fowler, Analysis Pat t erns: Reusable Obj ect Models, Addison-Wesley, 1997. [ Fow le r , ne w m e t hodology] Mart in Fowler, " The New Met hodology," h t t p:/ / m a r t in fow le r .com / a r t icle s/ n e w M e th odology.h t m l [ Fow le r a n d Foe m m e l] Mart in Fowler and Mat t hew Foem m el, " Cont inuous I nt egrat ion," h t t p:/ / m a r t in fow le r .com / a r t icle s/ con t in u ou sI n te gr a t ion .h t m l [ Fow le r , P of EAA] Martin Fowler, Pat t erns of Ent erprise Applicat ion Archit ect ure, Addison-Wesley, 2003. [ Fow le r , re fact or in g] Mart in Fowler, Refact oring: I m proving t he Design of Existing Program s, Addison-Wesley, 1999.

116/ 118

[ Ga n g of Fou r] Erich Gam m a, Richard Helm , Ralph Johnson, and John Vlissides, Design Pat t erns: Elem ent s of Reusable Obj ect - Orient ed Soft ware, Addison-Wesley, 1995. [ H igh sm it h ] Jim Highsm it h, Agile Soft ware Developm ent Ecosyst em s, Addison-Wesley, 2002. [ H oh m an n ] Luke Hohm ann, Beyond Soft ware Archit ecture, Addison-Wesley, 2003. [ Ja cobson , OOSE] I var Jacobson, Magnus Christ erson, Pat rik Jonsson, and Gunnar Övergaard, Obj ect - Orient ed Soft ware Engineering: A Use Case Driven Approach , Addison-Wesley, 1992. [ Ja cobson , UP] I var Jacobson, Maria Ericsson, and Agnet a Jacobson, The Obj ect Advant age: Business Process Reengineering wit h Obj ect Technology , Addison-Wesley, 1995. [ Ke r t h] Norm Kert h, Proj ect Ret rospect ives, Dorset House, 2001 [ Kle ppe e t a l.] Anneke Kleppe, Jos Warm er, and Wim Bast , MDA Explained, Addison-Wesley, 2003. [ Kr u ch t e n] Philippe Krucht en, The Rat ional Unified Process: An I nt roduct ion , Addison- Wesley, 1999. [ La r m an ] Craig Larm an, Applying UML and Pat t erns, 2d ed., Prent ice-Hall, 2001. [ M a r t in] Robert Cecil Mart in, The Principles, Pat t erns, and Pract ices of Agile Soft ware Developm ent , Prent ice- Hall, 2003. [ M cCon ne ll] St eve McConnell, Rapid Developm ent : Tam ing Wild Soft ware Schedules, Microsoft Press, 1996. [ M e llor an d Ba lcer ] St eve Mellor and Marc Balcer, Execut able UML, Addison-Wesley, 2002. [ M e yer ] Bert rand Meyer, Obj ect - Orient ed Soft ware Const ruct ion. Prent ice-Hall, 2000. [ Ode ll] Jam es Mart in and Jam es J. Odell, Obj ect - Orient ed Met hods: A Foundat ion (UML Edit ion) , Prent ice Hall, 1998. [ Pon t ] Michael Pont , Pat t erns for Tim e- Triggered Em bedded Syst em s, Addison-Wesley, 2001. [ POSA1 ] Frank Buschm ann, Regine Meunier, Hans Rohnert , Pet er Som m erlad, and Michael St al, Pat t ern- Orient ed Soft ware Archit ecture: A Syst em of Pat t erns, Wiley, 1996. [ POSA2 ] Douglas Schm idt , Michael St al, Hans Rohnert , and Frank Buschm ann, Pat t ern- Orient ed Soft ware Archt ect ure Volum e 2: Pat t erns for Concurrent and Net worked Obj ect s , Wiley, 2000. [ Ru m ba u gh , in sigh t s] Jam es Rum baugh, OMT I nsight s, SI GS Books, 1996. [ Ru m ba u gh , OMT] Jam es Rum baugh, Michael Blaha, William Prem erlani, Frederick Eddy, and William Lorenzen, Obj ect - Orient ed Modeling and Design, Prent ice-Hall, 1991. [ Ru m ba u gh , UM L Re fe r en ce] Jam es Rum baugh, I var Jacobson, and Grady Booch, The Unified Modeling Language Reference Manual, Addison-Wesley, 1999. [ Sh la er a n d M e llor , da t a ] Sally Shlaer and St ephen J. Mellor, Obj ect - Orient ed Syst em s Analysis: Modeling t he World in Dat a, Yourdon Press, 1989. [ Sh la er a n d M e llor , st a t e s] Sally Shlaer and St ephen J. Mellor, Obj ect Lifecycles: Modeling t he World in St at es. Yourdon Press, 1991.

117/ 118

[ W a r m e r an d Kle ppe ] Jos Warm er and Anneke Kleppe, The Obj ect Const raint Language: Precise Modeling wit h UML, Addison-Wesley, 1998. [ W ir fs- Br ock ] Rebecca Wirfs- Brock and Alan McKean, Obj ect Design: Roles Responsibilit ies and Collaborat ions. Prent ice-Hall, 2003.

118/ 118