The Object Primer Second Edition The App

Th e Object Prim er
Secon d Edition
Th e Ap p lica t ion Develop er’s Guid e t o
Object Orien t a t ion a n d t h e UML
Sc o t t W. Am b l e r
PUBLISHED BY THE PRESS SYNDICATE OF THE UNIVERSITY OF CAMBRIDGE
Th e Pitt Bu ild in g, Tru m p in gton Street, Cam brid ge, Un ited Kin gd om
CAMBRIDGE UNIVERSITY PRESS

Th e Ed in bu rgh Bu ild in g, Cam brid ge CB2 2RU, UK
40 West 2 0th Street, New York, NY 10011-4211, USA
10 Stam ford Road , Oakleigh , VIC 3166, Au stralia
Ru iz d e Alarcón 13, 28014 Mad rid , Sp ain
Dock Hou se, Th e Waterfron t, Cap t Town 8001, Sou th Africa
h ttp :/ / www.cam brid ge.org
Pu blish ed in association with SIGS Books
© Cam brid ge Un iversity Press 2 001
All righ ts reserved .
Th is book is in cop yrigh t. Su bject to statu tory excep tion an d to th e p rovision s

of relevan t collective licen sin g agreem en ts, n o rep rodu ction of an y p art m ay
take p lace with ou t th e written p erm ission of Cam bridge Un iversity Press.
An y p rod u ct m en tion ed in th is book m ay be a trad em ark of its com p an y.
First ed ition p u blish ed by SIGS Books an d Mu ltim ed ia in 1995

First ed ition p u blish ed by Cam brid ge Un iversity Press in 1998
Rep rin ted 1998, 1999
Secon d ed ition p u blish ed 2 001
Design by Kevin Callah an an d An d rea Cam m arata

Com p osition by An d rea Cam m arata
Cover d esign by Jean Coh n an d An d rea Cam m arata
Prin ted in th e Un ited States of Am erica
A catalog record for this book is available from the British Library.
Library of Congress Cataloging in Publication data available.
ISBN 0 521 78519 7 p ap erback

Co n t e n t s
Fo rew o rd xvii
Preface xix
Ackn o w ledgm en ts xxiii
Ch apter 1 • In tro ductio n 1

1.1 Th e Stru ctu red Parad igm versu s th e Object-Orien ted Parad igm 2
1.2 How Is Th is Book Organ ized ? 3
1.3 How to Read Th is Book 5
1.4 W h at You Have Learn ed 7
Ch apter 2 • Object Orien tatio n : A New So ftw are Paradigm 9

2.1 Th e Poten tial Ben efits of Object Orien tation 10
2.1.1 In creased Reu sability 10
2.1.2 In creased Exten sibility 10
2.1.3 Im p roved Qu ality 11
2.1.4 Fin an cial Ben efits 12
2.1.5 In creased Ch an ce of Project Su ccess 12
2.1.6 Red u ced Main ten an ce Bu rd en 15
2.1.7 Red u ced Ap p lication Backlog 17
2.1.8 Man aged Com p lexity 19
2.2 Th e Poten tial Drawbacks of OO 20
2.3 Objects Are Here to Stay 22
ix
x The Object Prim er
2.4 Object Stan d ard s 23

2.5 Th e Object-Orien ted Software Process 23
2.7 Review Qu estion s 28
Ch apter 3 • Gath erin g User Requirem en ts 31

3.1 Pu ttin g Togeth er a Req u irem en ts Mod elin g Team 34
3.1.1 Ch oosin g Good Su bject-Matter Exp erts 38
3.1.2 Ch oosin g Good Facilitators 39
3.1.3 Ch oosin g Good Scribes 40
3.2 Fu n d am en tal Req u irem en ts Gath erin g Tech n iq u es 40
3.2.1 In terviewin g 40
3.2.2 Brain storm in g 42
3.3 Essen tial Use Case Mod elin g 44
3.3.1 A Picture Says 1,000 Words: Drawin g Use Case Diagram s 45
3.3.2 Id en tifyin g Actors 48
3.3.3 Docu m en tin g a Use Case 50
3.3.4 Use Cases: Essen tial versu s System 52
3.3.5 Id en tifyin g Use Cases 56
3.3.6 Mod elin g Differen t Logic Flows: Altern ate Cou rses of Action 61
3.4 Essen tial User In terface Prototyp in g 63
3.4.1 An Exam p le Essen tial User-In terface Mod el 67
3.4.2 En su rin g System Usability 71
3.4.3 User In terface-Flow Diagram m in g 72
3.5 Dom ain Modelin g with Class Respon sibility Collaborator (CRC) Cards 74
3.5.1 Prep arin g to CRC Mod el 77
3.5.2 Fin d in g Classes 77
3.5.3 Fin d in g Resp on sibilities 82
3.5.4 Defin in g Collaborators 85
3.5.5 Arran gin g th e CRC Card s 89
3.5.6 Th e Ad van tages an d Disad van tages of CRC Mod elin g 91
3.6 Develop in g a Su p p lem en tary Sp ecification 95
3.6.1 Id en tifyin g Bu sin ess Ru les 95
3.6.2 Iden tifyin g Non fun ction al Requirem en ts an d Con strain ts 97
3.7 Id en tifyin g Ch an ge Cases 98
3.7.1 Docu m en tin g Ch an ge Cases 99
3.7.2 Th e Ad van tages of Ch an ge Cases 100
3.8 Tip s for Organ izin g a Mod elin g Room 101
3.9 Req u irem en ts Tip s an d Tech n iq u es 102
3.10.1 Th e ABC Ban k Case Stu d y 105
Ch apter 4 • En surin g Yo ur Requirem en ts Are Co rrect:

Requirem en ts Validatio n Tech n iques 109
4.1 Testin g Early an d Often 111
4.2 Use Case Scen ario Testin g 114
4.2.1 Th e Step s of th e Use Case Scen ario Testin g Process 114
Con ten ts xi
4.2.2 Creatin g Use Case Scen arios 116

4.2.3 Actin g Ou t Scen arios 119
4.2.4 Th e Ad van tages of Use Case Scen ario Testin g 126
4.2.5 Th e Disad van tages of Use Case Scen ario Testin g 127
4.3 User In terface Walkth rou gh s 128
4.4 Req u irem en ts Reviews 128
Ch apter 5 • Un derstan din g Th e Basics: Object-Orien ted Co n cepts 133

5.1 New an d Old Con cep ts Togeth er 134
5.2 OO Con cep ts from a Stru ctu red Poin t-of-View 136
5.3 Objects an d Classes 138
5.4 Attribu tes an d Meth od s 140
5.5 Abstraction , En capsulation , an d In form ation Hidin g 143
5.5.1 Abstraction 143
5.5.2 En cap su lation 144
5.5.3 In form ation Hid in g 144
5.5.4 An Exam p le 145
5.5.5 W h y Th is Is Im p ortan t 145
5.6 In h eritan ce 146
5.6.1 Mod elin g In h eritan ce 147
5.6.2 In h eritan ce Tip s an d Tech n iq u es 148
5.6.3 Sin gle an d Mu ltip le In h eritan ce 150
5.6.4 Abstract an d Con crete Classes 152
5.7 Association 152
5.7.1 Mod elin g Association s 153
5.7.2 How Association s Are Im p lem en ted 157
5.8 Aggregation 158
5.8.1 Mod elin g Aggregation 158
5.8.2 Aggregation Tip s an d Tech n iq u es 160
5.9 Collaboration 160
5.9.1 Messages 161
5.9.2 Collaboration Tip s an d Tech n iq u es 163
5.10 Persisten ce 165
5.10.1 Persisten ce Tip s an d Tech n iq u es 166
5.10.2 Persisten t Mem ory: Th e Object Sp ace 167
5.10.3 Object Databases (ODBs) 167
5.11 Persisten t versu s Tran sitory Association s 168
5.11.1 Persisten t Association s 169
5.11.2 Tran sitory Association s: Dep en d en cies 169
5.12 Cou p lin g 170
5.12.1 Cou p lin g Tip s an d Tech n iq u es 171
5.13 Coh esion 172
5.14 Polym orp h ism 173
5.14.1 An Exam p le: Th e Poker Gam e 173
5.14.2 Polym orp h ism at th e Un iversity 174
5.15 In terfaces 175
x ii The Object Prim er
5.16 Com p on en ts 176

5.17 Pattern s 178
Ch apter 6 • Determ in in g Wh at to Build: Object-Orien ted An alysis 181

6.1 System Use Case Mod elin g 185
6.1.1 Writin g System Use Cases 186
6.1.2 Reu se in Use Case Mod els: <<exten d >>, <<in clu d e>>,
an d In h eritan ce 190
6.1.3 Good Th in gs to Kn ow Abou t Use Case Mod elin g 193
6.1.4 Use Case Mod elin g Tip s an d Tech n iq u es 195
6.2 Seq u en ce Diagram s: From Use Cases to Classes 197
6.2.1 How to Draw Seq u en ce Diagram s 2 04
6.2.2 W h y an d W h en Sh ou ld You Draw Seq u en ce Diagram s? 2 07
6.2.3 How to Docu m en t Seq u en ce Diagram s 2 07
6.2.4 A Good Th in g to Kn ow Abou t Seq u en ce Diagram s 2 07
6.3 Con cep tu al Mod elin g: Class Diagram s 2 08
6.3.1 Mod elin g Classes, Attribu tes, an d Meth od s 213
6.3.2 Mod elin g Association s 216
6.3.3 Mod elin g Dep en d en cies 22 0
6.3.4 In trod u cin g Reu se Between Classes via In h eritan ce 22 0
6.3.5 Mod elin g Aggregation Association s 222
6.3.6 Mod elin g Association Classes 224
6.3.7 Docu m en tin g Class Mod els 225
6.3.8 Con cep tu al Class Mod elin g Tip s 227
6.4 Activity Diagram m in g 229
6.4.1 How to Draw Activity Diagram s 230
6.4.2 How to Docu m en t Activity Diagram s 232
6.5 User In terface Prototyp in g 232
6.5.1 Determ in in g th e Need s of You r Users 232
6.5.2 Bu ild in g th e Prototyp e 234
6.5.3 Evalu atin g th e Prototyp e 234
6.5.4 Determ in in g If You Are Fin ish ed 234
6.5.5 Good Th in gs to Un d erstan d Abou t Prototyp in g 235
6.5.6 Prototyp in g Tip s an d Tech n iq u es 235
6.6 Evolvin g You r Su p p lem en tary Sp ecification 237
6.6.1 Th e Object Con strain t Lan gu age 237
6.7 Ap p lyin g An alysis Pattern s Effectively 238
6.7.1 Th e Bu sin ess En tity An alysis Pattern 238
6.7.2 Th e Con tact Poin t An alysis Pattern 239
6.7.3 Th e Ad van tages an d Disad van tages of Pattern s 240
6.8 User Docu m en tation 242
6.8.1 Typ es of User Docu m en tation 242
6.8.2 How to Write User Docu m en tation 243
6.9 Organ izin g You r Mod els with Packages 245
Con ten ts x iii
Ch apter 7 • Determ in in g Ho w to Build Yo ur System :

Object-Orien ted Design 249
7.1 Layerin g You r Mod els—Class Typ e Arch itectu re 254
7.1.1 Th e User-In terface Layer 256
7.1.2 Th e Con troller/ Process Layer 256
7.1.3 Th e Bu sin ess/ Dom ain Layer 260
7.1.4 Th e Persisten ce Layer 260
7.1.5 Th e System Layer 261
7.2 Class Mod elin g 262
7.2.1 In h eritan ce Tech n iq u es 263
7.2.2 Association an d Dep en d en cy Tech n iq u es 266
7.2.3 Aggregation an d Com p osition Tech n iq u es 270
7.2.4 Mod elin g Meth od s Du rin g Design 272
7.2.5 Mod elin g Attribu tes Du rin g Design 281
7.2.6 In trod u cin g In terfaces In to You r Mod el 286
7.2.7 Class Mod elin g Design Tip s 289
7.3 Ap p lyin g Design Pattern s Effectively 293
7.3.1 Th e Sin gleton Design Pattern 294
7.3.2 Th e Façad e Design Pattern 295
7.3.3 Tip s for Ap p lyin g Pattern s Effectively 295
7.4 State Ch art Mod elin g 296
7.4.1 How to Draw a State Diagram 299
7.4.2 W h en an d W h y Sh ou ld You Draw State Diagram s? 300
7.4.3 State Diagram s an d In h eritan ce 301
7.5 Collaboration Mod elin g 301
7.5.1 Drawin g Collaboration Diagram s 303
7.5.2 Collaboration an d In h eritan ce 304
7.5.3 W h en Sh ou ld You Draw Collaboration Diagram s? 305
7.6 Com p on en t Mod elin g 306
7.6.1 How to Develop a Com p on en t Mod el 306
7.6.2 Im p lem en tin g a Com p on en t 312
7.7 Dep loym en t Mod elin g 312
7.7.1 How to Develop a Dep loym en t Mod el 313
7.7.2 W h en Sh ou ld You Create Dep loym en t Mod els? 315
7.8 Relation al Persisten ce Mod elin g 316
7.8.1 Keys an d Object Id en tifiers 316
7.8.2 Th e Basics of Map p in g Objects to RDBs 324
7.8.3 Map p in g Association s, Aggregation , an d Com p osition 329
7.8.4 Drawin g Persisten ce Mod els 333
7.8.5 W h en Sh ou ld You Develop Persisten ce Mod els? 334
7.9 User In terface Design 335
7.9.1 User-In terface Design Prin cip les 335
7.9.2 Tech n iq u es for Im p rovin g You r User-In terface Design 336
7.9.3 User-In terface Flow Diagram m in g 339
7.9.4 User-In terface Design Stan d ard s an d Gu id elin es 340
7.10 Design Tip s 341
7.12.1 Th e Ban k Case Stu d y Six Mon th s Later 346
x iv The Object Prim er
Ch apter 8 • Object-Orien ted Testin g 347

8.1 W h at Is Program m in g? 350
8.2 From Design to Java Cod e 352
8.2.1 Im p lem en tin g a Class In Java 354
8.2.2 Declarin g In stan ce Attribu tes In Java 356
8.2.3 Im p lem en tin g In stan ce Meth od s In Java 358
8.2.4 Im p lem en tin g Static Meth od s an d Attribu tes in Java 360
8.2.5 Im p lem en tin g Con stru ctors 364
8.2.6 En cap su latin g Attribu tes with Accessors 366
8.2.7 Im p lem en tin g In h eritan ce In Java 372
8.2.8 Im p lem en tin g In terfaces In Java 372
8.2.9 Im p lem en tin g Association s, Aggregation ,
an d Com p osition In Java 377
8.2.10 Im p lem en tin g Dep en d en cies 384
8.2.11 Im p lem en tin g Collaboration in Java 385
8.2.12 Im p lem en tin g Bu sin ess Ru les 385
8.3 From Design to Persisten ce Cod e 386
8.3.1 Strategies for Im p lem en tin g Persisten ce Cod e 387
8.3.2 Defin in g an d Mod ifyin g You r Persisten ce Sch em a 389
8.3.3 Creatin g, Retrievin g, Up d atin g, an d Deletin g Data 389
8.3.4 Im p lem en tin g Beh avior in a Relation al Database 391
8.4 Program m in g Tip s 393
8.4.1 Tech n iq u es for Writin g Clean Cod e 393
8.4.2 Tech n iq u es for Writin g Effective Docu m en tation 396
8.4.3 Miscellan eou s 398
Ch apter 9 • Object-Orien ted Testin g 403

9.1 Overcom in g Miscon cep tion s Abou t Object-Orien ted Testin g 404
9.1.1 Miscon cep tion #1: With Objects You Do Less Testin g 405
9.1.2 Miscon ception #2: Structured Testin g Tech n iques Are Sufficien t 406
9.1.3 Miscon ception #3: Testin g th e User In terface Is Sufficien t 406
9.2 Fu ll Lifecycle Object-Orien ted Testin g (FLOOT) 406
9.2.1 Regression Testin g 407
9.2.2 Qu ality Assu ran ce 408
9.2.3 Testin g Your Requirem en ts, An alysis, an d Design Models 409
9.2.4 Testin g You r Sou rce Cod e 412
9.2.5 Testin g You r System in its En tirety 418
9.2.6 Testin g by Users 42 0
9.3 From Test Cases to Defects 422
Ch apter 10 • Puttin g It All To geth er: So ftw are Pro cess 427
10.1 W h at Is So Differen t Abou t Object-Orien ted Develop m en t? 429
10.2 W h at Is a Software Process? 430
10.3 W h y Do You Need a Software Process? 431
Con ten ts xv
10.4 From Waterfall/ Serial Develop m en t… 432

10.5 …to Iterative Develop m en t… 433
10.6 …an d In crem en tal Develop m en t 435
10.7 Th e Develop m en t Process Presen ted in Th is Book 437
10.8 Process Pattern s of th e Object-Orien ted Software Process (OOSP) 438
10.9 Th e Un ified Process 442
10.10 Oth er Processes 444
10.10.1 eXtrem e Program m in g (XP) 444
10.10.2 Th e Microsoft Solu tion s Fram ework (MSF) 448
10.10.3 Th e OPEN Process 449
10.10.4 Catalysis 449
10.11 W h en to Use Objects 450
10.12 W h en Not to Use Objects 451
Ch apter 11 • Wh ere to Go Fro m Here 455

11.1 Th e Post-2 000 (P2K) En viron m en t 456
11.1.1 New Software Strategies 456
11.1.2 En ablin g Tech n ologies 457
11.1.3 Lead in g-Ed ge Develop m en t Tech n iq u es 459
11.1.4 Mod ern Software Processes 461
11.1.5 Object Program m in g Lan gu ages 462
11.1.6 In tern et Develop m en t Lan gu ages 465
11.2 Skills for Sp ecific Position s 466
11.2.1 Bu sin ess An alyst 466
11.2.2 IT Sen ior Man ager 466
11.2.3 Object Mod eler 467
11.2.4 Persisten ce Mod eler 467
11.2.5 Persisten ce Ad m in istrator 468
11.2.6 Program m er 468
11.2.7 Project Man ager 468
11.2.8 Qu ality Assu ran ce En gin eer 469
11.2.9 Software Arch itect 469
11.2.10 Test En gin eer 470
11.3 Con tin u in g You r Learn in g Process 470
11.3.1 Take Gen eral In trod u ctory Train in g 471
11.3.2 Gain Han d s-on Exp erien ce 471
11.3.3 Obtain Men torin g 471
11.3.4 Work in a Learn in g Team 473
11.3.5 Read , Read , Read 473
11.3.6 Take Ad van ced Train in g 474
11.5 Partin g Word s 474
Glo ssary 475

Referen ces an d Reco m m en ded Readin g 499
In dex 505
Develop ers a re good a t build ing syst em s right .
W ha t we’re not good a t is build ing t he right syst em .
Ch a p t er 1
In t ro d u c t i o n
Wh a t You Will Lea rn in Th is Ch a pter
What is object orientation?

The difficulties encountered with traditional development methods
How this book is organized
How to read this book
Wh y You Need to Rea d Th is Ch a pter
To understand why you should consider embracing object-oriented techniques,

you need to understand the challenges of the structured paradigm and how the
object paradigm addresses them.
1
2 The Object Prim er
Th is book d escribes th e object-orien ted (OO) p arad igm , a d evelop m en t

strategy based on th e con cep t th at system s sh ou ld be bu ilt from a collec-
tion of reu sable com p on en ts called objects. In stead of sep aratin g d ata an d
fu n ction ality, as is d on e in th e stru ctu red p arad igm , objects en com p ass
both . W h ile th e object-orien ted p arad igm sou n d s sim ilar to th e stru c-
tu red p arad igm , as you will see in th is book, it is actu ally q u ite d ifferen t.
A com m on m istake th at m an y exp erien ced d evelop ers m ake is to assu m e
th ey h ave been “d oin g objects” all alon g, ju st becau se th ey h ave been
ap p lyin g sim ilar software-en gin eerin g p rin cip les. Th e reality is you m u st
recogn ize th at objects are d ifferen t so you can start you r learn in g exp eri-
en ce su ccessfu lly.
1.1 Th e Stru ctu red Pa ra dig m versu s th e Object-

Orien ted Pa ra dig m
Th e structured paradigm is a d evelop m en t strategy based on th e con cep t
th at a system sh ou ld be sep arated in to two p arts: d ata (m od eled u sin g a
d ata/ p ersisten ce m od el) an d fu n ction ality (m od eled u sin g a p rocess
m od el). In sh ort, u sin g th e stru ctu red ap p roach , you d evelop ap p lica-
tion s in wh ich d ata is sep arate from beh avior in both th e d esign m od el
an d in th e system im p lem en tation (th at is, th e p rogram ).
On th e oth er h an d , as you see in Figu re 1-1, th e m ain con cep t beh in d
th e object-orien ted p arad igm is th at in stead of d efin in g system s as two
sep arate p arts (d ata an d fu n ction ality), you n ow d efin e system s as a col-
lection of in teractin g objects. Objects d o th in gs (th at is, th ey h ave fu n c-
tion ality) an d th ey kn ow th in gs (th ey h ave d ata). W h ile th is sou n d s
sim ilar to th e stru ctu red p arad igm , it really isn ’t.
Con sid er th e d esign of an in form ation system for a u n iversity. Takin g
th e stru ctu red ap p roach , you wou ld d efin e th e layou t of a d atabase an d
th e d esign of a p rogram to access th at d ata. In th e d atabase wou ld be
in form ation abou t stu d en ts, p rofessors, room s, an d cou rses. Th e p rogram
wou ld en able u sers to en roll stu d en ts in cou rses, assign p rofessors to
teach cou rses, sch ed u le cou rses in certain room s, an d so on . Th e p rogram
wou ld access an d u p d ate th e d atabase, in effect su p p ortin g th e d aily
bu sin ess of th e sch ool.
Now con sid er th e u n iversity in form ation system from an object-
orien ted p ersp ective. In th e real world , th ere are stu d en ts, p rofessors,
room s, an d cou rses. All of th ese th in gs wou ld be con sid ered objects. In
D EFIN ITION
Pa ra d igm . (pronounced para-dime) An overall strategy or viewpoint for doing
things. A paradigm is a specific mindset.
Ch a pter 1 • In troduction 3
Object
Object
Functions
and Data
Procedures Object Object
A Structured Application An Object Application
th e real world , stu d en ts kn ow th in gs (th ey h ave n am es, ad d resses, birth Figure 1-1.
d ates, telep h on e n u m bers, an d so on ) an d th ey d o th in gs (en roll in Comparing the
cou rses, d rop cou rses, an d p ay tu ition ). Professors also kn ow th in gs (th e structured and
cou rses th ey teach an d th eir n am es) an d th ey d o th in gs (in p u t m arks an d object-oriented
paradigms
m ake sch ed u le req u ests). From a system s p ersp ective, room s kn ow th in gs
(th e bu ild in g th ey’re in an d th eir room n u m ber) an d sh ou ld be able to
d o th in gs, too (su ch as tell you wh en th ey are available an d en able you
to reserve th em for a certain p eriod of tim e). Cou rses also kn ow th in gs
(th eir title, d escrip tion , an d wh o is takin g th e cou rse) an d sh ou ld be able
to d o th in gs (su ch as lettin g stu d en ts en roll in th em or d rop th em ).
To im plem en t th is system , we would defin e a collection of classes (a class
is a gen eric represen tation of sim ilar objects) th at in teract with each oth er.
For exam ple, we would h ave “Course,” “Studen t,” “Professor,” an d “Room ”
classes. Th e collection of th ese classes would m ake up our application ,
wh ich would in clude both th e fun ction ality (th e program ) an d th e data.
As you can see, th e OO ap p roach resu lts in a com p letely d ifferen t view For ind ivid ua ls,
of wh at an ap p lication is all abou t. Rath er th an h avin g a p rogram th at OO is a whole new
accesses a d atabase, we h ave an ap p lication th at exists in wh at is called wa y t o t hink.
For orga niza t ions,
an object sp ace. Th e object space is wh ere both th e p rogram an d th e d ata
OO req uires a
for th e ap p lication resid e. I d iscu ss th is con cep t in fu rth er d etail in Ch ap - com p let e cha nge
ter 5 bu t, for n ow, th in k of th e object sp ace as virtu al m em ory. in it s syst em
d evelop m ent
cult ure.
1.2 How Is Th is Book Org a n ized?
The Object Prim er covers leadin g-edge OO tech n iques an d con cepts th at
h ave been proven in th e developm en t of real-world application s. It covers
in detail wh y you sh ould learn th is n ew approach called object orientation,
requirem en ts tech n iques, such as use cases an d CRC m odelin g, OO
D EFIN ITION S
Cla ss. A template from which objects are created (instantiated). Although in
the real world Doug, Wayne, and Bill are all “ student objects,” we would model
the class “ Student” instead.
Object sp a ce. The memory space, including all accessible permanent storage,
in which objects exist and interact with one another.
Object . A person, place, thing, concept, event, screen, or report. Objects both
know things (that is, they have data) and they do things (that is, they have
functionality).
Object -orient ed p a ra d igm . A development strategy based on the concept of
building systems from reusable components called objects.
OO. An acronym used interchangeably for two terms: Object-oriented and
object orientation. For example, when we say OO programming, we really
mean object-oriented programming. When we say this is a book that describes
OO, we really mean this it is a book that describes object orientation.
Th e Object Prim er con cepts, OO an alysis an d design usin g th e UML m odelin g tech n iques,
covers everyt hing OO program m in g, OO testin g, an d th e OO software process. Th e book
you need to know to en ds with a discussion of h ow to con tin ue your learn in g process, in cludin g
get you st a rt ed in
description s of com m on object-orien ted tech n ologies an d tech n iques you
OO d evelop m ent .
m igh t wan t to con sider applyin g on software projects.
Figu re 1-2 d ep icts th e organ ization of The Object Prim er, sh owin g th e
in d ivid u al ch ap ters an d th e relation sh ip s between th em . Table 1-1 su m -
m arizes th e con ten ts of each ch ap ter. On th e left sid e of th e d iagram are
th e ch ap ters th at d escribe th e fu n d am en tal activities of th e software
p rocess, su ch as gath erin g req u irem en ts, object-orien ted an alysis, an d
object-orien ted p rogram m in g. Th e arrows between th e boxes rep resen t
th e gen eral relation sh ip s between th e ch ap ters: you see th e ch ap ters
d escribin g gath erin g req u irem en ts, valid atin g req u irem en ts, an d object-
orien ted an alysis are closely related to on e an oth er. Ch ap ter 9 covers
object-orien ted testin g an d d escribes testin g tech n iq u es th at sh ou ld be
u sed to valid ate you r an alysis, d esign , an d p rogram m in g efforts. Alon g
th e righ t-h an d sid e of Figu re 1-2 are listed several “su p p ortin g” ch ap ters,
ch ap ters th at p resen t m aterial th at is critical to you r u n d erstan d in g of
th e object-orien ted p arad igm .
D EFIN ITION
Unified Mod eling La ngua ge (UML). The definition of a standard modeling
language for object-oriented software, including the definition of a modeling
notation and the semantics for applying it as defined by the Object Manage-
ment Group (OMG).
Gather Validate Object-Oriented

