Applying Use Case Driven Object Modeling with UML: An Annotated e-Commerce Example [annotated edition] 9780201730395, 0201730391

Citation preview

@htrung Release

Applyin g Use Ca se D r ive n Obj e ct M ode lin g w it h UM L: An An n ot a t e d e - Com m e r ce Ex a m ple Doug Rosenberg Kendall Scot t Publisher: Addison Wesley First Edit ion June 14, 2001 I SBN: 0- 201- 73039- 1, 176 pages

Front Mat t er Table of Cont ent s About t he Aut hor

Applying Use Case Driven Obj ect Modeling wit h UML: An Annot at ed e- Com m erce Exam ple is a pract ical, hands- on guide t o put t ing use case m et hods t o work in real- world sit uat ions. This workbook is a com panion t o Use Case Driven Obj ect Modeling wit h UML. I t bridges t he gap bet ween t he t heory present ed in t he m ain book and t he pract ical issues involved in t he developm ent of an I nt ernet e- com m erce applicat ion. Uniquely conceived as a workbook and feat uring as a running exam ple an e- com m erce syst em for an online bookst ore, Applying Use Case Driven Obj ect Modeling wit h UML exam ines design in det ail, dem onst rat ing t he m ost com m on design m ist akes and t he correct design solut ions. The hands- on exercises allow you t o det ect , ident ify, and correct crit ical errors on your own, before reviewing t he solut ions provided in t he book. St ruct ured around t he proven I CONI X Process, t his workbook present s a st ream lined approach t o UML m odeling designed t o avoid analysis paralysis wit hout skipping analysis and design. The book present s t he four key phases of t his m inim alist approach t o use case driven design- - dom ain m odeling, use case m odeling, robust ness analysis, and sequence diagram m ing- - and for each t opic provides an overview, det ailed discussion, list of com m on m ist akes, and a set of exercises for honing obj ect m odeling and design skills. The t hree chapt ers on reviews are also unique. The aut hors devot e a chapt er each t o requirem ent s review, prelim inary design review, and crit ical design review. This focus on " designing qualit y in" by t eaching how t o review UML m odels fills a m aj or gap in t he published lit erat ure. Through exam ples, Applying Use Case Driven Obj ect Modeling wit h UML shows you how t o avoid m ore t han sevent y specific design errors, as illust rat ed by t he " Top 10" error list s included as a handy key on t he inside covers and wit hin each chapt er. Wit h t he inform at ion, exam ples, and exercises found here, you will develop t he knowledge and skills you need t o apply use case m odeling m ore effect ively t o your next applicat ion.

Applyin g Use Ca se D r ive n Obj e ct M ode lin g w it h UM L: An An n ot a t e d e - Com m e r ce Ex a m ple Many of t he designat ions used by t he m anufact urers and sellers t o dist inguish t heir product s are claim ed as t radem arks. Where t hose designat ors appear in t his book, and Addison- Wesley was aware of t he t radem ark claim , t he designat ions have been print ed in it ial capit al let t ers or all capit al let t ers. The aut hors and publisher have t aken care in preparat ion of t his book, but m ake no expressed or im plied warrant y of any kind and assum e no responsibilit y for errors or om issions. No liabilit y is assum ed for incident al or consequent ial dam ages in connect ion wit h or arising out of t he use of t he inform at ion or program s cont ained herein. The publisher offers discount s on t his book when ordered in quant it y for special sales. For m ore inform at ion, please cont act : Pearson Educat ion Corporat e Sales Division One Lake St reet Upper Saddle River, NJ 07458 ( 800) 382- 3419 corpsales@pearsont echgroup.com Visit us on t he Web at www.awl.com / cseng/ . Libr a r y of Con gr e ss Ca t a login g- in- Pu blica t ion D a t a Rosenberg, Doug. Applying use case driven obj ect m odeling wit h UML: an annot at ed e- com m erce exam ple / Doug Rosenberg, Kendall Scot t . p. cm .

1. Obj ect - orient ed m et hods ( Com put er science) 2. UML ( Com put er science) 3. Use cases ( syst em s engineering) 4. E- com m erce. I . Scot t , Kendall, 1960- I I . Tit le. QA76.9.O35 R63 2001 005.1'17—dc21 2001034319 © 2001 by Addison- Wesley. All right s reserved. No part of t his publicat ion m ay be reproduced, st ored in a ret rieval syst em , or t ransm it t ed, in any form or by any m eans, elect ronic, m echanical, phot ocopying, recording, or ot herwise, wit hout t he prior writ t en consent of t he publisher. Print ed in t he Unit ed St at es of Am erica. Published sim ult aneously in Canada. Text print ed on recycled and acid- free paper 1 2 3 4 5 6 7 8 9–CRW–05 04 03 02 01 First print ing, June 2001 We dedicat e t his book t o t he m em ory of Tom Johnson, whose st eady and dependable work kept bot h of us busy t eaching t he t raining workshops t hat gave us t he source m at erial for t his book. Tom ’s unt im ely passing as t he m anuscript was in final product ion saddened all of us who knew him . He will be sorely m issed.

About the author Doug Rosenberg, Kendall Scott Doug Rosenberg, of ICONIX Software Engineering, Inc., has been providing system development tools and training for nearly two decades, with particular emphasis on object-oriented methods. He developed a Unified Booch/Rumbaugh/Jacobson design method in 1993 that preceded Rational's UML by several years. He has produced over a dozen multimedia training courses on object technology, including COMPREHENSIVE COM and COMPLETE CORBA, and is the author of several Addison-Wesley titles. Kendall Scott provides UML training and mentoring on a nationwide basis through ICONIX. He has written several Addison-Wesley titles, including UML Explained. He is also the supporting author of UML Distilled UML Distilled, Second Edition and Use Case Driven Object Modeling with UML.

Figures ..................................................................................................................................................... 6 Preface ..................................................................................................................................................... 8 Theory, in Pract ice ........................................................................................................................... 8 The Prem ise ....................................................................................................................................... 8 Acknowledgm ent s .......................................................................................................................... 10 Chapt er 1. I nt roduct ion ................................................................................................................... 12 A Walk ( Backwards) t hrough t he I CONI X Process ............................................................ 12 Key Feat ures of t he I CONI X Process ...................................................................................... 21 Process Fundam ent als ................................................................................................................. 22 The Process in a Nut shell ............................................................................................................ 23 Requirem ent s List for The I nt ernet Bookst ore ................................................................... 25 Chapt er 2. Dom ain Modeling ......................................................................................................... 27 The Key Elem ent s of Dom ain Modeling ................................................................................. 28 The Top 10 Dom ain Modeling Errors ...................................................................................... 29 Exercises ........................................................................................................................................... 32 Bringing t he Pieces Toget her ..................................................................................................... 37 Chapt er 3. Use Case Modeling ...................................................................................................... 39 The Key Elem ent s of Use Case Modeling .............................................................................. 40 The Top 10 Use Case Modeling Errors ................................................................................... 41 Exercises ........................................................................................................................................... 44 Bringing t he Pieces Toget her ..................................................................................................... 50 Chapt er 4. Requirem ent s Review ................................................................................................ 52 The Key Elem ent s of Requirem ent s Review ........................................................................ 52 The Top 10 Requirem ent s Review Errors ............................................................................. 54 Chapt er 5. Robust ness Analysis ................................................................................................... 58 The Key Elem ent s of Robust ness Analysis ........................................................................... 60 The Top 10 Robust ness Analysis Errors ................................................................................ 62 Exercises ........................................................................................................................................... 65 Bringing t he Pieces Toget her ..................................................................................................... 74 Chapt er 6. Prelim inary Design Review ...................................................................................... 76 The Key Elem ent s of Prelim inary Design Review .............................................................. 76 The Top 10 PDR Errors ................................................................................................................ 79 Chapt er 7. Sequence Diagram s.................................................................................................... 82 The Key Elem ent s of Sequence Diagram s............................................................................ 82 Get t ing St art ed wit h Sequence Diagram s ............................................................................ 84 The Top 10 Sequence Diagram m ing Errors ......................................................................... 86 Exercises ........................................................................................................................................... 89 Bringing t he Pieces Toget her ..................................................................................................... 96 Chapt er 8. Crit ical Design Review ............................................................................................. 100 The Key Elem ent s of Crit ical Design Review ..................................................................... 100 The Top 10 CDR Errors .............................................................................................................. 104 Appendix Appendix .......................................................................................................................... 108 USE CASE VI EW REPORT .......................................................................................................... 108 Bibliography ....................................................................................................................................... 126

Figu r e s Figure 1- 1: Use Cases t o Code Figure 1- 2: St art ing Off Figure 1- 3: Class Diagram s Map Out t he St ruct ure of t he Code Figure 1- 4: Sequence Diagram s Help Us Allocat e Operat ions ( Behavior) t o Classes Figure 1- 5: Robust ness Diagram s Close t he Gap Bet ween Requirem ent s and Det ailed Design Figure 1- 6: Referencing Dom ain Obj ect s by Nam e Rem oves Am biguit y from t he Use Cases Figure 1- 7: The I CONI X Process—A St ream lined Approach t o UML Modeling Figure 1- 8: Requirem ent s Analysis Figure 1- 9: Analysis and Prelim inary Design Figure 1- 10: Design Figure 1- 11: I m plem ent at ion Figure 2- 1: Dom ain Modeling and t he I CONI X Process Figure 2- 2: Dom ain Model for The I nt ernet Bookst ore Figure 3- 1: The I CONI X Process I s Use Case Driven Figure 3- 2: Use Case Diagram for The I nt ernet Bookst ore Figure 4- 1: Requirem ent s Review and t he I CONI X Process Figure 5- 1: Robust ness Diagram Sym bols Figure 5- 2: Robust ness Analysis Bridges t he Gap Bet ween What and How Figure 5- 3: Robust ness Analysis Helps You Refine t he Use Case Text and t he Dom ain Model Figure 5- 4: Robust ness Model–St at ic Model Feedback Loop Figure 5- 5: Robust ness Diagram Rules Figure 5- 6: Dom ain Model wit h At t ribut es for The I nt ernet Bookst ore Figure 6- 1: Prelim inary Design Review and t he I CONI X Process Figure 7- 1: Sequence Diagram s Drive t he Allocat ion of Behavior t o Soft ware Classes

Figure 7- 2: Building a Sequence Diagram Figure 7- 3: St at ic Model for The I nt ernet Bookst ore ( Part 1) Figure 7- 4: St at ic Model for The I nt ernet Bookst ore ( Part 2) Figure 7- 5: St at ic Model for The I nt ernet Bookst ore ( Part 3) Figure 8- 1: Crit ical Design Review and t he I CONI X Process

Pr e fa ce Th e or y, in Pr a ct ice I n our first book, Use Case Driven Obj ect Modeling wit h UML, we suggest ed t hat t he difference bet ween t heory and pract ice was t hat in t heory, t here is no difference bet ween t heory and pract ice, but in pract ice, t here is. I n t hat book, we at t em pt ed t o reduce OOAD m odeling t heory t o a pract ical subset t hat was easy t o learn and pret t y m uch universally applicable, based on our experience in t eaching t his m at erial t o people working on hundreds of proj ect s since about 1993. Now, t wo years aft er hit t ing t he shelves, t hat book is in it s fift h print ing. But even t hough our work has been favorably received, it seem s like t he j ob isn’t all t he way done yet . “ We need t o see m ore use case and UML m odeling exam ples” is a phrase we’ve been hearing fairly oft en over t he last couple of years. And, as we’ve used t he first book as t he backbone of t raining workshops where we apply t he t heory t o real client proj ect s, it has becom e clear t hat t he process of reviewing t he m odels is crit ically im port ant and not well underst ood by m any folks. So, alt hough we present a fairly ext ensive exam ple in our first book, we convinced Addison- Wesley t o let us produce t his com panion workbook, in which we dissect t he design of an I nt ernet bookst ore, st ep- by- st ep, in great det ail. This involves showing m any com m on m ist akes, and t hen showing t he relevant pieces of t he m odel wit h t heir m ist akes correct ed. We chose an I nt ernet bookst ore because it ’s relevant t o m any of t oday’s proj ect s in t he Web- driven world, and because we’ve been t eaching workshops using t his exam ple and, as a result , had a rich source of classroom UML m odels wit h real st udent m ist akes in t hem . We collect ed som e of our favorit e m ist akes—t hat is, t he kind of m ist akes we saw get t ing repeat ed over and over again—and built t his workbook around t hose m odels. And t hen we added t hree new chapt ers about reviews—one on requirem ent s reviews, one on prelim inary design reviews, and one on crit ical design reviews. What really m akes t his book unique, t hough, is t he fact t hat you, t he reader, get t o correct t he m ist akes.

Th e Pr e m ise Aft er we give you an overview of t he I CONI X process in Chapt er 1, four of t he seven subsequent chapt ers address t he four key phases of t he process in som e det ail. The form at of each of t hese chapt ers is as follows: ?? The first part describes t he essence of dom ain m odeling ( Chapt er 2) , use case m odeling ( Chapt er 3) , robust ness analysis ( Chapt er 5) , or sequence diagram s ( Chapt er 7) , and places t he m at erial in t he cont ext of t he “ big pict ure” of t he process. I n each of t hese chapt ers, you’ll work t hrough pieces of t he I nt ernet bookst ore exam ple, and t hen you’ll see an overview diagram at t he end of t he chapt er t hat brings t he relevant pieces t oget her. We present fragm ent s of t en different use cases in Chapt er 3; we carry five of t hese forward t hrough prelim inary design and det ailed design in Chapt ers 5 and 7, respect ively. ( The

fragm ent s of class diagram s t hat appear in Chapt er 2 also t race int o t he use case t ext and t o full class diagram s t hat appear in Chapt ers 5 and 7.) ?? The next sect ion describes t he key elem ent s of t he given phase. Each of t hese sect ions is basically a condensed version of an associat ed chapt er in Use Case Driven Obj ect Modeling wit h UML, wit h som e new inform at ion added wit hin each chapt er. ?? The following sect ion describes t he t op 10 m ist akes t hat our st udent s t end t o m ake during workshops in which we t each t he process. We’ve added five new Top 10 list s in t his book: Top 10 robust ness analysis errors, Top 10 sequence diagram m ing errors, and Top 10 m ist akes t o avoid for each of t he t hree “ review” chapt ers. ?? The final sect ion present s a set of five exercises for you t o work, t o t est your knowledge of t he m at erial in t he chapt er. The following aspect s are com m on t o each set of exercises: ?? There’s a red box, wit h a whit e label, at t he t op of each right - hand page. For t he dom ain m odeling and use case exercises, t his label t akes t he form Exercise X; for t he robust ness analysis and sequence diagram exercises, t he label t akes t he form of a use case nam e. ( We’ll explain t he significance of t his soon.) ?? There are t hree or four m ist akes on each right - hand page. Each m ist ake has a “ Top 10” logo next t o it t hat indicat es which rule is being violat ed. ?? The left - hand page on t he flip side of each “ red” page has a black box, wit h a whit e label, at t he t op. Correct ions t o t he errors present ed on t he associat ed “ bad” page are explicit ly indicat ed; explanat ions of t he m ist akes appear at t he bot t om of t he page. Your t ask is t o writ e correct ions on each “ bad” exercise page before you flip it over t o see t he “ good” exercise diagram . To sum m arize: Chapt er 2 present s classes used by t he t en sam ple use cases. Chapt er 3 present s fragm ent s from all of t hose use cases. Chapt ers 5 and 7 present diagram s connect ed wit h five of t he use cases. The idea is t hat you’ll m ove from a part ial underst anding of t he use cases t hrough t o sequence diagram s t hat present full t ext , and som e of t he associat ed elem ent s of t he det ailed design, for each use case. What about t he ot her t hree chapt ers, you ask? ?? Chapt er 4 describes how t o perform requirem ent s review, which involves t rying t o ensure t hat t he use cases and t he dom ain m odel work t oget her t o address t he cust om ers’ funct ional requirem ent s. ?? Chapt er 6 describes how t o perform prelim inary design review ( PDR) , which involves t rying t o ensure t hat robust ness diagram s exist for all use cases ( and are consist ent wit h t hose use cases) , t he dom ain m odel has a fairly rich set of at t ribut es t hat correspond well wit h what ever prot ot ypes are in place ( and all of t he obj ect s needed by t he use cases are represent ed in t hat m odel) , and t he developm ent t eam is ready t o m ove t o det ailed design.

?? Chapt er 8 describes how t o perform crit ical design review ( CDR) , which involves t rying t o ensure t hat t he “ how” of det ailed design, as shown on sequence diagram s, m at ches up well wit h t he “ what ” t hat t he use cases specify, and t hat t he det ailed design is of sufficient dept h t o facilit at e a relat ively sm all and seam less leap int o code. All t hree of t hese review chapt ers offer overviews, det ails, and t op 10 list s, but we don’t m ake you work any m ore exercises. What t hese reviews have in com m on is t he goal of ensuring consist ency of t he various part s of t he m odel, as expressed on t he “ good” exercise diagram s. The Appendix cont ains a report t hat sum m arizes t he m odel for t he bookst ore; you can download t he full m odel from ht t p: / / www.iconixsw.com / WorkbookExam ple.ht m l. The Appendix cont ains all of t he diagram s t hat appear in t he body of t he book, but t he full m odel includes design det ails for t he ot her five use cases. This allows you t o go t hrough t hese use cases as furt her exercises, and t hen com pare your result s t o ours; we highly recom m end t hat you do t his. Cool prem ise, isn’t it ? We’re not aware of anot her book like t his one, and we’re hoping you’ll find it useful in your effort s t o apply use case driven obj ect m odeling wit h UML.

Ack n ow le dgm e n t s Doug would like t o t hank his int repid crew at I CONI X, especially Andrea Lee for her work on t he script for t he I nside t he I CONI X Process CD, which we borrowed heavily from for Chapt er 1, along wit h Chris St arczak, Jeff Kant or, and Erin Arnold. Doug would also like t o t hank Kendall for ( finally) agreeing t hat yes, t his would m ake t he book bet t er, and yes, we do have t im e t o add t hat , and yes, t he fact t hat R com es before S does m ean t hat Mr. Rosenberg has m ore vot es t han Mr. Scot t . [ Co- aut hor’s not e t o self: Get nam e legally changed t o Scot t Kendall before t he next book com es out . That ’ll t each him .] Doug and Kendall would like t o t hank Paul Becker and all t he fine folks at AddisonWesley ( including Ross Venables, who’s no longer t here but who got t his proj ect off t he ground) who som ehow m anaged t o com press t he product ion schedule t o com pensat e for t he delays in t he writ ing schedule ( w hich are all Kendall’s fault ) . We’d also like t o t hank t he reviewers of t he m anuscript , especially Mark Woodbury, whose incisive com m ent s about “ defragm ent ing” t he exam ple gave us t he push we needed t o get it t he point where we t hink it ’s really, really cool as opposed t o j ust really cool. And, we’d like t o t hank Greg Wilson, who reviewed our first book for Dr. Dobbs’ Journal, liked it , and suggest ed t hat we writ e a com panion workbook. Specifically, he said: “ The second crit icism of t his book is one t hat I t hought I ’d never m ake: I t is sim ply t oo short . Having finally found a useful, readable, and pract ical descript ion of a design- cent ered developm ent m et hodology, I really want ed a dozen or m ore exam ples of each point t o work t hrough. I f t he aut hors were t o produce a com panion workbook, I can prom ise t hem t hat t hey’d have at least one buyer.” Finally, Kendall would like t o t hank Doug for raising t he art of snarkiness t o a level t hat m akes Kendall look like a paragon of good cheer in com parison t o Doug.

Doug Rosenberg

Kendall Scot t

Sant a Monica, California May 2001 [email protected] ht t p: / / www.iconixsw.com

Harrison, Tennessee May 2001 [email protected] ht t p: / / www.usecasedriven.com

Ch a pt e r 1 . I n t r odu ct ion The I CONI X process sit s som ewhere in bet ween t he very large Rat ional Unified Process ( RUP) and t he very sm all eXt rem e program m ing approach ( XP) . The I CONI X process is use case driven, like t he RUP, but wit hout a lot of t he overhead t hat t he RUP brings t o t he t able. I t ’s also relat ively sm all and t ight , like XP, but it doesn’t discard analysis and design like XP does. This process also m akes st ream lined use of t he Unified Modeling Language ( UML) while keeping a sharp focus on t he t raceabilit y of requirem ent s. And, t he process st ays t rue t o I var Jacobson’s original vision of what “ use case driven” m eans, in t hat it result s in concret e, specific, readily underst andable use cases t hat a proj ect t eam can act ually use t o drive t he developm ent effort . The approach we follow t akes t he best of t hree m et hodologies t hat cam e int o exist ence in t he early 1990s. These m et hodologies were developed by t he folks t hat now call t hem selves t he “ t hree am igos” : I var Jacobson, Jim Rum baugh, and Grady Booch. We use a subset of t he UML, based on Doug’s analysis of t he t hree individual m et hodologies. There’s a quot e in Chapt er 32 of The Unified Modeling Language User Guide, writ t en by t he am igos, t hat says, “ You can m odel 80 percent of m ost problem s by using about 20 percent of t he UML.” However, nowhere in t his book do t he aut hors t ell you which 20 percent t hat m ight be. Our subset of t he UML focuses on t he core set of not at ions t hat you’ll need t o do m ost of your m odeling work. Wit hin t his workbook we also explain how you can use ot her elem ent s of t he UML and where t o add t hem as needed. One of our favorit e quot es is, “ The difference bet ween t heory and pract ice is t hat in t heory, t here is no difference bet ween t heory and pract ice, but in pract ice, t here is.” I n pract ice, t here never seem s t o be enough t im e t o do m odeling, analysis, and design. There’s always pressure from m anagem ent t o j um p t o code, t o st art coding prem at urely because progress on soft ware proj ect s t ends t o get m easured by how m uch code exist s. Our approach is a m inim alist , st ream lined approach t hat focuses on t hat area t hat lies in bet ween use cases and code. I t s em phasis is on what needs t o happen at t hat point in t he life cycle where you’re st art ing out : you have a st art on som e use cases, and now you need t o do a good analysis and design. Our goal has been t o ident ify a m inim al yet sufficient subset of t he UML ( and of m odeling in general) t hat seem s generally t o be necessary in order t o do a good j ob on your soft ware proj ect . We’ve been refining our definit ion of “ m inim al yet sufficient ” in t his cont ext for eight or nine years now. The approach we’re t elling you about in t his workbook is one t hat has been used on hundreds of proj ect s and has been proven t o work reliably across a wide range of indust ries and proj ect sit uat ions.

A W a lk ( Ba ck w a r ds) t h r ou gh t h e I CON I X Pr oce ss Figure 1- 1 shows t he key quest ion t hat t he I CONI X process aim s t o answer. Figur e 1 - 1 . Use Ca se s t o Code

What we’re going t o illust rat e is how t o get from point A t o point B direct ly, in t he short est possible t im e. ( Act ually, we’re not going t o go all t he way t o code, but we’ll t ake you close enough so you can t ast e it .) You can t hink of point A as represent ing t his t hought : “ I have an idea of what m y syst em has t o do, and I have a st art on som e use cases,” and point B as represent ing som e com plet ed, t est ed, debugged code t hat act ually does what t he use cases said it needed t o do. I n ot her words, t he code im plem ent s t he required behavior, as defined by t he use cases. This book focuses on how we can get you from t he fuzzy, nebulous area of “ I t hink I want it t o do som et hing like t his” t o m aking t hose descript ions unam biguous, com plet e, and rigorous, so you can produce a good, solid archit ect ure, a robust soft ware design, t hen ( by ext ension) nice clean code t hat act ually im plem ent s t he behavior t hat your users want . We’re going t o work backwards from code and explain t he st eps t o our goal. We’ll explain why we t hink t he set of st eps we’re going t o t each is t he m inim al set of st eps you need, yet is sufficient for m ost cases in closing t he gap bet ween use cases and code. Figure 1- 2 shows t he t hree assum pt ions we’re going t o m ake t o st art t hings off: t hat we’ve done som e prot ot yping; t hat we have m ade som e idea of what our user int erface m ight look like; and t hat we m ight have som e st art in ident ifying t he scenarios or use cases in our syst em . Figur e 1 - 2 . St a r t in g Off

This put s us at t he point where we’re about t o launch int o analysis and design. What we want t o find out is how we can get from t his st art ing point t o code. When we begin, t here’s only a big quest ion m ark—we have som e nebulous, fuzzy ideas of what our syst em has t o do, and we need t o close t his gap before we st art coding. I n obj ect - orient ed syst em s, t he st ruct ure of our code is defined by classes. So, before we writ e code, we’d like t o know what our soft ware classes are going t o be. To do t his, we need one or m ore class diagram s t hat show t he classes in t he syst em . On each of t hese classes, we need a com plet e set of at t ribut es, which are t he dat a m em bers cont ained in t he classes, and operat ions, which define what t he soft ware funct ions are. I n ot her words, we need t o have all our soft ware funct ions ident ified, and we need t o m ake sure we have t he dat a t hose funct ions require t o do t heir j ob. We’ll need t o show how t hose classes encapsulat e t hat dat a and t hose funct ions. We show how our classes are organized and how t hey relat e t o each ot her on class diagram s. We’ll use t he UML class diagram as t he vehicle t o display t his inform at ion. Ult im at ely, what we want t o get t o is a set of very det ailed design- level class diagram s. By de sign- le ve l, we m ean a level of det ail where t he class diagram is very m uch a t em plat e for t he act ual code of t he syst em —it shows exact ly how your code is going t o be organized. Figure 1- 3 shows t hat class diagram s are t he st ep before code, and t here is a design- level diagram t hat m aps one- t o- one from classes on your diagram t o classes in your source code. But t here’s st ill a gap. I nst ead of going from use cases t o code, now we need t o get from use cases t o design- level class diagram s. Figur e 1 - 3 . Cla ss D ia gr a m s M a p Ou t t h e St r u ct u r e of t h e Code