Requirements Requirements Paradigm
(Chapter 3) (Chapter 4) (Chapter 2)
Object-Oriented Object-Oriented
Analysis Concepts
(Chapter 6) (Chapter 5)
Object-Oriented Object-Oriented Object-Oriented

Testing Design Software Process
(Chapter 9) (Chapter 7) (Chapter 10)
Object-Oriented Where To Go From

Programming Here
(Chapter 8) Chapter 11
Figure 1-2.
The organization of
1.3 How to Rea d Th is Book this book
Progra m m ers, Designers, a nd Project Ma na gers

Read th e en tire book, cover to cover. It’s tem p tin g to skip to Ch ap ter 5,
wh ich overviews object-orien ted con cep ts, an d start read in g from th ere,
bu t th at wou ld be a m ajor m istake. Ch ap ter 5 bu ild s on m an y of th e
id eas p resen ted in th e first fou r ch ap ters; th erefore, read in g ah ead is n ot
to you r ad van tage.
Business Ana lyst s a nd User Rep resent a t ives

Ch ap ters 3 an d 4 are written sp ecifically for you , d escribin g in d etail th e
tech n iq u es for gath erin g an d valid atin g th e u ser req u irem en ts for an OO
ap p lication . Bu sin ess an alysts sh ou ld also read Ch ap ter 5, wh ich
Ta ble 1-1. The m a t eria l cont a ined in ea ch cha p t er
Ch a pter Description
2: A New Software Paradigm Discussion of the advantages and disadvantages of object ori-
entation, why objects are here to stay, and an overview of the
software process.
3: Gathering Requirements Description of requirements gathering techniques, including

use cases, change cases, CRC modeling, interviewing, and
user interface prototyping. A discussion of how the tech-
niques work together is included.
4: Validating Requirements Description of requirements validation techniques such as use

case scenario testing and requirements walkthroughs.
5: Object-Oriented Concepts Description of the fundamental concepts of object orienta-

tion, including inheritance, polymorphism, aggregation, and
encapsulation.
6: Object-Oriented Analysis Description of common object-oriented analysis techniques

such as sequence diagrams and class diagrams. A description
of how to make the transition from requirements to analysis is
presented, as well as how all the techniques fit together.
7: Object-Oriented Design Description of common object-oriented design techniques

such as class diagrams, state chart diagrams, collaboration
diagrams, and persistence models. A description of how to
make the transition from analysis to design is presented, as
well as how the techniques fit together.
8: Object-Oriented Programming Overview of common object-oriented programming tips and

techniques. A discussion of how to make the transition from
design to coding is presented.
9: Object-Oriented Testing Overview of the Full Lifecycle Object-Oriented Testing (FLOOT)

methodology and techniques.
10: Object-Oriented Software Process Overview of the Object-Oriented Software Process (OOSP)
and the enhanced lifecycle of the Unified Process.
11: Where to Go From Here Discussion of what you need to do to continue your OO
learning process, including a description of leading object
technologies and techniques such as Java, Enterprise Java-
Beans (EJB), C++, and component-based development.
D EFIN ITION
Full lifecycle object -orient ed t est ing (FLOOT). A testing methodology for
object-oriented development that comprises testing techniques that, taken
together, provide methods to verify that your application works correctly at
each stage of development.
d escribes th e fu n d am en tal con cep ts of object orien tation , an d Ch ap ter 6,

wh ich d escribes OO an alysis tech n iq u es. Both grou p s sh ou ld also read
Ch ap ter 10, wh ich d escribes th e overall software p rocess for object-
orien ted software —th is will h elp p u t th e overall effort in to con text for
you an d give you a greater ap p reciation of h ow software is d evelop ed ,
m ain tain ed , an d su p p orted .
St ud ent s
Like th e first grou p of p eop le, you sh ou ld also read th is book from cover
to cover. Fu rth erm ore, you sh ou ld read th is book two or th ree weeks
before you r m id term test on object orien tation , an d n ot th e n igh t before
th e exam . Th is stu ff takes a wh ile to sin k in (actu ally it takes m u ch
lon ger th an a few weeks, bu t th ere’s on ly so m u ch tim e in a sch ool term ).
1.4 Wh a t You Ha ve Lea rn ed

Th e object-orien ted p arad igm is a software d evelop m en t strategy based
on th e id ea of bu ild in g system s from reu sable com p on en ts called objects.
As you saw in Figu re 1-1, th e p rim ary con cep t beh in d th e object-orien ted
p arad igm is, in stead of d efin in g system s as two sep arate p arts (d ata an d
fu n ction ality), you n ow d efin e system s as a collection of in teractin g
objects. Objects d o th in gs (th at is, th ey h ave fu n ction ality) an d th ey
kn ow th in gs (th at is, th ey h ave d ata).
Your req uirem ent s d efine wha t is req uest ed t o be built .
Your a na lysis d efines wha t will be built .
Ch a p t er 6
D e t e rm i n i n g W h a t t o
Bu i l d : Ob je c t -Ori e n t e d
An a l y si s
Wh a t You Will Lea rn In Th is Ch a pter
How to develop a system use case model from an essential use case model
How to develop sequence diagrams
How to develop a conceptual class model from a domain model
How to develop activity diagrams
How to develop a user interface prototype
How to evolve your supplementary specification
How to apply the Object Constraint Language (OCL)
How to apply analysis patterns
How to write user documentation
How to apply packages on your diagrams
Wh y You Need to Rea d Th is Ch a pter
Your requirements model, although effective for understanding what your users
want to have built, is not as effective at understanding what will be built.
Object-oriented analysis techniques, such as system use case modeling, sequence
diagramming, class modeling, activity diagramming, and user interface
prototyping are used to bridge the gap between requirements and system design.
181
Req uirem ent s Th e p u rp ose of an alysis is to u n d erstan d wh at will be bu ilt. Th is is sim ilar
engineering to req u irem en ts gath erin g, d escribed in Ch ap ter 3, th e p u rp ose of wh ich
focuses on
is to d eterm in e wh at you r u sers wan t to h ave bu ilt. Th e m ain d ifferen ce
und erst a nd ing
is th at th e focu s of req u irem en ts gath erin g is on u n d erstan d in g you r
users a nd t heir
usa ge, wherea s u sers an d th eir p oten tial u sage of th e system , wh ereas th e focu s of an aly-
a na lysis focuses sis sh ifts to u n d erstan d in g th e system itself.
on und erst a nd ing Figu re 6 -1 dep icts th e m ain artifacts of you r an alysis efforts an d th e
wha t need s t o be relation sh ip s between th em . Th e solid boxes in dicate m ajor an alysis arti-
built . facts, wh ereas th e dash ed boxes rep resen t you r m ajor req u irem en ts arti-
facts. As with th e p reviou s Figu re 3-1, th e arrows rep resen t “drives”
relation sh ip s; for exam p le, you see th at in form ation con tain ed in you r
CRC m odel affects in form ation in you r class m odel an d vice versa. Figu re
6 -1 h as th ree im p ortan t im p lication s. First, an alysis is an iterative p rocess.
Essential
Use Case
Use Case
Model
Model
Sequence Activity
Business Rules
Diagram Diagram
Class Model
CRC Model
(Analysis)
User Interface User Interface

Flow Diagram Prototype
Fig ure 6 -1 . Essential

User Interface
Overview of analysis
Prototype
artifacts and their
relationships
Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis 183
Secon d, taken togeth er, req u irem en ts gath erin g an d an alysis are h igh ly
in terrelated an d iterative. As you see in Ch ap ter 7, wh ich describes object-
orien ted design tech n iq u es, an alysis an d design are sim ilarly in terrelated
an d iterative. Th ird, th e “essen tial” m odels, you r essen tial u se case m odel
an d you r essen tial u ser in terface p rototyp e, evolve in to corresp on din g
an alysis artifacts—resp ectively, you r u se case m odel an d u ser in terface
p rototyp e. W h at isn ’t as obviou s is th at you r Class Resp on sibility Collabo-
rator (CRC) m odel evolves in to you r an alysis class m odel.
You r u se case m od el d escribes h ow you r u sers work with you r system ,
reflectin g th e bu sin ess ru les p ertin en t to you r system , as well as asp ects
of you r u ser in terface m od el. You can u se eith er Un ified Mod elin g Lan -
gu age (UML) seq u en ce d iagram s or UML activity d iagram s to flesh ou t
an d verify th e logic con tain ed in you r u se cases. Fu rth erm ore, you see
th at seq u en ce d iagram s act as a brid ge to you r class m od el, wh ich d ep icts
th e static stru ctu re of th e classes from wh ich you r system will be bu ilt.
You r u ser in terface m od el, in clu d in g you r u ser in terface p rototyp e an d
you r u ser in terface flow d iagram (see Ch ap ter 3), also d rives ch an ges to
you r class m od el.
An im p ortan t con cep t to n ote abou t Figu re 6 -1, an d sim ilarly Figu res Ana lysis is a n
7-1 an d 8-1, is th at every p ossible “d rives” relation sh ip is n ot sh own . For it era t ive p rocess.
exam p le, as you are d evelop in g you r u se case m od el, m ost likely you will
realize you are m issin g a featu re in you r u ser in terface, yet a relation sh ip
d oesn ’t exist between th ese two artifacts. From a p u re/ acad em ic p oin t of
view, wh en you realize you r u se case m od el con flicts with you r u ser-
in terface m od el, you sh ou ld first con sid er wh at th e p roblem is, u p d ate
you r u se case m od el ap p rop riately, p rop agate th e ch an ge to you r essen -
tial u se case m od el, an d th en to you r essen tial u ser in terface m od el, an d ,
fin ally, in to you r u ser in terface m od el. Yes, you m ay, in fact, take th is
rou te. Ju st as likely, an d p robably m ore so, is th at you will, in stead ,
u p d ate both you r u se case m od el an d u ser in terface m od el togeth er, an d
th en p rop agate th e ch an ges to th e corresp on d in g req u irem en ts artifacts.
Th is is an im p ortan t asp ect of iterative d evelop m en t. You d on ’t n ecessar-
ily work in a d efin ed ord er; in stead , you r work reflects th e relation sh ip s
between th e artifacts you evolve over tim e.
A secon d im p ortan t con cep t is th e d ifferen ce between a m od el an d a
d iagram . A d iagram is a p ictu re —typ ically con sistin g of bu bbles con -
n ected by lin es d ocu m en ted with labels—th at d ep icts an abstraction of
a p ortion or an asp ect of a system . A m od el is also an abstraction ,
alth ou gh it is m ore robu st becau se it con sists of zero or m ore d iagram s,
p lu s associated d ocu m en tation . For exam p le, a class m od el is com p osed
of a UML class d iagram an d th e sp ecification s of th e classes an d associa-
tion s d ep icted on th at d iagram , wh ereas a CRC m od el is a collection of
CRC card s.
D EFIN ITION S
Act ivit y d ia gra m . A UML diagram used to model high-level business processes or the transitions
between states of a class (in this respect, activity diagrams are effectively specializations of state chart
diagrams).
Cla ss d ia gra m . Shows the classes of a system and the associations between them.
Cla ss m od el. A class diagram and its associated documentation.
Cla ss Resp onsibilit y Colla bora t or (CRC) ca rd . A standard index card that has been divided into
three sections: one indicating the name of the class the card represents, one listing the responsibilities
of the class, and the third listing the names of the other classes with which this one collaborates to ful-
fill its responsibilities.
Cla ss Resp onsibilit y Colla bora t or (CRC) m od el. A collection of CRC cards that model all or part
of a system.
Dia gra m . A visual representation of a problem or solution to a problem.
Essent ia l use ca se. A simplified, abstract, generalized use case that captures the intentions of a user
in a technology and implementation independent manner.
Essent ia l use ca se m od el. A use case model comprised of essential use cases.
Essent ia l user int erfa ce p rot ot yp e. A low-fidelity prototype of a system’s user interface that mod-
els the fundamental, abstract characteristics of a user interface.
Mod el. An abstraction describing a problem domain and/or a solution to a problem domain. Tradi-
tionally models are thought of as diagrams plus their corresponding documentation, although non-
diagrams, such as interview results and collections of CRC cards, are also considered to be models.
Project st a kehold er. Anyone who could be materially affected by the implementation of a new sys-
tem or application.
Prototype. A simulation of an item, such as a user interface or a system architecture, the purpose of which
is to communicate your approach to others before significant resources are invested in the approach.
Sequence d ia gra m . A diagram that models the sequential logic, in effect, the time ordering of messages.
Use ca se. A sequence of actions that provide a measurable value to an actor.
Use ca se d ia gra m . A diagram that shows use cases, actors, and their interrelationships.
Use ca se m od el. A model comprised of a use case diagram, use case definitions, and actor defini-
tions. Use case models are used to document the behavior requirements of a system.
User int erfa ce (UI). The user interface of software is the portion the user directly interacts with,
including the screens, reports, documentation, and software support (via telephone, electronic mail,
and so on).
User int erfa ce flow d ia gra m . A diagram that models the interface objects of your system and the
relationships between them. Also know as an interface-flow diagram, a windows navigation diagram,
or an interface navigation diagram.
User int erfa ce p rot ot yp e. A prototype of the user interface (UI) of a system. User interface proto-
types could be as simple as a hand-drawn picture or a collection of programmed screens, pages, or
reports.
6.1 System Use Ca se Modelin g

Du rin g an alysis, you r m ain goal is to evolve you r essen tial u se cases in to Syst em use ca ses
system u se cases. Th e m ain differen ce between an essen tial u se case an d a reflect a na lysis
system u se case is, in th e system u se case, you in clu de h igh -level im p le- d ecisions a nd ,
a rgua bly, even
m en tation decision s. For exam p le, a system u se case refers to sp ecific u ser-
d esign d ecisions.
in terface com p on en ts—su ch as screen s, HTML p ages, or rep orts—som e-
th in g you wou ldn ’t do in an essen tial u se case. Du rin g an alysis, you m ake
decision s regardin g wh at will be bu ilt, in form ation reflected in you r u se
cases, an d, argu ably, even h ow it will be bu ilt (effectively design ). Becau se
you r u se cases refer to u ser in terface com p on en ts, an d becau se you r u ser
in terface is worked on du rin g design , in evitably design issu es will creep
in to you r u se cases. For exam p le, a design decision is wh eth er you r u ser
in terface is im p lem en ted u sin g browser-based tech n ology, su ch as HTML
p ages or grap h ical u ser in terface (GUI) tech n ology su ch as Win dows.
Becau se you r u ser in terface will work differen tly dep en din g on th e im p le-
m en tation tech n ology, th e logic of you r system u se cases, wh ich reflect
th e flow of you r u ser in terface, will also be affected.
Wh at is a system use case m odel? Sim ilar to essen tial use case m odels
described in Ch apter 3, a system use case m odel is com posed of a use case
diagram (Rum baugh , Jacobson , an d Booch , 1999) an d th e accom pan yin g
docum en tation describin g th e use cases, actors, an d association s. Figure 6-4,
wh ich provides an exam ple of a use case diagram , depicts a collection of
use cases, actors, th eir association s, a system boun dary box (option al), an d
packages (option al). A use case describes a sequen ce of action s th at provide
a m easurable value to an actor an d is drawn as a h orizon tal ellipse. An
actor is a person , organ ization , or extern al system th at plays a role in on e
or m ore in teraction s with your system . Actors are drawn as stick figures.
Association s between actors an d classes are in dicated in use case diagram s,
a relation sh ip exists wh en ever an actor is in volved with an in teraction
described by a use case. Association s also exist between use cases in system
use case m odels, a topic discussed in th e followin g section , som eth in g th at
didn ’t occur in essen tial use case m odels. Association s are m odeled as lin es
con n ectin g use cases an d actors to on e an oth er, with an option al arrow-
h ead on on e en d of th e lin e in dicatin g th e direction of th e in itial in voca-
tion of th e relation sh ip. Th e rectan gle aroun d th e use cases is called th e
system boun dary box an d, as th e n am e suggests, it delim its th e scope of
your system —th e use cases in side th e rectan gle represen t th e fun ction ality
you in ten d to im plem en t. Fin ally, packages are UML con structs th at en able
you to organ ize m odel elem en ts (such as use cases) in to groups. Packages
are depicted as file folders th at can be used on an y of th e UML diagram s,
in cludin g both use case diagram s an d class diagram s. Section 6.9 presen ts
strategies to apply packages effectively in your UML m odels.
6.1.1 W rit ing Syst em Use Ca ses

Writin g system u se cases is fairly straigh tforward . You begin with you r
essen tial u se cases an d m od ify th em to reflect th e in form ation cap tu red
with in you r UML seq u en ce d iagram s (Section 6 -2), you r UML activity
d iagram s (Section 6 -7), you r u ser in terface p rototyp e (Section 6 -5), an d
th e con ten ts of you r evolved su p p lem en tary sp ecification (Section 6 -6).
You will also rework you r u se cases to reflect op p ortu n ities for reu se,
ap p lyin g th e UML stereotyp es of <<exten d >> an d <<in clu d e>>, as well as
th e object-orien ted con cep t of in h eritan ce, tech n iq u es covered n ext in
Section 6.1.2.
Con sider th e system u se case p resen ted in Figu re 6 -4. Notice h ow it is
sim ilar to th e essen tial u se cases of Ch ap ter 3, with th e m ain excep tion s
bein g th e referen ces to u ser in terface elem en ts an d referen ces to oth er u se
cases. Th e u se case h as a basic cou rse of action , wh ich is th e m ain start-to-
fin ish p ath th e u ser will follow. It also h as th ree altern ate cou rses of
action , rep resen tin g in freq u en tly u sed p ath s th rou gh th e u se case, excep -
tion s, or error con dition s. Notice h ow I h ave added an iden tifier, som e-
th in g I cou ld h ave don e for th e essen tial u se cases dep icted in Ch ap ter 3.
It also h as section s labeled “Exten ds,” “In clu des,” an d “In h erits From ”
in dicatin g th e u se cases, if an y, with wh ich th is u se case is associated. I
discu ss wh at you n eed to p u t h ere in Section 6.1.1.
Two com m on Un til n ow, I h ave p resen ted u se cases in wh at is called n arrative
st yles exist for style —th e u se case of Figu re 6 -2 is written th is way—wh ere th e basic an d
writ ing use ca ses: altern ate cou rses of action are written on e step at a tim e. A secon d style,
na rra t ive st yle
called th e action -resp on se style, p resen ts u se case step s in colu m n s, on e
a nd a ct ion-
colu m n for each actor an d a secon d colu m n for th e system . Figu re 6 -3
resp onse st yle.
Choose one st yle p resen ts th e basic cou rse of action for Figu re 6 -4 rewritten u sin g th is
a nd st ick t o it . style. For th e sake of brevity, I d id n ’t in clu d e rewritten version s of th e
altern ate cou rses. Of th e two colu m n s, on e is for th e Stu d en t actor an d
on e for th e system , becau se on ly on e actor is in volved in th is u se case.
D EFIN ITION S
Ext end a ssocia t ion. A generalization relationship where an extending use case
continues the behavior of a base use case. The extending use case accomplishes
this by inserting additional action sequences into the base use case sequence.
This is modeled using a use case association with the <<extend>> stereotype.
Includ e a ssocia t ion. A generalization relationship denoting the inclusion of
the behavior described by a use case within another use case. This is modeled
using a use case association with the <<include>> stereotype Also known as a
“ uses” or a “ has-a” relationship.
Name: Enroll in Seminar Figure 6-2.

Identifier: UC 17 “ Enroll in seminar”
Description: Enroll an existing student in a seminar for which he is eligible. written in narrative
style
Preconditions: The Student is registered at the University.
Postconditions: The Student will be enrolled in the course he wants if he
is eligible and room is available.
Extends: —
Includes: —
Inherits From: -—
Basic Course of Action:
1. The student wants to enroll in a seminar.
2. The student inputs his name and student number into the system via
“ UI23 Security Login Screen.”
3. The system verifies the student is eligible to enroll in seminars at the
university, according to business rule “ BR129 Determine Eligibility to
Enroll.”
4. The system displays “ UI32 Seminar Selection Screen,” which indicates
the list of available seminars.
5. The student indicates the seminar in which he wants to enroll.
6. The system validates the student is eligible to enroll in the seminar,
according to the business rule “ BR130 Determine Student Eligibility to
Enroll in a Seminar.”
7. The system validates the seminar fits into the existing schedule of the
student, according to the business rule “ BR143 Validate Student Semi-
nar Schedule.”
8. The system calculates the fees for the seminar based on the fee pub-
lished in the course catalog, applicable student fees, and applicable
taxes. Apply business rules “ BR 180 Calculate Student Fees” and
“ BR45 Calculate Taxes for Seminar.”
9. The system displays the fees via “ UI33 Display Seminar Fees Screen.”
10. The system asks the student whether he still wants to enroll in the
seminar.
11. The student indicates he wants to enroll in the seminar.
12. The system enrolls the student in the seminar.
13. The system informs the student the enrollment was successful via
“ UI88 Seminar Enrollment Summary Screen.”
14. The system bills the student for the seminar, according to business rule
‘BR100 Bill Student for Seminar.”
15. The system asks the student if he wants a printed statement of the
enrollment.
16. The student indicates he wants a printed statement.
17. The system prints the enrollment statement “ UI89 Enrollment Sum-
mary Report.”
18. The use case ends when the student takes the printed statement.
continued on page 90
Alternate Course A: The Student is Not Eligible to Enroll in Seminars

A.3. The system determines the student is not eligible to enroll in seminars.
A.4. The system informs the student he is not eligible to enroll.
A.5. The use case ends.
Alternate Course B: The Student Does Not Have the Prerequisites
B.6. The system determines the student is not eligible to enroll in the sem-
inar he has chosen.
B.7. The system informs the student he does not have the prerequisites.
B.8. The system informs the student of the prerequisites he needs.
B.9. The use case continues at Step 4 in the basic course of action.
Alternate Course C: The Student Decides Not to Enroll in an Available
Seminar
C.4. The student views the list of seminars and doesn’t see one in which
he wants to enroll.
C.5. The use case ends.
Th e ad van tage of th e action -resp on se style is it is easier to see h ow actors

in teract with th e system an d h ow th e system resp on d s. Th e d isad van tage
is, in m y op in ion , it is a little h ard er to u n d erstan d th e flow of logic of
th e u se case. Th is is p articu larly tru e for altern ate cou rses an d th eir refer-
en ces to oth er cou rses of action . Th e style you ch oose is a m atter of p ref-
eren ce. W h at’s im p ortan t is th at you r team an d , id eally, you r
organ ization selects on e style an d sticks to it.
I wan t to p oin t ou t an im p ortan t style issu e p ertain in g to Step s 2 an d
3 of th e u se case of Figu re 6 -2. I cou ld ju st as easily h ave d efin ed a p re-
con d ition th at th e stu d en t h as alread y logged in to th e system an d h as
been verified as an eligible stu d en t. Actu ally, th is sh ou ld be two p recon -
d ition s: on e for bein g logged in an d on e for bein g eligible (th is way, th e
p recon d ition s are coh esive). To su p p ort th e first p recon d ition , bein g
logged in , I wou ld be tem p ted to write a “Log In to System ” u se case th at
wou ld d escribe th e p rocess of loggin g in an d valid atin g th e u ser, p erh ap s
in clu d in g altern ate cou rses for obtain in g a login id en tifier. Th is u se case
wou ld be a can d id ate for in clu sion in you r com m on , en terp rise m od el
becau se it is a featu re th at sh ou ld belon g to you r organ ization ’s sh ared
tech n ical arch itectu re. Cross-p roject issu es su ch as th is are am on g th e
top ics I cover in Process Patterns (Am bler, 1998b) an d More Process Patterns
(Am bler, 1999), th e th ird an d fou rth books in th is series. Th e secon d p re-
con d ition , th e on e for bein g eligible to en roll, likely d oesn ’t n eed its own
u se case, bu t I wou ld still referen ce th e ap p rop riate bu sin ess ru le.
Student System
1. The student wants to enroll in a seminar. 3. The system verifies the student is eligible to enroll
2. The student inputs his name and student number in seminars at the university, according to business
into the system via “ UI23 Security Login Screen.” rule “ BR129 Determine Eligibility to Enroll.”
4. The system displays “ UI32 Seminar Selection
Screen,” which indicates the list of available seminars.
5. The student indicates the seminar in which she 6. The system validates the student is eligible to
wants to enroll. enroll in the seminar, according to the business
rule “ BR130 Determine Student Eligibility to Enroll
in a Seminar.”
7. The system validates the seminar fits into the
existing schedule of the student, according to the
business rule “ BR143 Validate Student Seminar
Schedule.”
8. The system calculates the fees for the seminar
based on the fee published in the course catalog,
applicable student fees, and applicable taxes.
Apply business rules “ BR 180 Calculate Student
Fees” and “ BR45 Calculate Taxes for Seminar.”
9. The system displays the fees via “ UI33 Display
Seminar Fees Screen.”
10. The system asks the student whether she still
wants to enroll in the seminar.
11. The student indicates she wants to enroll in the 12. The system enrolls the student in the seminar.
seminar. 13. The system informs the student the enrollment
was successful via “ UI88 Seminar Enrollment Sum-
mary Screen.”
14. The system bills the student for the seminar,
according to business rule “ BR100 Bill Student for
Seminar.”
15. The system asks the student if she wants a
printed statement of the enrollment.
16. The student indicates she wants a printed 17. The system prints the enrollment statement
statement. “ UI89 Enrollment Summary Report.”
18. The use case ends when the student takes the
printed statement.
Figure 6-3.
Basic course of
action for “ Enroll in
Seminar” written in
action-response style
6.1.2 Reuse in Use Ca se Mod els: <<ext end >>, <<includ e>>,
a nd Inherit a nce
You ca n ind ica t e On e of you r goals d u rin g an alysis is to id en tify p oten tial op p ortu n ities
p ot ent ia l for reu se, a goal you can work toward as you are d evelop in g you r u se case
op p ort unit ies for m od el. Poten tial reu se can be m od eled th rou gh fou r gen eralization rela-
reuse on your use
tion sh ip s su p p orted by th e UML u se case m od els: exten d relation sh ip s
ca se m od els
between u se cases, in clu d e relation sh ip s between u se cases, in h eritan ce
between u se cases, an d in h eritan ce between actors.
6.1.2.1 Extend Associations Between Use Cases

The <<ext end >> An exten d association , form erly called an exten d s relation sh ip in th e
st ereot ype is used UML v1.2 an d earlier, is a gen eralization relation sh ip wh ere an exten d in g
t o ind ica t e a n
u se case con tin u es th e beh avior of a base u se case. Th e exten d in g u se
ext end a ssocia t ion.
case accom p lish es th is by con cep tu ally in sertin g ad d ition al action
seq u en ces in to th e base u se case seq u en ce. Th is en ables an exten d in g u se
case to con tin u e th e activity seq u en ce of a base u se case wh en th e ap p ro-
p riate exten sion p oin t is reach ed in th e base u se case an d th e exten sion
con d ition is fu lfilled . W h en th e exten d in g u se case activity seq u en ce is
com p leted , th e base u se case con tin u es. In Figu re 6 -4, you see th at th e
u se case “En roll In tern ation al Stu d en t in Un iversity” exten d s th e u se case
“En roll in Un iversity;” th e n otation for d oin g so is sim p ly a n orm al u se
case association with th e stereotyp e of <<exten d >>. In th is case, “En roll
in Un iversity” is th e base u se case an d “En roll In tern ation al Stu d en t in
Un iversity” is th e exten d in g u se case.
Extending use ca ses An exten d in g u se case is, effectively, an altern ate cou rse of th e base
a re often introd uced u se case. In fact, a good ru le of th u m b is you sh ou ld in trod u ce an
to resolve exten d in g u se case wh en ever th e logic for an altern ate cou rse of action is
com plexities of
at a com p lexity level sim ilar to th at of you r basic cou rse of action . I also
a lterna te courses.
like to in trod u ce an exten d in g u se case wh en ever I n eed an altern ate
cou rse for an altern ate cou rse; in th is case, th e exten d in g u se case wou ld
en cap su late both altern ate cou rses. Man y u se case m od elers avoid th e u se
of exten d association s as th is tech n iq u e h as a ten d en cy to m ake u se case
d iagram s d ifficu lt to u n d erstan d . My p referen ce is to u se exten d associa-
tion s sp arin gly. Note th at th e exten d in g u se case —in th is case “En roll
In tern ation al Stu d en t in Un iversity”—wou ld list “UC33 En roll in Un iver-
sity,” th e base u se case, in its “Exten d s” list.
Ext ension p oint s Ju st as you in dicate th e p oin t at wh ich th e logic of an altern ate cou rse
a re p la ced in ba se rep laces th e logic of a p ortion of th e basic cou rse of action for a u se case,
use ca ses t o you n eed to be able to do th e sam e th in g for an exten din g u se case. Th is is
ind ica t e where t he
accom p lish ed th rou gh th e u se of an exten sion p oin t, wh ich is sim p ly a
logic of t he
ext end ing use ca se
m arker in th e logic of a base u se case in dicatin g wh ere exten sion is
rep la ces t ha t of allowed. Figu re 6 -5 p resen ts an exam p le of h ow an exten sion p oin t wou ld
t he ba se use ca se. be in dicated in th e basic cou rse of action of th e “En roll in Un iversity” u se
Figure 6-4.
The opportunities
for reuse in use case
models
Registrar
Enroll in Enroll in
<<include>>
University Seminar
Student
<<extend>>
Enroll Enroll Family

International Student Member in
in University University
International
Student
case. Notice h ow th e iden tifier an d th e n am e of th e u se case is in dicated.

If several u se cases exten ded th is on e from th e sam e p oin t, th en each on e
wou ld n eed to be listed. A con dition statem en t, su ch as “Con dition :
En rollee is an in tern ation al stu den t,” cou ld h ave been in dicated im m edi-
ately followin g th e n am e of th e u se bu t, in th is exam p le, it was fairly
obviou s wh at was h ap p en in g.
6.1.2.2 Include Associations Between Use Cases

A secon d way to in dicate p oten tial reu se with in u se case m odels exists in An includ e
th e form of in clu de association s. An in clu de association , form erly kn own a ssocia t ion is t he
as a u ses relation sh ip in th e UML v1.2 an d earlier, is a gen eralization rela- eq uiva lent of a
tion sh ip den otin g th e in clu sion of th e beh avior described by an oth er u se funct ion ca ll.
case. Th e best way to th in k of an in clu de association is th at it is th e in vo-

cation of a u se case by an oth er on e. In Figu re 6 -4, n otice th at th e u se case
Figure 6-5.
4. The system displays “ UI43 Student Information Entry.” [Extension Point: Documenting an
UC34 Enroll International Student In University.] extension point
5. The student… within a use case
D EFIN ITION S
Ba se use ca se. A use case extended by another via an extend association.
Ext end ing use ca se. A use case that extends another use case via an extend
association.
Ext ension p oint . A marker in a use case where extension is allowed.
“En roll in Un iversity” in clu des th e u se case “En roll in Sem in ar”; th e n ota-
tion for doin g so is sim p ly a n orm al u se case association with th e stereo-
typ e of <<in clu de>>. Figu re 6 -6 p resen ts an exam p le of h ow you wou ld
in dicate wh ere th e u se case is in clu ded in th e logic of th e in clu din g u se
case. Sim ilar to callin g a fu n ction or in vokin g an op eration with in sou rce
code, isn ’t it? Object-orien ted p rogram m in g is covered in Ch ap ter 8.
You u se in clu d e association s wh en ever on e u se case n eed s th e beh av-
ior of an oth er. In trod u cin g a n ew u se case th at en cap su lates sim ilar logic
th at occu rs in several u se cases is q u ite com m on . For exam p le, you m ay
d iscover th at several u se cases n eed th e beh avior to search for an d th en
u p d ate in form ation abou t stu d en ts, in d icatin g th e p oten tial n eed for an
“Up d ate Stu d en t Record ” u se case in clu d ed by th e oth er u se cases.
As you wou ld exp ect, th e u se case “En roll in Un iversity” sh ou ld list
“UC17 En roll in Sem in ar” in its “In clu d es” list. W h y sh ou ld you both er
m ain tain in g an “In clu d es” an d an “Exten d s” list in you r u se cases? Th e
an swer is sim p le: You r u se cases sh ou ld stan d on th eir own ; you sh ou ldn ’t
exp ect p eop le to h ave you r u se case diagram in fron t of th em . Yes, it
wou ld be n ice if everyon e h as access to th e u se case d iagram becau se it
also con tain s th is in form ation , bu t th e reality is th at som etim es you u se
d ifferen t tools to d ocu m en t each p art of you r m od el. For exam p le, you r
d iagram s cou ld be d rawn u sin g a d rawin g p ackage an d you r u se cases
d ocu m en ted in a word p rocessor. Som e of you r p roject stakeh old ers m ay
h ave access to th e word p rocessor you are u sin g, bu t n ot th e d rawin g
p ackage. Th e m ain d isad van tage of th is ap p roach is you n eed to m ain -
tain th ese two lists in p arallel with th e d iagram , th e d an ger bein g th ey
m ay becom e u n syn ch ron ized .
Figure 6-6.
Indicating the 8. The student indicates the seminar(s) she wants to take via the use case
inclusion of a UC 17 Enroll in Seminar.
use case 9. The student…
6.1.2.3 Inheritance
Use cases can in h erit from oth er u se cases, offerin g a th ird op p ortu n ity to Use ca ses m a y
in dicate p oten tial reu se. Figu re 6 -4 dep icts an exam p le of th is, sh owin g inherit from ot her
th at “En roll Fam ily Mem ber in Un iversity” in h erits from th e “En roll In use ca ses.
Un iversity” u se case. In h eritan ce between u se cases is n ot as com m on as
eith er th e u se of exten d or in clu de association s, bu t it is still p ossible. Th e
in h eritin g u se case wou ld com p letely rep lace on e or m ore of th e cou rses
of action of th e in h erited u se case. In th is case, th e basic cou rse of action
is com p letely rewritten to reflect th at n ew bu sin ess ru les are ap p lied wh en
th e fam ily m em ber of a p rofessor is en rollin g at th e u n iversity. Fam ily
m em bers are allowed to en roll in th e sch ool, regardless of th e m arks th ey
earn ed in h igh sch ool; th ey don ’t h ave to p ay an y en rollm en t fees, an d
th ey are given top p riority for en rollm en t in th e u n iversity.
In h eritan ce between use cases sh ould be applied wh en ever a sin gle con di- Ap p ly inherit a nce
tion , in th is case, th e studen t is a fam ily m em ber of a professor, would result bet ween use ca ses
in th e defin ition of several altern ate courses. With out th e option to defin e when a single
cond it ion would
an in h eritin g use case, you n eed to in troduce an altern ate course to rework
result in severa l
th e ch eck of th e studen t’s h igh -sch ool m arks, th e ch argin g of en rollm en t a lt erna t e courses.
fees, an d for prioritization of wh o is allowed to en roll in th e given sem ester.
Th e in h eritin g u se case is m u ch sim p ler th an th e u se case from wh ich
it in h erits. It sh ou ld h ave a n am e, d escrip tion , an d id en tifier, an d it
sh ou ld also in d icate from wh ich u se case it in h erits in th e “In h erits
From ” section . In section s th at you rep lace, you m ay n eed to rewrite th e
p recon d ition s, p ostcon d ition s, or cou rses of action . If som eth in g is n ot
rep laced , th en leave th at section blan k, assu m in g it is in h erited from th e
p aren t u se case (you m igh t wan t to p u t text, su ch as “see p aren t u se
case,” in th e section ).
Th e fourth opportun ity for in dicatin g poten tial reuse with in use case Act ors m a y inherit
m odels occurs between actors: An actor on a use case diagram can in h erit from ot her a ct ors.
from an oth er actor. An exam ple of th is is sh own in Figure 6-4, wh ere th e
“In tern ation al Studen t” actor in h erits from “Studen t.” An in tern ation al stu-
den t is a studen t, th e on ly differen ce bein g h e or sh e is subject to differen t
rules an d policies (for in stan ce, th e in tern ation al studen t pays m ore in
tuition ). Th e stan dard UML n otation for in h eritan ce, th e open -h eaded
arrow, is used an d th e advice presen ted about th e appropriate use of in h eri-
tan ce still applies: It sh ould m ake sen se to say th e in h eritin g actor is or is
like th e in h erited actor.
6.1.3 Good Things t o Know About Use Ca se Mod eling

Associa t ions
An im p ortan t th in g to u n d erstan d abou t u se case m od els is th at th e asso- bet ween a ct ors
ciation s between actors an d u se cases in d icate th e n eed for in terfaces. a nd use ca ses
W h en th e actor is a p erson , th en to su p p ort th e association , you n eed to im p ly t he need for
d evelop u ser in terface com p on en ts, su ch as screen s an d rep orts. W h en int erfa ces.
th e actor is an extern al system , th en you n eed to d evelop a system in ter-

face, p erh ap s a d ata file tran sfer or a real-tim e on lin e lin k to th e extern al
system . For exam p le, in th e “En roll in Sem in ar” u se case of Figu re 6 -2,
th e Stu d en t actor in teracts with th e system via several m ajor UI com p o-
n en ts, p articu larly “UI23 Secu rity Login Screen ,” “UI32 Sem in ar Selec-
tion Screen ,” “UI33 Disp lay Sem in ar Fees Screen ,” “UI88 Sem in ar
En rollm en t Su m m ary Screen ,” an d “UI89 En rollm en t Su m m ary Rep ort.”
You should be a ble Secon d , u se cases are often written u n d er th e assu m p tion th at you can
t o exit from a use exit at an y tim e. For exam p le, in th e m id d le of th e “En roll in Sem in ar”
ca se a t a ny t im e. u se case, th e stu d en t m ay d ecid e to give u p an d try again later or th e sys-
tem m ay crash becau se th e load on it is too great. Th e d escrip tion of th e
u se case d oesn ’t in clu d e th ese as altern ate cou rses becau se it wou ld
greatly in crease th e com p lexity of th e u se case with ou t ad d in g m u ch
valu e. In stead , it is assu m ed , if on e of th ese even ts occu rs, th at th e u se
case sim p ly en d s an d th e righ t th in g will h ap p en . However, you r su bject
m atter exp erts (SMEs) m ay wan t to d efin e n on fu n ction al req u irem en ts
th at d escribe h ow situ ation s su ch as th is sh ou ld be h an d led .
Bewa re of t he “use Th ird , in m y op in ion , u se case m od elin g h as received far m ore atten -
ca se d riven” hyp e tion th an it actu ally d eserves. Yes, it is a u sefu l tech n iq u e bu t n o, it isn ’t
of consult a nt s a nd th e be-all-an d -en d -all of req u irem en ts an d an alysis m od elin g. You saw in
t ool vend ors. Ch ap ter 3 th at essen tial u se case m od elin g is on e tech n iq u e of several
you can u se to gath er req u irem en ts an d , as you see in th is ch ap ter, it is
also on e of several tech n iq u es to p erform object-orien ted an alysis. Don ’t
let th e m arketin g h yp e of CASE tool ven d ors an d object-orien ted con su l-
tan ts d eceive you in to th in kin g everyth in g sh ou ld be “u se case d riven .”
Use case m od elin g is m erely on e of m an y im p ortan t tech n iq u es you
sh ou ld h ave in you r m od elin g toolkit.
Includ e, ext end , Fou rth , alth ou gh th e reu se tech n iq u es— exten d association s, in clu d e
a nd inherit a nce association s, an d in h eritan ce —are u sefu l, d on ’t overu se th em . In clu d e
a ssocia t ions association s an d , to a lesser d egree, exten d association s, lead to fu n c-
bet ween use ca ses tion al d ecom p osition with in you r u se case m od el. Th e p roblem is u se
ca n lea d t o
cases are n ot m ean t to d escribe fu n ction s with in you r sou rce cod e; th ey
funct iona l
d ecom p osit ion if
are m ean t to d escribe series of action s th at offer valu e to actors. A good
you a re not ru le of th u m b to u se is if you are able to d escribe a u se case with a sin gle
ca reful. sen ten ce, th en you h ave likely d ecom p osed it too m u ch , som eth in g th at
occu rs wh en you ap p ly in clu d e association s too often . An oth er ru le of
th u m b is, if you h ave m ore th an two levels of in clu d e association s, for
exam p le, if u se case A in clu d es u se case B, wh ich in clu d es u se case C,
th en two levels of in clu d e exist, an d th en you are in d an ger of fu n ction al
d ecom p osition . Th e sam e can be said of exten d association s between u se
cases, as well as in h eritan ce.
6.1.4 Use Ca se Mod eling Tip s a nd Techniq ues

In th is section , I wan t to sh are a collection of tip s an d tech n iq u es I h ave
fou n d u sefu l over th e years to im p rove th e q u ality of m y system u se case
m od els.
1. Write fro m th e po in t-o f-v iew o f th e acto r in th e active vo ice.

Use cases sh ou ld be written in th e active voice: “Th e stu d en t
in d icates th e sem in ar,” in stead of in th e p assive voice, “Th e sem -
in ar is in d icated by th e stu d en t.” Fu rth erm ore, u se cases sh ou ld
be written from th e p oin t-of-view of th e actor. After all, th e p u r-
p ose of u se cases is to u n d erstan d h ow you r u sers will work with
you r system .
2. Write scen ario tex t, n o t f un ctio n al requirem en ts. A u se case
d escribes a series of action s th at p rovid e valu e to an actor; it
d oesn ’t d escribe a collection of featu res. For exam p le, th e u se
case of Figu re 6 -2 d escribes h ow a stu d en t in teracts with th e sys-
tem to en roll in a sem in ar. It d oesn ’t d escribe wh at th e u ser
in terface looks like or h ow it works. You h ave oth er m od els to
d escribe th is im p ortan t in form ation , su ch as you r u ser in terface
m od el an d you r su p p lem en tary sp ecification s. Object-orien ted
an alysis is com p lex, wh ich is wh y you h ave several m od els to
work with , an d you sh ou ld ap p ly each m od el ap p rop riately.
3. A use case is n eith er a class specificatio n n o r a data specifica-
tio n . Th is is th e sort of in form ation th at sh ou ld be cap tu red by
you r con cep tu al m od el, d escribed in Section 6.3, wh ich in th e
object world is m od eled via a UML class m od el. You are likely to
refer to classes d escribed in you r con cep tu al m od el; for exam p le,
th e “En roll in Sem in ar” u se case in clu d es con cep ts, su ch as sem i-
n ars an d stu d en ts, both of wh ich wou ld be d escribed by you r
con cep tu al m od el. On ce again , u se each m od el ap p rop riately.
4. Do n ’t fo rget th e user in terface. System u se cases often refer to
m ajor u ser in terface (UI) elem en ts, often called bou n d ary or sim -
p ly u ser in terface item s, an d som etim es m in or UI elem en ts as
ap p rop riate.
5. Create a use case tem plate. As you can see in Figu re 6 -2, u se
cases in clu d e a fair am ou n t of in form ation , in form ation th at can
easily be d ocu m en ted in a com m on form at. You sh ou ld con sid er
eith er d evelop in g you r own tem p late based on wh at you h ave
learn ed in th is book or ad op tin g an existin g on e you h ave eith er
p u rch ased with an object m od elin g tool or d own load ed from th e
In tern et.
6. Organ ize yo ur use case diagram s co n sisten tly. Com m on p rac-

tice is to d raw in h eritan ce an d exten d association s vertically,
with th e in h eritin g/ exten d in g u se case d rawn below th e p aren t/
base u se case. Sim ilarly, in clu d e association s are typ ically d rawn
h orizon tally. Note th at th ese are sim p le ru les of th u m b, ru les
th at, wh en followed con sisten tly, resu lt in d iagram s th at are eas-
ier to read .
7. Do n ’t fo rget th e system respo n ses to th e actio n s o f acto rs.
You r u se cases sh ou ld d escribe both h ow you r actors in teract
with you r system an d h ow you r system resp on d s to th ose in ter-
action s. With th e “En roll in Sem in ar” u se case, h ad th e system
n ot resp on d ed wh en th e stu d en t in d icated sh e wan ted to en roll
in a sem in ar, I su sp ect th e stu d en t wou ld soon becom e d iscou r-
aged an d walk away. Th e system wasn ’t d oin g an yth in g to h elp
th e stu d en t fu lfill h er goals.
8. Altern ate co urses o f actio n are im po rtan t. Start with th e h ap p y
p ath , th e basic cou rse of action , bu t d on ’t forget th e altern ate
cou rses as well. Altern ates cou rses will be in trod u ced to d escribe
p oten tial u sage errors, as well as bu sin ess logic errors an d excep -
tion s. Th is im p ortan t in form ation is n eed ed to d rive th e d esign
of you r system , so d on ’t forget to m od el it in you r u se cases.
9. Do n ’t get h un g up o n <<in clude>> an d <<ex ten d>> asso cia-
tio n s. I’m n ot q u ite su re wh at h ap p en ed, bu t I’ve always th ou gh t
th e p rop er u se of in clu de an d exten d association s, as well as u ses
an d exten ds association s in older version s of th e Un ified Model-
in g Lan gu age (UML), were n ever described well. As a resu lt, u se
case m odelin g team s h ad a ten den cy to argu e abou t th e p rop er
ap p lication of th ese association s, wastin g an in credible am ou n t of
tim e on an in terestin g, bu t m in or, p ortion of th e overall m odel-
in g tech n iq u e. I even worked at on e organ ization th at wen t so far
as to ou tlaw th e u se of th e <<in clu de>> an d <<exten d>> stereo-
typ es, an extrem e solu tion th at h ad to be reversed after a few
weeks wh en th e organ ization realized it still n eeded th ese con -
cep ts, even th ou gh th e organ ization h adn ’t com e to a fu ll agree-
m en t as to th eir p rop er u se. An yway, I believe Section 6.1.2 does a
good job exp lain in g h ow to ap p ly th ese association s effectively.
10. Use cases drive user do cum en tatio n . Th e p u rp ose of u ser d ocu -
m en tation is to d escribe h ow to work with you r system . Each u se
case d escribes a series of action s taken by actors u sin g you r sys-
tem . In sh ort, u se cases con tain th e in form ation from wh ich you
can start writin g you r u ser d ocu m en tation . For exam p le, th e
“h ow to en roll in a sem in ar” section of you r system ’s u ser d ocu -

m en tation cou ld be written u sin g th e “En roll in Sem in ar” u se
case as its base.
11. Use cases drive presen tation s. Part of software developm en t is
com m un icatin g your work efforts with project stakeh olders, result-
in g in th e occasion al n eed to give presen tation s. Because use cases
are written from th e poin t-of-view of your users, th ey con tain valu-
able in sigh t in to th e type of th in gs your users are likely to wan t to
h ear about in your presen tation s. In oth er words, use cases often
con tain th e logic from wh ich to develop presen tation scripts.
6.2 Sequ en ce Dia g ra m s: From Use Ca ses to Cla sses

Sequen ce diagram s (Rum baugh , Jacobson , an d Booch , 1999) are used to Seq uence
m odel th e logic of usage scen arios. A usage scen ario is exactly wh at its n am e d ia gra m s ena ble
you t o visua lly
in dicates—th e description of a poten tial way your system is used. Th e logic
m od el t he logic of
of a usage scen ario m ay be part of a use case, perh aps an altern ate course. It
your syst em .
m ay also be on e en tire pass th rough a use case, such as th e logic described
by th e basic course of action or a portion of th e basic course of action , plus
on e or m ore altern ate scen arios. Th e logic of a usage scen ario m ay also be a
pass th rough th e logic con tain ed in several use cases. For exam ple, a studen t
en rolls in th e un iversity, an d th en im m ediately en rolls in th ree sem in ars.
Figure 6-7 m odels th e basic course of action for th e “En roll in Sem in ar” use
case. Sequen ce diagram s m odel th e flow of logic with in your system in a
visual m an n er, en ablin g you both to docum en t an d validate your logic, an d
are com m on ly used for both an alysis an d design purposes.
Th e boxes across th e top of th e d iagram rep resen t classifiers or th eir Object s, cla sses,
in stan ces, typ ically u se cases, objects, classes, or actors. Becau se you can a nd a ct ors a re
sen d m essages to both objects an d classes, objects resp on d to m essages d ep ict ed in
seq uence
th rou gh th e in vocation of an op eration , an d classes d o so th rou gh th e
d ia gra m s.
in vocation of static op eration s, it m akes sen se to in clu d e both on
D EFIN ITION S
Ma jor user int erfa ce elem ent . A large-grained item, such as a screen, HTML
page, or report.
Minor user int erfa ce elem ent . A small-grained item, such as a user input
field, menu item, list, or static text field.
Sup p lem ent a ry sp ecifica t ion. An artifact where all requirements not contained
in your use case model, user interface model, or domain model are documented.
seq u en ce d iagram s. Becau se actors in itiate an d take an active p art in