One of t he hardest t hings t o do in obj ect - orient ed soft ware developm ent is be ha vior a lloca t ion, which involves m aking decisions for every soft ware funct ion t hat you’re going t o build. For each funct ion, you have t o decide which class in your soft ware design should be t he class t hat cont ains it . We need t o allocat e all t he behavior of t he syst em —every soft ware funct ion needs t o be allocat ed int o t he set of classes t hat we’re designing. One UML diagram t hat ’s ext rem ely useful in t his area is t he sequence diagram . This diagram is an ideal vehicle t o help you m ake t hese behavior allocat ion decisions. Sequence diagram s are done on a per- scenario basis: for every scenario in our syst em , we’ll draw a sequence diagram t hat shows us which obj ect is responsible for which funct ion in our code. The sequence diagram shows how runt im e obj ect inst ances com m unicat e by passing m essages. Each m essage invokes a soft ware funct ion on t he obj ect t hat receives t he m essage. This is why it ’s an ideal diagram for visualizing behavior allocat ion. Figure 1- 4 shows t hat t he gap bet ween use cases and code is get t ing sm aller as we cont inue t o work backwards. Now, we need t o get from use cases t o sequence diagram s. Figur e 1 - 4 . Se que nce D ia gr a m s H e lp Us Alloca t e Ope r a t ions ( Be ha vior ) t o Cla sse s

We’ll m ake our decisions about allocat ing behavior t o our classes as we draw t he sequence diagram s. That ’s going t o put t he operat ions on t he soft ware classes. When you use a visual m odeling t ool such as Rat ional Rose or GDPro, as you draw t he m essage arrows on t he sequence diagram s, you’re act ually physically assigning operat ions t o t he classes on t he class diagram s. The t ool enforces t he fact t hat behavior allocat ion happens from t he sequence diagram . As you’re drawing t he sequence diagram , t he classes on t he class diagram get populat ed wit h operat ions. So, t he t rick is t o get from use cases t o sequence diagram s. This is a non- t r ivial problem in m ost cases because t he use cases present a requirem ent s- level view of t he syst em , and t he sequence diagram is a very det ailed design view. This is where our approach is different from t he ot her approaches on t he m arket t oday. Most approaches t alk about use cases and sequence diagram s but don’t address how t o get across t he gap bet ween t he fuzzy use cases and a code- like level of det ail on t he sequence diagram s. Get t ing across t his gap bet ween what and how is t he cent ral aspect of t he I CONI X process. What we’re going t o do now is close t he gap bet ween t he fuzzy, nebulous use case and t he very det ailed and precise sequence diagram wit h anot her kind of diagram called a r obust ne ss dia gr a m . The robust ness diagram sit s in t he gap bet ween requirem ent s and det ailed design; it will help m ake get t ing from t he use cases t o t he sequence diagram s easier. I f you’ve been looking at UML lit erat ure, t he robust ness diagram was originally only part ially included in t he UML. I t originat ed in I var Jacobson’s work and got included in t he UML st andard as an appendage. This has t o do wit h t he hist ory and t he sequence of how Booch, Rum baugh, and Jacobson got t oget her and m erged t heir m et hodologies, as opposed t o t he relat ive im port ance of t he diagram in m odeling. Across t he t op of a sequence diagram is a set of obj ect s t hat are going t o be part icipat ing in a given scenario. One of t he t hings we have t o do before we can get t o a sequence diagram is t o have a first guess as t o which obj ect s will be part icipat ing in t hat scenario. I t also helps if we have a guess as t o what soft ware funct ions we’ll be perform ing in t he scenario. While we do t he sequence diagram ,

we’ll be t hinking about m apping t he set of funct ions t hat will accom plish t he desired behavior ont o t hat set of obj ect s t hat part icipat e in t he scenario. I t helps a great deal t o have a good idea about t he obj ect s t hat we’ll need and t he funct ions t hat t hose obj ect s will need t o perform . When you do it t he second t im e, it ’s a lot m ore accurat e t han when you t ake a first guess at it . The process t hat we’re following, which is essent ially I v ar Jacobson’s process as described in his Obj ect ory work, is a process t hat incorporat es a first guess, or prelim inary design, t he result s of which appear on what we call a robust ness diagram . We refine t hat first guess int o a det ailed design on t he sequence diagram . So, we’ll do a sequence diagram for each scenario t hat we’re going t o build. Figure 1- 5 shows t hat we’re adding a diagram t o our subset of UML. The robust ness diagram was described in t he original UML specs, but it s definit ion was in an ext ra docum ent called Obj ect ory Process- Specific Ext ensions. What we’ve found over t he past t en years is t hat it ’s very difficult t o get from use cases t o sequence diagram s wit hout t his t echnique. Using t he robust ness diagram helps avoid t he com m on problem of proj ect t eam s t hrashing around wit h use cases and not really get t ing anywhere t owards t heir soft ware design. I f you incorporat e t his st ep, it will m ake t his process and your proj ect m uch easier. We didn’t invent robust ness analysis, but we’re t rying t o m ake sure it doesn’t get forgot t en. Robust ness analysis has proven t o be an invaluable aid in get t ing across t he gap bet ween requirem ent s and design. Figur e 1 - 5 . Robu st n e ss D ia gr a m s Close t he Ga p Be t w e e n Re quir e m e nt s a nd D e t a ile d D e sign

Robust ness analysis sit s right in t he gap bet ween what t he syst em has t o do and how it ’s act ually going t o accom plish t his t ask. While we’re crossing t his gap, t here are act ually several different act ivit ies t hat are going on concurrent ly. First , we’re going t o be discovering obj ect s t hat we forgot when we t ook our first guess at what obj ect s we had in t he syst em . We can also add t he at t ribut es ont o our classes as we t race dat a flow on t he robust ness diagram s. Anot her im port ant t hing we’ll do is updat e and refine t he t ext of t he use case as we work t hrough t his diagram .

We st ill have a quest ion m ark, t hough. That quest ion m ark relat es t o t he com m ent we j ust m ade about discovering t he obj ect s t hat we forgot when we t ook our first guess. This im plies t hat we’re going t o t ake a first guess at som e point . There’s a m agic phrase t hat we use t o help t each people how t o writ e use cases successfully: Describe syst em usage in t he cont ext of t he obj ect m odel. The first t hing t his m eans is t hat we’re not t alking, in t his book, about writ ing fuzzy, abst ract and vague, am biguous use cases t hat don’t have enough det ail in t hem from which t o produce a soft ware design. We’re going t o t each you t o writ e use cases t hat are very explicit , precise, and unam biguous. We have a very specific goal in m ind when discussing use cases: we want t o drive t he soft ware design from t hem . Many books on use cases t ake a different perspect ive, using use cases as m ore of an abst ract requirem ent s explorat ion t echnique. Our approach is different because our goals are different . Rem em ber, our m ission is t o help you get from use cases t o code. We’ll st art out wit h som et hing called a dom ain m odel, which is a kind of glossary of t he m ain abst ract ions—in ot her words, t he m ost im port ant nouns t hat are in our problem space ( our problem dom ain) . I n t he t erm dom a in m ode l, t he word “ dom ain” com es from t he idea of t he problem dom ain. For exam ple, if our problem dom ain is elect ronic com m erce—as it is in t he workbook, am azingly enough—w e’ll probably have a dom ain obj ect like a cat alog or a purchase order. We’re going t o call t hese nouns t hat belong t o our problem space dom a in obj e ct s, and we’re going t o produce, at t he very beginning of our analysis and design act ivit ies, som et hing called a dom ain m odel, which lays all t hese dom ain obj ect s out on one big UML class diagram . On our robust ness diagram s, we’re also going t o use som et hing called bounda r y obj e ct s. Am ong t he boundary obj ect s, we find t hings like t he screens of t he syst em . I n t he t ext of our use cases, we want t o explicit ly reference bot h dom ain obj ect s and boundary obj ect s. We’ll writ e about such t hings as how t he users int eract wit h t he screens and how t hose screens int eract wit h t he dom ain obj ect s, which oft en have som e m apping ont o a dat abase t hat m ay sit behind t he OO part of our syst em . Our use case t ext will get a lot m ore specific and a lot less am biguous if we follow t his guideline of describing how t he syst em is used in t he cont ext of t he obj ect m odel as it evolves. During dom ain m odeling, we want t o ident ify t he m ost im port ant set of abst ract ions t hat describe t he problem space, or t he problem dom ain of t he syst em , t hat we need t o build. For t his t ask, we’ll follow t he m et hodology Jim Rum baugh developed: t he Obj ect Modeling Technique ( OMT) , which is a very t horough t reat m ent of som e useful t echniques for helping us do t his dom ain m odel. One difference bet ween our approach and som e of t he ot her use case–orient ed approaches you m ight run across is t hat we insist on st art ing t he whole process wit h dom ain m odeling. I n writ ing our use cases against t he set of nouns in t he dom ain m odel, t hus using t hat dom ain m odel as a glossary, we can unam biguously define a set of t erm s t hat we can reference wit hin our use case t ext . This approach proves t o be quit e useful, especially when you’re working in a t eam environm ent where t here are m ult iple groups of people t hat are t rying t o describe scenarios in different part s of t he syst em . I f you get closure and agreem ent on what t he im port ant nouns in t he syst em are, you elim inat e whole layers of am biguit y in t he use case m odels. For exam ple, t his enables you t o be clear on what a purchase order is, what a line it em is, and what a shopping cart is. All t hose t hings are clear from t he beginning, due t o t he fact t hat we’ve defined a glossary of t erm s before we st art writ ing our use cases.

I n t erm s of t he UML, t he dom ain m odel is basically a class diagram , so it ’s t he sam e kind of diagram as our design- level class diagram . Generally, on t he dom ain m odel, we suppress quit e a bit of det ail; in part icular, we don’t show t he at t ribut es and t he operat ions on t he classes. The dom ain m odel is m ore of a global sum m ary- level class diagram . I n fact , it ’s a first guess at a class diagram , focusing ent irely on t he problem dom ain of t he syst em we’re building. We t ake t his first guess at our class diagram , and t hen we work t hrough all t he det ails of our use cases and refine our view of t he syst em . As we work t hrough t he scenarios, t he first - guess class diagram evolves int o our det ailed st at ic m odel for t he syst em . As you can see in Figure 1- 6, we now have a fairly com plet e pict ure, wit h no big gaps in it , t hat helps us get from use cases and prot ot ypes over on t he left side t o design- level class diagram s and source code over on t he right side. Figur e 1 - 6 . Re fe r e n cin g D om a in Obj e ct s by N a m e Re m ove s Am bigu it y fr om t he Use Ca se s

Not e t hat we’re using a very st ream lined approach. We’re only using four different kinds of UML diagram s. That ’s four out of a set of nine different kinds of diagram s t hat m ake up t he UML. Generally, for m ost proj ect s, m ost of t he t im e you can do m ost of your work using less t han half of t he UML. Lim it ing your focus t o t his core subset of diagram s will m ake a significant im pact on your learning curve as you learn how t o do m odeling wit h UML. We’re going t o st art off wit h t he dom ain m odel, which is an analysis- level class diagram , as our first guess at t he st at ic st ruct ure of t he syst em . We’re going t o cont inuously refine and add det ail t o t his m odel, wit h t he ult im at e result being our det ailed design. The class diagram , which is in t he bot t om half of Figure 1- 6, is a st at ic descript ion of how t he code is organized, whereas t he use cases are a dynam ic descript ion of t he runt im e behavior. We’ll t ake t he first guess at our st at ic m odel, and t hen we’ll spend m ost of our t im e working t hrough use case aft er use case. Every t im e we work t hrough a use case, we’ll add som e det ail t o t he class diagram . Aft er we work t hrough all t he scenarios t hat t he syst em has t o support , add in all t he det ail needed t o m ake all t hose

scenarios happen, and review what we’ve done a couple of t im es, we should have a design t hat m eet s t he requirem ent s, and we’ll be well posit ioned t o writ e code. Figure 1- 7 shows t he “ big pict ure” for t he I CONI X process. This figure appears on t he first page of every chapt er in our book Use Case Driven Obj ect Modeling wit h UML. The pict ure has t wo part s t o it : The t op part is t he dynam ic m odel, which describes behavior, and t he bot t om part is t he st at ic m odel, which describes st ruct ure. Figur e 1 - 7 . Th e I CON I X Pr oce ss—A St r e a m line d Appr oa ch t o UM L M ode ling

We m ight st art wit h som e prot ot ypes, or perhaps sim ple line drawings of our screens. Then, aft er get t ing som e assurance from users t hat we’re on t he right t rack, we can work from t his beginning t o ident ify use cases on our use case diagram , which shows all t he scenarios t hat t he syst em has t o perform . Then we writ e t he t ext of our use cases. We refine t he use case t ext during robust ness analysis. I t ’s im port ant t o t ry t o get t he t ext st abilized and correct ed during t he prelim inary design phase before m oving int o det ailed design, which we do on sequence diagram s. Many people com plain about const ant ly changing requirem ent s. Som e use t his as an excuse t o st art coding prem at urely. We’re willing t o bet t hat t he vast m aj orit y of t hese folks have never used robust ness analysis, which is enorm ously helpful in get t ing t hose requirem ent s st abilized. By breaking explorat ion of t he dynam ic m odel int o t hese t hree st eps, we get t wo chances t o review t he behavior descript ion; hopefully, by t he t im e we’ve reviewed it t he second t im e, our underst anding of t he required behavior is det ailed and fairly st able, and we can st art designing against it . As you can see on t he st at ic part of t he pict ure, we st art wit h a quick first guess about obj ect s based t ot ally on t he problem space descript ion. We go t hrough one long cont inuous refinem ent t hat ’s driven by our analysis of t he dynam ic runt im e behavior of t he syst em . We t hink in det ail how one scenario is supposed t o work, t hen updat e our class diagram s based on our im proved underst anding of t hat . Then, we go back and t hink m ore about what t he behavior of t he syst em should be.

Next , we refine our soft ware st ruct ure accordingly. Our approach, which is derived 80 percent from I var Jacobson’s work, is a very nat ural way t o decom pose syst em s along use case boundaries, and t hen use t he result s of t he use case analysis t o drive t he obj ect m odeling forward t o a level t hat ’s det ailed enough t o code from .

Ke y Fe a t u r e s of t h e I CON I X Pr oce ss Figure 1- 7 shows t he essence of a st ream lined approach t o soft ware developm ent t hat includes a m inim al set of UML diagram s, and som e valuable t echniques, t hat you can use t o get from use cases t o code quickly and efficient ly. The approach is flexible and open; you can always elect t o use ot her aspect s of t he UML t o supplem ent t he basic m at erials. We’d like t o point out t hree significant feat ures of t his approach. First , t he approach offers st ream lined usage of t he UML. The st eps t hat we describe in t he upcom ing chapt ers represent a “ m inim alist ” approach—t hey com prise t he m inim al set of st eps t hat we’ve found t o be necessary and sufficient on t he road t o a successful OO developm ent proj ect . By focusing on a subset of t he large and oft en unwieldy UML, a proj ect t eam can also head off “ analysis paralysis” at t he pass. Second, t he approach offers a high degree of t raceabilit y. At every st ep along t he way, you refer back t o t he requirem ent s in som e way. There is never a point at which t he process allows you t o st ray t oo far from t he user’s needs. Traceabilit y also refers t o t he fact t hat you can t rack obj ect s from st ep t o st ep, as well, as analysis m elds int o design. Third, t he approach is it erat ive and increm ent al, alt hough we m ight not be using t hese t erm s in t he t radit ional sense. Mult iple it erat ions occur bet ween developing t he dom ain m odel and ident ifying and analyzing t he use cases. Ot her it erat ions exist , as well, as t he t eam proceeds t hrough t he life cycle. The st at ic m odel get s refined increm ent ally during t he successive it erat ions t hrough t he dynam ic m odel ( com posed of use cases, robust ness analysis, and sequence diagram s) . Please not e, t hough, t hat t he approach doesn’t require form al m ilest ones and a lot of bookkeeping; rat her, t he refinem ent effort s result in nat ural m ilest ones as t he proj ect t eam gains knowledge and experience. As we described in t he Preface, we’re going t o dem onst rat e t hese aspect s of t he I CONI X process in t he cont ext of an on- line bookst ore; t he focus will be on t he cust om er’s view of t he syst em . The fact t hat we’ve been able t o t each t his process, wit h only m inim al changes, over an ent ire decade, wit h it rem aining useful and relevant t oday, is m ade possible because our process is based on finding t he answers t o som e fundam ent ally im port ant quest ions about a syst em . These quest ions include t he following: ?? Who are t he users of t he syst em ( t he act ors) , and what are t hey t rying t o do? ?? What are t he “ real world” ( problem dom ain) obj ect s and t he associat ions am ong t hem ? ?? What obj ect s are needed for each use case? ?? How do t he obj ect s collaborat ing wit hin each use case int eract ?

?? How will we handle real- t im e cont rol issues? ?? How are we really going t o build t his syst em on a nut s- and- bolt s level? We have yet t o com e across a syst em t hat doesn’t need t o have t hese basic quest ions answered ( especially t he first four quest ions) , or one t hat couldn’t use t he t echniques described in t his book t o help answer t hem using an it erat ive, increm ent al, opport unist ic ( when you see t he answer, capt ure it ) approach. Alt hough t he full approach present s t he st eps in a specific order, it ’s not crucial t hat you follow t he st eps in t hat order. Many a proj ect has died a horrible deat h because of a heavy, rest rict ive, overly prescript ive “ cem ent collar” process, and we are by no m eans proponent s of t his approach. What we are saying is t hat m issing answers t o any of t hese quest ions will add a significant am ount of risk t o a developm ent effort .

Pr oce ss Fu n da m e n t a ls We believe t hat t he best way t o m ake process m ore at t ract ive is t o educat e as m any people as possible about t he benefit s of answering t he quest ions we raised earlier, along wit h sim ilar quest ions, and about t he risks of failing t o answer t hem . Building good obj ect m odels is st raight forward if you keep rut hlessly focused on answering t he fundam ent ally im port ant quest ions about t he syst em you are building and refuse t o get caught up in superfluous m odeling issues. That philosophy lies at t he heart of t he I CONI X process. The people who have t o use t he process, and m anagem ent , are bot h cust om ers of a soft ware developm ent process. We t hink of a process as a road m ap for a t eam t o follow, a m ap t hat ident ifies a set of landm arks, or m ile st one s, along t he way t o producing a qualit y product . There are various pat hs a t eam can t ravel, depending on t he capabilit ies and preferences of it s m em bers. But no m at t er which pat h t hey go down, at som e point , t hey m ust reach t he m ilest ones. At t hese point s in t he process, t heir work becom es visible t o m anagem ent —during reviews of int erm ediat e result s. Passing t he m ilest ones does not guarant ee a qualit y product , but it should great ly im prove t he chances. We believe m ilest ones for an obj ect - orient ed process should include, at a m inim um , t he follow ing. ?? The t eam has ident ified and described all t he usage scenarios for t he syst em it ’s about t o build. ?? The t eam has t aken a hard look for reusable abst ract ions ( classes) t hat part icipat e in m ult iple scenarios. ?? The t eam has t hought about t he problem dom ain and has ident ified classes t hat belong t o t hat dom ain—in ot her words, t he t eam has t hought about reusabilit y beyond j ust t his syst em . ?? The t eam has verified t hat all funct ional requirem ent s of t he syst em are account ed for in t he design. ?? The t eam has t hought carefully about how t he required syst em behavior get s allocat ed t o t he ident ified abst ract ions, t aking int o considerat ion good design

principles such as m inim izing coupling, m axim izing cohesion, generalit y, and sufficiency, and so fort h. Beyond t hese m ilest ones, t here are at least four ot her fundam ent al requirem ent s of a process. 1. I t has t o be flexible enough t o accom m odat e different st yles and kinds of problem s. 2. I t has t o support t he way people really work ( including prot ot yping and it erat ive/ increm ent al developm ent ) . 3. I t needs t o serve as a guide for less- experienced m em bers of t he t eam , helping t hem be as product ive as possible wit hout handcuffing m ore experienced m em bers. 4. I t needs t o expose t he precode product s of a developm ent effort t o m anagem ent in a reasonably st andard and com prehensible form .

Th e Pr oce ss in a N u t sh e ll The basic st eps t hat com prise t he full I CONI X process and t he associat ed m ilest ones are present ed in Figures 1- 8 t o 1- 11. Not e t hat t he first t hree of t hese diagram s will appear again lat er in t he t ext , t o rem ind you where we are in t he overall process. ( We don’t t alk about im plem ent at ion in t his book, but we do have a chapt er about im plem ent at ion in t he original book. Figure 1- 11 is here for com plet eness.) Figur e 1 - 8 . Re quir e m e nt s Ana lysis

Figur e 1 - 9 . Ana lysis a nd Pr e lim ina r y D e sign

Figur e 1 - 1 0 . D e sign

Figur e 1 - 1 1 . I m ple m e n t a t ion

These diagram s t oget her illust rat e t hree key principles t hat underlie t he process: inside- out , out side- in, and t op- down, all at t he sam e t im e. 1. Work inward from t he user requirem ent s.

2. Work out ward from t he key abst ract ions of t he problem dom ain.

3. Drill dow n from high- level m odels t o det ailed design. We’ll reinforce t hese principles, in one way or anot her, in each subsequent chapt er. We suggest t hat if you adopt t hem at t he beginning of a soft ware developm ent proj ect and st ick wit h t hem , you will significant ly increase your chances of success.

Re qu ir e m e n t s List for Th e I n t e r n e t Book st or e St art ing in t he next chapt er, we’re going t o be following a running exam ple, which we call The I nt ernet Bookst ore, t hrough each phase of t he process we’ve j ust out lined for you. The use cases we’ll be working t hrough, and t he classes we’ll discover, exist t o sat isfy cert ain requirem ent s t hat our client ( t he owner of t he

bookst ore we’re going t o build) has specified. These requirem ent s include t he follow ing: ?? The bookst ore shall accept orders over t he I nt ernet . ?? The bookst ore shall m aint ain a list of account s for up t o 1,000,000 cust om ers. ?? The bookst ore shall provide password prot ect ion for all account s. ?? The bookst ore shall provide t he abilit y t o search t he m ast er book cat alog. ?? The bookst ore shall provide a num ber of search m et hods on t hat cat alog, including search by aut hor, search by t it le, search by I SBN num ber, and search by keyword. ?? The bookst ore shall provide a secure m eans of allowing cust om ers t o pay by credit card. ?? The bookst ore shall provide a secure m eans of allowing cust om ers t o pay via purchase order. ?? The bookst ore shall provide a special kind of account t hat is preaut horized t o pay via purchase order. ?? The bookst ore shall provide elect ronic links bet ween t he Web and dat abase and t he shipping fulfillm ent syst em . ?? The bookst ore shall provide elect ronic links bet ween t he Web and dat abase and t he invent ory m anagem ent syst em . ?? The bookst ore shall m aint ain reviews of books, and allow anyone t o upload review com m ent s. ?? The bookst ore shall m aint ain rat ings on books, based on cust om er input s.