u sage scen arios, th ey are also in clu d ed in seq u en ce d iagram s. Objects
h ave labels in th e stan d ard UML form at “n am e: ClassNam e,” wh ere
“n am e” is op tion al (objects th at h aven ’t been given a n am e on th e d ia-
gram are called an on ym ou s objects). Classes h ave labels in th e form at
“ClassNam e,” an d actors h ave n am es in th e form at “Actor Nam e”—both
UML stan d ard s as well. For exam p le, in Figu re 6 -7, you see th e Stu d en t
actor h as th e n am e “A Stu d en t” an d is labeled with th e stereotyp e
<<actor>>. Th e in stan ce of th e m ajor UI elem en t rep resen tin g “UI32
Sem in ar Selection Screen ,” is an an on ym ou s object with th e n am e
“:Sem in arSelector” an d th e stereotyp e <<UI>>. Th e “Stu d en t” class is
in d icated on th e d iagram , th e box with th e n am e “Stu d en t,” becau se th e
static m essage “isEligible(n am e, stu d en tNu m ber)” is sen t to it. More on
th is later. Th e in stan ce of “Stu d en t” was given a n am e “th eStu d en t”
becau se it is u sed in several p laces as a p aram eter in a m essage, wh ereas
th e in stan ce of th e “Stu d en tsFees” class d id n ’t n eed to be referen ced an y-
wh ere else in th e d iagram an d , th u s, cou ld be an on ym ou s.
Th e dash ed lin es h an gin g from th e boxes are called object lifelin es, rep-
resen tin g th e life span of th e object durin g th e scen ario bein g m odeled.
Th e lon g, th in boxes on th e lifelin es are m eth od-in vocation boxes in dicat-
in g th at processin g is bein g perform ed by th e target object/class to fulfill a
m essage. Th e X at th e bottom of a m eth od-in vocation box is a UML con -
ven tion to in dicate th at an object h as been rem oved from m em ory, typi-
cally th e result of receivin g a m essage with th e stereotype of <<destroy>>.
Messa ges a re Messages are in dicated as labeled arrows, wh en th e sou rce an d target of
ind ica t ed by a m essage is an object or class th e label is th e sign atu re of th e m eth od
la beled a rrows, in voked in resp on se to th e m essage. However, if eith er th e sou rce or target
a nd ret urn va lues
is a h u m an actor, th en th e m essage is labeled with brief text describin g
by d a shed a nd
th e in form ation bein g com m u n icated. For exam p le, th e “:En rollIn Sem i-
la beled a rrows.
n ar” object sen ds th e m essage “isEligibleToEn roll(th eStu den t)” to th e
in stan ce of “Sem in ar.” Notice h ow I in clu de both th e m eth od’s n am e an d
th e n am e of th e p aram eters, if an y, p assed in to it. Figu re 6 -7 also in dicates
th at th e Stu den t actor p rovides in form ation to th e “:Secu rityLogon ”
object via th e m essages labeled “n am e” an d “stu den t n u m ber” (th ese
really aren ’t m essages; th ey are actu ally u ser in teraction s). Retu rn valu es
are op tion ally in dicated as u sin g a dash ed arrow with a label in dicatin g
th e retu rn valu e. For exam p le, th e retu rn valu e “th eStu den t” is in dicated
com in g back from th e “Stu den t” class as th e resu lt of in vokin g a m essage,
wh ereas n o retu rn valu e is in dicated as th e resu lt of sen din g th e m essage
“isEligibleToEn roll(th eStu den t)” to “sem in ar.” My style is n ot to in dicate
th e retu rn valu es wh en it’s obviou s wh at is bein g retu rn ed, so I don ’t clu t-
ter m y seq u en ce diagram s (as you can see, seq u en ce diagram s get com p li-
cated fairly q u ickly).
Enroll In Seminar
Basic Course of Action
schedule
A Student :EnrollInSeminar :SecurityLogon :SeminarSelector :FeeDisplay Student seminar:Seminar theStudent :StudentFees
SD #: UC17-01
:StudentSchedule
<<actor>> <<controller>> <<UI>> <<UI>> <<UI>> :Student
1. Student indicates wish to enroll wish to enroll

<<create>>
2. Student inputs name and number name
student number
isEligible(name, studentNumber)
3. System verifies student <<create>>
theStudent
theStudent
<<destroy>> Note: Need to
X flesh this message
out more.
<<create>>
4. System displays seminar list
selection
5. Students picks seminar
isEligibleToEnroll(theStudent) qualifications()
6. System determines eligibility to enroll
getSchedule()
determineFit(seminar)
7. System determines schedule fit
8. System calculates fees

X calculateFees(seminar, theStudent)
<<create>>
9. System displays fees
10. System verifies student wishes to enroll
11. Students indicates yes. verification
12. System enrolls student in seminar X enrollStudent(theStudent)
Figure 6-7.
A UML sequence
diagram for the basic
course of action for
Figure 6-2
Messages fu lfill th e logic of th e step s of th e u se case, su m m arized

d own th e left-h an d sid e of th e d iagram . Notice h ow th e exact word in g of
th e u se case step s isn ’t u sed becau se th e step s are often too word y to fit
n icely on a d iagram . W h at is critical is th at th e step n u m bers corresp on d
to th ose in th e u se case an d th at th e gen eral id ea of th e step is ap p aren t
to th e read er of th e d iagram .
St ereot yp es m a y Notice th e u se of stereotyp es th rou gh ou t th e d iagram . For th e boxes, I
be a p p lied t o ap p lied th e stereotyp es <<actor>>, <<con troller>>, an d <<UI>> in d icatin g
a ct ors, object s, th at th ey rep resen t an actor, a con troller class, or a u ser in terface (UI)
cla sses, a nd class, resp ectively. For n ow, a con troller class is a p laceh old er for on e or
m essa ges on
m ore classes th at wou ld be flesh ed ou t d u rin g d esign (Ch ap ter 7) to
seq uence
im p lem en t th e bu sin ess logic of you r system . As you see in Ch ap ter 7,
d ia gra m s.
you wan t to layer you r system , sep aratin g you r u ser in terface logic, bu si-
n ess logic, system logic, an d p ersisten ce logic away from each oth er.
Stereotyp es are also u sed on m essages. Com m on p ractice on UML d ia-
gram s is to in d icate creation an d d estru ction m essages with th e stereo-
typ es of <<create>> an d <<d estroy>>, resp ectively. For exam p le, you see
th at th e “:Secu rityLogon ” object is created in th is m an n er (actu ally, th is
m essage wou ld likely be sen t to th e class th at wou ld th en resu lt in a
retu rn valu e of th e created object, so I ch eated a bit). Th is object later
D EFIN ITION S
Anonym ous object . An object appearing on the diagram that hasn’t been
given a name; instead, the label is simply an indication of the class, such as
“ : Invoice.”
Cla ssifier. A mechanism that describes behavioral or structural features. Classi-
fiers include use cases, classes, interfaces, and components.
Lifeline. Represents, in a sequence diagram, the life span of an object during
an interaction.
Met hod . Something a class or object does. A method is similar to a function or
procedure in structured programming and is often referred to as an operation
or member function in object development.
Messa ge-invoca t ion box. The long, thin, vertical boxes that appear on sequence
diagrams, which represent invocation of an operation on an object or class.
Signa t ure. The combination of the name, parameter names (in order), and
name of the return value (if any) of a method.
St a t ic m et hod . A method that operates at the class level, potentially on all
instances of that class.
St ereot yp e. A stereotype denotes a common usage of a modeling element.
Stereotypes are used to extend the UML in a consistent manner.
d estroys itself in a sim ilar m an n er, p resu m ably wh en th e win d ow is

closed . In Java an d C++, m eth od s th at create objects are called construc-
tors, an d in C++, m eth od s th at d estroy objects are called destructors (Java
au tom atically m an ages m em ory, wh ereas C++ d oesn ’t, so Java d oesn ’t
req u ire d estru ctor m eth od s).
I u sed a UML n ote; n otes are basically free-form text th at can be Not es ca n be used
p laced on an y UML d iagram , to p rovid e a h ead er for th e d iagram , in d i- t o a d d free-form
t ext t o a ny UML
catin g its title an d id en tifier (as you m ay h ave n oticed , I give u n iq u e
d ia gra m .
id en tifiers to everyth in g). Notes are d ep icted as a p iece of p ap er with th e
top -righ t corn er fold ed over. I also u sed a n ote to in d icate fu tu re work
th at n eed s to be d on e, eith er d u rin g an alysis or d esign ; in th is d iagram ,
th e “q u alification s()” m essage likely rep resen ts a series of m essages sen t
to th e stu d en t object. Com m on UML p ractice is to an ch or a n ote to
an oth er m od el elem en t with a d ash ed lin e wh en ap p rop riate, as you see
in Figu re 6 -7, with th e n ote attach ed to th e m essage.
W h en I develop ed th e seq u en ce diagram of Figu re 6 -7, I m ade several Verify m od eling
decision s th at cou ld p oten tially affect m y oth er m odels. For exam p le, as I d ecisions wit h
m odeled Step 10, I m ade th e assu m p tion (argu ably, a design decision ) th at your SMEs.
th e fee disp lay screen also h an dled th e verification by th e stu den t th at th e
fees were acceptable. Th is decision sh ou ld be reflected by th e u ser in terface
prototype, th e topic of Section 6.5, an d verified by m y SMEs. Sequen ce dia-
gram m in g is som eth in g you sh ou ld be doin g togeth er with you r SMEs,
p articu larly sop h isticated on es wh o u n derstan d h ow to develop m odels
su ch as th is. Also, as I was m odelin g Step s 2 an d 3, I cam e to th e realiza-
tion th at stu den ts sh ou ld p robably h ave p asswords to get in to th e system .
I brou gh t th is con cep t u p with m y SMEs an d discovered I was wron g: th e
com bin ation of n am e an d stu den t n u m ber is u n iq u e en ou gh for ou r p u r-
p oses an d th e u n iversity didn ’t wan t th e added com p lexity of p assword
m an agem en t. Th is is an in terestin g decision th at wou ld be docu m en ted
in th e su p p lem en tary sp ecification , likely as a bu sin ess ru le, becau se it is
an op eratin g p olicy of th e u n iversity. By verifyin g th is idea with m y SMEs,
in stead of assu m in g I kn ew better th an everyon e else, I avoided an op p or-
tu n ity for goldp latin g an d, th u s, redu ced th e work m y team wou ld n eed
to do to develop th is system .
Regard in g style issu es for seq u en ce d iagram m in g, I p refer to d raw m es- Und erst a nd t he
sages goin g from left-to-righ t an d retu rn valu es from righ t-to-left, ba sic logic d uring
alth ou gh th at d oesn ’t always work with com p lex objects/ classes. I ju stify a na lysis, flesh out
t he d et a ils d uring
th e label on m essages an d retu rn valu es, so th ey are closest to th e arrow-
d esign.
h ead . As m en tion ed earlier, I p refer n ot to in d icate retu rn valu es on
seq u en ce d iagram s to sim p lify th e d iagram s wh en ever p ossible. However,
eq u ally valid is to d ecid e always to in d icate retu rn valu es, p articu larly
wh en you r seq u en ce d iagram is u sed for d esign in stead of an alysis (I like
m y an alysis d iagram s to be as sim p le as p ossible an d m y d esign d iagram s
D EFIN ITION S
C++. A hybrid object-oriented programming language that adds object-oriented
features to the C programming language.
Const ruct or. A method, typically a static one, whose purpose is to instantiate
and, optionally, initialize an object.
Cont roller. A class that implements business/domain logic, coordinating sev-
eral objects to perform a task.
Dest ruct or. A method whose purpose is to remove an object completely from
memory.
Gold p la t ing. The addition of extraneous features to a system.
Ja va . An object-oriented programming language based on the concept of
“ write once, run anywhere.”
Not e. A modeling construct for adding free-form text to the UML diagrams.
to be as th orou gh as p ossible). Du rin g an alysis, m y goal is to u n d erstan d

th e logic an d to en su re I h ave it righ t. Du rin g d esign , I th en flesh ou t th e
exact d etails, as th e n ote rem in d s m e to d o with th e “q u alification s()”
m essage in Figu re 6 -7. I also p refer to layer th e seq u en ce d iagram s from
left-to-righ t. I in d icate th e actors, th en th e con troller class(es), an d th en
th e u ser in terface class(es), an d , fin ally, th e bu sin ess class(es). Du rin g
d esign , you p robably n eed to ad d system an d p ersisten ce classes, wh ich I
u su ally p u t on th e righ t-m ost sid e of seq u en ce d iagram s. Layin g you r
seq u en ce d iagram s in th is m an n er often m akes th em easier to read an d
also m akes it easier to fin d layerin g logic p roblem s, su ch as u ser in terface
classes d irectly accessin g p ersisten ce classes (m ore on th is in Ch ap ter 7).
In terestin g to n ote is th e style of logic ch an ged p art way th rou gh th e
seq u en ce d iagram of Figu re 6 -7. Th e u ser in terface was h an d lin g som e of
th e basic logic at first —p articu larly th e login —yet for selectin g th e sem i-
n ar, an d th en verifyin g it, th e con troller class d id th e work. Th is is actu -
ally a d esign issu e. I wou ld n ’t get too worked u p over th is bu t, as always,
I su ggest ch oosin g on e style for n ow an d stickin g to it.
Alth ough Figure 6-7 m odels th e logic, th e basic course of action for th e
“En roll in Sem in ar” use case, h ow would you go about m odelin g altern ate
courses? Th e m ost com m on way to do so is to create a sin gle sequen ce dia-
gram for each altern ate course, as you see depicted in Figure 6-8. Th is dia-
gram m odels on ly th e logic of th e altern ate course, as you can tell by th e
n um berin g of th e steps on th e left-h an d side of th e diagram . Th e h eader
n ote for th e diagram in dicates th at it is an altern ate course of action . Also
n otice h ow th e ID of th is diagram in cludes th at th is is altern ate course B,
yet an oth er m odelin g rule of th um b I h ave foun d useful over th e years.
You may have heard terms such as dynamic modeling and static modeling TIP
bantered about by other developers familiar with object-oriented modeling
techniques. You may even have heard arguments about the merits of each Seq uence
style. Dynamic modeling techniques focus on identifying the behavior within Dia gra m s Are
your system. These techniques include sequence diagramming and activity Dyna m ic
diagramming (both of which are described in this chapter) and collaboration
diagramming, described in Chapter 7. Static modeling focuses on the static
aspects of your system, including the classes, their attributes, and the associations
between classes. Class models, described in this chapter, are the main artifact
of static modeling, as are persistence models, which are described in Chapter
7. Both dynamic and static modeling techniques are required to specify an
object-oriented system adequately, which makes the “ dynamic modeling
versus static modeling” debates questionable at best.
Th e seq u en ce diagram of Figu re 6 -8 is sim p ler th an th at of Figu re 6 -7;

th is is gen erally th e case of altern ate cou rses. I m odeled th e retu rn valu e
from th e “isEligibleToEn roll(th eStu den t)” m essage becau se th is is wh at
cau ses th e altern ate cou rse to occu r in th e first p lace. Th is argu ably p oin ts
to th e n eed always to m odel retu rn valu es in you r seq u en ce diagram s. I
still p refer to keep m y diagram s as sim p le as p ossible, th ou gh , so I m odel
th em on ly wh en th e in form ation is vital to m y u n derstan din g of th e
logic. I also ch ose to sh ow th e in eligibility n otice as its own u ser- in terface
elem en t, on ce again borderin g on a design decision th at wou ld n eed to be
reflected in th e u ser in terface p rototyp e. I also m odeled th at th e p rereq u i-
sites list is disp layed as p art of th e sem in ar details u ser in terface elem en t,
wh ich is m ore th an th e u se case cu rren tly calls for. Th is im p lies th at I
sh ou ld verify th e ch an ge with m y SMEs becau se I h ave effectively
in creased th e req u irem en ts alth ou gh , by doin g so, I h ave likely in dicated Fig ure 6 -8 .
an op p ortu n ity for both reu se an d an overall sim p lification of th e p oten - A UML sequence
diagram for an
alternate course
Enroll In Seminar
Alternate Course of
Action: Student Does
not Have Prerequisites A Student :EnrollInSeminar :IneligibilityNotice :SeminarDetails seminar:Seminar
<<actor>> <<controller>> <<UI>> <<UI>>
SD #: UC17-01B
isEligibleToEnroll(theStudent)
B.6. System determines ineligibility to enroll
false
<<create>>
B.7. System informs the student of ineligibility
B.8. System informs the student of <<create>>
prerequisites
B.9. Use case resumes at step 4
tial design . As you can see with th is exam p le, th e lin e between an alysis
an d design is fu zzy with object-orien ted develop m en t; exp erien ced devel-
op ers n ew to objects can take tim e to get u sed to th is. Fin ally, I left th e
“Stu den t” actor in th e diagram , even th ou gh n o direct in teraction occu rs
at th is p oin t becau se th is actor is referred to in th e step s of th e u se case.
6.2.1 How t o Dra w Seq uence Dia gra m s

Th e followin g step s d escribe th e fu n d am en tal tasks of seq u en ce d iagram -
m in g, tasks you p erform in an iterative m an n er.
1. Iden tify th e sco pe o f th e sequen ce diagram . Begin by id en tify-

in g wh at you are m od elin g. Is it th e basic cou rse of action for a
sin gle u se case? A sin gle altern ate cou rse? Th e com bin ation of
th e basic cou rse of action an d on e or m ore altern ate cou rses?
Logic from several u se cases? On ce you id en tify th e scop e of you r
d iagram , you sh ou ld ad d a label at th e top , u sin g a n ote, in d icat-
in g an ap p rop riate title for th e d iagram an d a u n iq u e id en tifier
for it. You m ay also wan t to in clu d e th e d ate an d also th e n am es
of th e au th ors of th e d iagram .
2. List th e use case steps do w n th e left-h an d side. I like to start a
seq u en ce d iagram by writin g a su m m ary of th e origin al u se case
text in th e left-h an d m argin , as you saw in Figu re 6 -7 an d Figu re
6 -8. Th is logic is wh at you are m od elin g, so you m igh t as well
h ave it on you r d iagram from th e start. Rosen berg an d Scott
(1999) p oin t ou t th is also p rovid es valu able traceability in form a-
tion between you r u se cases an d seq u en ce d iagram s.
3. In tro duce bo xes fo r each acto r. In trod u ce a box for each actor
across th e top of you r d iagram . I p refer to p u t actors th at rep re-
sen t h u m an s an d organ ization s on th e left-h an d sid e an d th ose
th at rep resen t extern al system s on th e righ t-h an d sid e. Label
each box with th e <<actor>> stereotyp e.
4. In tro duce co n tro ller class(es). My style is to in trod u ce at least
on e con troller class wh ose p u rp ose is to m ed iate th e logic
d escribed by th e u se case step s. Th is bu sin ess logic typ ically d oes-
n ’t belon g in you r u ser in terface classes. In stead , it sh ou ld be
en cap su lated by bu sin ess classes (a con troller class is a typ e of
bu sin ess class). Later, d u rin g d esign , you will likely refactor th is
logic in to on e or m ore classes to reflect issu es with you r ch osen
im p lem en tation tech n ologies. Label each box with th e <<con -
troller>> stereotyp e.
5. In tro duce a bo x fo r each m ajo r UI elem en t. Major u ser in ter-

face elem en ts, an d m in or on es for th at m atter, are im p lem en ted
as classes in object-orien ted system s. Th erefore, th ey sh ou ld be
m od eled as a box in a seq u en ce d iagram . My style is to list th e UI
elem en ts to th e im m ed iate righ t of th e con troller class(es). Label
each box with th e <<UI>> stereotyp e. 1
6. In troduce a box for each in cluded use case. Alth ough I didn ’t
in clude th is in an exam ple, in cluded use cases are treated just like
objects. Mark th em with th e stereotype <<use case>> an d give th em
a n am e in th e form at “id:Use case n am e,” such as “UC17:En roll in
Sem in ar.” To in dicate th at th e use case is bein g in voked by a step, I
sim ply sen d it a m essage with th e stereotype of <<uses>>.
7. Iden tify appropriate m essages for each use case step. Goin g on e
step at a tim e, walk th rough th e process logic for th e scen ario, iden -
tifyin g each m essage th at n eeds to be sen t an d its destin ation . Th e
sequen cin g of th e m essages is im plied on th e diagram by th e order
of th e m essages th em selves, startin g at th e top-left corn er of th e
diagram . Wh en you are drawin g sequen ce diagram s, th e im portan t
task is to get th e logic righ t; you effectively flesh out your logic as
you iden tify m essages for each step. Also, don ’t forget th at an
object or class can sen d a m essage to itself, as you saw in Figure 6-7.
8. Add a m eth od-in vocation box for each in vocation of a m eth od.
Every tim e an object or class receives a m essage, a m eth od is
in voked. To represen t th is, you sh ould in clude a m eth od-in vocation
box to th e lifelin e of th e target. Th e in com in g m essage will be
received at th e top of th e box an d, to fulfill th e logic of th e step, you
m ay fin d th e target n eeds to sen d m essages to oth er objects an d
classes, wh ich , in turn , in voke m eth ods on th ose n ew targets. From
th e box, m essages m ay be sen t to oth er objects th at, in turn , in voke
m eth ods with in th ose targets. Even tually, th is m eth od will com -
plete; th erefore, th e m eth od in vocation box “stops” an d, possibly, a
value is return ed to th e origin al sen der of th e m essage.
1
Stereotyp es in th e UML typ ically begin with a lowercase letter. However, becau se I am
u sin g th e term “UI” for th e stereotyp e label, in stead of “u ser in terface,” I h ave ch osen
to cap italize it. Also, in Ch ap ter 3, I was u sin g th e stereotyp e <<Actor>> in stead of
<<actor>> on th e Class Resp on sibility Collaborator (CRC) card s. I d id th is for two rea-
son s. First, CRC m od els are n ot p art of th e UML an d , th erefore, d on ’t h ave com p ly
with UML p ractices. Secon d , I d id it to sh ow you th e world won ’t en d if you break th e
ru les a bit. I’ve lot track of th e am ou n t of tim e, easily in th e h u n d red s of h ou rs, th at
I’ve wasted in con versation s d u rin g m od elin g session s over n itp icky issu es su ch as th is.
You r goal is to m od el you r system accu rately in a way th at is u n d erstan d able to th e
p eop le in volved ; wh eth er you u se <<Actor>> or <<actor>> as a stereotyp e is barely rele-
van t wh en th e big p ictu re is taken in to con sid eration .
9. Add destructio n m essages w h ere appro priate. At th e en d of a

m eth od in vocation , th e target object m ay be d estroyed . Th is is
com m on for tran sitory objects su ch as u ser in terface elem en ts
an d for bu sin ess objects d eleted as th e resu lt of an op eration .
Th erefore, a m essage with th e stereotyp e <<d estroy>> sh ou ld be
sen t to th e object an d th e m eth od -in vocation box labeled with
an X at its bottom . Som etim es an object will d estroy itself, as you
saw in Figu re 6 -7.
10. Add yo ur busin ess classes an d o bjects. As you id en tify m es-
sages you also n eed to id en tify targets for th ose m essages, targets
th at will in evitably be classes or objects. Th e ap p rop riate classes
(objects are in stan ces of classes) sh ou ld be in you r con cep tu al
m od el (if n ot, th en you n eed to ad d th em ). Use th e class n am es
from you r con cep tu al m od el for th e n am es of th e classes in you r
seq u en ce d iagram s (an y bu sin ess class th at ap p ears on a
seq u en ce d iagram sh ou ld also ap p ear in you r con cep tu al m od el).
For n ow, d on ’t worry too m u ch wh eth er an object or a class
sh ou ld be th e target of a m essage. You can always rework you r
d iagram if you get it wron g at first. Th e im p ortan t th in g is to get
th e fu n d am en tal id ea correct, an d th en you can go back to p er-
fect it later. Rem em ber to layer you r classes an d objects as
d escribed in p reviou s step s. Also, you m ay fin d you n eed several
in stan ces of th e sam e class on a sin gle seq u en ce d iagram . For
exam p le, h ad I m od eled a scen ario in wh ich a stu d en t en rolled
in th ree d ifferen t sem in ars, th en I wou ld h ave in clu d ed th ree
sem in ar objects in th e d iagram .
11. Update your class m odel. Because you are sequen ce diagram -
m in g, you will iden tify n ew respon sibilities for classes an d objects,
an d, som etim es, even for n ew classes. Rem em ber, each m essage
sen t to a class in vokes a static m eth od/operation on th at class, an
operation th at sh ould appear on your class m odel. Sim ilarly, each
m essage sen t to an object in vokes an operation on th at object, an
operation th at sh ould also appear on your class m odel. Sequen ce
diagram m in g is a sign ifican t source for iden tifyin g beh avior to be
m odeled on your class m odel, th e subject of Section 6.3.
12. Update yo ur user in terface m o del. As you work th rou gh th e
logic of each scen ario, you m ay d iscover you are m issin g featu res
in you r u ser in terface or you h ave m od eled som e featu res in ap -
p rop riately. W h en you d iscover th is, you sh ou ld work togeth er
with you r SMEs to id en tify th e p rop er way for you r u ser in terface
to work, th e top ic of Section 6.5.
13. Update yo ur use case m o del. As you are seq u en ce d iagram -

m in g, you m ay fin d errors in you r origin al u se case logic, errors
th at n eed to be fixed on both you r seq u en ce d iagram (s) an d in
you r u se case(s). As always, valid ate an y u se case ch an ges with
you r SMEs first.
6.2.2 W hy a nd W hen Should You Dra w Seq uence Dia gra m s?

You wan t to d raw seq u en ce d iagram s for several reason s. First an d fore- Seq uence
m ost, seq u en ce d iagram s are a great way to valid ate an d flesh ou t you r d ia gra m s a re used
logic (n ot th at th is sh ou ld stop you from u se case scen ario testin g, as t o t est your d esign
a nd t o d ocum ent
d escribed in Ch ap ter 4). Secon d , seq u en ce d iagram s are a great way to
use ca ses.
d ocu m en t you r d esign , at least from th e p oin t-of-view of u se cases.
Th ird , seq u en ce d iagram s are a great m ech an ism for d etectin g bottle-
n ecks in you r d esign . By lookin g at wh at m essages are bein g sen t to an
object, an d by lookin g at rou gh ly h ow lon g it takes to ru n th e in voked
m eth od , you q u ickly get an u n d erstan d in g of wh ere you n eed to ch an ge
you r d esign to d istribu te th e load with in you r system . In fact, som e CASE
tools even en able you to sim u late th is asp ect of you r software. Fin ally,
seq u en ce d iagram s often give you a feel for wh ich classes in you r ap p lica-
tion are goin g to be com p lex, wh ich , in tu rn , is an in d ication you m ay
n eed to d raw state ch art d iagram s for th ose classes (UML state ch art d ia-
gram s are d escribed in Ch ap ter 8).
6.2.3 How t o Docum ent Seq uence Dia gra m s

I gen erally d on ’t d evelop d ocu m en tation sp ecific to seq u en ce d iagram s.
Seq u en ce d iagram s p rovid e a brid ge between you r u se cases an d you r
class m od el. Everyth in g th at is sh own in a seq u en ce d iagram is d ocu -
m en ted in th ese m od els. For exam p le, th e step s d ep icted by th e seq u en ce
d iagram are d ocu m en ted by you r u se cases. Th e boxes across th e top of
th e d iagram are d ocu m en ted .
6.2.4 A Good Thing t o Know About Seq uence Dia gra m s

You n eed to d o at least on e seq u en ce d iagram for each u se case an d ,
often , you will create several for each u se case. Becau se th e d iagram
sh ou ld m atch th e n arrative flow of th e u se case, Rosen berg an d Scott
D EFIN ITION
Tra nsit ory object . An object that is not saved to permanent storage.
D EFIN ITION
Com p ut er-a id ed syst em engineering (CASE) t ool. Software that supports
the creation of models of software-oriented systems.
(1999) p oin t ou t th at if you are h avin g p roblem s gettin g started d rawin g

seq u en ce d iagram s for a u se case, th en you likely wrote th e u se case
in correctly an d sh ou ld recon sid er its logic. Th ey also p oin t ou t th at
seq u en ce d iagram m in g is th e p rim ary veh icle for allocatin g beh avior.
Du rin g an alysis, you will begin to ad d solu tion -sp ace objects to th e
p roblem -d om ain objects (from you r CRC m od el), in clu d in g con troller
an d u ser in terface objects. Fu rth erm ore, d u rin g d esign , Rosen berg an d
Scott (1999) also p oin t ou t th at you will in frastru ctu re objects su ch as
system an d p ersisten ce objects, scaffold in g, an d oth er h elp er objects in to
you r m od els.
6.3 Con ceptu a l Modelin g : Cla ss Dia g ra m s

Class m od els (Ru m bau gh , Jacobson , an d Booch , 1999) are th e m ain stay
of object-orien ted an alysis an d d esign . Before th e UML, m ost m eth od olo-
gies called th em object m od els in stead of class m od els.2 Class m od els are
created by u sin g m an y of th e m od elin g con cep ts an d n otation s d iscu ssed
in Ch ap ter 5. Class m od els sh ow th e classes of th e system , th eir in terrela-
tion sh ip s (in clu d in g in h eritan ce, aggregation , an d association ), an d th e
op eration s an d attribu tes of th e classes. Du rin g an alysis, you u se class
m od els to rep resen t you r con cep tu al m od el, an exp an sion of th e d om ain
m od el d escribed in Ch ap ter 3, becau se it sh ows greater d etail an d a wid er
ran ge of d etail. Con cep tu al m od els are u sed to d ep ict you r d etailed
u n d erstan d in g of th e p roblem sp ace for you r system . Du rin g d esign , th is
m od el is evolved fu rth er to in clu d e classes th at ad d ress th e solu tion
sp ace, as well as th e p roblem sp ace.
Th e easiest way to begin con cep tu al m od elin g is to u se you r d om ain
m od el as a base. In th is case, you will take you r Class Resp on sibility Col-
laborator (CRC) m od el (Beck an d Cu n n in gh am , 1989) an d con vert it
d irectly in to a UML class d iagram . CRC m od els sh ow th e in itial classes of
a system , th eir resp on sibilities, an d th e basic relation sh ip s (in th e form of
a list of collaborators) between th ose classes. W h ile a CRC m od el p ro-
vid es an excellen t overview of a system , it d oesn ’t p rovid e th e d etails
2
In th e origin al ed ition of th is book, written in 1995, I argu ed for, an d th en u sed , th e
term “class m od el,” in stead of “object m od el,” for th e sim p le reason th at you u se th em
to m od el classes an d th eir relation sh ip s, n ot objects.
D EFIN ITION S
Problem sp a ce. The scope of your business domain being addressed by your
system.
Solut ion sp a ce. The problem space being addressed by your system plus the
nondomain functionality required to implement your system.
n eed ed to actu ally bu ild it. Lu ckily, th ose d etails h ave been cap tu red in
th e n otes taken d own by th e scribe(s) d u rin g CRC m od elin g. Figu re 6 -9
d ep icts th e CRC m od el we d evelop ed in Ch ap ter 3, th e “Secu rityLogon ”
class id en tified in th e seq u en ce d iagram s earlier h as been in trod u ced to
CRC m od el, an d Figu re 6 -10 d ep icts th e UML class d iagram th at wou ld
be created based on th at CRC m od el.
For each card in th e CRC m odel, you create a con crete class in th e class
diagram , with th e exception of cards th at represen t actors (actors exist in th e Fig ure 6 -9 .
real world). Notice h ow th e n am es stayed th e sam e (spaces were rem oved A CRC model for
the university
Professor
Name
Seminar
Address
Phone number
Email address
Salary
Transcript <<UI>>
Provide information
Seminars instructing
**See the prototype** Student
Student <<Actor>> Get student info Seminar
Get seminars student Professor .
Provide information Enroll in Seminar took Enrollment Record
about self Transcript Determine average Seminar
Request to enroll in mark
seminar Name
Output self Student
Request Transcript Seminar number
Professor
Fees
Waiting list
Enrolled students
Enroll in Seminar <<UI>> Instructor
Add student
**See the prototype** Seminar Drop student
Enable seminar search Professor
Display seminar list
Display seminar fees Student
Display professor info
Name Enrollment
Address Record
Phone number
Email address
Student number
Average mark received
SecurityLogon <<UI>> Validate identifying info
Provide list of seminars
**See the prototype** Student taken
Request identifying
info for student
Enrollment Record
Mark(s) received Seminar

Average to date
Final grade
Student
Seminar
EnrollmentRecord
marksReceived
SecurityLogon
<<UI>> getAverageToDate()
enrolled getFinalMark()
acceptStudentID() in enrolled
acceptStudentName()
in
validateStudent()
Student
name Seminar
Transcript
address name
<<UI>>
phoneNumber seminarNumber
emailAddress fees
getStudent() studentNumber on waiting list waitingList
getSeminars() averageMark
determineAverage() addStudent(student)
isEligible (name, dropStudent(student)
output() studentNumber)
getSeminarsTaken()
EnrollInSeminar
<<UI>> instructs
searchForSeminar()
displaySeminarList() Professor
displaySeminarFees() name
displayProfessor() address
phoneNumber
emailAddress
salary
Fig ure 6 -1 0 . getInformation()
A UML class diagram
based on the CRC
model
from th e n am es to follow th e n am in g con ven tion of ClassNam e). Next, th e

collaborators on CRC cards in dicate th e n eed for an association , aggregation
association , or depen den cy between classes. I m odeled depen den cies
between user in terface classes an d th e busin ess classes with wh ich th ey col-
Collaborations from laborate because user in terface classes are tran sitory in n ature, im plyin g th e
a user interfa ce association s th ey are in volved with are tran sitory an d, h en ce, sh ould be
cla ss im plies a m odeled as depen den cies. Wh en ever a collaboration occurred between two
dependency, wherea s
busin ess classes, I m odeled an association for n ow. As you see later, th ese
collaborations
from business/
association s m ay, in fact, prove to be aggregation association s but, for n ow, it
dom ain cla sses is good en ough sim ply to h ave m odeled th e lin e.
im ply either Con sid er th e association s m od eled in Figu re 6 -10. Th e “waitin g list”
association or association between “Sem in ar” an d “Stu d en t” was ad d ed , m od elin g th e
aggregation sim ilarly n am ed resp on sibility on th e “Sem in ar” CRC card . I cou ld h ave
between the cla sses. ad d ed an attribu te in th e “Sem in ar” class called “waitin gList” bu t,
in stead , ch ose to m od el it as an association becau se th at is wh at it actu -
ally rep resen ts: th at sem in ar objects m ain tain a waitin g list of zero or
m ore stu d en t objects. In Ch ap ter 5, I sh owed th at association s are im p le-
m en ted as a com bin ation of attribu tes an d op eration s so, fran kly, you
m ay as well ad d th e attribu te to th e m od el n ow an d get it over with . Th e
“waitin g list” association is u n id irection al becau se th ere was n eith er a
D EFIN ITION
Concret e cla ss. A class that has objects instantiated from it.
corresp on d in g collaborator in d icated by th e “Stu d en t” card n or d id a Associa t ions a re

resp on sibility in d icate th at th e “Stu d en t” card h ad kn owled ge of bein g bid irect iona l only
on a waitin g list. I m od eled an “en rolled in ” association between th e if t hey need t o be
t ra versed in bot h
“Stu d en t” an d “En rollm en tRecord ” classes to su p p ort th e sim ilarly
d irect ions.
n am ed resp on sibility on th e “Stu d en t” CRC card . For th is association , it
ap p ears stu d en t objects kn ow wh at en rollm en t record s th ey are in volved
with , record in g th e sem in ars th ey h ave taken in th e p ast, as well as th e
sem in ars in wh ich th ey are cu rren tly in volved . Th is association wou ld be
traversed to calcu late th eir stu d en t object’s average m ark an d to p rovid e
in form ation abou t sem in ars taken . Th ere is also an “en rolled in ” associa-
tion between “En rollm en tRecord ” an d “Sem in ar” to su p p ort th e cap abil-
ity for stu d en t objects to p rod u ce a list of sem in ars taken . Th e “in stru cts”
association between th e “Professor” class an d th e “Sem in ar” class is bid i-
rection al becau se p rofessor objects kn ow wh at sem in ars th ey in stru ct
(th e Sem in ar’s in stru ctin g resp on sibility) an d sem in ar objects kn ow wh o
in stru cts th em (th e In stru ctor resp on sibility).
Oth er th an th e p reviou sly n oted excep tion s, th e resp on sibilities on Resp onsibilit ies
th e CRC card s were m od eled eith er as attribu tes or m eth od s of th e corre- a re usua lly
sp on d in g classes. Th e “Stu d en t” class is in terestin g becau se I ch ose to m od eled a s
a t t ribut es or
m od el th e “Average m ark received ” resp on sibility as an attribu te an d n ot
m et hod s.
a m eth od . How th is resp on sibility is actu ally im p lem en ted is a d esign
d ecision , on e I d on ’t n eed to m ake n ow. I h ave m ad e a good gu ess as to
h ow to im p lem en t th is resp on sibility an d m oved on to oth er issu es. It is
too early in th e m od elin g p rocess to worry abou t n itp icky issu es like th is:
Th e “Stu d en t” class cou ld go away, based on an oth er d esign d ecision
(u n likely, bu t…), so wh y in vest a lot of effort gettin g th e d etails righ t
wh en close en ou gh works ju st as well? My style is to n am e attribu tes an d
m eth od s u sin g th e form ats attribu teNam e an d m eth od Nam e(p aram eter-
Nam e), resp ectively, wh ich h ap p en to be th e com m on n am in g con ven -
tion s for both Java (Verm eu len et al., 2 000) an d C++.
Also n otice, in Figu re 6 -10, h ow I h aven ’t m od eled th e visibility of th e
attribu tes an d m eth od s to an y great exten t. Visibility is an im p ortan t
issu e d u rin g d esign bu t, for n ow, it can be ign ored . Also n otice, I h aven ’t
d efin ed th e fu ll m eth od sign atu res for th e classes. Yes, I h ave in d icated
th e p aram eters, bu t n ot th eir typ e. An d I h aven ’t in d icated th e retu rn
valu e from each m eth od eith er, an oth er task I typ ically leave to d esign .
Now con sid er th e u ser in terface classes. I d id n ’t both er to list th e
attribu tes becau se th ey are m od eled well en ou gh by th e p rototyp e an d
D EFIN ITION S
Bid irectiona l a ssocia tion. An association that may be traversed in both directions.
Unid irect iona l a ssocia t ion. An association that may be traversed in only one
direction.
Visibilit y. The level of access external objects have to an item, such as an
object’s attributes or methods, or even to a class itself.
Mod eling user even tu al u ser in terface d esign . Th e p u rp ose of m od els is to d escribe you r
interfa ce cla sses on system ad eq u ately, rarely to d escribe it th orou gh ly. Yes, I cou ld create
cla ss d ia gra m s d etailed classes for each UI class in m y m od el, bu t wh at valu e wou ld th at
often a d d s a lot of
be? It sou n d s like a lot of work for little retu rn , p articu larly wh en m ore
clutter without
th an en ou gh d etails are in th e u ser in terface m od el alread y. Also, as you
a d d ing m uch
useful inform a tion. can see in Figu re 6 -10, th e UI classes h ave m ad e q u ite a m ess of th e d ia-
gram , req u irin g th e m od elin g of a lot of d ep en d en cies th at ad d sign ifi-
can t clu tter with ou t com m u n icatin g m u ch valu able in form ation . Th is
in form ation cou ld be better record ed as p art of you r u ser in terface
m od el; a sim p le sp read sh eet listin g each m ajor UI elem en t an d th e bu si-
n ess classes on wh ich th ey are d ep en d en t sh ou ld be su fficien t.
Figu re 6 -11 p resen ts a revised version of Figu re 6 -10; th e u ser in terface
classes h ave been rem oved an d th e m u ltip licity of th e association s h ave
been m od eled . Based on wh at th e SMEs tell you an d on th e in form ation
con tain ed in th e n otes you r scribe(s) took as p art of req u irem en ts gath er-
in g, you sh ou ld be able to m ake ed u cated gu esses at th e m u ltip licities of
each association . In Figu re 6 -11, I was able to d eterm in e with certain ty,
based on th is in form ation , th e m u ltip licities for all bu t on e association
an d , for th at on e, I m arked it with a n ote to m yself. Notice m y u se of
q u estion m arks in th e n ote. As m en tion ed in Ch ap ter 5, m y style is to
m ark u n kn own in form ation on m y d iagram s th is way to rem in d m yself
th at I n eed to look in to it.
Mod el com p lex In Figu re 6 -11, I also m od eled a UML con strain t, in th is case “{ord ered
or im p ort a nt FIFO},” on th e association between “Sem in ar” an d “Stu d en t.” Th e basic
concep t s on your id ea is th at stu d en ts are p u t on th e waitin g list on a first-com e, first-ou t
UML d ia gra m s
(FIFO) basis. In oth er word s, th e stu d en ts are p u t on th e waitin g list in
using OCL.
ord er. UML con strain ts are u sed to m od el com p lex an d / or im p ortan t
in form ation accu rately in you r UML d iagram s. UML con strain ts are m od -
eled u sin g th e form at “{con strain t d escrip tion }” form at, wh ere th e con -
strain t d escrip tion m ay be in an y form at, in clu d in g p red icate calcu lu s.
Fowler an d Scott (1997) su ggest th at you focu s on read ability an d u n d er-
stan d ability an d , th erefore, su ggest u sin g an in form al d escrip tion . Con -
strain ts are d escribed in fu rth er d etail in Section 6.6.1.
EnrollmentRecord
1 enrolled in 1..* 1..* enrolled in 1
Student marksReceived Seminar
name getAverageToDate() name
address getFinalMark() seminarNumber
phoneNumber fees
{ordered, FIFO}
emailAddress 0..* on waiting list 0..* waitingList
studentNumber addStudent(student)
averageMark 0..* dropStudent(student)
isEligible (name,
studentNumber)
Professor
getSeminarsTaken()
name instructs
address
0..1
phoneNumber
emailAddress
salary
getInformation()
?Some seminars may

not have an instructor?
Fig ure 6 -1 1 .
On ce you h ave con verted th e in form ation con tain ed in you r CRC The revised class
m od el in to an in itial UML class m od el, you are th en read y to con tin u e diagram
flesh in g ou t you r m od el with ad d ed d etail. Class m od els con tain a
wealth of in form ation an d can be u sed for both th e an alysis an d d esign
of system s. To create an d evolve a class m od el, you n eed to m od el:
• Classes
• Meth od s
• Attribu tes
• Association s
• Dep en d en cies
• In h eritan ce relation sh ip s
• Aggregation association s
• Association classes
6.3.1 Mod eling Cla sses, At t ribut es, a nd Met hod s

An object, as defin ed previously, is an y person , place, th in g, con cept, even t,
screen , or report applicable to your system . Objects both kn ow th in gs (th ey
h ave attributes) an d th ey do th in gs (th ey h ave m eth ods). A class is a repre-
sen tation of an object an d, in m an y ways, it is sim ply a tem plate from
wh ich objects are created. Classes form th e m ain buildin g blocks of an

object-orien ted application . Two of th e steps of CRC m odelin g in cluded th e
fin din g of classes an d th e fin din g of respon sibilities. Classes represen t a col-
lection of sim ilar objects. For exam ple, alth ough th ousan ds of studen ts
atten d th e un iversity, you would on ly m odel on e class, called “Studen t,”
wh ich would represen t th e en tire collection of studen ts.
Classes are m odeled as rectan gles with th ree section s: th e top section for
th e n am e of th e class, th e m iddle section for th e attributes of th e class, an d
th e bottom section for th e m eth ods of th e class. Th e in itial classes of your
m odel will be iden tified wh en you con vert from your CRC m odel, as will
th e in itial attributes an d m eth ods. To describe a class, you defin e its attrib-
utes an d m eth ods. Attributes are th e in form ation stored about an object (or
at least in form ation tem porarily m ain tain ed about an object), wh ile m eth -
ods are th e th in gs an object or class does. For exam ple, studen ts h ave stu-
den t n um bers, n am es, addresses, an d ph on e n um bers. Th ose are all
exam ples of th e attributes of a studen t. Studen ts also en roll in courses, drop
courses, an d request tran scripts. Th ose are all exam ples of th e th in gs a stu-
den t does, wh ich get im plem en ted (coded) as m eth ods. You sh ould th in k of
m eth ods as th e object-orien ted equivalen t of fun ction s an d procedures.
An im portan t aspect of an alysis is to m odel your classes to th e appropri-
ate level of detail. Con sider th e “Studen t” class m odeled in Figure 6-11,
wh ich h as an attribute called “address.” Wh en you stop an d th in k about it,
addresses are com plicated th in gs. Th ey h ave com plex data, con tain in g
street an d city in form ation for exam ple, an d th ey poten tially h ave beh av-
ior. An arguably better way to m odel th is is depicted in Figure 6-12. Notice
h ow th e “Address” class h as been m odeled to in clude an attribute for each
piece of data it com prises an d two m eth ods h ave been added: on e to verify
it is a valid address an d on e to output it as a label (perh aps for an en velope).
By in troducin g th e “Address” class, th e “Studen t” class h as becom e m ore
coh esive. It n o lon ger con tain s logic (such as validation ) th at is pertin en t to
addresses. Th e “Address” class could n ow be reused in oth er places, such as
th e “Professor” class, reducin g your overall developm en t costs. Furth er-
m ore, if th e n eed arises to support studen ts with several addresses—durin g
th e sch ool term , a studen t m ay live in a differen t location th an h is perm a-
n en t m ailin g address, such as a dorm —th is is in form ation th e system m ay
TIP Use the terminology of your users in all your models. The purpose of
analysis is to understand the world of your users, not to foist your
Use t he Term inology of artificial, technical terms on them. Remember, they’re the experts,
Your Users not you. In short, avoid geek-speak.
Student Address Figure 6-12.

The “ Student” and
name street “ Address” classes
phoneNumber city
emailAddress 1 lives at 1 state
studentNumber postalCode
averageMark country
isEligible (name, validate()
studentNumber) outputAsLabel()
getSeminarsTaken()
n eed to track. Havin g a separate class to im plem en t addresses sh ould m ake

th e addition of th is beh avior easier to im plem en t.
Sim ilarly, th e “Sem in ar” class of Figure 6-11 is refactored in to th e classes
depicted in Figure 6-13. Refactorin g such as th is is called class norm alization
(Am bler, 1998a), a process in wh ich you refactor th e beh avior of classes to
in crease th eir coh esion an d/or to reduce th e couplin g between classes. A
sem in ar is an offerin g of a course; for exam ple, th ere could be five sem in ar
offerin gs of th e course “CSC 148 In troduction to Com puter Scien ce.” Th e
attributes “n am e” an d “fees” were m oved to th e “Course” class an d
“courseNum ber” was in troduced. Th e “getFullNam e()” m eth od con cate-
n ates th e course n um ber, “CSC 148,” an d th e course n am e, “In troduction
to Com puter Scien ce,” to give th e full n am e of th e course. Th is is called a
getter m eth od, an operation th at return s a data value pertin en t to an
object. Alth ough getter m eth ods, an d th e correspon din g setter m eth ods,
n eed to be developed for a class, th ey are typically assum ed to exist an d are
th erefore n ot m odeled (particularly on con ceptual class diagram s) so th ey
do n ot clutter your m odels. Figure 6-14 depicts “Course” from Figure 6-13
as it would appear with its getter an d setter m eth ods m odeled. Setters an d
getters are described in detail in Ch apter 7.
0..* offering of 1
Seminar Course
seminarNumber name
waitingList courseNumber
fees
addStudent(student) getFullName() Figure 6-13.
dropStudent(student) Normalizing the
“ Seminar” class
Figure 6-14. Course

“ Seminar” with all name
its getter and setter courseNumber
methods modeled fees
getFullName()
getCourseNumber()
setCourseNumber(number)
getFees()
setFees(amount)
getName()
setName(name)
Figu re 6 -15 p resen ts th e class d iagram th at resu lts3 wh en Figu res 6 -11,
6 -12, an d 6 -13 are com bin ed . Notice h ow “Professor””n ow referen ces th e
“Ad d ress” class, takin g ad van tage of th e work we d id to im p rove th e
“Stu d en t” class.
6.3.2 Mod eling Associa t ions

Objects are often associated with , or related to, oth er objects. For exam -
p le, as you see in Figu re 6 -15, several association s are between objects:
Stu d en ts are on waitin g list for sem in ars, p rofessors in stru ct sem in ars,
sem in ars are an offerin g of cou rses, a p rofessor lives at an ad d ress, an d so
on . Association s are m od eled as lin es con n ectin g th e two classes wh ose
in stan ces (objects) are in volved in th e relation sh ip .
Id ent ifying t he Wh en you m odel association s in UML class diagram s, you sh ow th em as a
m ult ip licit ies of th in lin e con n ectin g two classes, wh ich was illustrated in Figure 5-9. Associa-
a n a ssocia t ion is tion s can becom e quite com plex; con sequen tly, you can depict som e th in gs
a n im p ort a nt p a rt about th em on your diagram s. Figure 5-9 dem on strated th e com m on item s
of m od eling it .
to m odel for an association . You m ay wan t to refer to The Unified Modeling
Language Reference Manual (Rum baugh , Jacobson , an d Booch , 1999) for a
detailed discussion , in cludin g th e role an d cardin ality on each en d of th e
association , as well as a label for th e association . Th e label, wh ich is option al,
alth ough h igh ly recom m en ded, is typically on e or two words describin g th e
association . For exam ple, in Figure 6-15, you see professors in struct sem in ars.
However, it is n ot en ough sim ply to kn ow professors in struct sem in ars. How
m an y sem in ars do professors in struct? Non e, on e, or several? Furth erm ore,
3
I h ave ch eated a little an d ad d ed th e m eth od “p u rch aseParkin gPass()” to th e “Profes-
sor” an d “Stu d en t” classes, even th ou gh I d id n ’t h ave req u irem en ts for th is. You ’ll see
wh y I ad d ed th is m eth od later in Section 6.3.4 wh en I d iscu ss in h eritan ce.
EnrollmentRecord
1 enrolled in 1..* 1..* enrolled in 1 0..* offering of 1
Student marksReceived Seminar Course
getAverageToDate() seminarNumber name
name
getFinalMark() waitingList courseNumber
phoneNumber
fees
emailAddress {ordered, FIFO}
studentNumber 0..* on waiting list 0..* addStudent(student) getFullName()
averageMark dropStudent(student)
0..*
isEligible (name,
studentNumber) 0..1
Address Professor instructs
getSeminarsTaken() lives
purchaseParkingPass() street
at name
city lives at phoneNumber
state
1 1 0..1 emailAddress 0..1
postalCode
salary
country
getInformation()
validate()
outputAsLabel() purchaseParkingPass()
Figure 6-15.
Combined class
diagram
D EFIN ITION S
Cla ss norm a liza t ion. The process by which you refactor the behavior within
a class diagram in such a way as to increase the cohesion of classes while mini-
mizing the coupling between them.
Cohesion. The degree of relatedness within an encapsulated unit (such as a
component or a class).
Coup ling. The degree of dependence between two items. In general, it is bet-
ter to reduce coupling wherever possible.
Get t er. A method to obtain the value of a data attribute, or to calculate the
value, of an object or class.
Set t er. A method that sets the value of a data attribute of an object or class.
Also known as a mutator.
association s are often two-way streets: n ot on ly do professors in struct sem i-

n ars, but also sem in ars are in structed by professors. Th is leads to question s
such as: h ow m an y professors can in struct an y given sem in ar an d is it possi-
ble to h ave a sem in ar with n o on e in structin g it? Th e im plication is you also
n eed to iden tify th e cardin ality an d option ality of an association . Cardin ality
represen ts th e con cept of “h ow m an y,” an d option ality represen ts th e con -
cept of “wh eth er you m ust h ave som eth in g.” Im portan t to n ote is th e UML
ch ooses to com bin e th e con cepts of option ality an d cardin ality in to th e sin -
gle con cept of m ultiplicity. Th e m ultiplicity of th e association is labeled on
eith er en d of th e lin e, on e m ultiplicity in dicator for each direction (Table 6-1
sum m arizes th e poten tial m ultiplicity in dicators you can use).
An oth er op tion for association s is to in d icate th e d irection in wh ich
th e label sh ou ld be read . Th is is d ep icted u sin g a filled trian gle, an exam -
p le of wh ich is sh own on th e “offerin g of” association between th e “Sem -
in ar” an d “Cou rse” classes of Figu re 6 -15. Th is m arker in d icates th at th e
association sh ou ld be read “a sem in ar is an offerin g of a cou rse,” in stead
TIP For each class involved in an association, there is always a multiplicity for it.
When the multiplicity is one and one only (for example, one and one only
Alwa ys Ind ica t e person may be President of the United States at any given time), then it is
t he Mult ip licit y common practice not to indicate the multiplicity and, instead, to assume it is
“ 1.” I believe this is a mistake. If the multiplicity is “ 1,” then indicate it as such.
When something is left off a diagram, I can’t tell if that is what is meant or if the
modeler simply hasn’t gotten around to working on that aspect of the model
yet. I always assume the modeler hasn’t done the work yet.
Ta ble 6-1. UML m ult ip licit y ind ica t ors
In dica tor Mea n in g
0..1 Zero or one