Ch a pt e r 2 . D om a in M ode lin g Dom ain m odeling form s t he foundat ion of t he st at ic part of our UML m odel. When we build a dom ain m odel, we st art off by t rying t o ident ify abst ract ions in t he real w orld—t hat is, t he m ain concept ual obj ect s t hat are going t o part icipat e in t his syst em . When you design obj ect - orient ed soft ware, you t ry t o st ruct ure your soft ware around t hese real- world, problem space obj ect s. The t heory behind t his is t hat t he real world changes less frequent ly t han t he soft ware requirem ent s. The basis for our whole obj ect m odeling act ivit y, part icularly t he st at ic m odeling part of t he act ivit y, is a m odel of t hese problem dom ain abst ract ions. You m ay be wondering why t his chapt er precedes a discussion of use cases in a book called Applying Use Case Driven Obj ect Modeling. The reason is t hat when we writ e our use cases ( see Chapt er 3) , we’re not going t o writ e t hem from an abst ract , pure user viewpoint ; inst ead, we’re going t o be writ ing use cases in t he cont ext of t he obj ect m odel. By doing t his, we’ll be able t o link t oget her t he st at ic and dynam ic port ions of t he m odel, which is essent ial if we’re going t o drive t he design forward from t he use cases. The dom ain m odel serves as a glossary of t erm s t hat writ ers of use cases can use in t he early st ages of t hat effort . As we ident ify real- world, problem dom ain obj ect s, we also need t o ident ify t he relat ionships am ong t hose obj ect s. These include t wo part icularly im port ant relat ionship t ypes: ge ne r a liza t ion, which is t he superclass/ subclass relat ionship, and a ggr e ga t ion, which is t he whole part / subpart kind of relat ionship. There are ot her t ypes of relat ionships bet ween classes in addit ion t o generalizat ion and aggregat ion, including plain vanilla associat ions bet ween obj ect s, but generalizat ion and aggregat ion are part icularly im port ant . As t he foundat ion of our st at ic m odel, we’re using UML class diagram s t o express our dom ain m odel. UML classes give us a place t o capt ure a t t r ibut e s, which are dat a elem ent s or dat a m em bers, as well as ope r a t ions, which are t he funct ions t hat a given obj ect perform s. However, in t he init ial dom ain m odeling act ivit y, we don’t usually want t o spend t oo m uch t im e capt uring at t ribut es and operat ions—we’ll do t his lat er on as we refine and flesh out t he st at ic part of our m odel. We want t o focus on ident ifying obj ect s and t he relat ionships bet ween t hem as we’re doing t he dom ain m odeling. Reuse is one of t he m ain goals of building your soft ware around t hese real- world abst ract ions, because we oft en have m ult iple soft ware syst em s t hat share a com m on problem dom ain. Keep in m ind t hat if you’re aim ing for reuse, you want t o do a very good j ob at dom ain m odeling because t he reusable aspect s of your soft ware are largely going t o com e out of t his dom ain m odeling act ivit y. This dom ain m odel t hen becom es t he foundat ion for t he st at ic part of your m odel. The dom ain m odeling process, for which we’re following t he Obj ect Modeling Technique ( OMT) school of t hought , is fundam ent ally an inside- out approach. I nsideout m eans t hat we’re st art ing wit h t he core obj ect s in t he syst em , t hen working from t he inside out ward, t o see how t hose obj ect s are going t o part icipat e in t he syst em we’re building. So, t he use case approach, or t he dynam ic part of t he m odel, is an out side- in approach, whereas t he st at ic part of t he m odel is an inside- out approach. The t rick when you’re working bot h out side- in and inside- out is t o m ake t hese t wo part s m eet in t he m iddle and not have a disconnect in bet ween. As we get int o robust ness analysis ( see Chapt er 5) and sequence diagram s ( see Chapt er 7) , we’ll

see exact ly how t his works. For now, j ust keep in m ind t hat t his dom ain m odel and st at ic m odeling act ivit y is really an inside- out look at our syst em . Figure 2- 1 shows where dom ain m odeling resides wit hin t he “ big pict ure” for t he I CONI X process. Figur e 2 - 1 . D om a in M ode ling a nd t he I CON I X Pr oce ss

Th e Ke y Ele m e n t s of D om a in M ode lin g The first t hing you need t o do in building a st at ic m odel of your syst em is t o find appropriat e classes t hat accurat ely represent t he real abst ract ions t hat t he problem dom ain present s. I f you execut e t his act ivit y well, you will have not only a solid foundat ion on which t o build t he syst em but also excellent prospect s for reuse by syst em s t hat will be designed and built down t he line. The best sources of dom ain classes are likely t o be t he high- level problem st at em ent , lower- level requirem ent s, and expert knowledge of t he problem space. To get st art ed on t he road t o discovery, lay out as m any relevant st at em ent s from t hese sources ( and ot hers, such as m arket ing lit erat ure) as you can find, and t hen circle or highlight all t he nouns and noun phrases. Chances are t hat you will find a large m aj orit y of t he im port ant dom ain obj ect s ( classes) t his way. Aft er refining t he list s as work progresses, t his is what t ends t o happen: ?? Nouns and noun phrases becom e obj ect s and at t ribut es. ?? Verbs and verb phrases becom e operat ions and associat ions. ?? Possessive phrases indicat e t hat nouns should be at t ribut es rat her t han obj ect s. The next st ep is t o sift t hrough your list of candidat e classes and elim inat e t he it em s t hat are unnecessary ( because t hey’re redundant or irrelevant ) or incorrect ( because

t hey’re t oo vague, t hey represent t hings or concept s out side t he scope of t he m odel, or t hey represent act ions even t hough t hey’re phrased as nouns) . While you’re building your class diagram ( s) , you can also m ake som e init ial decisions about generalizat ion ( “ kind of” or “ is a” relat ionships am ong classes) . I f you need t o, and if you’re com fort able doing so at t his st age of your proj ect , you can generalize t o m ore t han one level of subclass. Rem em ber t o look for “ kind of” st at em ent s t hat are t rue in t he real world. Dom ain m odeling is also t he appropriat e area for decisions about aggregat ions ( “ part of” or “ has” relat ionships) am ong classes. Finally, m uch like an ent it y- relat ionship diagram ( ERD) , our dom ain m odel, updat ed t o show associat ions—t he st at ic relat ionships bet ween pairs of classes—should be a t rue st at em ent about t he problem space, independent of t im e ( t hat is, st at ic) . This m odel serves as t he foundat ion of our st at ic class m odel. We recom m end t hat you est ablish a t im e budget for building your init ial dom ain m odel. You’re not going t o m ake it perfect , anyway, so do it quickly and expect t o fix it up as you proceed. You should be vigilant about m aking necessary adj ust m ent s t o your analysis- level class m odel in response t o occurrences during robust ness analysis and t hroughout t he proj ect .

Th e Top 1 0 D om a in M ode lin g Er r or s The flip side of t he principles we j ust discussed t akes t he form of a num ber of com m on errors t hat our st udent s m ake when t hey’re doing dom ain m odeling for t heir proj ect s. Our “ Top 10” list follows.

St art assigning m ult iplicit ies t o associat ions right off t he bat . Make sure t hat every associat ion has an explicit m ult iplicit y. Som e associat ions on a class diagram represent one- t o- one relat ionships, whereas ot hers represent one- t o- m any relat ionships. These are bot h called m ult iplicit ie s. However, you should avoid dealing wit h m ult iplicit y alt oget her during dom ain m odeling—it chews up t im e and can be a m aj or cause of analysis paralysis.

Do noun and verb analysis so exhaust ive t hat you pass out along t he way. Kurt Derr’s Applying OMT ( SI GS Books, 1995) is a good source of inform at ion about “ gram m at ical inspect ion.” I f you follow Derr’s advice all t he way down t he line, t hough, you’re likely t o find yourself at t oo a low level of abst ract ion, in addit ion t o running t he risk of a nervous breakdown. Use t he t echnique t o get your obj ect discovery st art ed, but t ake care not t o get carried away.

Assign operat ions t o classes wit hout exploring use cases and sequence diagram s. We advocat e a m inim alist approach t o defining operat ions during dom ain m odeling. I n fact , we’re going t o t ell you t hat you shouldn’t assign any operat ions t o classes during dom ain m odeling. That ’s because t here isn’t enough inform at ion available wit h which t o m ake good design decisions about operat ions at t hat st age of a proj ect . When we get t o int eract ion m odeling, however, we do have good inform at ion ( at least we hope t o) . We describe int eract ion m odeling in Chapt er 7.

Opt im ize your code for reusabilit y before m aking sure you’ve sat isfied t he user’s requirem ent s. The m ore general your obj ect s and classes, t he higher t he probabilit y t hat you’ll be able t o reuse t hose obj ect s and classes for ot her proj ect s. And a com plet e class is one t hat is t heoret ically reusable in any num ber of cont ext s. However, t o achieve reusabilit y and com plet eness, you need t o consider bot h at t ribut es and operat ions, and we j ust t old you why you shouldn’t be assigning operat ions t o classes during dom ain m odeling, so it ’s not wise t o overdo your effort s t o m ake classes reusable when you’re doing high- level class diagram s. Move quickly t hrough dom ain m odeling, so you have t im e t o m ake sure t hat you’re building what your cust om ers w ant .

Debat e whet her t o use aggregat ion or com posit ion for each of your “ part of” associat ions. Grady Booch’s original descript ions of “ has by reference” relat ionships m orphed int o aggregat ion wit hin t he UML. Sim ilarly, “ has by value” becam e a “ st rong” form of aggregat ion called com posit ion wit hin which a “ piece” class is “ owned by” a parent class: if t he parent is delet ed, all inst ances of t he child get delet ed aut om at ically. Trying t o different iat e bet ween t hese t wo during a dom ain m odeling effort is a surefire way t o do som e serious t ail- chasing. We prefer t o use sim ple aggregat ion during dom ain m odeling. Aggregat ion versus com posit ion is a det ailed design issue.

Presum e a specific im plem ent at ion st rat egy wit hout m odeling t he problem space. As part of ongoing refinem ent of your dom ain m odel, you should rem ove anyt hing t hat clearly st at es an act ion rat her t han a dependency or t hat ’s specifically relat ed t o

im plem ent at ion. What you should not do is st art int roducing t hings on your highlevel class diagram s t hat represent com m it m ent s t o specific t echnologies, such as a relat ional dat abase or a part icular kind of server. Leave im plem ent at ion issues t o im plem ent at ion; m odel t he problem dom ain first .

Use hard- t o- underst and nam es for your classes, like cPort MgrI nt f, inst ead of int uit ively obvious ones, like Port folioManager. One good reason t o do dom ain m odeling up front is t o facilit at e t he t ask of get t ing everyone on t he proj ect t eam t o agree on what your key abst ract ions should be called. The m ore obvious t he class nam es, t he easier t hat t ask will be. Save acronym s and ot her kinds of abbreviat ions ( if you insist on having t hem ) for im plem ent at ion.

Jum p direct ly t o im plem ent at ion const ruct s, such as friend relat ionships and param et erized classes. The UML offers a lot of opport unit ies t o add what we call “ Booch st uff” t o class diagram s. This includes const ruct s t hat cam e across m ore or less direct ly from C+ + , such as param et erized classes and friend relat ionships. These are m uch m ore relevant t o t he solut ion space t han t o t he problem space, t hough, and t he focus of dom ain m odeling should definit ely be t he problem space.

Creat e a one- for- one m apping bet ween dom ain classes and relat ional dat abase t ables. I f you’re reengineering a legacy syst em t hat uses a relat ional dat abase, t he t ables wit hin t hat dat abase are likely t o be an excellent source of nam es for your dom ain classes. However, be careful not t o j ust bring t hem over t o your st at ic m odel wholesale. A relat ional t able can have a lot of at t ribut es t hat m ight not belong t oget her in t he cont ext of an obj ect m odel. You should t ry t o use aggregat ion t o fact or groups of at t ribut es int o “ helper” classes, which cont ain at t ribut es and operat ions t hat can be grouped int o sm aller “ piece- part ” classes.

role= " t it leicon" Perform “ prem at ure pat t ernizat ion,” which involves building cool solut ions, from pat t erns, t hat have lit t le or no connect ion t o user problem s.

Pat t erns oft en st art becom ing visible during robust ness analysis. As we’ll explore in Chapt er 5, t here are t wo st rat egies, “ cont rol in t he screen” and “ use case cont roller,” t hat lend t hem selves t o discovering pat t erns connect ed t o use cases. Looking ahead, design pat t erns can be highly useful in t he cont ext of sequence diagram s and design- level class diagram s. Dom ain m odeling is not t he t im e t o st art t hinking in t erm s of pat t erns.

Ex e r cise s The following exercises, t aken from t he dom ain m odel for our I nt ernet Bookst ore, are designed t o t est your abilit y t o spot t he t op 10 m ist akes t hat people m ake during dom ain m odeling. ( The full dom ain m odel is present ed at t he end of t he chapt er and also in Appendix.) Each page wit h a red label at t he t op cont ains t hree or four of t hese m ist akes; your t ask is t o writ e correct ions on t he page near t he erroneous m at erial. Following each of t hese pages is a page wit h a whit e label inside a black box at t he t op; t his page cont ains correct ed m at erial and explanat ions of t he t op 10 rules t hat were violat ed on t he previous page. Happy hunt ing!

Ex e r cise 1

Ex e r cise 1

On t he previous diagram : ?? The cBinaryTree class is a param et erized class ( also known as a t em plat e class wit hin t he UML) . There’s no good reason t o st art defining an im plem ent at ion const ruct such as a binary t ree at t his st age of m odeling.

?? The cLoginMgr class has an operat ion nam ed verifyPassword. I t ’s t oo early t o m ake decisions about which operat ions go on which classes, and besides, chances are good t hat t he operat ion belongs on t he Account class anyway. ?? The nam e of t he class we j ust discussed was not int uit ively obvious.

Ex e r cise 2

Ex e r cise 2

On t he previous diagram : ?? The nam e of t he cSessionBeanShpngCart class indicat ed t hat t he m odeler decided t o represent t he concept of a shopping cart using a session Ent erprise Java Bean ( EJB) . Robust ness analysis, which we’ll discuss in Chapt er 5, is t he appropriat e st age t o st art exploring how t o m ap classes t o t hings such as beans. ?? A class t hat represent s a shopping cart should be called Shopping Cart . ?? The class we’ve been discussing had a com posit ion relat ionship wit h t he Order class. The m odeler com m it t ed t o t he idea t hat an Order disappears when t he shopping cart obj ect t o which it belongs is dest royed. This m ay or not m ake sense in t he long run, but it ’s cert ainly t oo soon t o be t hinking along t hose lines.

Ex e r cise 3

Ex e r cise 3

On t he previous diagram : ?? The presence of t he foreignI nvent oryDBKey at t ribut e indicat es t hat t he m odeler is looking ahead t oward a relat ional dat abase. ( Not e also t hat classes in your dom ain m odel shouldn’t have at t ribut es yet , and t hey cert ainly shouldn’t have operat ions.) ?? The Order class has operat ions assigned t o it . ?? The associat ion bet ween Account and Billing I nfo has a m ult iplicit y.

Ex e r cise 4

Ex e r cise 4

On t he previous diagram : ?? The presence of at t ribut es nam ed “ price,” “ quant it yOnHand,” and “ publisher,” all of w hich probably belong in associat ed classes, indicat es t hat t he m odeler is likely t o have m apped an exist ing Order t able direct ly t o t he Order class. ( Also, as we m ent ioned for Exercise 3, classes in your dom ain m odel shouldn’t have at t ribut es yet .) ?? The Purchase Order class uses t he Vect or const ruct from Java.

?? The m odeler has chosen t o use t he Proxy design pat t ern; dom ain m odeling is t oo early t o be m aking t his decision.

Ex e r cise 5

Ex e r cise 5

On t he previous diagram : ?? The Cust om er Review class has an operat ion. ?? The associat ion bet ween I t em and Shopping Cart is a com posit ion, but it ’s t oo early t o know whet her t his m akes sense as opposed t o an ordinary aggregat ion. ?? The st ereot ypes on t he Order and Candidat e Order classes indicat e a prem at ure decision as t o t he layers t o which t he classes belong.

Br in gin g t h e Pie ce s Toge t h e r Figure 2- 2 shows t he full dom ain m odel for our I nt ernet Bookst ore. This diagram consolidat es t he fragm ent s present ed wit hin t he exercises and adds classes and associat ions t hat com e int o play lat er in t his workbook. Figur e 2 - 2 . D om a in M ode l for Th e I n t e r n e t Book st or e

Ch a pt e r 3 . Use Ca se M ode lin g This chapt er addresses a fundam ent al quest ion t hat every developm ent effort m ust ask: What are t he users of t he syst em t rying t o do? We’re going t o focus our effort s on t rying t o capt ure our users’ act ions, and t he associat ed syst em responses, in great det ail because t he soft ware behavior is dict at ed by t he user requirem ent s. I n ot her words, what we need t he soft ware t o do depends on how t he users are accessing it and what t he users are t rying t o do. This oft en relat es t o screens and user int erfaces. Figure 3- 1 shows where use case m odeling resides wit hin t he “ big pict ure” for t he I CONI X process. As you can see, we t hink it ’s a good idea t o use prot ot ypes t o help define t he use cases. And, we do our use case m odel, along wit h our dom ain m odel, right at t he very beginning of our proj ect . The ent ire dynam ic part of t he obj ect m odel is direct ly driven from t he use case m odel we put t oget her. Since t he dynam ic m odel drives t he st at ic m odel, t he use cases are also driving our st at ic m odel, as w ell. Figur e 3 - 1 . The I CON I X Pr oce ss I s Use Ca se D r ive n

Figure 3- 1 also shows t hat we’re cont inuously updat ing and refining our st at ic m odel based on furt her analysis of t hese use cases as we do our robust ness and sequence diagram s. We’re const ant ly updat ing our st at ic m odel as we walk t hrough t he scenarios. That ’s how it evolves from t he first - cut dom ain m odel t o our det ailed design- level st at ic m odel. We’re com plet ely use case driven in t his approach, in t hat our soft ware archit ect ure and our soft ware design are bot h driven from our analysis of usage scenarios. The whole dynam ic m odel is very m uch an out side- in t ype of approach. We st art wit h users who are out side our syst em , and we work our way in t o expose all det ails of t he soft ware behavior. From t hat , t he soft ware st ruct ure t hat support s t hat behavior is creat ed. But we’re working inward from t he out side of t he syst em , one scenario at a t im e. Because t he use cases are t he fundam ent al unit of decom posit ion in t his

m odeling effort , everyt hing else is direct ly driven from t his out side- in approach. As a result , we’re reliably able t o design syst em s t hat m eet our user requirem ent s, which is no sm all accom plishm ent .

Th e Ke y Ele m e n t s of Use Ca se M ode lin g The t ask of building use cases for your new syst em is based on ident ifying as m any as you can up front and t hen est ablishing a cont inuous loop of writ ing and refining t he t ext t hat describes t hem . Along t he way, you will discover new use cases and also fact or out com m onalit y in usage. You should keep one overriding principle in m ind at all t im es in your effort t o ident ify use cases: They should have st rong correlat ions wit h m at erial in t he user m anual for t he syst em . I t should be obvious what t he connect ion is bet ween each use case and a dist inct sect ion of your user guide. This reinforces t he fundam ent al not ion t hat you are conform ing t he design of your syst em t o t he viewpoint s of t he users. I t also provides a convenient sum m ary of what “ use case driven” m eans: Writ e t he user m anual, t hen writ e t he code. I f you’re reengineering a legacy syst em , you can sim ply work from t he user m anual backward, m aking any necessary changes as you go. Once you have som e t ext in place for a use case, it ’s t im e t o refine it by m aking sure t he sent ences are clear and discret e, t he basic form at of your t ext is noun- verbnoun, and t he act ors and pot ent ial dom ain obj ect s are easily ident ifiable. You should also updat e your dom ain m odel ( see Chapt er 2) as you discover new obj ect s and expand your underst anding of t he obj ect s you’d previously found. And, it ’s very im port ant t o t hink of all possible alt ernat e courses of act ion for each use case wherever possible, which should be a large m aj orit y of t he t im e. Not e t hat robust ness analysis ( see Chapt er 5) will be very helpful t oward accom plishing all of t his refinem ent . Alt hough som e aut hors encourage t he use of volum inous use case t em plat es, here’s what we recom m end t o every one of our client s: 1. Creat e a use case t em plat e t hat has areas labeled Basic Course and Alt ernat ive Courses. Don’t put anyt hing else in t here; it ’ll j ust dist ract you. 2. Ask “ What happens?” This will get t he basic course of act ion st art ed. 3. Ask “ And t hen what happens?” Keep asking t hat quest ion unt il you have all t he det ails of your basic course on paper. 4. Ask, “ What else can happen?” Be relent less. Are t here any ot her t hings t hat can happen? Are you sure? Keep asking t hose quest ions unt il you have a rich set of alt ernat ive courses writ t en down. Trust us: Grief at t his point is m uch easier t o t ake t han grief during, say, int egrat ion t est ing. The goal is not t o const ruct an elegant use case m odel; t he goal is t o account for everyt hing t he user m ight do. You’ll review t his m at erial during a requirem ent s review ( see Chapt er 4) ; you’ll review it again during a prelim inary design review ( see Chapt er 6) ; and you’ll review it once m ore during a crit ical design review ( see Chapt er 8) . This m ay seem excessive, but keep in m ind t hat t he m ore well- defined t he syst em behavior, t he easier it ’s going t o be t o build t he syst em .

You can use several m echanism s t o fact or out com m on usage, such as error handling, from set s of use cases. This is usually a good t hing t o do because breaking usage down t o at om ic levels will m ake your analysis effort easier and save you a lot of t im e when you’re drawing sequence diagram s. Whet her you use t he UML’s use case generalizat ion and include and ext end relat ionships, or t he invoke and precede relat ionships from t he Open Modeling Language ( OML) , which we recom m end in Use Case Driven Obj ect Modeling wit h UML, your goal should be a set of sm all, precise, reusable use cases. We recom m end grouping use cases int o packages, prim arily because t hese packages form logical boundaries for dividing work am ong subt eam s. A good rule t o follow is: Each package should correspond wit h a chapt er, or at least a m aj or sect ion, in your user m anual. You should feel com fort able proceeding t o t he next phases of t he developm ent process when you’ve achieved t he following goals of use case m odeling: ?? You’ve built use cases t hat t oget her account for all of t he desired funct ionalit y of t he syst em . ?? You’ve produced clear and concise writ t en descript ions of t he basic course of act ion, along wit h appropriat e alt ernat ive courses of act ion, for each use case. ?? You’ve fact ored out scenarios com m on t o m ore t han one use case, using whichever const ruct s you’re m ost com fort able using.

Th e Top 1 0 Use Ca se M ode lin g Er r or s The flip side of t he principles we j ust discussed t akes t he form of a num ber of com m on errors t hat we have seen st udent s m ake when t hey’re doing use case m odeling on t heir proj ect s for t he first t im e. Our “ Top 10” list follows.

Writ e funct ional requirem ent s inst ead of usage scenario t ext . Requirem ent s are generally st at ed in t erm s of what t he syst em shall do. Usage scenarios describe act ions t hat t he users are t aking and t he responses t hat t he syst em generat es. Event ually, we’re going t o use our use case t ext as a runt im e behavioral spec for t he scenario we’re describing, and t his t ext will sit on t he left m argin of a sequence diagram . We want t o be able t o easily see how t he syst em ( shown wit h obj ect s and m essages) is im plem ent ing t he desired behavior, as described in t he use case t ext . So, we need t o keep a clear dist inct ion bet ween ( act ive voice) usage descript ions ( behavior) and ( passive voice) syst em requirem ent s.

Describe at t ribut es and m et hods rat her t han usage.

Not only shouldn’t your use case t ext include t oo m any present at ion det ails, but it should be relat ively free of det ails about t he fields on your screens, as well. Field nam es oft en m at ch up direct ly wit h t he nam es of at t ribut es on your dom ain classes, which we t alked about in Chapt er 2. I f you find yourself st art ing t o list t he nam es of, say, 13 fields from t he screen in your use case t ext , st op. Open t he dom ain m odel, find t he class( es) where t hose at t ribut es belong, and capt ure t hem where t hey’ll do you som e good—as at t ribut es. Lat er, when you need t hem , t hey’ll be t here. Met hods shouldn’t be nam ed or described in case t ext because t hey represent how t he syst em will do t hings, as opposed t o what t he syst em will do.

Writ e t he use cases t oo t ersely. When it com es t o writ ing t ext for use cases, expansive is preferable t o t erse. You’re going t o need t o address all of t he det ails of user act ions and syst em responses as you m ove int o robust ness analysis and int eract ion m odeling, so you m ight as well put som e of t hose det ails in your use cases up front . Rem em ber also t hat your use cases will serve as t he foundat ion for your user m anual, and it ’s always bet t er t o err on t he side of t oo m uch det ail rat her t han not enough when it com es t o user docum ent at ion.

Divorce yourself com plet ely from t he user int erface. One of t he fundam ent al not ions of “ use case driven” is t hat t he developm ent t eam conform s t he design of t he syst em t o t he viewpoint s of t he users. You can’t do t his wit hout being specific as t o what act ions t he users will be perform ing on your screens. As we m ent ioned for it em 9, you don’t need t o t alk about fields in your use case t ext , and you also don’t want t o go int o any det ail about t he cosm et ic appearance of your screens; you can let your prot ot ypes, in what ever form t hey t ake, do t hat work for you. You do, however, need t o discuss t hose feat ures of t he user int erface t hat allow t he user t o t ell t he syst em t o do som et hing.

Avoid explicit nam es for your boundary obj ect s. Bounda r y obj e ct s are t he obj ect s wit h which act ors will be int eract ing. These frequent ly include windows, screens, dialogs, and m enus. I n keeping wit h our t hem es of including am ple det ail and being explicit about user navigat ion, we subm it t hat it ’s necessary t o nam e your boundary obj ect s explicit ly in your use case t ext . Anot her reason t hat it ’s im port ant t o do t his is t hat you’re going t o explore t he behavior of t hese obj ect s during robust ness analysis ( see Chapt er 5) , and it can only help reduce am biguit y and confusion t o nam e t hem early.

Writ e using a perspect ive ot her t han t he user’s, in passive voice. A use case is m ost effect ively st at ed from t he perspect ive of t he user as a set of present - t ense verb phrases in act ive voice. The t endency of engineers t o use passive voice is well- est ablished, but use cases should st at e t he act ions t hat t he user perform s, and t he syst em ’s responses t o t hose act ions, and t his kind of t ext is only effect ive when it ’s st at ed in act ive voice.

Describe only user int eract ions; ignore syst em responses. The narrat ive of a use case should be event - response orient ed, as in, “ The syst em does t his when t he user does t hat .” The use case should capt ure a good deal of what happens “ under t he covers” in response t o what t he act or is doing, such as creat ing new obj ect s, validat ing user input , or generat ing error m essages. Rem em ber t hat your use case t ext describes bot h sides of t he dialog bet ween t he user and t he syst em , and t hat all of t he soft ware behavior t hat you’re t rying t o discover happens on t he syst em side of t hat dialog. I f you leave out t he syst em responses, you ignore t he soft ware behavior.