1 One only
0..* Zero or more
1..* One or more
n Only n (where n > 1)
0..n Zero to n (where n > 1)
1..n One to n (where n > 1)
of “a cou rse is an offerin g of a sem in ar.” Direction m arkers sh ou ld be

u sed wh en ever it isn ’t clear wh ich way a label sh ou ld be read . My ad vice,
h owever, is if you r label is n ot clear, th en you sh ou ld con sid er reword in g
it. Refer to Figu re 5-9 for an overview of m od elin g association s in UML
class d iagram s.
At each en d of th e association , th e role, th e con text an object takes Mod el roles when
with in th e association , m ay also be in dicated. My style is to m odel th e a n a ssocia tion is
role on ly wh en th e in form ation adds valu e, for exam p le, kn owin g th e recursive or when
severa l a ssocia tions
role of th e “Stu den t” class is “en rolled stu den t” in th e “en rolled in ” asso-
exist between two
ciation doesn ’t add an yth in g to th e m odel. I in dicate roles wh en it isn ’t cla sses.
clear from th e association label wh at th e roles are, if th ere is a recu rsive
association , or if th ere are several association s between two classes. In Fig-
u re 6 -16, I h ave evolved ou r class diagram to in clu de two association s
between “Professor” an d “Sem in ar.” Not on ly do p rofessors in stru ct sem i-
n ars, th ey also assist in th em . W h en several association s exist between
two classes, som eth in g th at is relatively com m on , you often fin d you
n eed to in dicate th e roles to u n derstan d th e association s fu lly. In th is
case, I in dicated th e roles p rofessors take, bu t n ot sem in ars, becau se th e
role of th e sem in ar objects weren ’t very in terestin g. Both roles are m od-
eled for th e “m en tors” recu rsive association th at th e “Professor” class h as
becau se it is in terestin g to kn ow th at th e m en torin g p rofessor is called an
advisor an d th e m en tored p rofessor is called an associate.
Figu re 6 -16 is also in terestin g becau se it u ses a UML con train t to in d i-
cate th at a p rofessor m ay in stru ct a given sem in ar, m ay assist with a sem -
in ar, or m ay n ot be in volved in th e sem in ar, bu t wou ld n ’t be both an
assistan t an d an in stru ctor for th e sam e sem in ar. Th e con train t d escrip -
tion “NAND” rep resen ts th e logical con cep t of “n ot an d .”
Professor Seminar
0..1 0..*
name seminarNumber
assistant
associate phoneNumber waitingList
0..* emailAddress {NAND}
salary addStudent(student)
0..1 0..* dropStudent(student)
getInformation()
instructor
0..1 advisor
mentors
Figure 6-16. 6.3.3 Mod eling Dep end encies

Modeling roles in
Depen den cy relation sh ips are used to m odel tran sitory association s between
associations
two classes. Tran sitory association s occur wh en on e or both of th e classes are
n ot persisten t, in oth er words, th eir in stan ces are n ot saved to perm an en t
storage. User in terface classes are typically n ot persisten t: you create th e
screen or report object, work with it, an d th en discard/destroy it wh en you
n o lon ger n eed it. Because th ese objects collaborate with oth er objects to ful-
fill th eir respon sibilities, an d because th e on ly way an object can collaborate
with an oth er is if it kn ows about it, th en som e sort of relation sh ip m ust exist
between th e two classes. In th is case, you m odel th is fact with a depen den cy
relation sh ip, wh ich , as you see in Figure 6-17, is depicted as a dash ed arrow.
In th is diagram , I ch ose to m odel th e classes sim ply as boxes, in stead of th e
usual th ree-section ed boxes in dicatin g th e n am e of th e class, its attributes,
an d its m eth ods. As you saw in Ch apter 5, both n otation s are acceptable
with in th e UML.
6.3.4 Int rod ucing Reuse Bet ween Cla sses via Inherit a nce
Sim ilarities often exist between differen t classes. Very often two or m ore
classes will sh are th e sam e attributes an d/or th e sam e m eth ods. Because you
D EFIN ITION S
Ca rd ina lit y. Represents the concept “ how many?” in associations.
Op t iona lit y. Represents the concept “ do you need to have it?” in associations.
Mult ip licit y. The UML combines the concepts of cardinality and optionality
into the single concept of multiplicity.
Recursive a ssocia t ion. An association in which the objects involved in it are
instances of the same class. For example, people marry people.
Figure 6-17.
EnrollInSeminar Modeling
Seminar
<<UI>> dependencies
between classes
don ’t wan t to h ave to write th e sam e code repeatedly, you wan t a m ech an ism
th at takes advan tage of th ese sim ilarities. In h eritan ce is th at m ech an ism . In h eri-
tan ce m odels “is a” an d “is like” relation sh ips, en ablin g you to reu se existin g
data an d code easily. W h en A in h erits from B, we say A is th e su bclass of B
an d B is th e su p erclass of A. Fu rth erm ore, we say we h ave “p u re in h eri-
tan ce” wh en A in h erits all th e attribu tes an d m eth ods of B. Th e UML
m odelin g n otation for in h eritan ce is a lin e with a closed arrowh ead p oin t-
in g from th e su bclass to th e su p erclass.
In Figu re 6 -15, m an y sim ilarities occu r between th e “Stu den t” an d
“Professor” classes. Not on ly do th ey h ave sim ilar attribu tes, bu t th ey also
h ave sim ilar m eth ods. To take advan tage of th ese sim ilarities, I created a
n ew class called “Person ” an d h ad both “Stu den t” an d “Professor” in h erit
from it, as you see in Figu re 6 -18. Th is stru ctu re wou ld be called th e “Per-
son ” in h eritan ce h ierarch y becau se “Person ” is its root class. Th e “Person ”
class is abstract: Objects are n ot created directly from it, an d it cap tu res
th e sim ilarities between th e stu den ts an d p rofessors. Abstract classes are
m odeled with th eir n am es in italics, as op p osed to con crete classes, classes
from wh ich objects are in stan tiated, wh ose n am es are in n orm al text.
Both classes h ad a n am e, em ail address, an d p h on e n u m ber, so th ese
attribu tes were m oved in to “Person .” Th e “p u rch aseParkin gPass()”
m eth od was also com m on between th e two classes, so th at was also
m oved in to p aren t class. By in trodu cin g th is in h eritan ce relation sh ip to
th e m odel, I redu ced th e am ou n t of work to be p erform ed. In stead of
im p lem en tin g th ese resp on sibilities twice, th ey are im p lem en ted on ce, in
th e “Person ” class, an d reu sed by “Stu den t” an d “Professor.”
An in terestin g asp ect of Figu re 6 -18 is th e association between “Per- Associa t ions a re
son ” an d “Ad d ress.” First, th is association was p u sh ed u p to “Person ” inherit ed .
becau se both “Professor” an d “Stu d en t” h ad a “lives at” association with
D EFIN ITION S
Dep end ency rela t ionship . A dependency relationship exists between Class A
and B when instances of Class A interact with instances of Class B. Dependency
relationships are used when no direct relationship (inheritance, aggregation, or
association) exists between the two classes.
Persist ence. The issue of how objects are permanently stored.
D EFIN ITION S
Abst ra ct cla ss. A class that doesn’t have objects instantiated from it.
Concret e cla ss. A class that has objects instantiated from it.
Inherit a nce hiera rchy. A set of classes related through inheritance. Also
referred to as a class hierarchy.
Inherit a nce. The representation of an is a, is like, or is kind of relationship
between two classes. Inheritance promotes reuse by enabling a subclass to ben-
efit automatically from all the behavior it inherits from its superclass(es).
Root cla ss. The top-most class in an inheritance hierarchy.
Subcla ss. If Class B inherits from Class A, we say B is a subclass of A.
Sup ercla ss. If Class B inherits from Class A, we say A is a superclass of B.
“Ad d ress.” I cou ld d o th is becau se, as I d escribed in Ch ap ter 5, associa-

tion s are im p lem en ted by th e com bin ation of attribu tes an d m eth od s.
Becau se attribu tes an d m eth od s can be in h erited , an y association th ey
im p lem en ted can also be in h erited by im p lication . It m ad e sen se to
ap p ly in h eritan ce h ere becau se th e association s rep resen ted th e sam e
con cep t: a p erson lives at an ad d ress (I was also lu cky becau se th e d irec-
tion of th e association s, as well as th eir m u ltip licities, were id en tical).
An oth er in terestin g asp ect of Figu re 6 -18 is th at alth ou gh both “Pro-
fessor” an d “Stu d en t” h ad association s with “Sem in ar,” I d id n ’t ch oose to
p u sh th is association u p in to “Person .” Th e issu e is th at th e sem an tics of
th e two association s are d ifferen t. First, on e association is u n id irection al
wh ereas th e oth er is bid irection al, a good in d ication th at th ey are sign ifi-
can tly d ifferen t. Secon d , th e m u ltip licities are d ifferen t, an oth er good
in d ication th at th e association s are d ifferen t. Th ird , an d m ost im p ortan t,
th e two association s are com p letely d ifferen t from on e an oth er. On e rep -
resen ts th e fact th at p rofessors in stru ct sem in ars, wh ereas th e oth er on e
rep resen ts th at stu d en ts are on waitin g lists to en roll in a sem in ar.
6.3.5 Mod eling Aggrega t ion Associa t ions

Aggrega t ion Som etim es an object is m ade u p of oth er objects. For exam p le, an airp lan e
m od els “is p a rt of” is m ade u p of a fu selage, win gs, en gin es, lan din g gear, flap s, an d so on . A
a ssocia t ions. delivery sh ip m en t con tain s on e or m ore p ackages. A team con sists of two
or m ore em p loyees. Th ese are all exam p les of th e con cep t of aggregation ,
wh ich rep resen ts “is p art of” relation sh ip s. An en gin e is p art of a p lan e, a
p ackage is p art of a sh ip m en t, an d an em p loyee is p art of a team .
Modelin g aggregation association s, or com position association s th at are
sim ply stron ger form s of aggregation , is sim ilar con ceptually to m odelin g
Person Address
name street
phoneNumber city
0..1 lives at 1
emailAddress state
postalCode
purchaseParkingPass() country
validate()
outputAsLabel()
Student Professor
Figure 6-18.
studentNumber salary
Applying the
averageMark getInformation() concept of
inheritance in a
isEligible (name, class diagram
studentNumber)
getSeminarsTaken()
association s. In Figure 6-19, you see a sim ple class m odel depictin g th e rela-
tion sh ips between “Program ,” (a program is a collection of courses th at lead
to a degree) an d th e “Course” class. A course m ay be part of on e or m ore
program s—som e courses such as “ARC 305 Medieval Garden in g Tools” are
for gen eral in terest on ly an d are n ot part of a program —an d an y given pro-
gram h as on e or m ore courses in it. Also n otice h ow an association exists
between “Program ” an d “Course” represen tin g th at som e courses are rec-
om m en ded for a program , but are n ot officially offered as part of th em (m y
SMEs told m e th is). For exam ple, th e course “CSC 148 In troduction to
Com puter Scien ce” is recom m en ded for th e en gin eerin g, busin ess, an d
ph ysics program s with in th e un iversity. It m ade sen se to m odel th is rela-
tion sh ip with an association in stead of an aggregation because it isn ’t true
th at a recom m en ded course is part of a program .
In the class diagram of Figure 6-15, I was lucky because I used similar names for TIP
these attributes in both classes: “ name,” “ emailAddress,” and “ phoneNumber,”
respectively. However, you will often find situations where one class has an Som et im es
attribute called “ name,” whereas another one has “ firstName,” “ middleInitial,” Op p ort unit ies
and “ lastName.” You then need to decide whether these are, in fact, the same for Inherit a nce
thing and, if they are, be prepared to refactor your existing model, and perhaps Are Not So
even code to reflect whichever approach to storing a person’s name you accept. Obvious
A similar issue can also occur with methods and associations.
D EFIN ITION S
Aggrega t ion. The representation of “ is part of” associations.
Com p osit ion. A strong form of aggregation in which the “ whole” is com-
pletely responsible for its parts and each “ part” object is only associated with
the one “ whole” object.
In Figu re 6 -2 0, I p resen t an exam p le u sin g com p osition , m od elin g th e

fact th at a p rod u ct is com p osed of on e or m ore com p on en ts, an d th en ,
in tu rn , th at a com p on en t m ay be com p osed of several su bcom p on en ts
(you can h ave recu rsive aggregation an d com p osition association s).
Com p osition m akes sen se in both th ese cases becau se wh atever you d o
to an in stan ce of th e wh ole, you are likely to also d o to its p arts. For
exam p le, if I sell a p rod u ct by im p lication , I am sellin g its com p on en ts. A
good ru le of th u m b is th at th e com p osition form of aggregation is gen er-
ally ap p licable wh en ever both classes rep resen t p h ysical item s an d aggre-
gation m akes sen se.
6.3.6 Mod eling Associa t ion Cla sses

Associa t ion Association classes, also called link classes, are u sed to m od el association s
cla sses m a y be th at h ave m eth od s an d attribu tes. “En rollm en tRecord ” is m od eled as an
useful d uring associative class in Figu re 6 -21, in stead of bein g m od eled as a “n orm al”
a na lysis, but need class as in Figu re 6 -15. Associative classes are typ ically m od eled d u rin g
t o be resolved
an alysis, as you see in Figu re 6 -21, an d th en refactored in to th e origin al
d uring d esign.
ap p roach you see in Figu re 6 -15 d u rin g d esign . Th e reason th is occu rs is,
Figure 6-19.
0..* 1..*
A course is part of a
program
Program 0..* recommended for 0..* Course
Figure 6-20. 0..* 1..* 0..* sub-

Modeling Product Component
composition assembly
0..*
assembly
One of the following sentences should make sense: “ A subclass IS A superclass” TIP
or “ A subclass IS LIKE A superclass.” For example, it makes sense to say a
student is a person and a dragon is like a bird. It doesn’t make sense to say a Ap p ly t he
student is a vehicle or is like a vehicle, so the class “ Student” likely shouldn’t Sent ence Rule
inherit from “ Vehicle.”
to d ate, at least to m y kn owled ge, n o m ain stream p rogram m in g lan gu age

exists th at su p p orts th e n otion of association s th at h ave resp on sibilities.
Becau se you can d irectly bu ild you r software in th is m an n er, I h ave a ten -
d en cy to stay away from u sin g association classes an d , in stead , resolve
th em d u rin g an alysis, as you saw with m y origin al ap p roach . Yes, th is is
n ot a p u rist way to m od el, bu t it is p rogram m atic. Noth in g is wron g with
u sin g associative classes. I ap p ly th is con cep t on occasion ; I ju st d on ’t
fin d m an y situ ation s wh ere it m akes sen se.
I wan t to take a m in u te to p oin t ou t a p oten tial p roblem with th e
“en rolled in ” association s in both Figu re 6 -15 an d Figu re 6 -21. I d ou bt
th ey are tru ly u n id irection al. In Ch ap ter 3, a u se case in d icates th at lists
of stu d en ts en rolled in a sem in ar are p rod u ced for p rofessors. Th is tells
m e a n eed exists to traverse from “Sem in ar” objects to “Stu d en t” objects,
in d icatin g th at th ese association s sh ou ld be m od eled bid irection ally.
6.3.7 Docum ent ing Cla ss Mod els

It isn ’t en ou gh to d raw a class d iagram ; it also n eed s to be d ocu m en ted .
Th e bu lk of th e d ocu m en tation work is d ocu m en tin g th e d etails abou t a
class, as well as th e reason in g beh in d an y trad e-offs you h ave m ad e.
Here’s wh at to d o:
EnrollmentRecord
marksReceived
getAverageToDate()
getFinalMark()
Figure 6-21.
Student 1..* 1..* Seminar An example of an
enrolled in associative class
TIP When deciding whether to use aggregation or composition over association,

Craig Larman (1998) says it best: If in doubt, leave it out. The reality is that
If In Doubt , many modelers will agonize over when to use aggregation even though little
Lea ve It Out difference exists among association, aggregation, and composition at the
coding level, something you see in Chapter 8.
1. Classes. A class is d ocu m en ted by a sen ten ce or two d escribin g

its p u rp ose. You sh ou ld also in d icate wh eth er th e class is p ersis-
ten t or tran sitory, an d if it h as an y aliases (oth er n am es it is
called ) for th e class. Docu m en tin g th e p oten tial alias for a class is
im p ortan t becau se d ifferen t p eop le in an organ ization can call
th e sam e th in g by d ifferen t n am es. For exam p le, d o ban ks serve
clien ts or cu stom ers? Do tru ckers d rive tru cks, veh icles, or lor-
ries? Do ch ild ren eat sweets, can d ies, or good ies? You wan t to
en su re th at everyon e is u sin g th e sam e term in ology. Also,
in clu d e referen ces to an y ap p licable bu sin ess ru les or con strain ts
con tain ed in th e su p p lem en tary sp ecification .
2. Attributes. An attribu te is best d escribed with on e or two sen -
ten ces, its typ e sh ou ld be in d icated if ap p rop riate, an exam p le
sh ou ld be given if n ot u n clear h ow th e attribu te is to be u sed ,
an d a ran ge of valu es sh ou ld be d efin ed , if ap p rop riate. Also,
in clu d e referen ces to an y ap p licable bu sin ess ru les or con strain ts
con tain ed in th e su p p lem en tary sp ecification .
3. Meth ods. Meth ods are docum en ted with pseudo-code, also kn own
as structured En glish , describin g its logic. Th e param eters (if an y)
an d th e return value (if an y) sh ould be docum en ted in a m an n er
sim ilar to attributes. Th e precon dition s an d postcon dition s for th e
m eth od sh ould be in dicated so developers un derstan d wh at th e
m eth od does. Also, in clude referen ces to an y applicable busin ess
rules or con strain ts con tain ed in th e supplem en tary specification .
4. In h eritan ce. I gen erally don ’t docu m en t in h eritan ce relation -
sh ip s. My belief is if you n eed to docu m en t wh y you h ave ap p lied
in h eritan ce, th en you p robably sh ou ldn ’t h ave ap p lied it to start.
5. Asso ciatio n s. Th e m ost im p ortan t in form ation abou t associa-
tion s—th e label, m u ltip licities, an d roles—alread y ap p ear on th e
d iagram . I typ ically also in clu d e a few sen ten ces d escribin g th e
association , as well as referen ce an y ap p licable bu sin ess ru les or
con strain ts con tain ed in th e su p p lem en tary sp ecification .
6. Aggregatio n an d co m po sitio n . Th ese are both d ocu m en ted

exactly as you wou ld association s.
6.3.8 Concep t ua l Cla ss Mod eling Tip s

In th is section , I wan t to sh are a collection of tip s an d tech n iq u es th at I
h ave fou n d u sefu l over th e years to im p rove th e q u ality of m y con cep -
tu al class m od els.
1. Yo u do n ’t h ave to get it perfect at th e start. I started th e con -

cep tu al m od el by con vertin g m y Class Resp on sibility Collabora-
tor (CRC) m od el in to a UML class m od el. Th is was a good start,
bu t I q u ickly fou n d I n eed ed to evolve th e m od el as m y an alysis
of th e system m oved forward . Th e p oin t is I d id n ’t get th e m od el
righ t at th e start an d th at was okay. I d id n ’t get th e m u ltip licities
on association s at th e begin n in g, an d I d id n ’t even get all th e
classes to start. Man y m od elers will waste a lot of tim e at th e
begin n in g of con cep tu al m od elin g by focu sin g on on e sm all
asp ect of th e m od el an d tryin g to get it righ t at first. It’s also
com m on to see m od elin g team s argu e for h ou rs abou t wh eth er
to u se association , aggregation , or com p osition in a certain sp ot
wh en little d ifferen ce actu ally exists am on g th e th ree op tion s. I
wou ld rath er p ick on e, m ove forward , an d tru st th at, at som e
p oin t in th e fu tu re, it will becom e clearer wh ich op tion to u se as
I u n d erstan d th e p roblem d om ain better.
2. Start at yo ur do m ain m o del. You r CRC m od el con tain s im p or-
tan t in form ation th at is relevan t to you r con cep tu al m od el, p ro-
vid in g an excellen t startin g p oin t.
3. Evolve your class diagram via sequen ce diagram s. Your seq u en ce
d iagram s m od el th e logic of you r u se cases, in p articu lar, th e crit-
ical bu sin ess logic you r system m u st su p p ort. As you d evelop
you r seq u en ce d iagram s, th e top ic of Section 6.2, you q u ickly
flesh ou t th e beh aviors req u ired of you r classes.
D EFIN ITION S
Post cond it ion. An expression of the properties of the state of an operation or
use case after it has been invoked successfully.
Precond it ion. An expression of the constraints under which an operation or use
case will operate properly.
4. Focus on th e problem space. Th e purpose of an alysis is to un der-

stan d an d m odel th e problem space of your system , n ot th e solution
space. Optim ization an d tech n ology issues sh ouldn ’t yet be taken
in to accoun t with in your m odels; th is is wh at design is all about.
5. Fo cus o n f ulfillin g th e requirem en ts first. Man y m od elers
m ake th e m istake of focu sin g on th e ap p lication of in h eritan ce
relation sh ip s or an an alysis p attern th ey h ave read abou t, in stead
of on an alyzin g th eir req u irem en ts m od el. In h eritan ce an d
an alysis p attern s are good th in gs bu t, if you r m od el d oesn ’t
reflect you r p roblem sp ace, th en it d oesn ’t really m atter wh at
fan cy tech n iq u es you h ave ap p lied , d oes it?
6. Use m ean in gful n am es. Your m odel elem en ts sh ould all h ave
n am es th at describe wh at th ey represen t. Use full words. I prefer to
see m eth od n am es, such as “calculateIn voiceTotal()” as opposed to
“calcIn vTot().” Yes, th e secon d n am e is easier to type because it’s
sh orter, but is it easier to un derstan d? Even worse are n am es such as
“param 1” an d “x” because you h ave n o idea wh at th ey represen t.
7. Perfo rm o bject-o rien ted an alysis. Th rou gh ou t th is ch ap ter, I
d escribe p roven tech n iq u es for p erform in g object-orien ted
an alysis (OOA), yet n owh ere d o you see m e ad vise you to look at
th e existin g d atabase sch em a an d create you r m od els based on
th at d esign . Th is is a d ata-d riven ap p roach to d evelop m en t, n ot
an object-orien ted on e, an ap p roach th at rarely resu lts in h igh -
q u ality software (Am bler, 1998b). Man y organ ization s flou n d er
with objects becau se th ey refu se to give u p th eir old d ata-d riven
ways an d / or th ey seek to recover th eir h u ge in vestm en t in exist-
in g legacy d ata m od els. Data m od elin g, m ore accu rately called
p ersisten ce m od elin g, is d escribed in Ch ap ter 7. An oth er related
issu e you ru n in to, lu ckily on e th at is easier to overcom e, is SMEs
wh o d escribe req u irem en ts in term s of tables. Don ’t worry abou t
it; ju st con vert th e con cep t to classes an d m ove forward .
8. Un derstan d an d effectively apply an alysis pattern s. Th is is
th e top ic of Section 6.7, so th e on ly th in g I say n ow is an alysis
p attern s are good th in gs.
9. Class m o del in parallel w ith user in terface pro to typin g. As
you d evelop you r u ser in terface p rototyp e, you q u ickly d iscover
th at d etailed attribu tes an d op eration s n eed to be im p lem en ted
by you r classes. Never forget th at object-orien ted d evelop m en t is
iterative —you will typ ically work on several m od els in p arallel,
workin g on each on e a bit at a tim e.
6.4 Activity Dia g ra m m in g

UML activity d iagram s (Ru m bau gh , Jacobson , an d Booch , 1999) are u sed Act ivit y d ia gra m s
to d ocu m en t th e logic of a sin gle op eration / m eth od , a sin gle u se case, or a re used t o m od el
th e flow of logic of a bu sin ess p rocess. In m an y ways, activity d iagram s t he logic of a
business p rocess,
are th e object-orien ted eq u ivalen t of flow ch arts an d d ata-flow d iagram s
use ca se, or
(DFDs) from stru ctu red d evelop m en t (Gan e an d Sarson , 1978). Th e activ-
m et hod .
ity d iagram of Figu re 6 -22 d ep icts th e bu sin ess logic for h ow som eon e
n ew to th e u n iversity wou ld en roll for th e first tim e.
Th e filled circle rep resen ts th e startin g p oin t of th e activity diagram —
effectively a p laceh older—an d th e filled circle with a border rep resen ts
th e en din g p oin t. Th e rou n ded rectan gles rep resen t p rocesses or activities
th at are p erform ed. For th e diagram of Figu re 6 -22, th e activities m ap rea-
son ably closely to u se cases, alth ou gh you will n otice th e “En roll in Sem i-
n ar(s)” activity wou ld be th e in vocation of th e “En roll in Sem in ar” u se
case several tim es. Activities can also be m u ch m ore fin ely grain ed, p artic-
u larly if I h ad ch osen to docu m en t th e logic of a m eth od in stead of a
h igh -level bu sin ess p rocess. Th e diam on d rep resen ts decision p oin ts. In
th is exam p le, th e decision p oin t h ad on ly two p ossible ou tcom es, bu t it
cou ld ju st as easily h ave h ad m an y m ore. Th e arrows rep resen t tran sition s
between activities, m odelin g th e flow order between th e variou s activities.
Th e text on th e arrows rep resen t con dition s th at m u st be fu lfilled to p ro-
ceed alon g th e tran sition an d are always described u sin g th e form at “[con -
dition ].” 4 Th e th ick bars rep resen t th e start an d en d of p oten tially p arallel
p rocesses—after you are su ccessfu lly en rolled in th e u n iversity, you m u st
atten d th e m an datory overview p resen tation , as well as en roll in at least
on e sem in ar an d p ay at least som e of you r tu ition .
Exitin g from an activity is p ossible in several ways, as you see with th e
“Fill ou t En rollm en t Form s” activity. If you r form s are correctly filled ou t,
th en you can p roceed to en roll in th e u n iversity. If you r form s aren ’t cor-
rect, h owever, th en you n eed to obtain h elp , p erh ap s from a registrar, to
fill th em ou t correctly.
Th is activity d iagram is in terestin g becau se it cu ts across th e logic of
several of th e u se cases id en tified in Ch ap ter 3. It is a good th in g th at u se
case m od els d on ’t com m u n icate th e tim e ord erin g of p rocesses well. For
exam p le, alth ou gh th e u se case d iagram p resen ted in Figu re 3-8 gives you
a good id ea as to th e typ e of fu n ction ality th is system p erform s, it offers
n o d efin itive an swer as to th e ord er in wh ich th ese u se cases m igh t occu r.
Th e activity d iagram of Figu re 6 -22 d oes, h owever. On ce again , d ifferen t
m od els h ave d ifferen t stren gth s an d weakn esses.
4
I su sp ect, in fu tu re version s of th e UML, we will see con d ition s d ocu m en ted u sin g th e
UML con strain t n otation d iscu ssed earlier.
Figure 6-22.
A UML activity
diagram for Enrolling in the
University for the
enrolling in school Fill out Enrollment [incorrect] Obtain Help to Fill first time
for the first time Forms Out Forms
AD #: 007
[correct]
Enroll in University
Attend University
Overview
Presentation
[accepted]
[rejected]
Make Initial Tuition
Enroll In Seminar(s)
Payment
6.4.1 How t o Dra w Act ivit y Dia gra m s