Om it t ext for alt ernat ive courses of act ion. Basic courses of act ion are generally easier t o ident ify and writ e t ext for. That doesn’t m ean, however, t hat you should put off dealing wit h alt ernat ive courses unt il, say, det ailed design. I n fact , it ’s been our experience t hat when im port ant alt ernat ive courses of act ion are not uncovered unt il coding and debugging, t he program m er responsible for writ ing or fixing t he code t ends t o t reat t hem in ways t hat are m ost convenient for him or her. Needless t o say, t his isn’t healt hy for a proj ect .

Focus on som et hing ot her t han what ’s “ inside” a use case, such as how you get t here or what happens aft erward. Several prom inent aut hors advocat e t he use of long, com plicat ed use case t em plat es. Spaces for precondit ions and post condit ions are generally present on t hese t em plat es. We like t o t hink of t his as t he 1040 “ long form ” approach t o use case m odeling, in com parison t o t he 1040EZ- like t em plat e t hat we advocat e ( t wo headings: Basic Course and Alt ernat e Course) . You shouldn’t insist on using long and com plex use case t em plat es j ust because t hey appeared in a book or art icle. Don’t wast e your t im e.

Spend a m ont h deciding whet her t o use includes or ext ends. I n our years of t eaching use case driven developm ent , we have yet t o com e across a sit uat ion in which we’ve needed m ore t han one m echanism for fact oring out com m onalit y. Whet her you use t he UML’s include const ruct , or t he OML’s invoke and precede m echanism s, or som et hing else t hat you’re com fort able wit h, doesn’t m at t er; what m at t ers is t hat you pick one way of doing t hings and st ick wit h it . Having t wo sim ilar const ruct s is worse t han having only one. I t ’s t oo easy t o get confused—and bogged down—when you t ry t o use bot h. Don’t spin your wheels.

Ex e r cise s The following exercises, t aken from t he use case m odel for our I nt ernet Bookst ore, are designed t o t est your abilit y t o spot t he t op 10 m ist akes t hat people m ake during use case m odeling. ( The full use case m odel is present ed in Appendix.) Each page wit h a red label at t he t op cont ains t hree or four of t hese m ist akes; your t ask is t o writ e correct ions on t he page near t he erroneous m at erial. Following each of t hese pages is a page wit h a whit e label inside a black box at t he t op; t his page cont ains correct ed m at erial ( in it alics) and explanat ions of t he t op 10 rules t hat were violat ed on t he previous page. Happy hunt ing!

Ex e r cise 1 [ from Open Account ]

Ba sic Cour se : The Cust om er ent ers t he required inform at ion. The syst em validat es t he inform at ion and creat es a new Account obj ect . Alt e r na t e Cour se : I f any dat a is invalid, t he syst em displays an appropriat e error m essage. [ from Search by Aut hor]

The user subm it s t he request . The syst em displays anot her page t hat cont ains t he search result s. [ from Log I n]

The Cust om er ent ers his or her user I D and password, and t hen clicks t he Log I n but t on. The syst em ret urns t he Cust om er t o t he Hom e Page.

Ex e r cise 1 Basic Course: The Cust om er t ypes his or her nam e, an em ail address, and a password ( t wice) , and t hen presses t he Creat e Account but t on. The syst em ensures t hat t he Cust om er has provided valid dat a, and t hen creat es an Account obj ect using t hat dat a. Then t he syst em ret urns t he Cust om er t o t he Hom e Page. Alt ernat e Courses: ?? I f t he Cust om er did not provide a nam e, t he syst em displays an error m essage t o t hat effect and prom pt s t he Cust om er t o t ype a nam e. ?? I f t he Cust om er provided an em ail address t hat ’s not in t he correct form , t he syst em displays an error m essage t o t hat effect and prom pt s t he Cust om er t o t ype a different address. ?? I f t he Cust om er provided a password t hat is t oo short , t he syst em displays an error m essage t o t hat effect and prom pt s t he Cust om er t o t ype a longer password. ?? I f t he Cust om er did not t ype t he sam e password t wice, t he syst em displays an error m essage t o t hat effect and prom pt s t he Cust om er t o t ype t he password correct ly t he second t im e. The Cust om er t ypes t he nam e of an Aut hor on t he Search Page, and t hen presses t he Search but t on. The syst em …ret rieves all of t he Books wit h which t hat Aut hor is associat ed….Then t he syst em displays t he list of Books on t he Search Result s Page. Basic Course: The Cust om er ent ers his or her user I D and password, and t hen clicks t he Log I n but t on. The syst em validat es t he login inform at ion against t he persist ent Account dat a, and t hen ret urns t he Cust om er t o t he Hom e Page. Alt ernat e Course: I f t he syst em cannot find t he specified userI D, On t he previous page: ?? The first use case is t oo t erse. There’s no reference t o what kind of inform at ion t he Cust om er is ent ering, nor t o t he page he or she is looking at . The t ext doesn’t explain what ’s involved in t he validat ion of t he dat a t he Cust om er ent ered. And t he use case doesn’t describe how t he Cust om er needs t o respond t o an error condit ion. ?? The second use case fragm ent doesn’t cont ain explicit nam es for t he relevant boundary obj ect s. ?? The t hird use case fragm ent is lacking alt ernat e courses, even t hough it should be fairly obvious from t he cont ext t hat som e validat ion needs t o occur and t hat t here are several possible error condit ions.

Ex e r cise 2 [ from Log I n]

N a m e : Log I n Goa l: To log a cust om er int o t he syst em . Pr e condit ion: The Cust om er is not already logged int o t he syst em . Ba sic Cour se : The Cust om er ent ers his or her user I D and password, and t hen clicks t he Log I n but t on…. Alt e r na t e Cour se s: … Post con dit ion : The Cust om er is logged int o t he syst em . [ from Edit Cont ent s of Shopping Cart ]

On t he Shopping Cart Page, t he Cust om er m odifies t he quant it y of an I t em in t he Shopping Cart , and t hen presses t he Updat e but t on. Then t he Cust om er presses t he Cont inue Shopping but t on. [ from Cancel Order]

Ba sic Cour se : The syst em displays t he relevant inform at ion for t he Order on t he Cancel Order Page, including it s cont ent s and t he shipping address. The Cust om er presses t he Confirm Cancel but t on…

Ex e r cise 2 Ba sic Cour se : The Cust om er ent ers his or her user I D and password, and t hen clicks t he Log I n but t on…. On t he Shopping Cart Page, t he Cust om er m odifies t he quant it y of an I t em in t he Shopping Cart , and t hen presses t he Updat e but t on. The syst em st ores t he new quant it y, and t hen com put es and displays t he new cost for t hat I t em …. Ba sic Cour se : The syst em ensures t hat t he Order is cancellable ( in ot her words, t hat it s st at us isn’t “ shipping” or “ shipped” ) . Then t he syst em displays t he relevant inform at ion for t he Order on t he Cancel Order Page, including it s cont ent s and t he shipping address. The Cust om er presses t he Confirm Cancel but t on. The syst em m arks t he Order st at us as “ delet ed,” and t hen invokes t he Ret urn I t em s t o I nvent ory use case. Alt e r na t e Cour se : I f t he st at us of t he Order is “ shipping” or “ shipped,” t he syst em displays a m essage indicat ing t hat it ’s t oo lat e for t he Cust om er t o cancel t he order.

On t he previous page: ?? The first use case fragm ent shows how useless it can be t o be obsessive about using a com plicat ed use case t em plat e. The nam e of t he use case expresses t he goal clearly enough; t he cont ent of t he basic course will m ake t he st at ed precondit ion and post condit ion quit e redundant . ?? The second use case fragm ent doesn’t specify what t he syst em does in response t o t he Cust om er pressing t he Updat e but t on, including possibly delet ing an I t em . ?? The t hird use case fragm ent doesn’t allow for t he possibilit y t hat t he Order m ight have a st at us t hat prevent s it from being cancelled.

Ex e r cise 3 [ from Search by Aut hor]

The Cust om er t ypes t he nam e of an Aut hor, and t hen subm it s a search request ….The syst em ret rieves t he im port ant det ails about each Book, and t hen displays t he list of Books. [ from Edit Cont ent s of Shopping Cart ]

Ba sic Cour se : I f t he Cust om er m odifies t he quant it y of an I t em in t he Shopping Cart , and t hen presses t he Updat e but t on, t he syst em will st ore t he new quant it y, and t hen com put e and display t he new cost for t hat I t em …. Alt e r na t e Cour se : The syst em will delet e an I t em from t he Shopping Cart if t he quant it y of t hat I t em in t hat Shopping Cart becom es 0. [ from Process Received Shipm ent ]

The Receiving Clerk ensures t hat t he Line I t em s list ed on t he Purchase Order m at ch t he physical it em s. The Clerk waves t he bar code on t he packing slip under t he sensor at t he receiving st at ion. The syst em execut es a “ change order st at us” m et hod t o change t he Order st at us t o “ fulfilled,” and t hen calls t he changeQuant it yOnHand m et hod for each of t he variousBooks. The Clerk hands t he Books off t o t he I nvent ory Clerk.

Ex e r cise 3

The Cust om er t ypes t he nam e of an Aut hor on t he Search Page, and t hen presses t he Search but t on….The syst em ret rieves t he im port ant det ails about each Book….Then t he syst em displays t he list of Books on t he Search Result s Page…. Ba sic Cour se : On t he Shopping Cart Page, t he Cust om er m odifies t he quant it y of an I t em in t he Shopping Cart , and t hen presses t he Updat e but t on. The syst em st ores t he new quant it y, and t hen com put es and displays t he new cost for t hat I t em …. Alt e r na t e Cour se : I f t he Cust om er changes t he quant it y of t he I t em t o 0, t he syst em delet es t hat I t em from t he Shopping Cart . The Receiving Clerk ensures t hat t he Line I t em s list ed on t he Purchase Order m at ch t he physical it em s. The Clerk waves t he bar code on t he packing slip under t he sensor at t he receiving st at ion. The syst em changes t he st at us of t he Purchase Order t o “ fulfilled” and updat es t he quant it y on hand values for t he various Books. The Clerk hands t he Books off t o t he I nvent ory Clerk. On t he previous page: ?? The first use case fragm ent doesn’t nam e t he boundary obj ect . ?? The second use case fragm ent reads m ore like part of a requirem ent s spec t han a use case. ?? The t hird use case fragm ent refers t o t wo m et hods.

Ex e r cise 4 [ from Check Out ]

The Cust om er select s a billing m et hod and presses t he Use This Billing I nform at ion but t on. Then t he Cust om er presses t he Confirm Order but t on. The use case ends. [ from Ship Order]

The Clerk waves t he bar code on t he packing slip under t he sensor at t he shipping st at ion. The syst em changes t he st at us of t he Order t o “ shipping.” Then t he syst em ret rieves t he Shipping Met hod t hat t he Cust om er specified for t his Order, and displays it on t he Shipping St at ion Console…. [ from Track Recent Orders]

The Cust om er clicks on a link. The syst em ret rieves and displays t he Cont ent s of t he Order, in view - only m ode, on t he Order Det ails Page. This display shows t he relevant

values of t he Order obj ect at t he t op of t he page and t he I t em det ails, including t he basics about each Book t hat t he Cust om er ordered ( but not t he t hum bnails) , below t hat . The Cust om er presses OK t o ret urn t o t he Order Tracking Page.

Ex e r cise 4 The Cust om er select s a billing m et hod and presses t he Use This Billing I nform at ion but t on. The syst em associat es t he given Billing I nfo obj ect wit h t he Candidat e Order. Then t he syst em displays t he Confirm Order Page. The Cust om er presses t he Confirm Order but t on. The syst em convert s t he Candidat e Order t o an Order and dest roys t he Shopping Cart . Then t he syst em ret urns cont rol t o t he use case from which t his use case received cont rol. Ba sic Cour se : The Shipping Clerk ensures t hat t he I t em s list ed on t he packing slip for t he Order m at ch t he physical it em s. The Clerk waves t he bar code on t he packing slip under t he sensor at t he shipping st at ion. The syst em changes t he st at us of t he Order t o “ shipping.” Then t he syst em ret rieves t he Shipping Met hod t hat t he Cust om er specified for t his Order, and displays it on t he Shipping St at ion Console…. Alt e r na t e Cour se : I f t he Shipping Clerk finds a m ism at ch bet ween t he Order and t he physical it em s, t he Clerk st ops processing of t he Order unt il he or she is able t o m ake a m at ch. The Cust om er clicks on a link. The syst em ret rieves and displays t he cont ent s of t he Order, in view - only m ode, on t he Order Det ails Page. [ not e m issing t ext ] The Cust om er presses OK t o ret urn t o t he Order Tracking Page. On t he previous page: ?? The first use case fragm ent doesn’t describe what happens when t he Cust om er presses t he Use This Billing I nform at ion but t on or when he or she presses Confirm Order. ?? The second use case fragm ent doesn’t allow for t he possibilit y t hat t he set of I t em s t hat t he Shipping Clerk has in front of him or her doesn’t m at ch what ’s on t he packing slip. ?? The t hird use case cont ains t oo m any det ails about what t he Order Det ails page w ill look like.

Ex e r cise 5 [ from Ship Order]

The Clerk finishes packaging t he Order, and records t he t racking num ber, and t hen sends t he package out via t he associat ed Shipper. [ from Track Recent Orders]

The syst em ret rieves and displays t he Orders t hat t he Cust om er has Placed wit hin t he last 30 days….The Cust om er request s det ails for an Order. The syst em ret rieves and displays t he cont ent s of t he Order, in view - only m ode. The Cust om er ret urns t o t he list of Orders when he or she is finished looking at t he det ails of t he given Order. [ from Browse List of Books]

The Cust om er clicks on a Cat egory on t he Browse Books Page. The Syst em invokes t he “ displayYourSubcat egories” m et hod on t he Cat egory obj ect . This process cont inues unt il t here are no m ore subcat egories, at which point t he syst em displays t he Books in t he lowest subcat egory.

Ex e r cise 5 The Clerk weighs t he set of physical it em s. The Clerk packages t he I t em s. The Clerk at t aches a m anifest appropriat e for t he given shipping m et hod. The Clerk waves t he bar code on t he m anifest under t he sensor. The syst em records t he t racking num ber from t he bar code for t he given Order. The Clerk sends t he package out via t he associat ed Shipper. The syst em ret rieves t he Orders t hat t he Cust om er has placed wit hin t he last 30 days, and displays t hese Orders on t he Order Tracking Page. Each ent ry has t he Order I D ( in t he form of a link) ,…The Cust om er clicks on a link. The syst em ret rieves and displays t he cont ent s of t he Order, in view - only m ode, on t he Order Det ails Page. The Cust om er presses OK t o ret urn t o t he Order Tracking Page. The Cust om er clicks on a Cat egory on t he Browse Books Page. The syst em displays t he subcat egories wit hin t hat Cat egory. This process cont inues unt il t here are no m ore subcat egories, at which point t he syst em displays t he Books in t he lowest subcat egory. On t he previous page: ?? The first use case fragm ent doesn’t specify how t he Shipping Clerk records t he t racking num ber and t hus how it get s associat ed wit h t he given Order. ?? The second use case fragm ent om it s several det ails about where t he list of Orders and t he Order det ails appear and how t he Cust om er navigat es bet ween t hese. ?? The t hird use case fragm ent describes what happens in t erm s of a m et hod rat her t han from t he act or’s st andpoint .

Br in gin g t h e Pie ce s Toge t h e r

Figure 3- 2 shows t he full use case diagram for our I nt ernet Bookst ore. This diagram shows t he use cases t hat provide t he fragm ent s present ed wit hin t he exercises, along wit h t he act ors involved in t hose use cases. Figur e 3 - 2 . Use Ca se D ia gr a m for The I nt e r ne t Book st or e

Ch a pt e r 4 . Re qu ir e m e n t s Re vie w Requirem ent s review involves t rying t o ensure t hat t he use cases and t he dom ain m odel work t oget her t o address t he cust om ers’ funct ional requirem ent s. I t also involves m aking sure t hat t he cust om ers have enough of an idea of what t hey want t hat our developm ent t eam is able t o base a design on t hose requirem ent s. Som e schools of t hought hold t hat “ cust om ers never know what t hey want … t he requirem ent s change weekly, som et im es daily, even hourly,” and use t his t o j ust ify skipping analysis and design. This is an enorm ous cop- out . I t ’s t he analyst ’s j ob t o help t he cust om ers focus t heir underst anding of t heir requirem ent s. Use cases, prot ot ypes, and dom ain m odels are am ong t he t ools we can use t o m ake t his process work. Figure 4- 1 shows where we are. Figur e 4 - 1 . Re quir e m e nt s Re vie w a nd t he I CON I X Pr oce ss

Th e Ke y Ele m e n t s of Re qu ir e m e n t s Re vie w Requirem ent s review m ust involve represent at ives of bot h t he cust om er( s) and t he developm ent t eam , as well as any necessary m anagers. The goal is t o achieve basic agreem ent am ong all part ies t hat t he use cases, t oget her wit h t he dom ain m odel and what ever prot ot ype elem ent s are in place, capt ure t he funct ional requirem ent s of t he syst em . This works best when everyone is in a room t oget her, wit h a facilit at or/ m oderat or who keeps t he conversat ions on t rack and a scribe who records t he result s and t he act ion it em s. The key word is t raceabilit y: it should be clear how

each requirem ent t races int o one or m ore use cases, and how one or m ore classes from t he dom ain m odel and one or m ore elem ent s of t he prot ot ype work t oget her wit h t hose use cases t o address t he requirem ent . One of t he fundam ent al quest ions t hat every developm ent effort m ust ask is t his: What are t he real- world obj ect s we need t o m odel, and how do t hey relat e t o each ot her? Wit hin t he I CONI X process, dom ain m odeling form s t he foundat ion of t he st at ic part of our UML m odel. When we build a dom ain m odel, we st art by t rying t o ident ify abst ract ions in t he real world—t hat is, t he m ain concept ual obj ect s t hat are going t o part icipat e in t his syst em . When you design obj ect - orient ed soft ware, you t ry t o st ruct ure your soft ware around t hese real- world, problem space obj ect s because t he real world changes less frequent ly t han t he soft ware requirem ent s. The basis for our whole obj ect m odeling act ivit y, part icularly t he st at ic m odeling part of t he act ivit y, is a m odel of t hese problem dom ain abst ract ions. You’re going t o evolve t he init ial class diagram s t hat show t he dom ain m odel t o t he point where you can code from t hem , so it ’s crit ical t hat you capt ure t he key abst ract ions early and effect ively. Anot her of t hose fundam ent al quest ions for a developm ent effort is t his: What are t he users of t he syst em t rying t o do? During use case m odeling, and, by ext ension, requirem ent s review, we’re going t o focus our effort s on t rying t o nail down our users’ behavior in great det ail, because t he soft ware behavior is dict at ed by t he user requirem ent s. I n ot her words, what we need t he soft ware t o do depends on how t he users are accessing it and what t he users are t rying t o do. Keep in m ind t hat t he m ore well- defined t he syst em behavior, t he easier it ’s going t o be t o build t he syst em . As you can see from Figure 1- 1, we t hink it ’s a good idea t o use prot ot ypes t o help define t he use cases. We encourage our client s t o use rapid prot ot yping as frequent ly as possible. The idea is t hat developers and users sit down t oget her and build som et hing t hat will dem onst rat e “ proof of concept .” However—and t his is t he big “ however” t hat separat es us from t he eXt rem e Program m ing ( XP) com m unit y—don’t m ist ake your proof of concept prot ot ype for deliverable, shippable soft ware—even if you’ve run som e unit t est s 300 or so t im es—unless you’re fond of your users pressing Ct r l- Alt - D e le t e when confront ed wit h t he “ blue screen of deat h.” Proof of concept prot ot ypes are built wit h t he goal of rapid delivery at t he expense of robust , “ bullet proof” design. When you’re t rying t o dem onst rat e proof of concept , you’re t rying t o get som et hing t hat looks cosm et ically close t o what your users m ight be seeing built , as fast as you possibly can. So, you’re likely t o “ do t he sim plest t hing t hat can possibly work,” t o borrow a cat chy slogan. I t ’s like bringing in a const ruct ion crew t o put up a m ovie set : They can build a “ house” ( act ually a facade of a house) t hat looks fant ast ic from t he out side, in j ust a sm all fract ion of t he t im e it t akes t o build a real house, but im agine t rying t o refact or t his m ovie facade int o a real house. For a real house, you need blueprint s, elect rical schem at ics, and plans for t he plum bing. Always keep in m ind t hat your proof of concept prot ot ypes are j ust like m ovie set facade houses. What do you do if you have point y- haired m anagem ent t hat can’t t ell t he difference? I t ’s sim ple. Don’t build your prot ot ypes in code. Just work wit h pencil and paper line drawings. Som e of our client s use an abst ract ion of t he GUI called an int e r a ct ion flow dia gr a m very effect ively for t his purpose. This is essent ially a large sheet of paper t hat shows sm all line drawings of t he screens and t he opt ions for navigat ing am ong t hem .

Taking t his idea one st ep furt her, we’ve found t hat exploring t he graphical user int erface ( GUI ) design in parallel wit h t he required syst em behavior is generally an excellent approach. This involves it erat ing, wit h t he users, t he present at ion aspect s of t he syst em , and aft er achieving closure on a couple of screens, writ ing t he associat ed use cases. This bouncing back and fort h can be very effect ive in t he right environm ent . You should ext end t his t hinking t o your requirem ent s review: t he t ext for a given use case should m at ch up well wit h t he associat ed GUI elem ent ( s) , in t erm s of t he use case’s descript ions of t he basic nat ure of t hose elem ent s and t he syst em ’s responses t o act ions t hat t he act or perform s. Som e prom inent people in t he obj ect - orient ed ( OO) com m unit y advocat e t he opposit e: They insist t hat you shouldn’t t alk about GUI specifics in your use case t ext . They also insist t hat you shouldn’t t alk about m uch of anyt hing specific, t hat you should leave your t ext as abst ract ( or t e le oce nt r ic, which m eans goal- orient ed) as possible. ( “ Teleocent ric” is our favorit e new vocabulary word.) We believe t hat you can’t drive an abst ract use case down t hrough code nearly as effect ively as you can drive a specific use case. You shouldn’t t alk about whet her t his field cont ains a set of radio but t ons, or t hat window has bot h vert ical and horizont al scroll bars in your use cases, but you should definit ely t alk about t he “ call and response,” of act or and syst em , respect ively, and you should nam e t he obj ect s t hat com e int o play, as well. Doing t his is t he best way t o ensure a high level of t raceabilit y of your use cases int o your analysis and design. You should also do a gram m ar check on your use t ext during requirem ent s review. A use case is m ost effect ively st at ed from t he perspect ive of t he user as a set of present - t ense verb phrases in act ive voice. The t endency of engineers t o use passive voice is well- est ablished ( know anybody who writ es like t his: “ The engineer shall use passive voice t o art iculat e all possible behavioral opt ions t hat m ay be present ed by t he syst em .” ?) . However, as we j ust said, use cases should st at e t he act ions t hat t he user perform s and t he syst em ’s responses t o t hose act ions, and t his kind of t ext is only effect ive when it ’s st at ed in act ive voice. Anot her crit ical aspect of use case m odeling involves alt ernat e courses of act ion. As we explained in Chapt er 3, it ’s very im port ant t o t hink of all possible alt ernat e courses of act ion for each use case wherever possible, which should be a large m aj orit y of t he t im e, by asking, “ What else can happen? Are t here any ot her t hings t hat can happen? Are you sure?” As we described in Chapt er 3, you should also st ay away from long, com plicat ed use case t em plat es t hat have spaces for t he likes of precondit ions and post condit ions along wit h m any ot her t hings t hat t end t o be redundant at best and annoying at worst .

Th e Top 1 0 Re qu ir e m e n t s Re vie w Er r or s The flip side of t he principles we j ust discussed t akes t he form of a num ber of com m on errors t hat our st udent s m ake when t hey’re doing requirem ent s review for t heir proj ect s. Our “ Top 10” list follows.