Th e followin g step s d escribe th e fu n d am en tal tasks of activity d iagram -
m in g, tasks you will p erform in an iterative m an n er.
1. Iden tify th e sco pe o f th e activ ity diagram . Begin by id en tify-
in g wh at it is you are m od elin g. Is it a sin gle u se case? A p ortion
of a u se case? A bu sin ess p rocess th at in clu d es several u se cases?
A sin gle m eth od of a class? On ce you id en tify th e scop e of you r
d iagram , you sh ou ld ad d a label at th e top , u sin g a n ote, in d icat-
in g an ap p rop riate title for th e d iagram an d a u n iq u e id en tifier
for it. You m ay also wan t to in clu d e th e d ate an d even th e n am es
of th e au th ors of th e d iagram , as well.
2. Add start an d en d po in ts. Every activity d iagram h as on e start-
in g p oin t an d on e en d in g p oin t, so you m igh t as well ad d th em
righ t away. Fowler an d Scott’s (1997) style is to m ake en d in g
p oin ts op tion al. Som etim es an activity is sim p ly a d ead en d bu t,
if th is is th e case, th en th ere is n o h arm in in d icatin g th e on ly
tran sition is to an en d in g p oin t. Th is way, wh en som eon e else
read s you r d iagram , h e or sh e kn ows you h ave con sid ered h ow
to exit from th ese activities.
D EFIN ITION S
Act ivit y d ia gra m . A UML diagram used to model high-level business
processes or the transitions between states of a class (in this respect, activity dia-
grams are effectively specializations of state chart diagrams).
Da t a -flow d ia gra m (DFD). A diagram that shows the movement of data
within a system among processes, entities, and data stores. Data-flow diagrams,
also called process diagrams, were a primary artifact of structured/procedural
modeling.
Flow cha rt . A diagram depicting the logic flow of a single process or method.
Flow charts were a primary artifact of structured/procedural modeling.
St a t e cha rt d ia gra m . A UML diagram that describes the states an object may
be in, as well as the transitions between states. Formerly referred to as a “ state
diagram” or “ state-transition diagram.”
3. Add activ ities. If you are m od elin g a u se case, in trod u ce an

activity for each m ajor step in itiated by an actor (th is activity
wou ld in clu d e th e in itial step , p lu s an y step s d escribin g th e
resp on se of th e system to th e in itial step ). If you are m od elin g a
h igh -level bu sin ess p rocess, in trod u ce an activity for each m ajor
p rocess, often a u se case or a p ackage of u se cases. Fin ally, if you
are m od elin g a m eth od , th en it is com m on to h ave an activity
for th is step in th e cod e.
4. Add tran sitio n s fro m th e activ ities. My style is always to exit
from an activity, even if it is sim p ly to an en d in g p oin t. W h en -
ever th ere is m ore th an on e tran sition ou t of an activity, you
m u st label each tran sition ap p rop riately.
5. Add decisio n po in ts. Som etim es th e logic of wh at you are m od -
elin g calls for a d ecision to be m ad e. Perh ap s som eth in g n eed s to
be in sp ected or com p ared to som eth in g else. Im p ortan t to n ote
is th at th e u se of d ecision p oin ts is op tion al. For exam p le, in Fig-
u re 6 -22, I cou ld ju st as easily h ave m od eled th e accep ted an d
rejected tran sition s straigh t ou t of th e “En roll in Un iversity”
activity.
6. Iden tify o ppo rtun ities fo r parallel activ ities. Two activities
can occu r in p arallel wh en n o d irect relation sh ip exists between
th em an d th ey m u st both occu r before a th ird activity can . For
exam p le, in Figu re 6 -22, you see it is p ossible to atten d th e
overview or en roll in sem in ars in eith er ord er; it is ju st th at both
activities m u st occu r before you can en d th e overall p rocess.
TIP Every activity has at least one entry transition—otherwise, you would never
perform the activity, and at least one exit transition—otherwise you would
Act ivit ies Ha ve never stop performing it. For each activity, I always ask myself: From where
Ent ry a nd Exit could I get into this and where can I go from here? By asking this question, it
Tra nsit ions enables you to model the pertinent logic thoroughly.
6.4.2 How t o Docum ent Act ivit y Dia gra m s

Activity d iagram s are u su ally d ocu m en ted with a brief d escrip tion of th e
activity an d an in d ication of an y action s taken d u rin g a p rocess. Often ,
th is is sim p ly a referen ce to on e or m ore u se cases or m eth od s. Also, for
com p lex activities, it is com m on to d ocu m en t it u sin g an activity d ia-
gram . In m an y ways, activity d iagram s are sim p ly a variation of th e UML
state ch art d iagram s, d escribed in Ch ap ter 7.
6.5 User In terfa ce Prototypin g

User in terface p rototyp in g is an iterative an alysis tech n iq u e in wh ich
u sers are actively in volved in th e m ockin g-u p of th e UI for a system . UI
p rototyp in g h as two p u rp oses: First, it is an an alysis tech n iq u e becau se it
en ables you to exp lore th e p roblem sp ace you r system ad d resses. Secon d ,
UI p rototyp in g en ables you to exp lore th e solu tion sp ace of you r system ,
at least from th e p oin t-of-view of its u sers, an d p rovid es a veh icle for you
to com m u n icate th e p ossible UI d esign (s) of you r system . In th is ch ap ter,
I d iscu ss th e fu n d am en tals of UI p rototyp in g an d , in Ch ap ter 7, I p resen t
a collection of tip s an d tech n iq u es for d esign in g effective u ser in terfaces
for object-orien ted software.
As you see in th e activity d iagram d ep icted in Figu re 6 -23, fou r h igh -
level step s are in th e UI p rototyp in g p rocess:
• Determ in e th e n eed s of you r u sers

• Bu ild th e p rototyp e
• Evalu ate th e p rototyp e
• Determ in e if you are fin ish ed
6.5.1 Det erm ining t he Need s of Your Users

User in terface m odelin g m oves from requirem en ts defin ition in to an alysis
at th e poin t you decide to evolve all or part of your essen tial user in terface
Figure 6-23.
The iterative steps
of prototyping
Determine Needs
Build Prototype
Evaluate Prototype
[continue]
[finished]
prototype, described in detail in Ch apter 3, in to a tradition al UI prototype. You begin by

Th is im plies th at you con vert your h an ddrawin gs, flip-ch art paper, an d choosing t he
sticky n otes in to som eth in g a little m ore substan tial. You begin th is process user int erfa ce
p la t form .
by m akin g platform decision s. For exam ple, do you in ten d to deploy your
system so it run s in an In tern et browser, as an application with a Win dows-
based graph ical user in terface (GUI), as a cross-platform Java application , or
as a m ain fram e-based set of “green screen s”? Differen t platform s lead to dif-
feren t prototypin g tools, for a browser-based application , you n eed to use
an HTML-developm en t tool, wh ereas a Java-based application would
require a Java developm en t tool an d a differen t approach to th e user in ter-
face design . User in terface design is discussed in Ch apter 7.
As you iterate th rou gh UI p rototyp in g, you d iscover you n eed to You d iscover t he
u p d ate you r d efin ed req u irem en ts, in clu d in g you r u se case m od el (Sec- need t o up d a t e
tion 6.1) an d you r essen tial u ser in terface p rototyp e (Ch ap ter 3). You are ot her m od els a s
your UI p rot ot yp e
also likely to d iscover th at in form ation is m issin g from you r d om ain
evolves.
m od el, a Class Resp on sibility Collaborator (CRC) m od el (Ch ap ter 3), as
well as from you r con cep tu al m od el, a UML class m od el (Section 6.3).
Th ese m od els sh ou ld be u p d ated , as is ap p rop riate, as you p roceed with
UI p rototyp in g. Rem em ber, object-orien ted software d evelop m en t is an
iterative p rocess, so th is is n orm al.
TIP Although UI prototyping is an important part of analysis and design, it’s not
sufficient by itself. UI prototypes depict what will be built, but are unable to
User Int erfa ce communicate adequately how they will be used (that is what use case models
Prot ot yp ing Is are good for). Furthermore, UI prototypes don’t provide much indication as to
Not a Subst it ut e the details of the business logic behind the screens, which is what sequence and
for Ana lysis a nd activity diagrams are good at. And they aren’t good at depicting the static
Design structure of your software, which is where class models excel.
6.5.2 Build ing t he Prot ot yp e

Usin g a prototypin g tool or h igh -level lan guage, you develop th e screen s,
pages, an d reports n eeded by your users. Th e best advice durin g th is stage of
th e process is n ot to in vest a lot of tim e in m akin g th e code “good” because
ch an ces are h igh you will scrap large portion s of your prototype code wh en
portion s or all of your prototype fail th e evaluation . With th e user in terface
platform selected, you can begin con vertin g in dividual aspects of your
essen tial UI prototype in to your tradition al UI prototype. For exam ple, with
a browser-based platform , your m ajor UI elem en ts becom e HTML pages
wh ereas, with a Win dows-based platform , th ey would becom e win dows or
dialog boxes. Min or UI elem en ts would becom e button s, list boxes, custom
list boxes, radio button s, an d so on as appropriate.
6.5.3 Eva lua t ing t he Prot ot yp e

After a version of th e UI p rototyp e is bu ilt, it n eed s to be evalu ated by
you r SMEs to verify th at it m eets th eir n eed s. I’ve always fou n d I n eed to
ad d ress th ree basic q u estion s d u rin g an evalu ation :
• W h at is good abou t th e UI p rototyp e?

• W h at is bad abou t th e UI p rototyp e?
• W h at is m issin g from th e UI p rototyp e?
6.5.4 Det erm ining If You Are Finished

After evalu atin g th e p rototyp e, you m ay fin d you n eed to scrap p arts of
it, m od ify p arts, an d even ad d bran d -n ew p arts. You wan t to stop th e UI
p rototyp in g p rocess wh en you fin d th at th e evalu ation p rocess is n o
lon ger gen eratin g an y n ew id eas or it is gen eratin g a sm all n u m ber of
n ot-so-im p ortan t id eas. Oth erwise, back to step on e.
6.5.5 Good Things t o Und erst a nd About Prot ot yp ing

Con stan tin e an d Lockwood (1999) p rovide valu able in sigh t in to th e
p rocess of u ser in terface p rototyp in g. First, you can n ot m ake everyth in g
sim p le. Som etim es you r software will be difficu lt to u se becau se th e p rob-
lem it addresses is in h eren tly difficu lt. You r goal is to m ake you r u ser
in terface as easy as p ossible to u se, n ot sim p listic. Secon d, th ey differen ti-
ate between th e con cep ts of W YSIW YG, “W h at You See Is W h at You Get,”
an d W YSIW YN, “W h at You See Is W h at You Need.” Th eir p oin t is th at a
good u ser in terface fu lfills th e n eeds of th e p eop le wh o work with it. It
isn ’t loaded with a lot of in terestin g bu t u n n ecessary, featu res. Th ird, con -
sisten cy is im p ortan t in you r u ser in terface. In con sisten t u ser in terfaces
lead to less u sable software, m ore p rogram m in g, an d greater su p p ort an d
train in g costs. Fou rth , sm all details can m ake or break you r u ser in terface.
Have you ever u sed som e software, an d th en discarded it for th e p rodu ct
of a com p etitor becau se you didn ’t like th e way it p rin ts, saves files, or
som e oth er featu re you sim p ly fou n d too an n oyin g to u se? I h ave.
Alth ou gh th e rest of th e software m ay h ave been great, th at ven dor lost
m y bu sin ess becau se a p ortion of its p rodu ct’s u ser in terface was deficien t.
6.5.6 Prot ot yp ing Tip s a nd Techniq ues

I h ave fou n d th e followin g tip s an d tech n iq u es h ave worked well for m e
in th e p ast wh ile UI p rototyp in g:
1. Wo rk w ith th e real users. Th e best p eop le to get in volved in

p rototyp in g are th e on es wh o will actu ally u se th e ap p lication
wh en it is d on e. Th ese are th e p eop le wh o h ave th e m ost to gain
from a su ccessfu l im p lem en tation , an d th ese are th e p eop le wh o
kn ow th eir own n eed s best.
2. Use a pro to typin g to o l. In vest th e m on ey in a p rototyp in g tool
th at en ables you to p u t screen s togeth er q u ickly. Becau se you
p robably won ’t wan t to keep th e p rototyp e cod e you write —
cod e written q u ickly is rarely worth keep in g —you sh ou ld n ’t be
too con cern ed if you r p rototyp in g tool gen erates a d ifferen t typ e
of cod e th an wh at you in ten d to d evelop in .
3. Get yo ur SMEs to w o rk w ith th e pro to type. Ju st as you wan t to
take a car for a test drive before you bu y it, you r u sers sh ou ld be
D EFIN ITION S
W YSIW YG. What You See Is What You Get.
W YSIW YN. What You See Is What You Need.
able to take an ap p lication for a test drive before it is develop ed.

Fu rth erm ore, by workin g with th e p rototyp e h an ds-on , th ey can
q u ickly determ in e wh eth er th e system m eets th eir n eeds. A good
ap p roach is to ask th em to work th rou gh som e u se case scen arios
u sin g th e p rototyp e as if it were th e real system .
4. Un derstan d th e un derlyin g busin ess. You n eed to un derstan d
th e un derlyin g busin ess before you can develop a prototype th at
supports it. In oth er words, you n eed to base your UI prototype on
your requirem en ts. Th e m ore you kn ow about th e busin ess, th e
m ore likely it is you can build a prototype th at supports it.
5. Do n ’t spen d a lo t o f tim e m akin g th e co de go o d. At th e begin -
n in g of th e p rototyp in g p rocess, you will th row away a lot of
you r work as you learn m ore abou t th e bu sin ess. Th erefore, it
d oesn ’t m ake sen se to in vest a lot of effort in cod e you p robably
aren ’t goin g to keep an yway.
6. On ly pro to type features th at yo u can actually build. Ch rist-
m as wish lists are for kid s. If you can n ot p ossibly d eliver th e
fu n ction ality, d on ’t p rototyp e it.
7. Get an in terface ex pert to h elp yo u design it. User in terface
exp erts u n d erstan d h ow to d evelop easy-to-u se in terfaces,
wh ereas you p robably d on ’t. A gen eral ru le of th u m b is, if you ’ve
n ever taken a cou rse in h u m an factors, you p robably sh ou ld n ’t
be lead in g a UI p rototyp in g effort.
8. Ex plain w h at a prototype is. Th e biggest com plain t developers
h ave about UI prototypin g is th eir users say “Th at’s great. In stall it
th is aftern oon .” Basically, th is h appen s because users don ’t realize
a few m on th s of work are left to do on th e system . Th e reason th is
h appen s is sim ple: From your user’s poin t-of-view, a fully fun c-
tion al application is a bun ch of screen s an d reports tied togeth er
by a m en u. Un fortun ately, th is is exactly wh at a prototype looks
like. To avoid th is problem , poin t out th at your prototype is like a
Styrofoam m odel th at arch itects build to describe th e design of a
h ouse. Nobody would expect to live in a Styrofoam m odel, so wh y
would an yon e expect to use a system prototype to get a job don e?
9. Avo id im plem en tatio n decisio n s as lo n g as po ssible. Be care-
fu l abou t h ow you n am e u ser in terface item s. Strive to keep th e
n am es gen eric, so you d on ’t im p ly too m u ch abou t th e im p le-
m en tation tech n ology. For exam p le, in Figu re 6 -2, I u sed th e
n am e “UI23 Secu rity Login Screen ,” wh ich im p lies I in ten d to
u se GUI tech n ology to im p lem en t th is m ajor UI item . Had I
n am ed it “UI23 Secu rity Login ,” I wou ld n ’t h ave im p lied an

im p lem en tation tech n ology.
6.6 Evolvin g You r Su pplem en ta ry Specifica tion

Durin g an alysis, you will evolve your un derstan din g of th e con ten ts of your You will a p p ly
supplem en tary specification . Th is in cludes flesh in g out th e con strain ts, busi- t he inform a t ion
n ess rules, an d n on fun ction al requirem en ts you iden tified durin g th e require- cont a ined in your
sup p lem ent a ry
m en ts defin ition . As you evolve your oth er m odels, such as your activity
sp ecifica t ion in
diagram s an d your con ceptual class m odel, you are likely to discover th at th e your ot her m od els.
in form ation con tain ed in your supplem en tary specification is n ot as detailed
as it sh ould be an d, th erefore, n eeds to be worked on m ore. Also, you will
apply th e in form ation con tain ed in your supplem en tary specification with in
your m odels, eith er on your diagram s usin g th e UML’s Object Con strain t Lan -
guage (OCL) or as referen ces with in th e m odel docum en tation .
6.6.1 The Object Const ra int La ngua ge

OCL (Warn er an d Kleppe, 1999) is a form al lan guage, sim ilar to structured OCL is used t o
En glish , used to express side-effect-free con strain ts with in Un ified Modelin g d ep ict const ra int s,
p recond it ions,
Lan guage m odels. OCL can appear on an y UML diagram or in th e support-
p ost cond it ions,
in g docum en tation describin g a diagram . OCL can be used for a wide variety
a nd inva ria nt s
of purposes, in cludin g specifyin g th e in varian ts of classes, precon dition s an d wit hin your UML
postcon dition s on operation s, an d con strain ts on operation s. Th e reality is m od els.
th at a graph ical m odel, such as a UML class diagram , isn ’t sufficien t for a pre-
cise an d un am biguous specification . You m ust describe addition al con -
strain ts about th e objects in th e m odel, con strain ts th at are defin ed in your
supplem en tary specification . OCL can be used to m odel actual con strain ts,
described in your supplem en tary specification , as well as busin ess rules an d
fun ction al requirem en ts. Alth ough th is in form ation is described in your sup-
plem en tary specification usin g n atural lan guage your users un derstan d,
experien ce sh ows th at n atural lan guage often results in am biguities th at, in
turn , lead to defects in your software. Hen ce, th e n eed for OCL.
OCL statem en ts are depicted on UML diagram s in th e form at “{con -
strain t description },” wh ere th e con strain t description m ay be in an y for-
m at, in cludin g predicate calculus. Fowler an d Scott (1997) suggest you
focus on readability an d un derstan dability an d, th erefore, suggest usin g an
in form al description . For exam ple, in Figure 6-11, I m odeled th e con strain t
“{ordered FIFO}” on th e association between “Sem in ar” an d “Studen t”
an d, in Figure 6-16, I m odeled th e “{NAND}” con strain t between two asso-
ciation roles. Th e basic idea is th at studen ts are put on th e waitin g list on a
first-com e, first-served basis—in oth er words, th e studen ts are put on th e
waitin g list in order. UML con strain t statem en ts are used to m odel com -
plex an d/or im portan t in form ation accurately in your UML diagram s. An

im portan t aspect of OCL is it is a m odelin g lan guage, n ot a program m in g
lan guage. You will use a lan guage such as OCL to docum en t your object
design , an d a lan guage such as Java or C++ to im plem en t it.
6.7 Applyin g An a lysis Pa ttern s Effectively

An alysis p attern s (Fowler, 1997; Am bler, 1998a) d escribe solu tion s to
com m on p roblem s fou n d in th e an alysis/ bu sin ess d om ain of a system .
An alysis p attern s are typ ically m ore sp ecific th an d esign p attern s,
d escribed in Ch ap ter 7, becau se th ey d escribe a solu tion for a p ortion of a
bu sin ess d om ain . Th is d oesn ’t m ean an an alysis p attern is ap p licable
on ly to a sin gle lin e of bu sin ess, alth ou gh it cou ld be. In th is section , I
overview two an alysis p attern s I h ave u sed in variou s bu sin ess d om ain s,
p attern s I believe you will fin d u sefu l wh en you are m od elin g.
6.7.1 The Business Ent it y Ana lysis Pa t t ern

The Business Every organ ization h as to d eal eith er with oth er organ ization s or p eop le,
Ent it y a na lysis u su ally both . As a resu lt, you n eed to keep track of th em . Th e solu tion
p a t t ern d escribes for th e Bu sin ess En tity an alysis p attern (Am bler, 1998a), sim ilar to
t he d ifferent t yp es
Fowler’s (1997) Party p attern , is p resen ted in Figu re 6 -24. Th is p attern is a
of p eop le a nd
orga niza t ions
sp ecialization of Peter Coad ’s Roles Played p attern (Coad , 1992; Am bler,
wit h whom you 1998a) to m od el th e d ifferen t typ es of organ ization s an d p eop le with
int era ct . wh om you r com p an y in teracts.
Figure 6-24.
The Business Entity
analysis pattern
EntityRole
BusinessEntity 1 1..* start
end
Person Organization CustomerRole SupplierRole EmployeeRole

name 0..1 customerID employeeID
salutation
placeOrder()
firstName hire()
middleInitial 0..*
promote()
surname demote()
transfer()
fire()
endEmployment()
D EFIN ITION S
Inva ria nt . A set of assertions about an instance or class that must be true at all
“ stable” times, where a stable time is the period before a method is invoked on
the object/class and immediately after a method is invoked.
Object Const ra int La ngua ge (OCL). A formal language, similar to struc-
tured English, to express side-effect-free constraints within UML models.
Th e basic id ea of th is p attern is to sep arate th e con cep t of a bu sin ess

en tity, su ch as a p erson or com p an y, from th e roles it fu lfills. For exam -
p le, Ton y Stark m ay be a cu stom er of you r organ ization , as well as an
em p loyee. Fu rth erm ore, on e d ay h e m ay also sell services to you r com -
p an y, also m akin g h im a su p p lier. Th e p erson d oesn ’t ch an ge, bu t th e
role(s) h e h as with you r organ ization d oes, so you n eed to fin d a way to
m od el th is, wh ich is wh at th is p attern d oes. Each bu sin ess en tity h as on e
or m ore roles with you r organ ization an d each role h as a ran ge d u rin g
wh ich it was ap p licable (th e “start” an d “en d ” attribu tes). Each role
im p lem en ts th e beh avior sp ecific to it, su ch as p lacin g an ord er with a
su p p lier or th e h irin g an d p rom otion of an em p loyee.
Note th at th e u se of aggregation between “”Bu sin essEn tity” an d “En ti-
tyRole” is q u estion able at best. Is a role really p art of a bu sin ess en tity?
Th is sou n d s like a p h ilosop h ical q u estion th at likely won ’t h ave a d efin i-
tive an swer. However, th e Roles Played p attern , on wh ich th is is based ,
u ses aggregation , so I d ecid ed to stay con sisten t with th e sou rce.
6.7.2 The Cont a ct Point Ana lysis Pa t t ern

Th e Con tact Poin t an alysis p attern (Am bler, 1998a), th e solu tion for The Cont a ct Point
wh ich is d ep icted in Figu re 6 -25, d escribes an ap p roach for keep in g track a na lysis p a t t ern
of th e variou s m ean s by wh ich you in teract with bu sin ess en tities. You r d escribes a n
a p p roa ch for
organ ization m ost likely sen d s in form ation an d bills to, as well as sh ip s
keep ing t ra ck of
p rod u cts to, th e su rface ad d resses of you r cu stom ers. Perh ap s it em ails t he wa y your
in form ation to cu stom ers an d em p loyees, or faxes in form ation to th em . orga niza t ion
It also p robably n eed s to keep track of th e con tact p h on e n u m ber for int era ct s wit h
an yon e with wh om it in teracts. Th e Con tact Poin t p attern m od els an business ent it ies.
ap p roach to su p p ortin g th is fu n ction ality.
Th e basic id ea beh in d th is p attern is th at su rface ad d resses, em ail
ad d resses, an d p h on e n u m bers are really th e sam e sort of th in g —a
m ean s by wh ich you can con tact oth er bu sin ess en tities. Su bclasses of
“Con tactPoin t” n eed to be able to d o at least two tasks: Th ey n eed to
kn ow h ow th in gs/ in form ation can be sen t to th em an d th ey n eed to
kn ow h ow to ou tp u t th eir “label in form ation .” You can sen d faxes to
TIP The real value of analysis patterns is the thinking behind them. A
pattern might not be the total solution to your problem, but it
How t o Use Ana lysis might provide enough insight to help save you several hours or
Pa t t erns Effect ively days during development. Consider analysis patterns as a good start
at solutions.
p h on e n u m bers, em ail to electron ic ad d resses, an d letters an d p ackages