Don’t review requirem ent s at all. I nst ead, invit e “ feat ure- it is” by let t ing t he coders build what ever t hey want . One of t he fundam ent al t enet s of XP is t hat since requirem ent s change every day, it doesn’t m ake m uch sense t o t ry t o deal wit h t hem explicit ly. People who follow t his approach, or som et hing sim ilar, lose not only t raceabilit y of requirem ent s but also t he abilit y t o build t rust bet ween cust om ers and developers t hat can only result from int ensive face- t o- face negot iat ion. The likely out com e is t hat coders build a cool syst em t hat doesn’t have a whole lot t o do wit h what t he cust om ers t hink t hey’re paying for. The XP folks even have cool slogans t o describe t his phenom enon. Kent Beck used it t o diagnose t he failure of t he C3 proj ect ( XP’s big claim t o fam e) on t heir Wiki Websit e: “ …t he fundam ent al problem was [ t hat ] t he Gold Owner and Goal Donor weren’t t he sam e. The cust om er feeding st ories t o t he t eam didn’t care about t he sam e t hings as t he m anagers evaluat ing t he t eam ’s perform ance….The new cust om ers who cam e on want ed t weaks t o t he exist ing syst em m ore t han t hey want ed t o t urn off t he next m ainfram e payroll syst em . I T m anagem ent want ed t o t urn off t he next m ainfram e payroll syst em .” Translat ing: I n XP lingo, t he Goal Donor is t he cust om er represent at ive who sit s in t he room wit h t he coders, who explain t hat it ’s okay t o change requirem ent s in m idst ream , while t he Gold Owner is t he proj ect sponsor—t he one who owns t he gold. I n t he case of C3 ( which was a Y2K m ainfram e payroll replacem ent proj ect ) , t he Gold Owner “ inexplicably” pulled t he plug in February of 2000 when t he program ( no doubt com plet e wit h cool feat ures) was only paying one t hird of t he em ployees, aft er som et hing on t he order of four years of labor. ( We suggest t hat you visit http://c2.com/cgi/wiki?CthreeProjectTerminated and t hink very carefully about what it says t here.) Would requirem ent s reviews have saved t his proj ect ? We can’t say for cert ain. But we can say t hat “ feat ure- it is,” which com es at t he expense of schedule, is a com m on and predict able result of let t ing t he program m ing t eam decide ( and cont inuously change) t he priorit y of t he requirem ent s ( in ot her words, m ake it up as t hey go along) and not reviewing t his priorit izat ion wit h t he “ gold owner” proj ect sponsors.

Don’t m ake sure t he use case t ext m at ches t he desired syst em behavior. The phrase “ use case driven” refers t o t he principle of using use cases, which capt ure t he “ what ” t hat t he syst em needs t o do, t o drive analysis, design, t est ing, and im plem ent at ion ( t he “ how” ) . I f your use case t ext doesn’t offer high correlat ions wit h what your users want t he syst em t o do, you’re going t o build t he wrong syst em . Period.

Don’t use any kind of GUI prot ot ype or screen m ockup t o help validat e syst em behavior. Prot ot ypes, whet her t hey t ake t he form of fully workable front ends, drawings on scraps of paper, or som et hing in bet ween, generally provide a “ j um p st art ” for t he t ask of discovering and exploring use cases. Making sure t hat your use case t ext m at ches t he navigat ion t hat a prot ot ype shows is an excellent way t o ensure t hat you’re going t o build t he right syst em . I f you don’t have any visual fram e of reference, you run t he risk t hat user int erface people will build st uff t hat doesn’t m at ch your users’ requirem ent s as expressed in t he use cases.

Keep your use cases at such a high level of abst ract ion t hat your nont echnical client s have no clue what t hey’re about . Good use cases have enough det ails t o enable t heir use in driving t he developm ent of a syst em from requirem ent s discovery all t he way t hrough code. They also serve as a very effect ive t ool for negot iat ing requirem ent s wit h cust om ers and m anaging cust om er expect at ions. This only works, t hough, if t he use case t ext is specific: t he act or does t his, t he syst em does t his. A cust om er can’t sign off on a use case t hat he or she doesn’t underst and.

Don’t m ake sure t hat t he dom ain m odel accurat ely reflect s t he real- world concept ual obj ect s. You’re going t o build code from class diagram s t hat have am ple det ail on t hem . These diagram s evolve from high- level class diagram s t hat show t he init ial dom ain m odel as you explore t he dynam ic behavior of t he syst em you’re designing. This evolut ion sim ply won’t happen t he way it should if you don’t get t he right set of dom ain obj ect s in place t o st art wit h.

Don’t m ake sure t he use case t ext references t he dom ain obj ect s. The m ain reason we discussed dom ain m odeling ( in Chapt er 2) before we t alked about use case m odeling ( in Chapt er 3) is t hat a key goal of dom ain m odeling is t o build a glossary of t erm s for use case t ext t o use. This t echnique will help you considerably in your effort t o be specific in your use cases, and it ’ll also help you focus on t raceabilit y, because your use cases and your class diagram s will work t oget her. Plus, it ’s quit e a bit easier t o do robust ness analysis ( t he subj ect of Chapt er 5) quickly if you’ve already nam ed your obj ect s in your use case t ext .

Don’t quest ion any use case wit h no alt ernat e courses of act ion. I t ’s been our experience t hat upwards of 90 percent of good use cases have at least one alt ernat e course of act ion. The appearance of a word such as “ check” or “ ensure” or “ validat e” or “ verify” in use t ext is a clear signal t hat t here’s at least one alt ernat e course, associat ed wit h an error condit ion. A use case is also likely t o have at least one pat h t hat t he act or t akes m ore frequent ly t han t he one specified by t he basic course. You need t o be diligent about digging for t hese ot her pat hs.

Don’t quest ion whet her all alt ernat e courses of act ion have been considered on every use case. One t echnique t hat works well in finding alt ernat e courses is t o quest ion every sent ence in your basic course. What could possibly go wrong? I s t here som et hing else t hat t he act or could do besides t his act ion? Could t he syst em respond in different ways? As we st at ed earlier, you should be relent less in your search for alt ernat e courses; m uch of t he int erest ing behavior of your syst em will be reflect ed in t hem , not in t he basic courses.

Don’t worry if your use cases are writ t en in passive voice. Your use cases should describe act ions: ones t hat t he act ors perform , and ones t hat t he syst em perform s. Act ions are best expressed wit h act ion verbs, and act ive voice is t he appropriat e voice for act ion verbs. Passive voice is appropriat e only when t he writ er doesn’t know who or what is perform ing a given act ion, and t hat should never be t he case wit hin use case t ext .

Don’t worry if your use cases are four pages long. The basic course of a use case should be one or t wo paragraphs long. Each alt ernat e course should be a sent ence or t wo. Som et im es you’ll have short er use cases, especially when t hey serve as “ connect ing t issue” ( for exam ple, use cases cent ered around select ing from a m enu) . And t here are t im es when you need longer use cases. But you should use t echniques such as t he invokes and precedes const ruct s we t alk about in Use Case Driven Obj ect Modeling wit h UML t o fact or out com m on behavior so t hat you can writ e concise use cases t hat you’re m ore likely t o be able t o reuse—and you should definit ely st ay away from lengt hy use case t em plat es t hat generat e considerably m ore heat t han light .

Ch a pt e r 5 . Robu st n e ss An a lysis There are t wo m aj or quest ions t hat help us link t he dynam ic m odel wit h t he st at ic m odel. The first quest ion is: What obj ect s do we need for each of t hese use cases? ( We’ll pose t he second quest ion in Chapt er 7.) We’ll use t he robust ness analysis t echnique originally developed by I var Jacobson t o help answer t his quest ion. A r obust ne ss dia gr a m is sim ilar t o a UML collaborat ion diagram , in t hat it shows t he obj ect s t hat part icipat e in t he scenario and how t hose obj ect s int eract wit h each ot her. Robust ness analysis is not exact ly a core part of UML; inst ead, it requires t he use of som e st ereot ypes. Robust ness analysis was part of Jacobson’s Obj ect ory m et hod; it ’s an inform al, “ back of t he envelope” kind of analysis t hat ’s of enorm ous value in helping you refine use case t ext and discover obj ect s t hat are needed, but t hat didn’t m ake it int o t he dom ain m odel. When t hey built t he UML, t he t hree am igos recognized t he exist ence of t his t echnique, but t hey didn’t incorporat e it as a core part of t he UML st andard. I nst ead, t hey developed Obj ect ory process- specific ext ensions. They did t his using a UML t echnique called st e r e ot ypin g, which allows you t o bind cust om icons t o any kind of sym bol. I n t he case of robust ness analysis, st ereot ypes im plem ent t he icons you see on t he screen as icons for classes. Anat om ically, a robust ness diagram in UML is a class diagram , alt hough Jacobson’s original concept was closer t o a collaborat ion diagram , which shows obj ect inst ances rat her t han classes. Today, t hough, it ’s a class diagram on which, inst ead of showing t he norm al UML class sym bol, you use t hree kinds of icons, for t hree different kinds of obj ect s: 1. Bounda r y obj e ct s, which act ors use in com m unicat ing wit h t he syst em 2. En t it y obj e ct s, which are usually obj ect s from t he dom ain m odel ( t he subj ect of Chapt er 2) 3. Cont r ol obj e ct s ( which we usually call cont r olle r s because t hey oft en aren’t real obj ect s) , which serve as t he “ glue” bet ween boundary obj ect s and ent it y obj ect s Figure 5- 1 shows t he visual icons for t hese t hree t ypes of obj ect s. Figur e 5 - 1 . Robust ne ss D ia gr a m Sym bols

Wit hin t he I CONI X process, t his sim ple but highly useful t echnique serves as a crucial link bet ween analysis ( t he what ) and design ( t he how) , as shown in Figure 52. Figur e 5 - 2 . Robust ne ss Ana lysis Br idge s t he Ga p Be t w e e n W ha t a nd H ow

This diagram explains a lot about why soft ware developm ent , in general, is a hard process. What we’re t alking about is t he need t o st art from a requirem ent s- level view, where you’re t hinking only about what your users need t o do wit h t he syst em wit hout considering im plem ent at ion det ails, and t hen driving t hat view of your syst em forward int o som et hing t hat ’s t ot ally focused on design. I n t his case, on your sequence diagram ( see Chapt er 7) , you’re showing precisely how runt im e obj ect inst ances int eract wit h each ot her as your syst em is execut ing. One of t he m ost difficult problem s in soft ware developm ent is t o get from t his “ what ” view of t he world int o a “ how” view of t he world. Robust ness analysis is a t echnique t hat helps people do t his. At t his prelim inary design phase, you should st art t o t hink t hrough possible alt ernat ive design st rat egies and t echnical archit ect ures t hat are going t o differ, depending on what t echnologies you’re using t o build t he syst em . You’re going t o st art t o uncover issues relat ed t o syst em perform ance. For exam ple, you m ay find t hat you have t wo obj ect s t hat need t o have heavy com m unicat ion wit h each ot her and t hat t hese obj ect s are rem ot ely connect ed across a net work. This m ay have perform ance im plicat ions for your design. During robust ness analysis, you’ll t ake your requirem ent s- level use case t ext and st art m aking som e prelim inary design assum pt ions. I t ’s curious t hat m ost of t he current body of UML lit erat ure doesn’t m ake any m ent ion of t his concept . Our experience is t hat success on your proj ect s and avoiding analysis paralysis is direct ly linked t o using t his t echnique. Figure 5- 3 shows where robust ness analysis resides wit hin t he “ big pict ure” for t he I CONI X process. Figur e 5 - 3 . Robust ne ss Ana lysis H e lps You Re fin e t h e Use Ca se Te x t a n d t h e D om a in M ode l

Th e Ke y Ele m e n t s of Robu st n e ss An a lysis Robust ness analysis plays several essent ial roles wit hin t he I CONI X process. Not e t hat you will refine bot h your use case t ext and your st at ic m odel as a result of robust ness analysis, as shown in Figure 5- 4. Figur e 5 - 4 . Robu st n e ss M ode l– St a t ic M ode l Fe e dba ck Loop

?? I t provides a sanit y check by helping you m ake sure t hat your use case t ext is correct and t hat you haven’t specified syst em behavior t hat ’s unreasonable— or im possible—given t he set of obj ect s you have t o work wit h. This refinem ent of t he use case t ext changes t he nat ure of t hat t ext from a pure user m anual perspect ive t o a usage descript ion in t he cont ext of t he obj ect m odel. ?? I t also provides a com plet eness and correct ness check by helping you m ake sure t he use cases address all necessary alt ernat e courses of act ion ( which

we discussed in Chapt er 3) . I n our experience, t he t im e spent drawing robust ness diagram s t oward t his end, and also t oward t he end of producing t ext t hat adheres t o som e well- defined guidelines, is invariably m ade up t hreefold or fourfold in t im e saved in drawing sequence diagram s, w hich w e’ll t alk about in Chapt er 7. ?? I t enables ongoing discovery of obj ect s, which is im port ant because you alm ost cert ainly m issed som e obj ect s during dom ain m odeling. You can also address obj ect nam ing discrepancies and conflict s before t hey cause serious problem s. And, robust ness analysis helps ensure t hat we’ve ident ified m ost of t he ent it y and boundary classes before st art ing sequence diagram s. ?? And, it serves t he role of prelim inary design, by closing t he gap bet ween analysis and det ailed design, as we m ent ioned at t he beginning of t he chapt er. Let ’s t ake a closer look at t he t hree st ereot ypes t hat we apply t o obj ect s during robust ness analysis. ?? Boundary obj ect s are t he obj ect s wit h which t he act ors ( for inst ance, t he users) will be int eract ing in t he new syst em . These frequent ly include windows, screens, dialogs, and m enus. I f you have a GUI prot ot ype in place, you can see what m any of your prim ary boundary obj ect s will be. I f you follow t he guidelines we gave you in Chapt er 3, you can also easily pick boundary obj ect s out of your use case t ext . ?? Ent it y obj ect s oft en m ap t o t he dat abase t ables and files t hat hold t he inform at ion t hat needs t o “ out live” use case execut ion. Som e of your ent it y obj ect s are “ t ransient ” obj ect s, such as search result s, t hat “ die” when t he use case ends. Many of your ent it y obj ect s will com e from your dom ain m odel. ?? Cont rol obj ect s ( cont rollers) em body m uch of t he applicat ion logic. They serve as t he connect ing t issue bet ween t he users and t he st ored dat a. This is where you capt ure your frequent ly changing business rules and policies, wit h t he idea t hat you can localize changes t o t hese obj ect s wit hout disrupt ing your user int erface or your dat abase schem a down t he line. Once in a while ( perhaps 20 percent of t he t im e) , cont rollers are “ real obj ect s” in a design, but m ost of t he t im e, cont rollers serve as placeholders t o m ake sure t hat you don’t forget any funct ionalit y and syst em behavior required by your use cases. You perform robust ness analysis for a use case by walking t hrough t he use case t ext , one sent ence at a t im e, and drawing t he act or( s) , t he appropriat e boundary and ent it y obj ect s and cont rollers, and t he connect ions am ong t he various elem ent s of t he diagram . You should be able t o fit t he basic course and all of t he alt ernat e courses on one diagram . Four basic rules apply: 1. Act ors can only t alk t o boundary obj ect s. 2. Boundary obj ect s can only t alk t o cont rollers and act ors. 3. Ent it y obj ect s can only t alk t o cont rollers.

4. Cont rollers can t alk t o boundary obj ect s, ent it y obj ect s, and ot her cont rollers, but not t o act ors. Keep in m ind t hat bot h boundary obj ect s and ent it y obj ect s are nouns, and t hat cont rollers are verbs. Nouns can’t t alk t o ot her nouns, but verbs can t alk t o eit her nouns or verbs. Figure 5- 5 sum m arizes t he robust ness diagram rules. Figur e 5 - 5 . Robust ne ss D ia gr a m Rule s

A reviewer of a robust ness diagram should be able t o read a course of act ion in t he use case t ext , t race his or her finger along t he associat ions on t he diagram , and see a clear m at ch bet ween t ext and pict ure. You will probably have t o rewrit e your use case t ext as you do t his, t o rem ove am biguit y and t o explicit ly reference boundary obj ect s and ent it y obj ect s. Most people don’t writ e perfect use case t ext in t he first draft . I n addit ion t o using t he result s of robust ness analysis t o t ight en up t he use case t ext , you should also cont inuously refine your st at ic m odel. The new obj ect s you discover drawing t he diagram s should becom e part of your class diagram s when you discover t hem . This is also t he right t im e t o add som e key at t ribut es t o your m ore significant classes.

Th e Top 1 0 Robu st n e ss An a lysis Er r or s The flip side of t he principles we j ust discussed t akes t he form of a num ber of com m on errors t hat we have seen st udent s m ake when t hey’re doing robust ness analysis on t heir proj ect s for t he first t im e. Our “ Top 10” list follows.

Violat e one or m ore of t he noun/ verb robust ness diagram rules.

These rules are in place prim arily t o get your t ext int o noun- verb- noun form at and t o help ensure t hat you don’t st art allocat ing behavior t o obj ect s before you have enough inform at ion t o m ake good design decisions. ( We’ll t alk m ore about behavior allocat ion in Chapt er 7, which focuses on sequence diagram s.) The rules about boundary obj ect s are in place t o ensure t hat you explicit ly specify t he boundaries of t he syst em , out side of which reside t he act or( s) involved in your use cases.

Don’t use robust ness analysis t o help you use a consist ent form at for your use case t ext . The boundary obj ect –cont roller–ent it y obj ect pat t ern will t end t o appear on m any of your robust ness diagram s. This pat t ern has a close correlat ion wit h t he subj ect - verbobj ect pat t ern of basic English sent ences. You should use robust ness analysis t o m ake t he t ext of your use cases st ylist ically consist ent am ong t hem selves t o t he largest ext ent t hat you can, which will great ly im prove t heir readabilit y and m aint ainabilit y.

Don’t include alt ernat e courses on robust ness diagram s. You need t o perform robust ness analysis on all of your use case t ext , not j ust t he basic courses. Much of t he int erest ing behavior of a syst em occurs in t he cont ext of alt ernat e courses, so it ’s very im port ant t o analyze t hat behavior as part of your m odeling effort s. Robust ness analysis can also help you discover new alt ernat e courses, especially when you draw cont rollers wit h labels such as Verify and Validat e.

Don’t use robust ness analysis t o ensure consist ency bet ween class nam es on class diagram s and in use case t ext . Specifying syst em usage in t he cont ext of t he obj ect m odel is t he m agic form ula you need t o build useful sequence diagram s. By nam ing your boundary obj ect s and ent it y obj ect s in your use cases, you t ake a healt hy st ep t oward get t ing your sequence diagram s off t o a good st art , by sim ply drawing t hose obj ect s across t he t op of t he sequence diagram for each use case.

Allocat e behavior t o classes on your robust ness diagram s. As we m ent ioned earlier, cont rollers serve as placeholders for funct ionalit y and syst em behavior. You should not st art assigning m et hods t o classes on a robust ness

diagram because you’re not likely t o have enough inform at ion j ust yet . You’ll m ake decisions about behavior allocat ion using sequence diagram s.

I nclude t oo few or t wo m any cont rollers. We recom m end having bet ween t wo and five cont rollers on a robust ness diagram . I f you only have one cont roller per use case, you’re likely t o have a lot of very sm all use cases, each of which doesn’t really describe enough behavior. On t he ot her hand, if you have m ore t han t en cont rollers on one diagram , you should consider split t ing your use case up int o m ore m anageable chunks.

Take t oo m uch t im e t rying t o perfect robust ness diagram s. The robust ness diagram serves as som et hing of a “ boost er- st age engine” t hat get s t he process of driving use cases forward int o an obj ect - orient ed design off t he ground. Robust ness analysis is a t ool t hat helps us discover obj ect s, allocat e at t ribut es, and check t he use case t ext for com plet eness and correct ness. But once we’ve accom plished t he overall m ission, we don’t need t o m aint ain t he work product . I t ’s a m eans t o an end, not an end in it self.

Try t o do det ailed design on robust ness diagram s. The concept of t hrowaway diagram s is useful in connect ion wit h prelim inary design; it is not a useful concept when it com es t o det ailed design. Sequence diagram s are t he appropriat e place for det ailed design. Robust ness analysis should be a quick pass across all of t he scenarios you’re going t o build, in order t o provide m axim um value t o your proj ect . I f your prelim inary design t akes as long as det ailed design, you’ll lose t he benefit s of t his quick sanit y check.

Don’t perform a visual t race bet ween t he use case t ext and t he robust ness diagram . We st rongly recom m end t hat you have peer review of all of your use case t ext and robust ness diagram s, wit h each reviewer perform ing t he finger t race t echnique t hat we described earlier. You should not consider your use case done unt il you can pass t he sim ple visual t race t est . When you’ve reached t he point where all of your use cases pass t he t est , t he next st ep—drawing sequence diagram s—will be easier for you t o perform t han if you were st art ing from first - draft , vague, am biguous, abst ract use case t ext alone.

Don’t updat e your st at ic m odel. You m ust updat e your dom ain m odel before you can consider yourself done wit h robust ness analysis and ready t o m ove on t o int eract ion m odeling using sequence diagram s. You can’t allocat e behavior t o classes t hat don’t appear in your st at ic m odel, aft er all.

Ex e r cise s The following exercises, which com e from t he robust ness diagram s wit hin t he m odel for our I nt ernet Bookst ore, are designed t o t est your abilit y t o spot t he t op 10 m ist akes t hat people m ake during robust ness analysis. Each page wit h a red label at t he t op cont ains t hree or four of t hese m ist akes; your t ask is t o writ e correct ions on t he page near t he erroneous m at erial. Following each of t hese pages is a page wit h a whit e label inside a black box at t he t op; t his page cont ains correct ed m at erial and explanat ions of t he t op 10 rules t hat were violat ed on t he previous page. Happy hunt ing!

Log I n

Ba sic Cour se : The Cust om er clicks t he Log I n but t on on t he Hom e Page. The syst em displays t he Login Page. The Cust om er ent ers his or her user I D and password and t hen clicks t he Log I n but t on. The syst em validat es t he login inform at ion against t he persist ent Account dat a and t hen ret urns t he Cust om er t o t he Hom e Page. Alt e r na t e Cour se s:

I f t he Cust om er clicks t he New Account but t on on t he Login Page, t he syst em invokes t he Open Account use case. I f t he Cust om er clicks t he Rem inder Word but t on on t he Login Page, t he syst em displays t he rem inder word st ored for t hat Cust om er, in a separat e dialog box. When t he Cust om er clicks t he OK but t on, t he syst em ret urns t he Cust om er t o t he Login Page.

Log I n

On t he previous diagram : ?? The Hom ePage boundary obj ect t alked t o t he Login Page boundary obj ect and t he Account ent it y obj ect . ?? The Account obj ect had a m et hod assigned t o it . ?? No alt ernat e courses were represent ed.

Se a r ch by Au t h or

Ba sic Cour se : The Cust om er t ypes t he nam e of an Aut hor on t he Search Page and t hen presses t he Search but t on. The syst em ensures t hat t he Cust om er t yped a valid search phrase, Aut hor and t hen searches t he Cat alog and ret rieves all of t he Books wit h which t hat is associat ed. The t he syst em ret rieves t he im port ant det ails about each Book.

Then t he syst em displays t he list of Books on t he Search Result s Page, wit h t he Books list ed in reverse chronological order by publicat ion dat e. Each ent ry has a t hum bnail of t he Book’s cover, t he Book’s t it le and aut hors, t he average Rat ing, and an Add t o Shopping Cart but t on. The Cust om er presses t he Add t o Shopping Cart but t on for a part icular Book. The syst em passes cont rol t o t he Add I t em t o Shopping Cart use case. Alt e r na t e Cour se s:…no search phrase…no books found…Cust om er exit s before searching…

Se a r ch by Au t h or

The syt st em ret rieves t he im port ant det ails about each Book and creat es Search Result s wit h t hat inform at ion. Then t he syst em displays t he list of Books on t he Search Result s Page…. On t he previous diagram : ?? There are t oo few cont rollers. Verify Search Phrase enables t he syst em t o avoid perform ing a search wit h no search phrase, while Display is a st andard cont roller associat ed wit h Web pages. ( These cont rollers also reflect alt ernat e courses t hat t he previous diagram didn’t .) ?? The Search Result s ent it y obj ect is t alking t o t he Search Result s Page boundary obj ect . ?? The use case t ext doesn’t reflect t he creat ion of t he Search Result s obj ect .

Edit Con t e n t s of Sh oppin g Ca r t

Ba sic Cour se : On t he Shopping Cart Page, t he Cust om er m odifies t he quant it y of a Line I t em in t he Shopping Cart and t hen presses t he Updat e but t on. The syst em st ores t he new quant it y and t hen com put es and displays t he new cost for t hat Line I t em . The Cust om er Presses t he Cont inue Shopping but t on. The syst em ret urns cont rol t o t he use case from which it received cont rol. Alt e r na t e Cour se s: ( 1) I f t he Cust om er changes t he quant it y of t he I t em t o 0, t he syst em delet es t hat I t em from t he Shopping Cart . ( 2) I f t he Cust om er presses t he Delet e but t on inst ead of t he Updat e but t on, t he syst em delet es t hat I t em from t he Shopping Cart . ( 3) I f t he Cust om er presses t he Check Out but t on inst ead of t he Cont inue Shopping but t on, t he syst em passes cont rol t o t he Check Out use case.

Edit Con t e n t s of Sh oppin g Ca r t

On t he Shopping Cart Page, t he Cust om er m odifies t he quant it y of an I t em in t he Shopping Cart , t hen presses t he Updat e but t on. The syst em st ores t he new quant it y, t hen com put es and displays t he new cost for t hat I t em . On t he previous diagram : ?? The Change Cost cont roller is unnecessary, since bot h it and t he Updat e Quant it y cont roller operat e on t he I t em obj ect . ?? The use case t ext refers t o Line I t em , but it ’s clear from t he class diagram excerpt and t he robust ness diagram t hat t he t ext should refer t o I t em inst ead. ( This kind of nam e usage inconsist ency can be deadly.) ?? The class diagram excerpt doesn’t reflect t he at t ribut es t hat are m ent ioned in t he use case t ext .

Ship Or de r

Ba sic Cour se : The Shipping Clerk ensures t hat t he I t em s list ed on t he packing slip for t he Order m at ch t he physical it em s. The Clerk waves t he bar code on t he packing slip under t he sensor at t he shipping st at ion. The st at us of t he order is changed t o “ shipping.” The Shipping Met hod is displayed on t he Shipping St at ion Console.

The Clerk weighs t he set of physical it em s. The Clerk packages t he I t em s. The Clerk at t aches a m anifest appropriat e for t he given shipping m et hod. The Clerk waves t he bar code on t he m anifest under t he sensor. The Clerk sends t he package out via t he associat ed Shipper. Alt e r na t e Cour se : I f t he Shipping Clerk finds a m ism at ch bet ween t he Order and t he physical it em s, t he Clerk st ops processing of t he Order unt il he or she is able t o m ake a m at ch.

Ship Or de r

The syst em changes t he st at us of t he Order t o “ shipping.” Then t he syst em ret rieves t he Shipping Met hod t hat t he Cust om er specified for t his Order and displays it on t he Shpping St at ion Console. On t he previous diagram : ?? The I nt errupt obj ect is a const ruct t hat belongs t o det ailed design. ?? The Order obj ect had m et hods assigned t o it . ?? The use case t ext is in passive voice and not as precise as it should be relat ive t o t he robust ness diagram .

Ta k e Re ce n t Or de r s

Ba sic Cour se : The syst em ret rieves t he Orders t hat t he Cust om er has placed wit hin t he last 30 days and displays t hese Orders on t he Order Tracking Page. Each ent ry has t he Order I D ( in t he form of a link) , t he Order dat e, t he Order st at us, t he Order recipient , and t he Shipping Met hod by which t he Order was shipped. The Cust om er clicks on a link.The syst em ret rieves t he relevant cont ent s of t he Order, and t hen displays t hat inform at ion, in view - only m ode, on t he Order Det ails Page. The Cust om er presses OK t o ret urn t o t he Order Tracking Page. Once t he Cust om er has finished viewing Orders, he or she clicks t he Account Maint enance link on t he Order Tracking Page. The syst em ret urns cont rol t o t he invoking use case. Alt e r na t e Cour se : I f t he Cust om er has not placed any Orders wit hin t he last 30 days, t he syst em displays a m essage t o t hat effect on t he Order Tracking Page.

Tr a ck Re ce n t Or de r s

On t he previous diagram : ?? The Order Det ails Page boundary obj ect is t alking t o t he Order Tracking Page boundary obj ect . ?? There’s no indicat ion of what happens if t he Cust om er hasn’t placed any recent orders. ?? The class diagram excerpt doesn’t reflect t he ( newly discovered) Order Table class.

Br in gin g t h e Pie ce s Toge t h e r Figure 5- 6 shows t he class diagram t hat includes som e of t he at t ribut es on t he classes for our I nt ernet Bookst ore. Figur e 5 - 6 . D om a in M ode l w it h At t r ibu t e s for Th e I n t e r n e t Book st or e

Ch a pt e r 6 . Pr e lim in a r y D e sign Re vie w Prelim inary design review ( PDR) involves reviewing t he robust ness diagram s and use case t ext for each scenario you’re planning t o build, and m aking sure t hat t he diagram s and t he use case t ext m at ch each ot her and t hat bot h are com plet e and correct ly represent t he desired syst em behavior. I t also involves ensuring t hat t he dom ain m odel m at ches t he robust ness diagram s—in part icular, t hat all ent it y obj ect s t hat show up on robust ness diagram s are represent ed in t he dom ain m odel. I n ot her words, we verify t hat we’ve ident ified t he key abst ract ions from t he problem space t hat we’ll need t o im plem ent t he desired behavior. We should also review t o m ake sure t hese ent it y classes are populat ed wit h at t ribut es and t hat we can t race dat a flow bet ween t he screens of our syst em ( w hich should now have nam es) t hrough our ent it y classes, and perhaps int o som e underlying dat abase t ables where we have persist ent dat a. We should also be reviewing t he t echnical archit ect ure behind our evolving design and m aking sure t hat t he design we’re beginning t o develop is plausible in t he cont ext of t hat t echnical archit ect ure. Figure 6- 1 shows where we are. Figur e 6 - 1 . Pr e lim ina r y D e sign Re vie w a nd t he I CON I X Pr oce ss

Th e Ke y Ele m e n t s of Pr e lim in a r y D e sign Re vie w PDR should involve represent at ives of bot h t he cust om er( s) and t he developm ent t eam , as well as any necessary m anagers, j ust like requirem ent s review. There’s a key difference, t hough: t his is t he last chance for t he cust om er t o change requirem ent s before t he developers drive t he given set of use cases t hrough t o code.

You can t hink of PDR as represent ing a line beyond which cust om ers are no longer welcom e t o act ively part icipat e in t he process. We t alked previously about how use cases represent cont ract s bet ween cust om ers and developers; it ’s during PDR t hat you finalize t hose cont ract s. As we described in Chapt er 5, robust ness analysis provides a sanit y check by helping you m ake sure t hat your use case t ext is correct and t hat you haven’t specified syst em behavior t hat ’s unreasonable—or im possible—given t he set of obj ect s you have t o work wit h. This refinem ent of t he use case t ext changes t he nat ure of t hat t ext from a pure user m anual perspect ive t o a usage descript ion in t he cont ext of t he obj ect m odel. PDR should cent er around peer review of all use case t ext and robust ness diagram s. Each reviewer should be able t o do t he following for each use case. ?? Read t he course of act ion. ?? Trace his or her finger along t he associat ions on t he corresponding robust ness diagram . ?? See a clear m at ch bet ween t ext and pict ure. Figure 5- 5 shows t he rules of robust ness analysis. Given t hat bot h boundary obj ect s and ent it y obj ect s are nouns, and t hat cont rollers are verbs, we can see t hat nouns can’t t alk t o ot her nouns, but verbs can t alk t o eit her nouns or verbs. The goal is t o it em ize all t he required behavior of t he use case in t he form of cont rol obj ect s ( cont rollers) . This involves t aking t he user m anual view and ident ifying all t he logical funct ions t hat m ust occur, t hen m assaging t he narrat ive of t he use case t ext int o a st raight forward noun- verb- noun form at . This form at will allow us t o check for correct ness when we em bark upon det ailed design by ensuring t hat we don’t forget any behavior while we’re doing t he design. Doing t his also helps enforce a com m on noun- verb- noun st yle of writ ing use cases across a design t eam . As we j ust m ent ioned, t he verbs in your use case t ext are represent ed as cont rollers on your robust ness diagram s. These cont rollers encapsulat e t he cont rol flow, and t hey serve as t he “ glue” bet ween boundary obj ect s and ent it y obj ect s, bet ween boundaries and ot her boundaries, and bet ween ent it ies and ot her ent it ies. Rem em ber t hat t he reason we call t hem cont rollers, rat her t han cont rol obj ect s, is t hat t hey serve as placeholders—we’re not ready t o assign t he behavior t hey represent t o any obj ect s yet because we don’t have enough inform at ion. Decisions about which m et hods go on which boundary obj ect s and ent it y obj ect s, and also about which cont rollers deserve t o becom e full obj ect s in your st at ic m odel, are prem at ure; we m ake t hem during sequence diagram m ing, not on robust ness diagram s. Arrows can go in one or bot h direct ions bet ween different t ypes of obj ect s on a robust ness diagram . An arrow point ing from a boundary obj ect t o a cont rol obj ect indicat es t hat t he form er is signaling t he lat t er t o perform . Or t here m ight be a t woheaded arrow bet ween a cont rol obj ect and an ent it y obj ect , signifying t hat t hey read from each ot her and writ e t o each ot her. Not e, however, t hat you need t o use only one t ype of arrowhead, which is not t he case on several t ypes of UML diagram s. Unlike arrows on sequence diagram s, arrows on robust ness diagram s don’t represent soft ware m essages; rat her, t hey sim ply indicat e com m unicat ion associat ions.

Because you won’t code from t hese diagram s, focus on t he logical flow of your use case and worry about t he direct ions of arrows lat er, in your sequence diagram s. You should, however, be aware of t he presence of pat t erns across robust ness diagram s. Pat t erns oft en st art becom ing visible during robust ness analysis. There are t wo st rat egies, “ cont rol in t he screen” and “ use case cont roller,” t hat lend t hem selves t o discovering pat t erns connect ed t o use cases. ( See Use Case Driven Obj ect Modeling for det ails about t hese t erm s.) Looking ahead t o int eract ion m odeling, design pat t erns can be highly useful in t he cont ext of sequence diagram s and design- level class diagram s. You should not , t hough, st art drawing full design pat t erns on your robust ness diagram s; it ’s sufficient t o st art t hinking about how you’ll be able t o use t hem t o advant age during det ailed design. We used t he t erm t e chnica l a r chit e ct ur e at t he beginning of t he chapt er. This refers t o t he set of basic decisions you need t o m ake about what t echnologies you’re going t o use in im plem ent ing t he syst em . These decisions involve t hings such as t he program m ing language ( for inst ance, Java versus Visual Basic) and how you’re going t o build and dist ribut e soft ware com ponent s ( will you go wit h Ent erprise Java Beans [ EJBs] and Java Server Pages [ JSPs] , or t ake t he Microsoft rout e wit h Dist ribut ed Com ponent Obj ect Model [ DCOM] com ponent s and Act ive Server Pages [ ASPs] ?) . The decisions you m ake about your t echnical archit ect ure need t o be reflect ed, t o som e ext ent , on your robust ness diagram s. I f, for inst ance, you’re building wit h a t echnical archit ect ure t hat involves EJBs and JSPs, your robust ness diagram s will t end t o reflect t he “ cont rol in t he screen” pat t ern m ore t han t hey would if you were building pure HTML pages. Thus, robust ness analysis, which is m eant t o give you a loose descript ion of t he design t hat you can crank out quickly, offers t he chance for you t o verify t hat your t echnical archit ect ure works for t he scenarios you’re building, and your review of t hese diagram s becom es a “ do- abilit y” check on t hat archit ect ure. Cont inuing t he t hought about pat t erns: The concept of t hrowaway diagram s is useful in connect ion wit h prelim inary design; it is not a useful concept when it com es t o det ailed design. Sequence diagram s are t he appropriat e place for det ailed design. Robust ness analysis should be a quick pass across all of t he scenarios you’re going t o build, in order t o provide m axim um value t o your proj ect . I f your prelim inary design t akes as long as det ailed design, you’ll lose t he benefit s of t his quick sanit y check. Robust ness analysis allows you t o m ake a reuse pass t hrough t he ent ire use case m odel before you com m it any use cases t o t he design. Looking for reuse possibilit ies also helps you ident ify obj ect s you m issed during dom ain m odeling. You m ust updat e your st at ic m odel before you can consider yourself done wit h robust ness analysis and ready t o m ove on t o int eract ion m odeling ( t he subj ect of Chapt er 7) . The new obj ect s you discovered while you were drawing all t hose robust ness diagram s and t alking about t hem wit h your cust om ers need t o go ont o your class diagram s now, not lat er. This is also t he right t im e t o add som e key at t ribut es t o your m ore significant classes. While we’re t alking about at t ribut es: As we int roduce windows and screens— in t he form of boundary obj ect s—t o our robust ness diagram s, we begin t o t race dat a associat ed wit h t hose obj ect s back t o t he ent it y obj ect s from which t he dat a com es and/ or t o which it goes. The nat ural result of t hat t racing is t he addit ion of at t ribut es t o t he classes in t he dom ain m odel.

Th e Top 1 0 PD R Er r or s The flip side of t he principles we j ust discussed t akes t he form of a num ber of com m on errors t hat our st udent s m ake when t hey’re doing prelim inary design review for t heir proj ect s. Our “ Top 10” list follows.

Don’t m ake sure t he cust om ers know t hat t his is t heir last chance t o change t he behavior before t his release of t he syst em is built . Robust ness analysis is where use cases get t ight ened up and t he developm ent t eam get s ready t o j um p int o det ailed design. Your goal should be t o have iron- clad use cases in place before you st art drawing sequence diagram s. As such, cust om ers need t o sign off on t hose use cases during PDR. I f you let cust om ers cont inue t o m onkey wit h use cases aft er t his review, you increase t he risk of “ feat ure creep,” and you’re also likely t o run int o problem s wit h t rying t o do a design while t he requirem ent s are changing underfoot .

Don’t m ake sure t he use case t ext and robust ness diagram s m at ch. A reviewer of a robust ness diagram should be able t o read a course of act ion in t he use case t ext , t race his or her finger along t he associat ions on t he diagram , and see a clear m at ch bet ween t ext and pict ure. I f t he reviewer can’t do t his, you need t o rewrit e your use case t ext , redo your diagram , or bot h. You should not proceed wit h a sequence diagram for t he given use case wit hout passing t his sim ple t est because your use case isn’t done if it doesn’t pass, and t herefore, you’re not going t o be able t o do good det ailed design for it . We’re fond of calling t his process disa m bigua t ion. This involves rem oving t he am biguit y from your use case t ext . We’d all rat her not design against am biguous requirem ent s if we can avoid it .

Don’t m ake sure t hat new ent it y obj ect s are added t o t he dom ain m odel. One of t he reasons t o do robust ness analysis is t o accelerat e t he evolut ion of t he init ial ( problem space) dom ain m odel t oward a final ( solut ion space) class m odel. You build t hat final class m odel by allocat ing behavior t o all of t he obj ect s t hat com e int o play wit hin your use cases. You can’t do behavior allocat ion properly if you don’t have all of your classes represent ed wit hin your st at ic m odel before you st art drawing sequence diagram s.

Don’t look for at t ribut es on t he dom ain classes.

You should st rive t o have a pret t y full and rich set of at t ribut es on t he classes in your dom ain m odel when you’re t hrough wit h robust ness analysis for a given set of use cases. As we m ent ioned earlier, a num ber of t hese at t ribut es should m at ch up wit h elem ent s of your boundary obj ect s, such as fields on a window or screen. Ot her at t ribut es will be m ore relevant t o funct ionalit y t hat ’s int ernal t o t he syst em . I f you don’t capt ure t hese at t ribut es before you st art doing sequence diagram s, your decisions about which class does which operat ion will be less inform ed t han t hey should be. When we do OO design, we generally put t he funct ions where t he dat a is. However, wit hin our approach, we m ake t hese decisions in t wo st eps: We st art allocat ing dat a during prelim inary design, and we revisit t his allocat ion when we allocat e t he funct ions, during det ailed design.

Expect operat ions t o be allocat ed t o classes during PDR. As we discussed in Chapt er 5, cont rollers serve as placeholders for funct ionalit y and syst em behavior. You should not st art assigning m et hods t o classes on a robust ness diagram because you’re not likely t o have enough inform at ion j ust yet . You’ll m ake decisions about behavior allocat ion using sequence diagram s, as we describe in Chapt er 7.

Don’t advise your cust om ers ( again) t hat use case t ext is a cont ract bet ween developers and client s. We t ell you in Chapt er 7 t hat you should copy t he use case t ext ont o t he sequence diagram you’ll be drawing for t hat use case. The result of t his is t hat when you’re doing t he design, t he required syst em behavior is always st aring you in t he face. This reinforces, t o t he designers, t he nat ure of use cases as cont ract s bet ween cust om ers and developers. I t ’s during PDR t hat you have t o reinforce t hat principle t o your cust om ers.

Require t he prelim inary st at ic design t o m ake ext ensive use of design pat t erns. We t alked about t he concept of prem at ure pat t ernizat ion in Chapt er 2. This is also a t rap t hat people t end t o fall int o during robust ness analysis and PDR. I t ’s healt hy t o discover pat t erns across robust ness diagram s, especially t hose t hat m ap easily t o est ablished design pat t erns or pat t erns t hat you’ve invent ed. What ’s not healt hy is expanding sim ple prelim inary design pat t erns t hat appear on robust ness diagram s int o det ailed design pat t erns. Save t he lat t er for sequence diagram s and design- level class diagram s.

Don’t review t he noun/ verb rules of robust ness analysis. On a sequence diagram , it ’s perfect ly accept able for nouns t o t alk t o ot her nouns— t his is because t he verbs represent t he m essages bet ween obj ect s—so boundary obj ect s can t alk t o ot her boundaries, ent it y obj ect s t o ot her ent it ies, boundaries t o ent it ies. On a robust ness diagram , t hough, nouns only t alk t o verbs, not ot her nouns. The associat ed rules are in place t o help you ensure t hat your use case is expressed correct ly, in noun- verb- noun form at j ust like st andard English dict at es, because we need t o have bot h t he nouns and t he verbs ident ified before we draw our sequence diagram s. Consist ency of your use case t ext across t he proj ect helps ensure a fairly st raight forward m ove int o sequence diagram m ing as you cont inue t o use your use cases t o drive your design.

Expect your robust ness diagram s t o show a com plet e det ailed design rat her t han a concept ual design. We’ve already t old you t hat you shouldn’t see m et hods or design pat t erns on your diagram s, so you shouldn’t be surprised t hat we’re going t o t ell you t hat you should not be exploring any ot her facet s of det ailed design when you’re doing PDR. Also, use cases, class diagram s, and sequence diagram s are persist ent ; robust ness diagram s aren’t ( at least , not necessarily; a lot of folks like t o keep t hem around, especially if t hey’re cont ained wit hin a visual m odel, and t here’s not hing wrong wit h t his) . So, you shouldn’t wast e t im e t rying t o perfect your robust ness diagram s as your design evolves.

Review t he direct ion of every arrow on a robust ness diagram carefully inst ead of doing a quick t race t o verify you’ve account ed for all of t he behavior. Robust ness analysis is m eant t o be a “ quick and dirt y” t echnique t hat helps you t ight en up your use cases, discover new obj ect s, and get a good st art t oward det ailed design. Robust ness diagram s are m eant as a m eans t o an end; it ’s a wast e of t im e t o m ake t he effort t o get t he arrows exact ly right . You should focus your effort s on perfect ing your sequence diagram s rat her t han t inkering wit h robust ness diagram s.

Ch a pt e r 7 . Se qu e n ce D ia gr a m s Aft er we finish our robust ness diagram s and have a prelim inary design review, it ’s t im e t o m ove forward int o det ailed design. Robust ness analysis—prelim inary design—is about obj ect discovery. Det ailed design is largely about allocat ing behavior: allocat ing t he soft ware funct ions we have ident ified int o t he set of obj ect s t hat we have discovered. I n t his chapt er, we focus on t he sequence diagram as t he cent ral elem ent of det ailed design, or at least of t he dynam ic part of our obj ect m odel. Once we’re t hrough doing prelim inary design using robust ness analysis, we’ll go back t hrough our scenarios and do a second, m ore det ailed pass t hrough t he design. We’re going t o t ake anot her look at our inform al first guesses at how t hese obj ect s collaborat e t oget her and m ake t hose st at em ent s very precise. By t he t im e we get t o t his point of t he proj ect , we should have accom plished t wo t hings. First , our use case t ext should now be very com plet e, correct , det ailed, and explicit . Second, we should have discovered m ost of t he obj ect s t hat we’re going t o need in t he syst em , at least at a concept ual, or idealized, level of abst ract ion. Figure 7- 1 shows where sequence diagram s reside wit hin t he “ big pict ure” for t he I CONI X process. Figur e 7 - 1 . Se que nce D ia gr a m s D r ive t he Alloca t ion of Be ha vior t o Soft w a r e Cla sse s

Th e Ke y Ele m e n t s of Se qu e n ce D ia gr a m s You want t o achieve t hree prim ary goals during int eract ion m odeling. ?? Allocat e behavior am ong boundary, ent it y, and cont rol obj ect s. During robust ness analysis, you ident ify ( or at least t ake an educat ed guess at ) a set of obj ect s t hat t oget her could accom plish t he desired behavior of our use cases. You also break t hat behavior down int o discret e unit s and creat e

placeholder cont rol obj ect s for each of t hose unit s of behavior. Now you need t o decide which obj ect s are responsible for which bit s of behavior. I f you are not cert ain about what t he relevant boundary, ent it y, and cont rol obj ect s are, it ’s t oo soon t o be cont em plat ing how you will allocat e behavior. Go back t o robust ness analysis and m ake sure. ?? Show t he det ailed int eract ions t hat occur over t im e am ong t he obj ect s associat ed wit h each of your use cases. Obj ect s int eract at runt im e by sending m essages t o each ot her. These m essages serve as what Jacobson calls st im uli—t hat is, a m essage st im ulat es an obj ect t o perform som e desired act ion. For each unit of behavior wit hin a use case, you m ust ident ify t he necessary m essages/ m et hods. ?? Finalize t he dist ribut ion of operat ions am ong classes. You should aim t o have a fairly high percent age ( perhaps 75 or 80 percent ) of your at t ribut es defined wit hin t he st at ic m odel when you finish wit h robust ness analysis. We advocat e a m inim alist approach t o defining operat ions during dom ain m odeling and robust ness analysis. I n fact , we recom m end t hat you don’t assign any m et hods during prelim inary design. That ’s because t here isn’t enough inform at ion available wit h which t o m ake good design decisions about operat ions at t hat st age of a proj ect . ( Think about it : You haven’t discovered all of t he obj ect s unt il you’ve com plet ed all of your robust ness diagram s, and t rying t o allocat e behavior int o an incom plet e set of obj ect s is going t o be error- prone at best .) When you get t o int eract ion m odeling, however, you do have good inform at ion ( at least you hope t o) . As you lay out t he det ailed behavior of your obj ect s, on sequence diagram s, in t he cont ext of your use cases, you should begin t o finalize t he process of finding appropriat e hom es for at t ribut es and operat ions. While you do t his dynam ic m odeling, you w ill be updat ing and expanding your st at ic m odel, w hich w ill solidify your increasing knowledge of how your new syst em should work. The UML’s se que nce dia gr a m evolved from Jacobson’s obj ect int eract ion diagram and t he event t race diagram from OMT. Wit hin t he I CONI X approach, sequence diagram s represent t he m aj or work product of design. You draw one sequence diagram t hat encom passes t he basic course and all alt ernat e courses of act ion w it hin each of your use cases. ( You can use m ore t han one page if you need t o.) The result s form t he core of your dynam ic m odel, in which t he behavior of your syst em at runt im e, including how t he syst em will accom plish t hat behavior, is defined in great det ail. There are four t ypes of elem ent s on a sequence diagram . ?? The t ext for t he course of act ion of t he use case appears down t he left - hand side. I t ’s a good idea t o break up t he t ext wit h whit e space so t hat it ’s easy t o see which sent ence( s) correspond wit h each set of elem ent s t o t he right . ?? Obj ect s, which you bring over direct ly from your robust ness diagram s, are represent ed in rect angular boxes wit h t wo nam es. The nam e or inst ance num ber, and t he nam e of t he obj ect ’s class, appear in t he form obj ect : class. Eit her nam e can be om it t ed. The obj ect s can opt ionally be displayed wit h t heir robust ness diagram st ereot ypes; t his is oft en helpful in keeping t rack of m essages passed am ong act ors, boundary obj ect s, and ent it y obj ect s.

?? Messages are arrows bet ween obj ect s. A m essage arrow can go direct ly bet ween t wo dot t ed lines, bet ween a line and a m et hod rect angle, or bet ween t wo m et hod rect angles ( see below) . ?? Met hods ( operat ions) are shown as rect angles t hat lie on t op of t he dot t ed lines t hat belong t o t he obj ect s t o which you’re assigning t he m et hods. You can use t he lengt hs of t hese rect angles t o reflect t he focus of cont rol w it hin t he sequence: a part icular m et hod is in cont rol up t o t he point at which it s rect angle ends. Unfort unat ely, focus of cont rol is oft en m ore useful in t heory t han in pract ice, because m ost visual m odeling t ools aren’t very well- behaved wit h respect t o t his part icular feat ure. I f you find yourself get t ing frust rat ed wit h t rying t o show focus of cont rol on your diagram s, don’t hesit at e t o j ust t urn it s display off—you don’t want anyt hing t o dist ract you from m aking good behavior allocat ion decisions.

Ge t t in g St a r t e d w it h Se qu e n ce D ia gr a m s I t ’s been our experience t hat m any people get st uck at t his point in a developm ent proj ect . ( This is especially likely if t hey’ve skipped prelim inary design.) The t echnique we describe below evolved from helping st udent s get “ unst uck” during dozens of t raining w orkshops over t he past several years. Figure 7- 2 shows t he four st eps you perform when drawing sequence diagram s t he I CONI X way. Figur e 7 - 2 . Building a Se que nce D ia gr a m

1. Copy t he t ext for t he given use case from t he use case specificat ion. Past e it ont o t he left m argin of t he page. Copying use case t ext t o begin t he corresponding sequence diagram enables t hat t ext t o serve as an ongoing

rem inder of what you’re t rying t o accom plish. The result of t his is t hat when you’re doing t he design, t he required syst em behavior is always st aring you in t he face. Not e t hat if you don’t have all t he relevant alt ernat ive courses of act ion writ t en out for each of your use cases, you should not proceed wit h your sequence diagram . The diagram s will not cover all special cases, and you will not uncover all t he behavior of t he use case. This m eans t hat you won’t discover all of t he necessary m et hods for your obj ect s. ( Do Not Pass GO; Do Not Collect $200.) 2. Add t he ent it y obj ect s from t he robust ness diagram . Each of t hese obj ect s is an inst ance of a class t hat appears on t he class diagram t hat represent s your st at ic m odel. ( I f you forgot t o updat e your st at ic class diagram s in response t o new obj ect s discovered during robust ness analysis, do it now. These obj ect s should have m ost of t heir at t ribut es in place. Many of t hem will be serving dat a t o ot her obj ect s.) You can expect t o discover m issing at t ribut es as you work t hrough your sequence diagram . Be religious about adding t hem t o your st at ic m odel; t his is likely t o be your last st ep before code. 3. Add t he boundary obj ect s and act ors from t he robust ness diagram . We didn’t m ent ion adding boundary obj ect s t o your dom ain m odel because t hese obj ect s are part of t he solut ion space; t he dom ain m odel addresses t he problem space. By account ing for boundary obj ect s on your sequence diagram s, you begin int egrat ing t he t wo spaces at t he st art of det ailed design. I f you follow t he I CONI X approach, t he first t hree st eps in drawing sequence diagram s are com plet ely m echanical in nat ure. ( I n fact , we’ve reduced t hem t o an execut able script t hat aut om at ically generat es a skelet on of a sequence diagram . I f you use Rat ional Rose, you can download a copy of t his script from ht t p: / / www.iconixsw.com / RoseScript s.ht m l. Sim ilar funct ionalit y is becom ing available for ot her t ools, such as GDPro from Em barcadero and Toget her/ J from Toget herSoft .) Script s such as t his have proven t o be very useful in achieving m om ent um as you get serious about your design. You get an im m ediat e payback in t im e savings from t he work you invest ed in your robust ness diagram s, which can be very useful as you get serious about your design. The fourt h st ep, deciding which m et hods go on which classes, is t he essence of int eract ion m odeling. Put t ing m et hods on classes involves convert ing t he cont rollers from your robust ness diagram , one at a t im e, t o set s of m et hods and m essages t hat em body t he desired behavior. ( Occasionally, you m ight elect t o t urn a cont roller int o a real cont rol obj ect .) Along t hese lines, we suggest t hat you use your robust ness diagram as a checklist t o m ake sure you have all t he required syst em behavior account ed for on your sequence diagram s. You sim ply check off each cont rol obj ect as you draw t he corresponding m essage( s) on t he sequence diagram s. This will help you elim inat e t he “ oops, I forgot about t hat funct ion” error—which, as you m ight guess, is an insidious one. ( Not e t hat one cont roller on a robust ness diagram can t ranslat e t o several m et hods on a sequence diagram .) There are t wo basic st rat egies for convert ing t he cont rollers from your robust ness diagram s: “ cont rol in t he screen” and “ use case cont roller.” I f you were t o head consist ent ly in one or t he ot her direct ion during your sequence diagram m ing effort s across all of your use cases, t hat would qualify as pat t ernizing. The idea is t hat t he t eam m em bers who are responsible for t he diagram s should est ablish, early in t his t ask, som e design st andards t hat can be used across all your use cases.

Looking in anot her direct ion: As you’re diagram m ing t he int eract ions am ong t he various obj ect s, well- est ablished design pat t erns, such as t hose you m ight find in t he Gang of Four book ( Erich Gam m a, Richard Helm , Ralph Johnson, and John Vlissides: Design Pat t erns, Addison- Wesley, 1995) would fit in nicely. Or perhaps you m ight develop new pat t erns t o est ablish a st andardized approach t o design problem s t hat appear across m ult iple use cases. Now is t he t im e t o visit your st at ic m odel and reflect t hose design decisions on your class diagram s, t hen draw your sequence diagram s t o m at ch. This is where m uch of real obj ect - orient ed design ( OOD) t akes place. You’ve already checked t he robust ness diagram s against your use case t ext . By checking your sequence diagram s against your robust ness diagram s, you add a m easure of assurance t hat you’re designing in response t o what t he user needs ( in ot her words, m eet ing your requirem ent s) .

Th e Top 1 0 Se qu e n ce D ia gr a m m in g Er r or s The flip side of t he principles we j ust discussed t akes t he form of a num ber of com m on errors t hat we have seen st udent s m ake when t hey’re drawing sequence diagram s on t heir proj ect s for t he first t im e. Our “ Top 10” list follows.

Don’t do a sequence diagram for each use case. Jacobson provided a st raight forward descript ion of t he need for int eract ion m odeling in his business process reengineering ( BPR) book ( The Obj ect Advant age, AddisonWesley, 1995) : “ I t is only aft er you have drawn int eract ion diagram s [ called “ sequence diagram s” in t he UML] for all courses of event s in all use cases t hat you can be cert ain t hat you have found all of t he roles t hat t he syst em requires each obj ect t o play and, t hus, t he responsibilit ies of each obj ect .”

Don’t put t he use case t ext on t he sequence diagram . Writ ing t he original requirem ent s- level t ext for t he use case ( aft er “ disam biguat ion” of t hat t ext as a result of robust ness analysis) in t he m argin of t he sequence diagram provides visual requirem ent s t raceabilit y from t he design back t o your user- cert ified requirem ent s. The proj ect t eam will have put a lot of effort int o writ ing t he use case t ext , and t he user com m unit y should have signed off on t he result s. The diagram should m at ch t he narrat ive flow of t he associat ed use case.

Don’t ident ify all of t he necessary obj ect s first , on a robust ness diagram . I f you’re having t rouble get t ing a sequence diagram st art ed, you probably wrot e t he use case incorrect ly and/ or didn’t com plet e robust ness analysis. Having proper

robust ness diagram s, associat ed wit h rigorously defined use cases, in place m akes t he j ob significant ly easier.

Don’t provide a visual t race bet ween t he use case t ext and t he m essage arrows. Each sent ence, and each sent ence fragm ent as appropriat e, wit hin t he use case t ext should have som e whit e space around it , and each sent ence or fragm ent should line up visually wit h t he m essage or set of m essages t hat correspond wit h t he specified behavior. This will enable people reading t he diagram t o easily see how t he syst em w ill accom plish t he what t hat t he use case describes.

Don’t show plum bing; inst ead, keep your sequence diagram at a high level of abst ract ion. I t isn’t necessary t o show plum bing on robust ness diagram s, since t hey reflect a prelim inary design view, but t he sequence diagram s serve as t he last st op before coding and as such need t o show t he real design in full det ail.

Turn your sequence diagram int o a flowchart inst ead of using it t o allocat e behavior am ong obj ect s. Rem em ber t hat t he sequence diagram is t he prim ary vehicle for m aking behavior allocat ion decisions. You’re really using your sequence diagram s t o assign operat ions t o your classes as you go, which m eans t hat you should not label your m essage arrows wit h free- form t ext , but should inst ead link t he m essage nam e t o t he nam e of an operat ion on a class. ( I n Rat ional Rose, for exam ple, you m ake t his linkage by right - clicking t he m ouse on t he m essage arrow; Rose provides visual feedback in t he form of parent heses aft er t he operat ion nam e. Behavior allocat ion—deciding w hich operat ions belong t o which classes—is of crit ical im port ance in t he I CONI X approach. Decisions m ade during t his phase of a proj ect dict at e whet her t he overall design is good or bad. This is where experienced designers earn t heir pay.

Don’t focus on int erest ing m et hods ( real soft ware behavior) , as opposed t o get t ers and set t ers. By exploring t he dynam ic behavior of t he syst em , you learn which at t ribut es and operat ions are needed in t he classes cont ained wit hin your st at ic m odel. To st art , add at t ribut es and m et hods t o your classes as soon as you decide where t hey go in

t he cont ext of your sequence diagram s. Not e, however, t hat you should not spend m uch t im e drawing “ get At t ribut e” and “ set At t ribut e” m essage arrows on your sequence diagram . However, it ’s st ill a good idea t o t ake advant age of t he principle of encapsulat ion: Only allow access t o at t ribut es via “ get t er” s and “ set t er” s. You j ust don’t have t o show every “ get ” and “ set ” on your sequence diagram . This get s count erproduct ive because it ’s easy for you t o lose t he flow of t he scenario t hat way.

Don’t t hink carefully about t he origins of t he m essage arrows ( in ot her words, which obj ect is in cont rol at any given t im e) . Messages bet ween obj ect s invoke t he operat ions on t he associat ed classes. Whereas it ’s not t hat im port ant t o get t he arrows precisely right on robust ness diagram s, it ’s essent ial t hat you get t hem right on sequence diagram s. The flow of cont rol needs t o be explicit ; it should be obvious at all t im es which obj ect is in cont rol.

Don’t follow basic principles of responsibilit y- driven OOD when allocat ing behavior by drawing m essage arrows. An obj ect ( and, by ext ension, a class) should have a single “ personalit y,” and you should do your best t o avoid “ schizophrenic” obj ect s. This m eans t hat a class should be focused on a st rongly relat ed set of behaviors. This parallels t he well- est ablished rules t hat st at e t hat obj ect s should be highly cohesive and loosely coupled. Ot her principles you should focus on include reusabilit y ( t he m ore general your obj ect s and classes, t he higher t he probabilit y t hat you’ll be able t o reuse t hose obj ect s and classes for ot her proj ect s) and applicabilit y ( when you assign m et hods t o t he obj ect s on your sequence diagram s, always ask yourself whet her t here seem s t o be a good fit bet ween m et hod and obj ect , and also whet her t he t ask t he m et hod perform s is obviously relevant t o t he obj ect .)

Don’t updat e your st at ic m odel as you go by building local class diagram s for each package of use cases. I t ’s nice t o keep a “ clean” set of dom ain classes on a pure dom ain m odel diagram . However, it ’s also a good idea t o draw “ localized” st at ic class diagram s t hat show bot h solut ion space obj ect s and problem space obj ect s. A good guideline for t his is one such diagram per package of use cases. As you com e up wit h scaffolding and ot her t ypes of infrast ruct ure, such as “ helper” classes, put t hem on t he st at ic class diagram , as well. This is where you shift your focus from t he problem space t o t he solut ion space. I t ’s best t o use localized class diagram s—say, one per use case package—because, by t his t im e, your st at ic m odel is probably t oo expansive t o be capt ured wit hin one readable diagram . Doing t his also allows work t o be split across t eam s.

Ex e r cise s The following exercises, which com e from t he sequence diagram s wit hin t he m odel for our I nt ernet Bookst ore, are designed t o t est your abilit y t o spot t he t op 10 m ist akes t hat people m ake during sequence diagram m ing. Each page wit h a red label at t he t op cont ains t hree or four of t hese m ist akes; your t ask is t o writ e correct ions on t he page near t he erroneous m at erial. Following each of t hese pages is a page wit h a whit e label inside a black box at t he t op; t his page cont ains correct ed m at erial and explanat ions of t he t op 10 rules t hat were violat ed on t he previous page. Happy hunt ing!

Se a r ch by Au t h or

Se a r ch by Au t h or

On t he previous diagram : ?? There is no Search Result s obj ect . This obj ect would have been ident ified during robust - ness analysis, since we obviously aren’t supposed t o display t he ent ire cont ent s of t he cat alog. ( Not e t hat t he case t ext on t hat diagram was incorrect as well in t his regard.) ?? The Search Page sent a display m essage even t hough t he diagram shows t hat t he Cat alog is in cont rol. ?? The Cat alog obj ect invokes t he displayErrorAndProm pt m et hod on t he Search Page.

Log I n

Log I n

On t he previous diagram : ?? The use case t est doesn’t line up visually wit h t he m essage arrows. ?? The Account obj ect sent a display m essage even t hough t he diagram shows t hat t he Login Page is in cont rol. ?? The arrow associat ed wit h t he “ rem inder word” alt ernat e course has a label, rat her t han behavior allocat ion in t he form of a m et hod.

Ship Or de r

Ship Or de r

On t he previous diagram : ?? The use case t ext doesn’t appear on t he left side. ?? The Shipper I nt erface is m issing; t he fact t hat t he Shipping Clerk t alks direct ly t o t he Shipper m eans t hat t he diagram doesn’t show how t he shipm ent get s recorded. ?? The Sensor obj ect has cont rol, even t hough t his isn’t logical for a sensor in t his kind of sit uat ion.

Edit Con t e n t s of Sh oppin g Ca r t

Edit Con t e n t s of Sh oppin g Ca r t

On t he previous diagram : ?? The second get I t em m et hod call clut t ers up t he diagram . ?? The I t em obj ect sends a delet eI t em m essage t o t he Shopping Cart obj ect . ?? There are no dest roy m essages, which m ight indicat e a hole in t he designer’s t hinking, since t he I t em s won’t act ually get delet ed unless t he syst em will be coded in a language, such as Java, t hat provides for aut om at ic garbage collect ion) .

Tr a ck Re ce n t Or de r s

Tr a ck Re ce n t Or de r s

On t he previous diagram : ?? The use case t est doesn’t line up visually wit h t he m essage arrows. ?? There is no Order Det ails obj ect , which would have been ident ified during robust ness analysis, and t hus t he use case t ext is wrong, as well. ?? The Order Table obj ect invokes t he displayNoOrderMessage m et hod on t he Order Tracking Page. I t ’s a bad idea t o have persist ent dat abase t ables, or t heir proxy obj ect s, invoking m et hods on t he user int erface.

Br in gin g t h e Pie ce s Toge t h e r

Figures 7- 3 t o 7- 5 t oget her show a design- level class diagram for our I nt ernet Bookst ore. ( The classes on t he left side of Figure 7- 3 m at ch up wit h t hose on t he right side of Figure 7- 2. Figure 7- 4 has a sim ilar relat ionship w it h Figure 7- 3.) Figur e 7 - 3 . St a t ic M ode l for Th e I n t e r n e t Book st or e ( Pa r t 1 )

Figur e 7 - 4 . St a t ic M ode l for Th e I n t e r n e t Book st or e ( Pa r t 2 )

Figur e 7 - 5 . St a t ic M ode l for Th e I n t e r n e t Book st or e ( Pa r t 3 )

Ch a pt e r 8 . Cr it ica l D e sign Re vie w Crit ical design review ( CDR) involves t rying t o ensure t hat t he “ how” of det ailed design, as shown on sequence diagram s and associat ed class diagram s, m at ches up well wit h t he “ what ” t hat t he use cases specify, and t hat t he det ailed design is of sufficient dept h t o facilit at e a relat ively sm all and seam less leap int o code. CDR also involves reviewing t he qualit y of your design from a num ber of perspect ives. These m ight include m odularit y, cohesiveness of your classes, coupling bet ween obj ect s, and a num ber of ot her m et rics t hat we can lum p t oget her and call “ OO goodness.” At t his t im e, you m ight also be m aking sure t hat your design m eet s a set of int ernal design st andards for your organizat ion. Som et im es t hese st andards m ight m ake use of design pat t erns. For exam ple, t here m ay be a proj ect - wide decision t o use fact ories t o creat e inst ances of our obj ect s. Or t here m ight be st andard access m echanism s for int erfacing t o an underlying relat ional dat abase. The sequence diagram s, and t he det ailed class diagram s t hat go wit h t hem , should reflect t he real soft ware design, as t he senior designers int end for it t o be coded. We’ve m ade our best at t em pt t o st abilize and validat e our requirem ent s and our t echnical archit ect ure before we got here. CDR is t he last st op before code, so at t his point we’re looking t o nail down all of our rem aining design issues. Figure 8- 1 shows where we are. Figur e 8 - 1 :. Cr it ica l D e sign Re vie w a nd t he I CON I X Pr oce ss

Th e Ke y Ele m e n t s of Cr it ica l D e sign Re vie w The first t hing t o keep in m ind about CDR is t hat it should involve designers and developers m ore or less exclusively. We t old you in Chapt er 6 t hat prelim inary design review ( PDR) was t he last chance for m ost of your cust om ers t o be involved on a hands- on basis. Unless you have cust om ers who have significant expert ise in

det ailed design, and who need t o be involved in reviewing det ailed designs ( whet her for t echnical or polit ical reasons) , you should, in effect , sm ile and say, “ Thanks, we’ll t ake it from here. Now t hat you’ve signed off on t hem t wice, we’re freezing t he behavior descript ions unt il we get t his st uff built . See you t hen, when you can t est what we built against t hese behavior descript ions t o verify t hat we built what you want ed.” Before you com m ence CDR, you need t o m ake sure t hat you have sequence diagram s for all of t he use cases for which you’re going t o deliver code in t he current release. Per our quot e from Jacobson in Chapt er 7, you can’t be sure t hat you’ve found all of t he responsibilit ies for each of your obj ect s unless you’ve drawn sequence diagram s for all of your basic courses and all of your alt ernat e courses for all of your use cases. Taken t oget her, t hese diagram s form t he core of your dynam ic m odel, which should now show t he behavior of your syst em at runt im e, including how t he syst em will accom plish t hat behavior, in great det ail. One key aspect of CDR involves perform ing a careful review of t he m at chups bet ween each sent ence of t he use case t ext and t he m essage( s) across from t hat t ext on t he sequence diagram . The proj ect t eam will have put a lot of effort int o writ ing t he use case t ext , and t he user com m unit y should have signed off on t he result s. Also, t he robust ness m odels will have dem onst rat ed feasibilit y in t he cont ext of t he obj ect m odel—in ot her words, we’ve found som e obj ect s t hat can work t oget her t o provide t he required behavior. Now it ’s t im e t o ensure t hat t he “ how” on t he sequence diagram addresses t he “ what ” specified by t he use case. I t should be obvious which m essage or set of m essages am ong t he obj ect s on t he right - hand side of t he diagram corresponds wit h each sent ence of t he use case, including t he basic course and all alt ernat e courses. Ensuring t hat t he flow of m essages corresponds well wit h t he flow of t he use case is crit ical in enforcing t raceabilit y of your design back t o your cust om er- specified funct ional requirem ent s. We recom m end t hat senior designers perform t his kind of review for m ore j unior designers, and ( t hink about it ) t hat j unior designers do t he sam e for m ore senior designers. The next t hing t o look for is cont inuit y of m essages. We t old you in Chapt er 7 t hat it ’s essent ial t hat you get t he direct ion of m essage arrows right on sequence diagram s, t hat t he flow of cont rol needs t o be explicit . I t m ust be obvious at all t im es which obj ect is in cont rol. I f you not ice any leaps bet ween obj ect s t hat don’t involve a m essage bet ween t hose obj ect s, you need t o m ake sure t he designers elim inat e t hose leaps. While designers are m aking behavior allocat ion decisions, t hey’re m aking decisions t hat affect t he qualit y of t he classes in your design. Halbert and O’Brien defined four crit eria of a good class, which designers should keep in m ind at all t im es when deciding which m et hods belong wit h which obj ect s on sequence diagram s: ?? Reusabilit y. The m ore general your obj ect s and classes, t he higher t he probabilit y t hat you’ll be able t o reuse t hose obj ect s and classes for ot her proj ect s. Ask yourself whet her assigning a m et hod t o a class m akes t hat class m ore or less reusable. ?? Applicabilit y. The concept of applicabilit y is basically t he sam e in t he cont ext of int eract ion m odeling as it is for dom ain m odeling and use case m odeling. When you assign m et hods t o t he obj ect s on your sequence diagram s, always

ask yourself whet her t here seem s t o be a good fit bet ween m et hod and obj ect , and also whet her t he t ask t hat t he m et hod perform s is obviously relevant t o t he obj ect . ?? Com plexit y. Our first t wo crit eria, reusabilit y and applicabilit y, are st ill som ewhat t heoret ical. The subj ect of com plexit y is an indicat ion t hat we’re about t o get serious about im plem ent at ion issues. I n essence, t he issue here is whet her it ’s easier t o build a m et hod in one or anot her obj ect . ?? I m plem ent at ion knowledge. This crit erion involves asking whet her t he im plem ent at ion of t he behavior depends on det ails int ernal t o t he associat ed m et hod. Applicabilit y is probably t he m ost im port ant of t hese crit eria. As you becom e experienced at OOD, you’ll develop an int uit ive sense of “ fit .” When t his happens, you’ll cut t hrough t he behavior allocat ion decisions on your sequence diagram s like a hot knife t hrough but t er. Not e t hat we learned about t hese crit eria ( and also t he ones t hat follow) from Grady Booch’s Obj ect - Orient ed Analysis and Design wit h Applicat ions ( Addison- Wesley, 1994) . Now is also a good t im e t o t hink about your classes and ask yourself if t hey sat isfy t he following qualit y crit eria: ?? Coupling is a m easure of t he st rengt h of a connect ion bet ween t wo classes. You can im prove t he m odularit y of a syst em by designing it wit h loose coupling wherever possible. This t ranslat es int o classes t hat are highly independent . ?? Cohe sion is a m easure of how t ight ly connect ed t he at t ribut es and operat ions of a class are. I t is desirable t o st rive for high funct ional cohesion, which occurs when t he elem ent s of each of your classes are working t oget her t o provide a clearly defined behavior ( in ot her words, a single personalit y) . ?? Su fficie n cy is t he condit ion in which a class encapsulat es enough of t he abst ract ions t hat your m odels present so t hat it offers som et hing m eaningful and efficient , wit h which ot her part s of t he syst em can int eract . The key quest ion is whet her t he class covers all t he relevant cases. ?? Com ple t e ne ss is t he condit ion in which a given class’s int erface capt ures all t he relevant abst ract ions. So a com plet e class is one t hat is t heoret ically reusable in any num ber of cont ext s. Keep in m ind, t hough, t hat you should be careful not t o overdo your effort s in t his direct ion—you m ight never get anyt hing built . ?? Pr im it ive ne ss is t he condit ion in which an operat ion can be efficient ly built only if it has access t o t he m at erial on which your m odels are built . The idea here is t hat you can design cert ain operat ions t hat you can use as building blocks for ot her operat ions as your design evolves. Anot her crit erion for a good sequence diagram is a sufficient am ount of det ail. Sequence diagram s serve as t he last st op before coding and as such need t o show t he real design in full det ail. You shouldn’t consider t his part of t he proj ect done unt il all t he m et hods from your sequence diagram s are assigned t o classes wit hin your

st at ic m odel, and you’ve fact ored in “ Booch st uff,” such as abst ract and param et erized classes, friend relat ionships, and com posit ion. ( Booch st uff is especially im port ant if you’re going t o code in C+ + .) You also need t o address issues relat ed t o t hings such as persist ent st orage and t he dist ribut ion of obj ect s across your syst em . By t he way, if you are building in C+ + and you want t o learn m ore about Booch st uff, we recom m end ( in addit ion t o t he Booch book) Robert Mart in’s book Designing Obj ect Orient ed C+ + Applicat ions Using t he Booch Met hod ( Prent ice Hall, 1995) . Bob wrot e t his book before he st art ed t eaching XP. One of our favorit e quot es is from page 43, where he writ es, under t he heading “ Why I s This Bet t er Than Writ ing Code?” , t he following: Why should you go t o all t he t rouble of drawing t hese diagram s, when t he code explains t hings j ust as well, if not bet t er? For problem s as sim ple as t he one above, you shouldn’t . Diagram m ing such sim ple m odels is an exercise in fut ilit y and pedant ry. I have done it here only t o dem onst rat e t he m echanics of t he diagram s, not t heir int ended use. The advant age t o using t he diagram s will becom e m ore apparent as we go on t o st udy m ore and m ore com plex exam ples. The diagram s allow us t o visualize, on one page, concept s t hat m ight t ake dozens of pages of C+ + code t o express. They also allow us t o quickly play wit h t hese concept s and com m unicat e t hem t o ot hers. Moreover, as we j ust saw in t he discussion of t he uses relat ionships, t hese diagram s allow us t o visualize physical com piler dependencies as well as logic and algorit hm ic concept s, so t hat we can m ake a full spect rum of decisions about t he st at ic and dynam ic st ruct ure of an applicat ion. Not only can we exam ine t he logical consist ency of t he design, but we can also probe how well t he design will fit int o our developm ent environm ent . Alt hough Bob is now off preaching t he XP gospel, we t hink he had t his about right t he first t im e t hrough. A surefire sign of a “ generic” sequence diagram is t he absence of im plem ent at ion det ails, such as t hose having t o do wit h dist ribut ion. I f you’re using a t echnology such as DCOM or EJB, your sequence diagram s should reflect how you’re using specific elem ent s of t hat t ech- nology. Rem em ber: You can’t effect ively build code from a det ailed design if t he connect ion bet ween t he design and t he im plem ent at ion environm ent isn’t obvious. Looking in anot her direct ion: As you’re reviewing t he int eract ions am ong t he various obj ect s, you m ay decide t hat one or m ore well- est ablished design pat t erns would fit in nicely. You m ight choose t o use t he Fact ory Met hod pat t ern, which let s a class defer inst ant iat ion t o subclasses, or I t erat or, which let s a client t raverse a list in various ways, wit hout needing t o know how t hat list has been im plem ent ed. See Design Pat t erns ( Erich Gam m a, Richard Helm , Ralph Johnson, and John Vlissides: Addison- Wesley, 1995) for m ore inform at ion about t hese and ot her design pat t erns. Or perhaps you m ight develop new pat t erns t o est ablish a st andardized approach t o design problem s t hat appear across m ult iple use cases. This is t he t im e t o review all of t hese decisions and m ake sure you’re com fort able wit h t hem , because soon t hese design decisions will be reflect ed in code. We int roduced t he concept of t echnical archit ect ure in Chapt er 6 as being t he set of basic decisions you need t o m ake about what t echnologies you’re going t o use in

im plem ent ing t he syst em : t he program m ing language, how you’re going t o build and dist ribut e soft ware com ponent s, and so fort h. We t old you t hat t he decisions you m ake about your t echnical archit ect ure need t o be reflect ed on your robust ness diagram s. During CDR, you need t o validat e t he det ailed design as it reflect s and expands upon t hat t echnical archit ect ure. Where one of t he goals of PDR is t o ensure t he “ do- abilit y” of t he archit ect ure, here you’re looking t o act ually build t hat archit ect ure t o im plem ent your scenarios.

Th e Top 1 0 CD R Er r or s The flip side of t he principles we j ust discussed t akes t he form of a num ber of com m on errors t hat our st udent s m ake when t hey’re doing crit ical design review for t heir proj ect s. Our “ Top 10” list follows.

I nvit e nont echnical cust om ers t o t he design review . Sequence diagram s are generally full of det ails t hat m ost likely won’t m ean m uch t o any but t he m ost t echnically aware cust om ers. They exist t o be used by designers and developers. Thus, CDR sessions should include t hose people involved in det ailed design and developm ent decisions, and no one else.

Don’t check t he use case t ext carefully against t he body of t he sequence diagram . A reviewer should be able t o see easily t he visual t race bet ween a sent ence of use case t ext and a m essage, or set of m essages, t hat describe t hat behavior in t erm s of obj ect int eract ions. The right - hand side of t he diagram should also account for all of t he use case’s alt ernat e courses of act ion in ways t hat are clear t o t he reader. I f t his doesn’t hold t rue, it ’s possible t hat t he designer who did t he diagram hasn’t fully addressed t he requirem ent s expressed by t he given use case.

Don’t check t he origin and dest inat ion of every m essage arrow on every sequence diagram carefully. I t ’s essent ial t hat a sequence diagram show which obj ect is in cont rol at all t im es. I f t here are discont inuit ies, t here will be problem s wit h t he code if som eone t ries t o build it based on t he diagram .

Don’t t hink t hrough t he Halbert / O’Brien crit eria as you review your sequence diagram s. You should look for a high degree of reusabilit y of obj ect s across your sequence diagram s, and a high level of applicabilit y of m et hods wit hin each obj ect . You should also look t o keep t he com plexit y level, and t he level of im plem ent at ion specificit y, low wit hin m et hods and wit hin obj ect s as a whole. Working t o m eet t hese qualit y crit eria will give you a healt hy foundat ion for a robust obj ect - orient ed design.

Don’t review your st at ic m odels for “ qualit y class” crit eria. One of t he best sources of guidance for m aking good behavior allocat ion decisions is responsibilit y- driven design. As we explained in Chapt er 7, a class should have a single “ personalit y,” and you should avoid “ schizophrenic” obj ect s. This m eans t hat a class should be focused on a st rongly relat ed set of behaviors t hat have m inim al dependencies on ot her classes. The m ost im port ant of t he “ qualit y class” crit eria present ed earlier in t his chapt er are high cohesion and loose coupling; singlepersonalit y classes are essent ial t o achieving t hese goals. To expand on t his, let ’s t urn t o Rebecca Wirfs- Brock ( Designing Obj ect - Orient ed Soft ware, Prent ice Hall, 1990) : “ Responsibilit ies are m eant t o convey a sense of t he purpose of an obj ect and it s place in t he syst em . The responsibilit ies of an obj ect are all t he services it provides for all t he cont ract s it support s. When we assign responsibilit ies t o a class we are st at ing t hat each and every inst ance of t hat class will have t hose responsibilit ies, whet her t here is j ust one inst ance or m any.” Make sure, if at all possible, t hat som ebody who’s read t he Wirfs- Brock book—and underst ood it — part icipat es in your crit ical design review.

Don’t worry about t he “ plum bing” ; it will t ake care of it self. The sequence diagram s serve as t he last st op before coding and as such need t o show t he real design in full det ail. This includes det ails about persist ent st orage ( t o which dat abase t ables are you going t o m ap t he various obj ect s?) and dist ribut ion ( on which layer or t ier will each obj ect reside?) .

Don’t consider whet her design pat t erns would be of any use in your design. Design pat t erns can provide you wit h a great deal of leverage wit h regard t o t he reusabilit y and m aint ainabilit y of your design. The m ore pat t erns you discover and

reuse across your sequence diagram s, t he great er t he m om ent um you can build as you push t oward code, and t he m ore t im e you’ll have t o focus on t he hard decisions t hat don’t lend t hem selves t o pat t ernizing.

Show “ generic” sequence diagram s t hat disregard im plem ent at ion t echnology such as DCOM or EJBs. As we said earlier in t his chapt er, sequence diagram s are t he last st ep before code wit hin t he I CONI X process. You should be working t o m inim ize t he size of t he gap t hat you have t o cross bet ween det ailed design and im plem ent at ion by adding a reasonable am ount of det ail about t he t echnology you’re using t o build t he syst em .

Don’t review sequence diagram s for every scenario t hat will be built in t he current release. I f you don’t have, or don’t go t hrough, sequence diagram s for one or m ore of your use cases, or if any of your diagram s don’t show bot h t he basic course and all alt ernat e courses for t he given use case, t here’s a good chance t hat you will m iss som e behavior t hat one or m ore obj ect s needs t o perform , m ake som e decisions about behavior allocat ion t hat aren’t opt im al, or bot h.

Don’t worry about t he det ails of your design before you j um p int o code. Just assum e t hat refact oring t he code will fix everyt hing. Refact oring is defined, in Mart in Fowler’s book Refact oring ( Addison- Wesley, 2000) as “ t he process of changing a soft ware syst em in such a way t hat it does not alt er t he ext ernal behavior of t he code yet im proves it s int ernal st ruct ure.” This sounds like an excellent t echnique for opt im izing code. However, XPers also rely heavily on t he likes of t his, from Ext rem e Program m ing I nst alled ( Ron Jeffries, Ann Anderson, and Chet Hendrickson; Addison- Wesley, 2001) : “ [ W] hen t he design want s t o change, as it w ill, change it .” People w ho discover—and change—t he design while t hey’re coding are probably not going t o build syst em s as robust as t hose built by people who spend a sufficient am ount of t im e com plet ing, and reviewing, t he design before coding begins, because you lose t he global view of t he design when you’re focused on coding one sm all piece of it . Refact oring won’t guarant ee t hat everyt hing com es out right if you’ve m errily skipped past analysis and design—and it cert ainly won’t guarant ee t hat you’re building t he right syst em ( t hat is, t he one t hat m eet s your users’ requirem ent s) . Trying t o design and code at t he sam e t im e is like playing chess on t he I nt ernet while you’re doing your calculus hom ework. You m ight be t hinking, “ Wow, I m ust be really sm art t o be able t o do t his! ” t o yourself, but if you’re like m ost people, bot h your chess rat ing and your m at h grade would probably im prove if you undert ook

t hese t wo m ent ally dem anding t asks separat ely. ( We used t o know a guy who wore a T- shirt t hat said “ The clever program m er out - sm art s him self again.” ) Bot h design and coding ( and for t hat m at t er, analysis) are skills in t heir own right , and t here are num erous aspect s t hat m ust be kept t rack of at each phase of developm ent . We’re about at t he end of t he book, so we’d like t o leave you wit h t his final t hought : All hum ans are fallible, and one of t he best ways t o reduce error rat es is t o focus on one t hing at a t im e. “ One t hing at a t im e” is one of t he cent ral t hem es t hat ’s woven t hrough t he I CONI X Process. Even if you t ake not hing else from t his book, we t hink you’ll be m ore successful if you t ry t o at least keep t hat sim ple fact in m ind.

Appe n dix Appe n dix This Appendix cont ains a report t hat sum m arizes t he Rat ional Rose m odel for our I nt ernet Bookst ore. This report includes t he following: ?? t he class diagram at t he end of Chapt er 2 ?? t he “ good” t ext for all of t he use cases represent ed in Chapt er 3 ?? t he use case diagram at t he end of Chapt er 3 ?? all of t he “ good” robust ness diagram s from Chapt er 5 ?? t he class diagram at t he end of Chapt er 5 ?? all of t he “ good” sequence diagram s from Chapt er 7 ?? t he class diagram s at t he end of Chapt er 7 Ra t iona l Rose M ode l Re por t Rose Use Case Model Use Case Docum ent at ion

USE CASE VI EW REPORT Use Ca se Vie w Use Ca se D ia gr a m - M a in

Cla ss D ia gr a m - D om a in M ode l

Cla ss D ia gr a m - D om a in M ode l w it h At t r ibut e s

Cla ss D ia gr a m - St a t ic M ode l ( Pa r t On e )

Cla ss D ia gr a m - St a t ic M ode l ( Pa r t Tw o)

Cla ss D ia gr a m - St a t ic M ode l ( Pa r t Th r e e )

Act or - Cu st om e r Act or - Shipping Cle r k Act or - Shippe r Act or - Re ce iving Cle r k

Act or - I nve nt or y Cle r k Act or - Shipping St a t ion Act or - Re ce iving St a t ion

Use Ca se - Br ow se List of Book s D ocu m e n t a t ion : Basic Course The Cust om er clicks on a Cat egory on t he Browse Books Page. The syst em displays t he subcat egories wit hin t hat Cat egory. This process cont inues unt il t here are no m ore subcat egories, at which point t he syst em displays t he Books in t he lowest subcat egory. The Cust om er clicks on t he t hum bnail for a Book. The syst em invokes t he Display Book Det ails use case. Alt ernat e Course I f t he syst em does not find any Books cont ained wit hin a given Cat egory, it displays a m essage t o t hat effect and prom pt s t he Cust om er t o select a different Cat egory. List of Associa t ions Cust om er Com m unicat es wit h Browse List of Books

Use Ca se - Ca nce l Or de r D ocu m e n t a t ion : Basic Course The syst em ensures t hat t he Order is cancellable ( in ot her words, t hat it s st at us isn’t “ shipping” or “ shipped” ) . Then t he syst em displays t he relevant inform at ion for t he Order on t he Cancel Order Page, including it s cont ent s and t he shipping address. The Cust om er presses t he Confirm Cancel but t on. The syst em m arks t he Order st at us as “ delet ed” and t hen invokes t he Ret urn I t em s t o I nvent ory use case. Alt ernat e Course I f t he st at us of t he Order is “ shipping” or “ shipped,” t he syst em displays a m essage indicat ing t hat it ’s t oo lat e for t he Cust om er t o cancel t he order. List of Associa t ions Search Result s Page Com m unicat es wit h Cancel Order

Use Ca se - Che ck Out D ocu m e n t a t ion : Basic Course The syst em creat es a Candidat e Order obj ect t hat cont ains t he cont ent s of t he Cust om er’s Shopping Cart . Then t he syst em ret rieves t he Shipping Addresses

associat ed wit h t he Cust om er’s Account and displays t hese addresses on t he Shipping Address Page. The Cust om er select s an address and t hen presses t he Use This Address but t on. The syst em associat es t he given Shipping Address wit h t he Candidat e Order. Then t he syst em displays t he available Shipping Met hods on t he Shipping Met hod Page. The Cust om er select s a shipping m et hod and t hen presses t he Use This Shipping Met hod but t on. The syst em associat es t he given Shipping Met hod wit h t he Candidat e Order. Then t he syst em displays t he cont ent s of t he Billing I nfo obj ect s associat ed wit h t he Cust om er’s Account , on t he Billing I nform at ion Page. The Cust om er select s a billing m et hod and presses t he Use This Billing I nform at ion but t on. The syst em associat es t he given Billing I nfo obj ect wit h t he Candidat e Order. Then t he syst em displays t he Confirm Order Page. The Cust om er presses t he Confirm Order but t on. The syst em convert s t he Candidat e Order t o an Order and dest roys t he Shopping Cart . Then t he syst em ret urns cont rol t o t he use case from which t his use case received cont rol. Alt ernat e Courses I f t he Cust om er has not already logged in, t he syst em invokes t he Log I n use case. I f t he syst em does not find any Shipping Addresses, it invokes t he Creat e Shipping Address use case. I f t he syst em does not find any Billing I nfo obj ect s, it invokes t he Define Billing I nform at ion use case. I f t he Cust om er presses t he Cancel Order but t on at any t im e, t he syst em dest roys t he Candidat e Order and ret urns cont rol t o t he use case from which t his use case received cont rol. List of Associa t ions Cust om er Com m unicat es wit h Check Out Shopping Cart Page Com m unicat es wit h Check Out

Use Ca se - Edit Con t e n t s of Sh oppin g Ca r t D ocu m e n t a t ion : Basic Course On t he Shopping Cart Page, t he Cust om er m odifies t he quant it y of an I t em in t he Shopping Cart and t hen presses t he Updat e but t on. The syst em st ores t he new quant it y and t hen com put es and displays t he new cost for t hat I t em . The Cust om er presses t he Cont inue Shopping but t on. The syst em ret urns cont rol t o t he use case from which it received cont rol. Alt ernat e Courses

I f t he Cust om er changes t he quant it y of t he I t em t o 0, t he syst em delet es t hat I t em from t he Shopping Cart . I f t he Cust om er presses t he Delet e but t on inst ead of t he Updat e but t on, t he syst em delet es t hat I t em from t he Shopping Cart . I f t he Cust om er presses t he Check Out but t on inst ead of t he Cont inue Shopping but t on, t he syst em passes cont rol t o t he Check Out use case. List of Associa t ions Cust om er Com m unicat es wit h Edit Cont ent s of Shopping Cart Cla ss D ia gr a m - Edit Con t e n t s of Sh oppin g Ca r t Robu st n e ss

I nt e r a ct ion D ia gr a m - Edit Con t e n t s of Sh oppin g Ca r t Se qu e n ce

Use Ca se - Log I n D ocu m e n t a t ion : Basic Course The Cust om er clicks t he Log I n but t on on t he Hom e Page. The syst em displays t he Login Page. The Cust om er ent ers his or her user I D and password and t hen clicks t he Log I n but t on. The syst em validat es t he login inform at ion against t he persist ent Account dat a and t hen ret urns t he Cust om er t o t he Hom e Page. Alt ernat e Courses I f t he Cust om er clicks t he New Account but t on on t he Login Page, t he syst em invokes t he Open Account use case. I f t he Cust om er clicks t he Rem inder Word but t on on t he Login Page, t he syst em displays t he rem inder word st ored for t hat Cust om er, in a separat e dialog box. When t he Cust om er clicks t he OK but t on, t he syst em ret urns t he Cust om er t o t he Login Page. I f t he Cust om er ent ers a user I D t hat t he syst em does not recognize, t he syst em displays a m essage t o t hat effect and prom pt s t he Cust om er t o eit her ent er a different I D or click t he New Account but t on.

I f t he Cust om er ent ers an incorrect password, t he syst em displays a m essage t o t hat effect and prom pt s t he Cust om er t o reent er his or her password. I f t he Cust om er ent ers an incorrect password t hree t im es, t he syst em displays a page t elling t he Cust om er t hat he or she should cont act cust om er service and also freezes t he Login Page. List of Associa t ions Cust om er Com m unicat es wit h Log I n Cla ss D ia gr a m - Log I n Robu st n e ss

I nt e r a ct ion D ia gr a m - Log I n Se qu e n ce

Use Ca se - Ope n Accou n t D ocu m e n t a t ion : Basic Course The Cust om er t ypes his or her nam e, an e- m ail address, and a password ( t wice) , and t hen presses t he Creat e Account but t on. The syst em ensures t hat t he Cust om er has provided valid dat a and t hen adds an Account t o t he Mast er Account Table using t hat dat a. Then t he syst em ret urns t he Cust om er t o t he Hom e Page. Alt ernat e Courses I f t he Cust om er did not provide a nam e, t he syst em displays an error m essage t o t hat effect and prom pt s t he Cust om er t o t ype a nam e. I f t he Cust om er provided an em ail address t hat ’s not in t he correct form , t he syst em displays an error m essage t o t hat effect and prom pt s t he Cust om er t o t ype a different address. I f t he Cust om er provided a password t hat is t oo short , t he syst em displays an error m essage t o t hat effect and prom pt s t he Cust om er t o t ype a longer password. I f t he Cust om er did not t ype t he sam e password t wice, t he syst em displays an error m essage t o t hat effect and prom pt s t he Cust om er t o t ype t he password correct ly t he second t im e.

I f t he account is already in t he Mast er Account Table, t he syst em t ells t he Cust om er. List of Associa t ions Cust om er Com m unicat es wit h Open Account Login Page Com m unicat es wit h Open Account Open Account Com m unicat es wit h Login Page

Use Ca se - Pr oce ss Re ce ive d Shipm e nt D ocu m e n t a t ion : Basic Course The Receiving Clerk ensures t hat t he Line I t em s list ed on t he Purchase Order m at ch t he physical it em s. The Clerk waves t he bar code on t he packing slip under t he sensor at t he receiving st at ion. The syst em changes t he st at us of t he Purchase Order t o “ fulfilled” and updat es t he quant it y on hand values for t he various Books. The Clerk hands t he Books off t o t he I nvent ory Clerk. Alt ernat e Course I f t he Receiving Clerk finds a m ism at ch bet ween t he Purchase Order and t he physical it em s, t he Clerk st ops processing of t he shipm ent unt il he or she is able t o m ake a m at ch. List of Associa t ions Receiving Clerk Com m unicat es wit h Process Received Shipm ent Process Received Shipm ent Com m unicat es wit h I nvent ory Clerk Process Received Shipm ent Com m unicat es wit h Receiving St at ion

Use Ca se - Se a r ch by Au t h or D ocu m e n t a t ion : Basic Course The Cust om er t ypes t he nam e of an Aut hor on t he Search Page and presses t he Search but t on. The syst em ensures t hat t he Cust om er t yped a search phrase and t hen searches t he Cat alog and ret rieves all of t he Books wit h which t hat Aut hor is associat ed. The syst em ret rieves t he im port ant det ails about each Book and creat es a Search Result s obj ect wit h t hat inform at ion. Then t he syst em displays t he list of Books on t he Search Result s Page, wit h t he Books list ed in reverse chronological order by publicat ion dat e. Each ent ry has a t hum bnail of t he Book’s cover, t he Book’s t it le and aut hors, t he average Rat ing, and an Add t o Shopping Cart but t on.

The Cust om er presses t he Add t o Shopping Cart but t on for a part icular Book. The syst em passes cont rol t o t he Add I t em t o Shopping Cart use case. Alt ernat e Courses I f t he Cust om er did not t ype a search phrase before pressing t he Search but t on, t he syst em displays an error m essage t o t hat effect and prom pt s t he Cust om er t o t ype a search phrase. I f t he syst em was unable t o find any Books associat ed wit h t he Aut hor t hat t he Cust om er specified, t he syst em displays a m essage t o t hat effect and prom pt s t he Cust om er t o perform a different search. I f t he Cust om er leaves t he page in a way ot her t han by pressing an Add t o Shopping Cart but t on, t he syst em ret urns cont rol t o t he use case from which t his use case received cont rol. List of Associa t ions Cust om er Com m unicat es wit h Search by Aut hor Cla ss D ia gr a m - Se a r ch by Aut hor Robust ne ss

I nt e r a ct ion D ia gr a m - Se a r ch by Au t h or Se qu e n ce

Use Ca se - Ship Or de r D ocu m e n t a t ion : Basic Course The Shipping Clerk ensures t hat t he I t em s list ed on t he packing slip for t he Order m at ch t he physical it em s. The Clerk waves t he bar code on t he packing slip under t he sensor at t he shipping st at ion. The syst em changes t he st at us of t he Order t o “ shipping.” Then t he syst em ret rieves t he Shipping Met hod t hat t he Cust om er specified for t his Order and displays it on t he Shipping St at ion Console. The Clerk weighs t he set of physical it em s. The Clerk packages t he I t em s. The Clerk at t aches a m anifest appropriat e for t he given shipping m et hod. The Clerk waves t he bar code on t he m anifest under t he sensor. The Clerk sends t he package out via t he associat ed Shipper. Alt ernat e Course

I f t he Shipping Clerk finds a m ism at ch bet ween t he Order and t he physical it em s, t he Clerk st ops processing of t he Order unt il he or she is able t o m ake a m at ch. List of Associa t ions Shipping Clerk Com m unicat es wit h Ship Order Ship Order Com m unicat es wit h Shipper Ship Order Com m unicat es wit h Shipping St at ion Cla ss D ia gr a m - Sh ip Or de r Robu st n e ss

I nt e r a ct ion D ia gr a m - Sh ip Or de r Se qu e n ce

Use Ca se - Tr a ck Re ce n t Or de r s D ocu m e n t a t ion : Basic Course The syst em ret rieves t he Orders t hat t he Cust om er has placed wit hin t he last 30 days and displays t hese Orders on t he Order Tracking Page. Each ent ry has t he Order I D ( in t he form of a link) , t he Order dat e, t he Order st at us, t he Order recipient , and t he Shipping Met hod by which t he Order was shipped. The Cust om er clicks on a link.The syst em ret rieves t he relevant cont ent s of t he Order and t hen displays t his inform at ion, in view - only m ode, on t he Order Det ails Page. The Cust om er presses OK t o ret urn t o t he Order Tracking Page. Once t he Cust om er has finished viewing Orders, he or she clicks t he Account Maint enance link on t he Order Tracking Page. The syst em ret urns cont rol t o t he invoking use case. Alt ernat e Course I f t he Cust om er has not placed any Orders wit hin t he last 30 days, t he syst em displays a m essage t o t hat effect on t he Order Tracking Page. List of Associa t ions Cust om er Com m unicat es wit h Track Recent Orders Cla ss D ia gr a m - Tr a ck Re ce n t Or de r s Robu st n e ss

I nt e r a ct ion D ia gr a m - Tr a ck Re ce n t Or de r s Se qu e n ce

TOTALS: 2 Packages 10 Use Cases USE CASE PACKAGE STRUCTURE Use Case View

Bibliogr a ph y Grady Booch: Obj ect - Orient ed Analysis and Design wit h Applicat ions, Second Edit ion. Addison- Wesley 1994. Grady Booch, Jam es Rum baugh, I var Jacobson: The Unified Modeling Language User Guide. Addison Wesley Longm an 1999. Pet er DeGrace Leslie Hulet St ahl: The Olduvai I m perat ive. Prent ice Hall 1993. Tom DeMarco: St ruct ured Analysis and Syst em Specificat ion. Prent ice Hall 1985. Kurt Derr: Applying OMT. SI GS Books 1995. Bruce Powel Douglass: Real- Tim e UML: Developing Efficient Obj ect s for Em bedded Syst em s. Addison Wesley Longm an 1998. Mart in Fowler: Refact oring. Addison- Wesley 2000. Erich Gam m a, Richard Helm , Ralph Johnson, John Vlissides [ Gang of Four] : Design Pat t erns: Elem ent s of Reusable Obj ect - Orient ed Soft ware. Addison- Wesley 1995. Maurice Howard Halst ead: Elem ent s of Soft ware Science. 1977. Out of print . I var Jacobson, Magnus Christ erson, Pat rick Jonsson, Gunnar Overgaard: Obj ect Orient ed Soft ware Engineering: A Use Case Driven Approach. Addison- Wesley 1992. I var Jacobson, Maria Ericsson, Agnet a Jacobson: The Obj ect Advant age: Business Process Reengineering wit h Obj ect Technology. Addison- Wesley 1995. Ron Jeffries, Ann Anderson, Chet Hendrickson: Ext rem e Program m ing I nst alled. Addison- Wesley 2001. Chris Kem erer: Soft ware Proj ect Managem ent : Readings and Cases. Richard D. I rwin 1996. Robert Cecil Mart in: Designing Obj ect - Orient ed C+ + Applicat ions Using t he Booch Met hod. Prent ice Hall 1995. Doug Rosenberg: “ Applying O- O Met hods t o I nt eract ive Mult im edia Proj ect s,” OBJECT, June 1995. Doug Rosenberg: I nside t he I CONI X Process ( CD- ROM; I CONI X, 2001) . Doug Rosenberg: Mast ering UML wit h Rat ional Rose ( CD- ROM; I CONI X, 1997) . Doug Rosenberg: “ Modeling Client / Server Syst em s,” OBJECT, March 1994. Doug Rosenberg: An Obj ect Met hodology Overview CD- ROM; I CONI X, 1994) . Doug Rosenberg: Rat ional Rose 98 for Power Users ( CD- ROM; I CONI X, 1998) . Doug Rosenberg: “ UML Applied: Nine Tips t o I ncorporat ing UML I nt o Your Proj ect ,” Soft ware Developm ent , March 1998.

Doug Rosenberg: A Unified Obj ect Modeling Approach ( 2 CD- ROM set ; I CONI X, 1996) . Doug Rosenberg: “ Using t he Obj ect Modeling Technique wit h Obj ect ory for Client / Server Developm ent ,” OBJECT, Novem ber 1993. Doug Rosenberg: “ Validat ing t he Design of Client / Server Syst em s,” OBJECT, July 1994. Doug Rosenberg, Kendall Scot t “ Opt im izing Rose 98 t o Support Use Case Driven Obj ect Modeling.” Available at ht t p:/ / w w w .r ose a r ch it e ct .com / a r ch ive s/ 9 8 1 0 / on lin e .sh t m l. Doug Rosenberg Kendall Scot t : Use Case Driven Obj ect Modeling wit h UML: A Pract ical Approach. Addison Wesley Longm an 1999. Jam es Rum baugh, Michael Blaha, William Prem erlani, Frederick Eddy, William Lorenzen: Obj ect - Orient ed Modeling and Design. Prent ice Hall 1991. William Shakespeare: Much Ado About Not hing. Public dom ain. Rebecca Wirfs- Brock, Brian Wilkerson, Lauren Wiener: Designing Obj ect - Orient ed Soft ware. Prent ice Hall 1990.