to su rface ad d resses. You also n eed to be able to p rin t con tact p oin t in for-
m ation on labels, letterh ead , an d rep orts. To d o so, con tact p oin ts collab-
orate with in stan ces of “Con tactPoin tTyp e” for d escrip tor in form ation .
For exam p le, you wan t to ou tp u t “Fax: (416) 555-1212,” n ot ju st “(416)
555-1212.” Fu rth erm ore, th e “Ph on e” class sh ou ld h ave th e cap ability to
be au tom atically d ialed . Th e d ifferen t varieties of con tact p oin t typ es
wou ld in clu d e d etails su ch as voice p h on e lin e, fax p h on e lin e, work
ad d ress, h om e ad d ress, billin g ad d ress, an d p erson al em ail ID.
You ca n use I ap p lied th e Item -Item Descrip tion p attern (Coad , 1992; Am bler,
p a t t erns t oget her 1998a) wh en m od elin g th e “Con tactPoin t” an d “Con tactPoin tTyp e”
t o solve d ifficult classes. Th is d em on strates an im p ortan t p rin cip le of object-orien ted p at-
p roblem s.
tern s—th ey can be u sed in com bin ation to solve larger p roblem s.
6.7.3 The Ad va nt a ges a nd Disa d va nt a ges of Pa t t erns

Several ad van tages an d d isad van tages exist to workin g with object-
orien ted p attern s. Th ey are d iscu ssed in th e followin g section s.
6.7.3.1 The Potential Advantages of Patterns
1. Pattern s in crease develo per pro ductiv ity. By d ocu m en tin g

solu tion s to com m on p roblem s, p attern s p rom ote reu se of d evel-
op m en t efforts. In creased reu se with in you r organ ization
im p roves you r p rod u ctivity.
2. Pattern s describe pro ven so lutio n s to co m m o n pro blem s. Pat-
tern s are “born ” wh en d evelop ers recogn ize th ey are ap p lyin g
th e sam e solu tion to a com m on p roblem over an d over again . I
d evelop ed th e Con tact Poin t an alysis p attern after im p lem en tin g
sim ilar solu tion s for a variety of com p u ter system s.
3. Pattern s in crease th e co n sisten cy betw een applicatio n s. By
u sin g th e sam e p attern s over an d over again , you in crease th e
con sisten cy between ap p lication s, m akin g th em easier to u n d er-
stan d an d m ain tain . W h en you r ap p lication s are d evelop ed in a
ContactPointType
ContactPoint
1 contacted through 1..* 0..* describes 1..* name
BusinessEntity
{ordered} sendTo() description
asLabel()
Phone
ShippingAddress 0..*
number
call()
sendTo()
asLabel()
ElectronicAddress SurfaceAddress
email street 1 Country
city 0..* name
sendTo() state phoneCode
asLabel() postalCode
sendTo()
asLabel()
Figure 6-25.
con sisten t m an n er, it’s th at m u ch easier to d o tech n ical walk- The Contact Point
th rou gh s th at en able you to im p rove th e q u ality of you r d evel- analysis pattern
op m en t efforts.
4. Pattern s are po ten tially better th an reusable co de. Peop le can
talk abou t reu sable cod e all th ey wan t, bu t th e d ifferen ces
between system p latform s m akes th is d ream d ifficu lt at best.
However, p attern s su p p ort th e reu se of oth er p eop le’s ap p roach es
to solvin g p roblem s (Am bler, 1998b; Am bler, 1999) an d , th ere-
fore, can be ap p lied in a wid e ran ge of en viron m en ts becau se
th ey are n ot en viron m en t-sp ecific.
5. More an d m ore pattern s are bein g developed every day. A lot of
excitin g work is goin g on in pattern s, with n ew pattern s bein g
in troduced every day. Th is en ables you to take advan tage of th e
developm en t efforts of th ousan ds of people, often for th e m ere cost
of a book, m agazin e, or teleph on e call to lin k you to th e In tern et.
I maintain a Web page, http:/ / www.ambysoft.com/ processPatternsPage.html, TIP

that provides links and references to printed literature pertaining to patterns
and the software process. From this page, I link to the major patterns sites Visit t he Process
online, including sites specializing in analysis patterns. Pa t t erns
Resource Pa ge
6.7.3.2 The Potential Disadvantages of Patterns
1. Yo u n eed to learn a large n um ber o f pattern s. Alth ou gh th ere’s

an ad van tage to h avin g access to a large n u m ber of p attern s, th e
d isad van tage is you h ave to learn a large n u m ber of th em , or at
least kn ow th ey exist. Th is can be a lot of work.
2. Th e NIH (n ot-in ven ted-h ere) syn drom e can get in th e w ay.
Man y developers are un willin g to accept th e work of oth ers: If th ey
didn ’t create it, th en it isn ’t an y good. In addition , if a pattern is
n ot exactly wh at th ey n eed, th en th ey m igh t n ot be willin g to use
it. Wh en ever I run in to th is attitude, I always like to poin t out th e
versatility an d widespread acceptan ce of pattern s with in th e object
com m un ity an d discuss several com m on pattern s such as Sin gleton
(Gam m a et al., 1995) an d Item -Item Description (Coad, 1992).
3. Pattern s are n o t co de. Hard -core tech ies are often u n willin g to
accep t an yth in g as reu sable excep t cod e. For som e reason , th ey
fin d it h ard to accep t th at you can reu se id eas as well as sou rce
cod e.
4. “Pattern ” is quickly beco m in g a buzzw o rd. As m ore p eop le
realize th e valu e of p attern s, m ore m arketin g p eop le are begin -
n in g to exp loit it to in crease th e sales of wh atever p rod u ct or
service th ey are p u sh in g. Ju st as in th e m id -1990s we saw th e
term “object-orien ted ” u sed as an ad jective to d escribe p rod u cts
th at h ad alm ost n oth in g to d o with objects, I su sp ect we’ll see
th e sam e sort of th in g h ap p en with th e term “p attern .”
6.8 User Docu m en ta tion

User d ocum enta tion Mayh ew (1992) believes th e u ser d ocu m en tation is p art of th e u ser in ter-
is required for m ost face for an ap p lication an d th at well-written u ser d ocu m en tation is n o
m od ern system s. excu se for a p oorly d esign ed u ser in terface. My exp erien ce con firm s th ese
beliefs—becau se m od ern system s are com p lex, you r u sers often req u ire
sign ifican t d ocu m en tation th at d escribes h ow to u se th em effectively.
Becau se d ifferen t typ es of u sers h ave d ifferen t n eed s, you also d iscover
you n eed to d evelop several kin d s of u ser d ocu m en tation . Don ’t worry,
it’s n ot as h ard as it sou n d s, p articu larly if you h ave d evelop ed th e m od -
els th is book recom m en d s.
6.8.1 Typ es of User Docum ent a t ion

Weiss (1991) p oin ts ou t th e n eed for differen t kin ds of m an u als to su p p ort
th e n eeds of differen t typ es of u sers. Th e lesson to be learn ed is th at on e
m an u al does n ot fit all. He su ggests a tu torial m an u al for n ovice u sers, a The user
u ser m an u al for in term ediate u sers, an d a referen ce m an u al for exp ert d ocum ent a t ion
for your application
u sers. Tou rn iaire an d Farrell (1997) also recom m en d th at you develop a
includ es a t ut oria l
su p p ort u ser’s gu ide describin g th e su p p ort services p rovided to you r u ser
m anual, a reference
com m u n ity, a docu m en t th at is typ ically less th an a p age in len gth . m a nua l, a user
W h en ap p rop riate, you r u ser docu m en tation sh ou ld in clu de a descrip - m a nua l, a nd a
tion of th e skills n eeded to u se you r system . For exam p le, you r u sers m ay sup p ort user’s
req u ire train in g in you r bu sin ess dom ain or in basic com p u ter skills, su ch guid e.
as u sin g a m ou se. Th is in form ation is n eeded to develop train in g p lan s for
u sers an d by su p p ort en gin eers wh en th ey are attem p tin g to determ in e
th e sou rce of a p roblem . Qu ite often , su p p ort en gin eers will receive su p -
p ort calls wh ere th e solu tion is to give th e u ser addition al train in g.
6.8.2 How t o W rit e User Docum ent a t ion

W h at were you tryin g to d o th e last tim e you looked at a u ser m an u al? Your use ca ses a nd
You were likely tryin g to d eterm in e h ow to accom p lish a task, a task th at a ct ivit y d ia gra m s
p robably wou ld be d escribed via a u se case or activity d iagram in you r d rive t he
d evelop m ent of
an alysis m od el. My exp erien ce is th at th e easiest way to write you r u ser
your user
d ocu m en tation is to start with th e m od els th at d escribe h ow you r u sers
d ocum ent a t ion.
work with you r system : you r u se case m od el an d you r activity d iagram s.
Use cases d escribe h ow u sers in teract with you r system an d , as you saw in
Section 6.4, UML activity d iagram s are often u sed to d escribe h igh -level
bu sin ess logic. Th is is exactly th e typ e of in form ation you r u ser d ocu -
m en tation sh ou ld reflect.
Start your user m an ual with a description of th e system itself, probably
several paragraph s, in form ation you likely h ave in your supplem en tary
specification . Th en , add a section describin g an y h igh -level busin ess
D EFIN ITION S
Reference m a nua l. A document, either paper or electronic, aimed at experts
who need quick access to information.
Sup p ort user’s guid e. A brief document, usually a single page, that describes
the support services for your application that are available to your user commu-
nity. This guide includes support phone numbers, fax numbers, and Web site
locations, as well as hours of operations and tips for obtaining the best services.
Tut oria l. A document, either paper or electronic, aimed at novice users who
need to learn the fundamentals of an application.
User m a nua l. A document, either paper or electronic, aimed at intermediate
users who understand the basics of an application, but who may not know how
to perform all applicable work tasks with the application.
processes, processes you sh ould h ave docum en ted th e logic for usin g a
UML activity diagram . For large system s, you m ay fin d you h ave a section
for each UML package with in your use case m odel or even a separate user
m an ual. Th en , for each use case, add an appropriate subsection describin g
it; th e use case text will drive th e body of th at section . You will likely wan t
to com bin e steps in to paragraph s to m ake your docum en tation m ore read-
able. Wh erever you referen ce a UI elem en t, you m ay decide to in clude a
relevan t picture of th at portion of your user in terface (m y suggestion is to
wait un til you h ave baselin ed your user in terface design before in vestin g
th e tim e to gen erate th e pictures). You m ay also decide to replace refer-
en ces to busin ess rules with th eir description s to h elp in crease your user’s
un derstan din g of h ow th e system actually works. Alth ough m an y in th e
in dustry call th is a use case driven approach to writin g user docum en ta-
tion , it really is a m odel-driven approach because your use cases sim ply
aren ’t sufficien t for th is purpose.
Your use ca ses, Tu torials are d evelop ed in a sim ilar m an n er to u ser m an u als, alth ou gh
a ct ivit y d ia gra m s, a few d ifferen ces exist. First, tu torials focu s on th e m ost critical u ses of
a nd UI p rot ot yp e th e system , wh ereas a u ser m an u al sh ou ld focu s on th e en tire system .
d rive t he d evelop -
Secon d , tu torials sh ou ld h ave a m ore exp licit focu s on learn in g a p rod -
m ent of your user
m a nua l a nd
u ct, so th ey’ll in clu d e m ore d etailed u se in stru ction s th an a u ser m an u al
t ut oria l. m igh t. Th e assu m p tion is th at an yon e u sin g a tu torial likely kn ows little
abou t th e system an d , th erefore, n eed s m ore h elp , wh ereas som eon e
u sin g a u ser m an u al is p robably fam iliar with th e system itself, bu t n eed s
h elp with a sp ecific asp ect of it.
Your user int erfa ce You r referen ce m an u al, becau se it h as a sligh tly d ifferen t p u rp ose, is
m od el oft en d rives gen erally d riven by you r u ser in terface m od el, in stead of you r u se cases
t he d evelop m ent of an d activity d iagram s. I gen erally in clu d e an overview of th e system , sec-
your reference
tion s for each m ajor p ortion of you r system , an d su bsection s d escribin g
m a nua l.
th e m ajor u ser in terface elem en ts. Th e su bsection s sh ou ld d escribe th e
p u rp ose of th e relevan t screen / rep ort/ p age an d h ow to work with it.
You will often h ear advice with in th e software in dustry to write your
docum en tation before you write you code. Alth ough th is is a reason ably
TIP Writing is hard and writing good user documentation is even harder. It takes a
lot of effort and significant skill to do well, the type of skill technical writers
Hire a Technica l have. If possible, hire a technical writer to work with you to produce your user
W rit er documentation. This will improve the quality of your documentation and,
hence, the quality of your overall user interface, Hiring a technical writer will
also free you to focus on other development activities, such as modeling,
coding, and testing.
good practice, wh y do people give th is advice? I believe th e m otivation is Mod el before you
th at writin g user docum en tation first forces you to th in k about h ow your writ e your user
d ocum ent a t ion
system will be used before you start to build it. My advice is differen t:
a nd source cod e.
in vest th e tim e to un derstan d your system by developin g requirem en ts for
it, an alyzin g it, an d design in g it, an d th en let th is un derstan din g drive th e
developm en t of your source code an d your user docum en tation . I h ave
worked on several system s wh ere we developed th e user docum en tation in
parallel with th e source code, n ot before it, an d it worked out well.
6.9 Org a n izin g You r Models w ith Pa cka g es

Packages are UML con stru cts th at en able you to organ ize m od el elem en ts
in to grou p s, m akin g you r UML d iagram s sim p ler an d easier to u n d er-
stan d . Packages are d ep icted as file fold ers an d can be u sed on an y of th e
UML d iagram s, alth ou gh th ey are m ost com m on on u se case d iagram s
an d class d iagram s becau se th ese m od els h ave a ten d en cy to grow. I u se
p ackages on ly wh en m y d iagram s becom e u n wield y, wh ich gen erally
im p lies th ey can n ot be p rin ted on a sin gle p age, to organ ize a large d ia-
gram in to sm aller on es. A good ru le of th u m b is th at a d iagram sh ou ld
h ave 7 +/ – 2 bu bbles on it, a bu bble bein g a u se case or class.
So h ow d o you id en tify p ackages on u se case d iagram s? I like to start
with u se cases th at are related to on e an oth er via exten d an d in clu d e
association s, m y ru le of th u m b bein g th at in clu d ed an d exten d ed u se
cases belon g in th e sam e p ackage as th e base/ p aren t u se case. Th is h eu ris-
tic works well becau se th ese u se cases typ ically were in trod u ced by
“p u llin g ou t” th eir logic from th e base/ p aren t u se case to start. I th en
an alyze th e u se cases with wh ich m y m ain actors are in volved . W h at you
fin d is each actor will in teract with you r system to fu lfill a few m ain
goals; for exam p le, stu d en ts in teract with you r system to en roll in th e
u n iversity, m an age th eir sch ed u les, an d m an age th eir fin an cial obliga-
tion s with th e u n iversity. Th is su ggests th e n eed for an “En rollm en t”
p ackage, a “Stu d en t Sch ed u le Man agem en t” p ackage, an d a “Stu d en t
Fin an cial Man agem en t” p ackage.
Anything you put into a package should make sense when considered with the TIP
rest of the contents of the package. To determine whether a package is
cohesive, a good rule of thumb is you should be able to give your package a Pa cka ges
short, descriptive name. If you can’t, then you may have put several unrelated Should Be
things into the package. Cohesive
With resp ect to class d iagram s, I take a sim ilar ap p roach an d , on ce

again , I ap p ly several ru les of th u m b. First, classes in th e sam e in h eri-
tan ce h ierarch y typ ically belon g in th e sam e p ackage. Secon d , classes
related to on e an oth er via aggregation or com p osition often belon g in
th e sam e p ackage. Th ird , classes th at collaborate with each oth er a lot —
in form ation reflected by you r seq u en ce d iagram s an d collaboration d ia-
gram s (Ch ap ter 7)—often belon g in th e sam e p ackage. Fou rth , th e d esire
to m ake you r p ackages coh esive will often d rive you r oth er d ecision s to
p u t a class in to a p ackage.
6.10 Wh a t You Ha ve Lea rn ed

Th is ch ap ter in trod u ced you to th e m ain artifacts of object-orien ted
an alysis (OOA) an d th eir in terrelation sh ip s, as d ep icted in Figu re 6 -1.
You learn ed th at th e p u rp ose of an alysis is to u n d erstan d wh at will be
bu ilt, as op p osed to th e p u rp ose of req u irem en ts gath erin g (Ch ap ter 3),
wh ich is to d eterm in e wh at you r u sers wou ld like to h ave bu ilt. Th e m ain
d ifferen ce is th at th e focu s of req u irem en ts gath erin g is on u n d erstan d -
in g you r u sers an d th eir p oten tial u se of th e system , wh ereas th e focu s of
an alysis sh ifts to u n d erstan d in g th e system itself.
In th is ch ap ter you saw h ow to ap p ly th e key object-orien ted an alysis
tech n iq u es: system u se case m odelin g, seq u en ce diagram m in g, class m od-
elin g, activity diagram m in g, an d u ser in terface p rototyp in g. In Ch ap ter 7,
you see h ow you r an alysis efforts bridge th e gap between req u irem en ts
an d system design .
6.11 Review Qu estion s
1. Develop system u se cases for th e u se case d iagram of Figu re 3-10. Use

th e essen tial u se cases you d evelop ed for Qu estion 1 in Ch ap ter 3 as
you r startin g p oin t.
2. Rework th e class d iagram s of Figu res 6 -15, 6 -16, an d 6 -18 to in clu d e
th e fact th at p rofessors also en roll in sem in ars exactly th e way stu -
d en ts d o. For th e p u rp ose of th is q u estion , focu s on th e association s
D EFIN ITION S
Cohesion. The degree of relatedness within an encapsulated unit (such as a
component or a class).
Pa cka ge. A UML construct that enables you to organize model elements into
groups.
between classes an d th e resu ltin g op p ortu n ities for ap p lyin g in h eri-

tan ce, if an y. Draw a n ew class d iagram th at in clu d es th e in h eritan ce
h ierarch y, assists association between “Professor” an d “Sem in ar,” an d
an y n ew association s. Ju stify an y n ew ap p lication s of in h eritan ce.
3. You r coworker h as two classes, A an d B, an d sh e kn ows som e sort of
relation sh ip exists between th em . However, wh at sh e isn ’t su re of is
wh eth er it is an association , an aggregation association , a com p osi-
tion association , or an in h eritan ce relation sh ip . Develop a UML
activity d iagram to h elp you r coworker d ecid e am on g th e d ifferen t
typ es of relation sh ip s.
4. Th e “En roll in Sem in ar” u se case, d escribed in Figu re 6 -3, states th at
wh en a stu d en t is n ot q u alified to en roll in a sem in ar, a list of th e
p rereq u isites for th at sem in ar wou ld be d isp layed . W h at ch an ges to
th e con cep tu al class d iagram d evelop ed in Section 6.3 wou ld n eed to
be m ad e to su p p ort th is featu re? W h at association (s) d id you n eed to
ad d ? W h at d o you th in k th e m u ltip licities wou ld be? W h y? Th e
role(s)? W h y? Is th ere m ore th an on e way to m od el th is? If so, wh at
are th e trad e-offs?
5. Develop a UML activity m odel describin g th e busin ess logic of th e
“En roll in Sem in ar” use case described in Figure 6-2. Be sure to in clude
th e altern ate courses described in th e figure. Are an y altern ate courses
m issin g? If so, m odel th em in your activity diagram . Is th ere an y
opportun ity for perform in g som e activities in parallel?
6. Both Figu res 6 -2 0 an d 6 -24 sh owed a sim ilar u se of com p osition . A
com p on en t is p oten tially com p osed of oth er com p on en ts an d an
organ ization is p oten tially com p osed of oth er organ ization s. Discu ss
wh y th is m ay or m ay n ot in d icate th e existen ce of a “com p osition
p attern .” Has su ch a p attern been p reviou sly id en tified ? (Do a search
of th e p attern s literatu re.)
7. Ap p ly th e Con tact Poin t an d Bu sin ess En tity an alysis p attern s to
you r class m od el for th e u n iversity. Discu ss h ow th is h as im p roved
you r m od el. Has th is d etracted from you r m od el in an y way? If so,
D EFIN ITION
Ba seline. A tested and certified version of a deliverable representing a concep-
tual milestone, which, thereafter, serves as the basis for further development
and that can be modified only through formal change control procedures. A
particular version becomes a baseline when a responsible group decides to des-
ignate it as such.
h ow? Do you n eed to verify th is ch an ge with you r SMEs? W h y or

wh y n ot?
8. Develop seq u en ce d iagram s for you r u se cases in Qu estion 1. As you
d evelop th e seq u en ce d iagram s, u p d ate you r con cep tu al class m od el
to reflect n ew op eration s or classes you id en tify. Also, u p d ate th e
logic of you r system u se cases as ap p rop riate.
9. Develop a con cep tu al class m od el for th e ban k case stu d y, d escribed
in Section 3.10.1, followin g th e ap p roach d escribed in th is ch ap ter.
First, start with you r CRC m od el, an d th en try to flesh it ou t as best
you can (d evelop seq u en ce d iagram s for th e u se cases you d evelop ed
in Ch ap ter 3). W h en you h ave d on e so, baselin e you r m od el. You
m ay d ecid e to organ ize you r m od el u sin g p ackages, as well as ap p ly
com m on an alysis p attern s.
10. Com p are an d con trast th e in form ation con ten t of you r d om ain
m od el (you r CRC m od el), an d you r con cep tu al class m od el for th e
ban k case stu d y. W h at are th e stren gth s an d weakn esses of each
m od el? W h y?
11. Com p are an d con trast th e n arrative style for writin g u se cases with
th e action -resp on se style. W h at are th e ad van tages an d d isad van -
tages of each ? W h en wou ld or wou ld n ’t you u se each ap p roach ?
12. Search th e Web for docu m en tation tem p lates for u se cases, actors, an d
u ser in terface sp ecification s. For u se case tem p lates, com p are an d con -
trast th e con ten t th ey cap tu re with wh at h as been su ggested in th is
book.
13. Search th e Web for p ap ers an d in form ation abou t object-orien ted
an alysis. Com p are an d con trast th e variou s tech n iq u es. Form u late a
reason wh y differen ces exist am on g th e variou s ap p roach es an d dis-
cu ss th e advan tages an d disadvan tages of h avin g differen t ap p roach es
available to you .

The Object Primer Second Edition The App

Uploaded by

Copyright:

Available Formats

The Object Primer Second Edition The App

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

The Object Primer Second Edition The App

Uploaded by

Copyright:

Available Formats

Th e Object Prim er

CAMBRIDGE UNIVERSITY PRESS

h ttp :/ / www.cam brid ge.org

Pu blish ed in association with SIGS Books

© Cam brid ge Un iversity Press 2 001

All righ ts reserved .

Th is book is in cop yrigh t. Su bject to statu tory excep tion an d to th e p rovision s

An y p rod u ct m en tion ed in th is book m ay be a trad em ark of its com p an y.

First ed ition p u blish ed by SIGS Books an d Mu ltim ed ia in 1995

Design by Kevin Callah an an d An d rea Cam m arata

Prin ted in th e Un ited States of Am erica

Library of Congress Cataloging in Publication data available.

ISBN 0 521 78519 7 p ap erback

Ch apter 1 • In tro ductio n 1

Ch apter 2 • Object Orien tatio n : A New So ftw are Paradigm 9

2.4 Object Stan d ard s 23

Ch apter 3 • Gath erin g User Requirem en ts 31

Ch apter 4 • En surin g Yo ur Requirem en ts Are Co rrect:

4.2.2 Creatin g Use Case Scen arios 116

Ch apter 5 • Un derstan din g Th e Basics: Object-Orien ted Co n cepts 133

5.16 Com p on en ts 176

Ch apter 6 • Determ in in g Wh at to Build: Object-Orien ted An alysis 181

Ch apter 7 • Determ in in g Ho w to Build Yo ur System :

Ch apter 8 • Object-Orien ted Testin g 347

Ch apter 9 • Object-Orien ted Testin g 403

10.4 From Waterfall/ Serial Develop m en t… 432

Ch apter 11 • Wh ere to Go Fro m Here 455

Glo ssary 475

W ha t we’re not good a t is build ing t he right syst em .

Wh a t You Will Lea rn in Th is Ch a pter

What is object orientation?

Wh y You Need to Rea d Th is Ch a pter

To understand why you should consider embracing object-oriented techniques,

Th is book d escribes th e object-orien ted (OO) p arad igm , a d evelop m en t

1.1 Th e Stru ctu red Pa ra dig m versu s th e Object-

A Structured Application An Object Application

Gather Validate Object-Oriented

Object-Oriented Object-Oriented Object-Oriented

Object-Oriented Where To Go From

Progra m m ers, Designers, a nd Project Ma na gers

Business Ana lyst s a nd User Rep resent a t ives

Ta ble 1-1. The m a t eria l cont a ined in ea ch cha p t er

3: Gathering Requirements Description of requirements gathering techniques, including

4: Validating Requirements Description of requirements validation techniques such as use

5: Object-Oriented Concepts Description of the fundamental concepts of object orienta-

6: Object-Oriented Analysis Description of common object-oriented analysis techniques

7: Object-Oriented Design Description of common object-oriented design techniques

8: Object-Oriented Programming Overview of common object-oriented programming tips and

9: Object-Oriented Testing Overview of the Full Lifecycle Object-Oriented Testing (FLOOT)

d escribes th e fu n d am en tal con cep ts of object orien tation , an d Ch ap ter 6,

1.4 Wh a t You Ha ve Lea rn ed

Your a na lysis d efines wha t will be built .

Wh a t You Will Lea rn In Th is Ch a pter

Wh y You Need to Rea d Th is Ch a pter

User Interface User Interface

Fig ure 6 -1 . Essential

6.1 System Use Ca se Modelin g

6.1.1 W rit ing Syst em Use Ca ses

Name: Enroll in Seminar Figure 6-2.