The Object Primer 2nd Edition - The Application Developer's Guide to Object Orientation and the UML

Citation preview

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 1.2 1.3 1.4

2 3 5 7

Th e Stru ctu red Parad igm versu s th e Object-Orien ted Parad igm How Is Th is Book Organ ized ? How to Read Th is Book W h at You Have Learn ed

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

2.2 2.3

Th e Poten tial Ben efits of Object Orien tation 2.1.1 In creased Reu sability 2.1.2 In creased Exten sibility 2.1.3 Im p roved Qu ality 2.1.4 Fin an cial Ben efits 2.1.5 In creased Ch an ce of Project Su ccess 2.1.6 Red u ced Main ten an ce Bu rd en 2.1.7 Red u ced Ap p lication Backlog 2.1.8 Man aged Com p lexity Th e Poten tial Drawbacks of OO Objects Are Here to Stay

ix

9 10 10 10 11 12 12 15 17 19 20 22

x

The Object Prim er

2.4 2.5 2.6 2.7

Object Stan d ard s Th e Object-Orien ted Software Process W h at You Have Learn ed Review Qu estion s

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

3.2

3.3

3.4

3.5

3.6

3.7

3.8 3.9 3.10 3.11

Pu ttin g Togeth er a Req u irem en ts Mod elin g Team 3.1.1 Ch oosin g Good Su bject-Matter Exp erts 3.1.2 Ch oosin g Good Facilitators 3.1.3 Ch oosin g Good Scribes Fu n d am en tal Req u irem en ts Gath erin g Tech n iq u es 3.2.1 In terviewin g 3.2.2 Brain storm in g Essen tial Use Case Mod elin g 3.3.1 A Picture Says 1,000 Words: Drawin g Use Case Diagram s 3.3.2 Id en tifyin g Actors 3.3.3 Docu m en tin g a Use Case 3.3.4 Use Cases: Essen tial versu s System 3.3.5 Id en tifyin g Use Cases 3.3.6 Mod elin g Differen t Logic Flows: Altern ate Cou rses of Action Essen tial User In terface Prototyp in g 3.4.1 An Exam p le Essen tial User-In terface Mod el 3.4.2 En su rin g System Usability 3.4.3 User In terface-Flow Diagram m in g Dom ain Modelin g with Class Respon sibility Collaborator (CRC) Cards 3.5.1 Prep arin g to CRC Mod el 3.5.2 Fin d in g Classes 3.5.3 Fin d in g Resp on sibilities 3.5.4 Defin in g Collaborators 3.5.5 Arran gin g th e CRC Card s 3.5.6 Th e Ad van tages an d Disad van tages of CRC Mod elin g Develop in g a Su p p lem en tary Sp ecification 3.6.1 Id en tifyin g Bu sin ess Ru les 3.6.2 Iden tifyin g Non fun ction al Requirem en ts an d Con strain ts Id en tifyin g Ch an ge Cases 3.7.1 Docu m en tin g Ch an ge Cases 3.7.2 Th e Ad van tages of Ch an ge Cases Tip s for Organ izin g a Mod elin g Room Req u irem en ts Tip s an d Tech n iq u es W h at You Have Learn ed 3.10.1 Th e ABC Ban k Case Stu d y Review Qu estion s

Ch apter 4 • En surin g Yo ur Requirem en ts Are Co rrect: Requirem en ts Validatio n Tech n iques 4.1 4.2

Testin g Early an d Often Use Case Scen ario Testin g 4.2.1 Th e Step s of th e Use Case Scen ario Testin g Process

23 23 26 28 31 34 38 39 40 40 40 42 44 45 48 50 52 56 61 63 67 71 72 74 77 77 82 85 89 91 95 95 97 98 99 100 101 102 105 105 108

109 111 114 114

Con ten ts

4.3 4.4 4.5 4.6

4.2.2 Creatin g Use Case Scen arios 4.2.3 Actin g Ou t Scen arios 4.2.4 Th e Ad van tages of Use Case Scen ario Testin g 4.2.5 Th e Disad van tages of Use Case Scen ario Testin g User In terface Walkth rou gh s Req u irem en ts Reviews W h at You Have Learn ed Review Qu estion s

xi

116 119 126 127 128 128 131 131

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

133

5.1 5.2 5.3 5.4 5.5

134 136 138 140 143 143 144 144 145 145 146 147 148 150 152 152 153 157 158 158 160 160 161 163 165 166 167 167 168 169 169 170 171 172 173 173 174 175

5.6

5.7

5.8

5.9

5.10

5.11

5.12 5.13 5.14

5.15

New an d Old Con cep ts Togeth er OO Con cep ts from a Stru ctu red Poin t-of-View Objects an d Classes Attribu tes an d Meth od s Abstraction , En capsulation , an d In form ation Hidin g 5.5.1 Abstraction 5.5.2 En cap su lation 5.5.3 In form ation Hid in g 5.5.4 An Exam p le 5.5.5 W h y Th is Is Im p ortan t In h eritan ce 5.6.1 Mod elin g In h eritan ce 5.6.2 In h eritan ce Tip s an d Tech n iq u es 5.6.3 Sin gle an d Mu ltip le In h eritan ce 5.6.4 Abstract an d Con crete Classes Association 5.7.1 Mod elin g Association s 5.7.2 How Association s Are Im p lem en ted Aggregation 5.8.1 Mod elin g Aggregation 5.8.2 Aggregation Tip s an d Tech n iq u es Collaboration 5.9.1 Messages 5.9.2 Collaboration Tip s an d Tech n iq u es Persisten ce 5.10.1 Persisten ce Tip s an d Tech n iq u es 5.10.2 Persisten t Mem ory: Th e Object Sp ace 5.10.3 Object Databases (ODBs) Persisten t versu s Tran sitory Association s 5.11.1 Persisten t Association s 5.11.2 Tran sitory Association s: Dep en d en cies Cou p lin g 5.12.1 Cou p lin g Tip s an d Tech n iq u es Coh esion Polym orp h ism 5.14.1 An Exam p le: Th e Poker Gam e 5.14.2 Polym orp h ism at th e Un iversity In terfaces

x ii

The Object Prim er

5.16 5.17 5.18 5.19

Com p on en ts Pattern s W h at You Have Learn ed Review Qu estion s

176 178 179 180

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

181

6.1

185 186

6.2

6.3

6.4

6.5

6.6 6.7

6.8

6.9 6.10 6.11

System Use Case Mod elin g 6.1.1 Writin g System Use Cases 6.1.2 Reu se in Use Case Mod els: , , an d In h eritan ce 6.1.3 Good Th in gs to Kn ow Abou t Use Case Mod elin g 6.1.4 Use Case Mod elin g Tip s an d Tech n iq u es Seq u en ce Diagram s: From Use Cases to Classes 6.2.1 How to Draw Seq u en ce Diagram s 6.2.2 W h y an d W h en Sh ou ld You Draw Seq u en ce Diagram s? 6.2.3 How to Docu m en t Seq u en ce Diagram s 6.2.4 A Good Th in g to Kn ow Abou t Seq u en ce Diagram s Con cep tu al Mod elin g: Class Diagram s 6.3.1 Mod elin g Classes, Attribu tes, an d Meth od s 6.3.2 Mod elin g Association s 6.3.3 Mod elin g Dep en d en cies 6.3.4 In trod u cin g Reu se Between Classes via In h eritan ce 6.3.5 Mod elin g Aggregation Association s 6.3.6 Mod elin g Association Classes 6.3.7 Docu m en tin g Class Mod els 6.3.8 Con cep tu al Class Mod elin g Tip s Activity Diagram m in g 6.4.1 How to Draw Activity Diagram s 6.4.2 How to Docu m en t Activity Diagram s User In terface Prototyp in g 6.5.1 Determ in in g th e Need s of You r Users 6.5.2 Bu ild in g th e Prototyp e 6.5.3 Evalu atin g th e Prototyp e 6.5.4 Determ in in g If You Are Fin ish ed 6.5.5 Good Th in gs to Un d erstan d Abou t Prototyp in g 6.5.6 Prototyp in g Tip s an d Tech n iq u es Evolvin g You r Su p p lem en tary Sp ecification 6.6.1 Th e Object Con strain t Lan gu age Ap p lyin g An alysis Pattern s Effectively 6.7.1 Th e Bu sin ess En tity An alysis Pattern 6.7.2 Th e Con tact Poin t An alysis Pattern 6.7.3 Th e Ad van tages an d Disad van tages of Pattern s User Docu m en tation 6.8.1 Typ es of User Docu m en tation 6.8.2 How to Write User Docu m en tation Organ izin g You r Mod els with Packages W h at You Have Learn ed Review Qu estion s

190 193 195 197 2 04 2 07 2 07 2 07 2 08 213 216 22 0 22 0 222 224 225 227 229 230 232 232 232 234 234 234 235 235 237 237 238 238 239 240 242 242 243 245 246 246

Con ten ts

Ch apter 7 • Determ in in g Ho w to Build Yo ur System : Object-Orien ted Design 7.1

7.2

7.3

7.4

7.5

7.6

7.7

7.8

7.9

7.10 7.11 7.12

Layerin g You r Mod els—Class Typ e Arch itectu re 7.1.1 Th e User-In terface Layer 7.1.2 Th e Con troller/ Process Layer 7.1.3 Th e Bu sin ess/ Dom ain Layer 7.1.4 Th e Persisten ce Layer 7.1.5 Th e System Layer Class Mod elin g 7.2.1 In h eritan ce Tech n iq u es 7.2.2 Association an d Dep en d en cy Tech n iq u es 7.2.3 Aggregation an d Com p osition Tech n iq u es 7.2.4 Mod elin g Meth od s Du rin g Design 7.2.5 Mod elin g Attribu tes Du rin g Design 7.2.6 In trod u cin g In terfaces In to You r Mod el 7.2.7 Class Mod elin g Design Tip s Ap p lyin g Design Pattern s Effectively 7.3.1 Th e Sin gleton Design Pattern 7.3.2 Th e Façad e Design Pattern 7.3.3 Tip s for Ap p lyin g Pattern s Effectively State Ch art Mod elin g 7.4.1 How to Draw a State Diagram 7.4.2 W h en an d W h y Sh ou ld You Draw State Diagram s? 7.4.3 State Diagram s an d In h eritan ce Collaboration Mod elin g 7.5.1 Drawin g Collaboration Diagram s 7.5.2 Collaboration an d In h eritan ce 7.5.3 W h en Sh ou ld You Draw Collaboration Diagram s? Com p on en t Mod elin g 7.6.1 How to Develop a Com p on en t Mod el 7.6.2 Im p lem en tin g a Com p on en t Dep loym en t Mod elin g 7.7.1 How to Develop a Dep loym en t Mod el 7.7.2 W h en Sh ou ld You Create Dep loym en t Mod els? Relation al Persisten ce Mod elin g 7.8.1 Keys an d Object Id en tifiers 7.8.2 Th e Basics of Map p in g Objects to RDBs 7.8.3 Map p in g Association s, Aggregation , an d Com p osition 7.8.4 Drawin g Persisten ce Mod els 7.8.5 W h en Sh ou ld You Develop Persisten ce Mod els? User In terface Design 7.9.1 User-In terface Design Prin cip les 7.9.2 Tech n iq u es for Im p rovin g You r User-In terface Design 7.9.3 User-In terface Flow Diagram m in g 7.9.4 User-In terface Design Stan d ard s an d Gu id elin es Design Tip s W h at You Have Learn ed Review Qu estion s 7.12.1 Th e Ban k Case Stu d y Six Mon th s Later

x iii

249 254 256 256 260 260 261 262 263 266 270 272 281 286 289 293 294 295 295 296 299 300 301 301 303 304 305 306 306 312 312 313 315 316 316 324 329 333 334 335 335 336 339 340 341 344 344 346

x iv

The Object Prim er

Ch apter 8 • Object-Orien ted Testin g

347

8.1 8.2

350 352 354 356 358 360 364 366 372 372

8.3

8.4

8.5 8.6

W h at Is Program m in g? From Design to Java Cod e 8.2.1 Im p lem en tin g a Class In Java 8.2.2 Declarin g In stan ce Attribu tes In Java 8.2.3 Im p lem en tin g In stan ce Meth od s In Java 8.2.4 Im p lem en tin g Static Meth od s an d Attribu tes in Java 8.2.5 Im p lem en tin g Con stru ctors 8.2.6 En cap su latin g Attribu tes with Accessors 8.2.7 Im p lem en tin g In h eritan ce In Java 8.2.8 Im p lem en tin g In terfaces In Java 8.2.9 Im p lem en tin g Association s, Aggregation , an d Com p osition In Java 8.2.10 Im p lem en tin g Dep en d en cies 8.2.11 Im p lem en tin g Collaboration in Java 8.2.12 Im p lem en tin g Bu sin ess Ru les From Design to Persisten ce Cod e 8.3.1 Strategies for Im p lem en tin g Persisten ce Cod e 8.3.2 Defin in g an d Mod ifyin g You r Persisten ce Sch em a 8.3.3 Creatin g, Retrievin g, Up d atin g, an d Deletin g Data 8.3.4 Im p lem en tin g Beh avior in a Relation al Database Program m in g Tip s 8.4.1 Tech n iq u es for Writin g Clean Cod e 8.4.2 Tech n iq u es for Writin g Effective Docu m en tation 8.4.3 Miscellan eou s W h at You Have Learn ed Review Qu estion s

377 384 385 385 386 387 389 389 391 393 393 396 398 401 401

Ch apter 9 • Object-Orien ted Testin g

403

9.1

404 405 406 406 406 407 408 409 412 418 42 0 422 424 425

9.2

9.3 9.4 9.5

Overcom in g Miscon cep tion s Abou t Object-Orien ted Testin g 9.1.1 Miscon cep tion #1: With Objects You Do Less Testin g 9.1.2 Miscon ception #2: Structured Testin g Tech n iques Are Sufficien t 9.1.3 Miscon ception #3: Testin g th e User In terface Is Sufficien t Fu ll Lifecycle Object-Orien ted Testin g (FLOOT) 9.2.1 Regression Testin g 9.2.2 Qu ality Assu ran ce 9.2.3 Testin g Your Requirem en ts, An alysis, an d Design Models 9.2.4 Testin g You r Sou rce Cod e 9.2.5 Testin g You r System in its En tirety 9.2.6 Testin g by Users From Test Cases to Defects W h at You Have Learn ed Review Qu estion s

Ch apter 10 • Puttin g It All To geth er: So ftw are Pro cess

427

10.1 10.2 10.3

429 430 431

W h at Is So Differen t Abou t Object-Orien ted Develop m en t? W h at Is a Software Process? W h y Do You Need a Software Process?

Con ten ts

10.4 10.5 10.6 10.7 10.8 10.9 10.10

10.11 10.12 10.13 10.14

From Waterfall/ Serial Develop m en t… …to Iterative Develop m en t… …an d In crem en tal Develop m en t Th e Develop m en t Process Presen ted in Th is Book Process Pattern s of th e Object-Orien ted Software Process (OOSP) Th e Un ified Process Oth er Processes 10.10.1 eXtrem e Program m in g (XP) 10.10.2 Th e Microsoft Solu tion s Fram ework (MSF) 10.10.3 Th e OPEN Process 10.10.4 Catalysis W h en to Use Objects W h en Not to Use Objects W h at You Have Learn ed Review Qu estion s

xv

432 433 435 437 438 442 444 444 448 449 449 450 451 452 453

Ch apter 11 • Wh ere to Go Fro m Here

455

11.1

456 456 457 459 461 462 465 466 466 466 467 467 468 468 468 469 469 470 470 471 471 471 473 473 474 474 474

11.2

11.3

11.4 11.5

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

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 collection 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 ctu 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 erien ce su ccessfu lly.

1.1 Th e Stru ctu red Pa ra dig m versu s th e ObjectOrien 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 lication 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 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 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 objectorien 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 Procedures

Data

A Structured Application

Object

Object

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 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 cou rses, d rop cou rses, an d p ay tu ition ). Professors also kn ow th in gs (th e 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 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 of wh at an ap p lication is all abou t. Rath er th an h avin g a p rogram th at accesses a d atabase, we h ave an ap p lication th at exists in wh at is called an object sp ace. Th e object space is wh ere both th e p rogram an d th e d ata 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 ter 5 bu t, for n ow, th in k of th e object sp ace as virtu al m em ory.

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

Figure 1-1. Comparing the structured and object-oriented paradigms

For ind ivid ua ls, OO is a whole new wa y t o t hink. For orga niza t ions, OO req uires a com p let e cha nge in it s syst em d evelop m ent cult ure.

4

The Object Prim er

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 covers everyt hing you need to know to get you st a rt ed in OO d evelop m ent .

con cepts, OO an alysis an d design usin g th e UML m odelin g tech n iques, OO program m in g, OO testin g, an d th e OO software process. Th e book en ds with a discussion of h ow to con tin ue your learn in g process, in cludin g description s of com m on object-orien ted tech n ologies an d tech n iques you 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 objectorien 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 M anagement Group (OM G).

Ch a pter 1 • In troduction

Gather Requirements (Chapter 3)

Object-Oriented Testing (Chapter 9)

Validate Requirements (Chapter 4)

5

Object-Oriented Paradigm (Chapter 2)

Object-Oriented Analysis (Chapter 6)

Object-Oriented Concepts (Chapter 5)

Object-Oriented Design (Chapter 7)

Object-Oriented Software Process (Chapter 10)

Object-Oriented Programming (Chapter 8)

Where To Go From Here Chapter 11

Figure 1-2.

1.3 How to Rea d Th is 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

The organization of this book

6

The Object Prim er

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 orientation, 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 techniques 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 orientation, 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 JavaBeans (EJB), C++, and component-based development.

Ch a pter 1 • In troduction

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 objectorien 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).

7

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

182

Req uirem ent s engineering focuses on und erst a nd ing users a nd t heir usa ge, wherea s a na lysis focuses on und erst a nd ing wha t need s t o be built .

Fig ure 6 -1 . Overview of analysis artifacts and their relationships

The Object Prim er

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 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 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 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 sage 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. Figu re 6 -1 dep icts th e m ain artifacts of you r an alysis efforts an d th e relation sh ip s between th em . Th e solid boxes in dicate m ajor an alysis artifacts, wh ereas th e dash ed boxes rep resen t you r m ajor req u irem en ts artifacts. 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 Model

Use Case Model

Business Rules

Sequence Diagram

CRC Model

Class Model (Analysis)

User Interface Flow Diagram

User Interface Prototype

Essential User Interface Prototype

Activity Diagram

Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis

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 objectorien 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 Collaborator (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 7-1 an d 8-1, is th at every p ossible “d rives” relation sh ip is n ot sh own . For 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 serin 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 ecessarily 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 association s d ep icted on th at d iagram , wh ereas a CRC m od el is a collection of CRC card s.

183

Ana lysis is a n it era t ive p rocess.

184

The Object Prim er

D EFIN ITION S Act ivit y d ia gra m . A UM L 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 fulfill 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 models the fundamental, abstract characteristics of a user interface. Mod el. An abstraction describing a problem domain and/ or a solution to a problem domain. Traditionally models are thought of as diagrams plus their corresponding documentation, although nondiagrams, 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 system 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 definitions. 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 prototypes could be as simple as a hand-drawn picture or a collection of programmed screens, pages, or reports.

Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis

185

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 system u se cases. Th e m ain differen ce between an essen tial u se case an d a system u se case is, in th e system u se case, you in clu de h igh -level im p lem en tation decision s. For exam p le, a system u se case refers to sp ecific u serin terface com p on en ts—su ch as screen s, HTML p ages, or rep orts—som eth 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 lem 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 arrowh ead on on e en d of th e lin e in dicatin g th e direction of th e in itial in vocation 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.

Syst em use ca ses reflect a na lysis d ecisions a nd , a rgua bly, even d esign d ecisions.

186

The Object Prim er

6.1.1 W rit ing Syst em Use Ca ses

Two com m on st yles exist for writ ing use ca ses: na rra t ive st yle a nd a ct ionresp onse st yle. Choose one st yle a nd st ick t o it .

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 an d , 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-tofin 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 eth 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. Un til n ow, I h ave p resen ted u se cases in wh at is called n arrative style —th e u se case of Figu re 6 -2 is written th is way—wh ere th e basic an d altern ate cou rses of action are written on e step at a tim e. A secon d style, called th e action -resp on se style, p resen ts u se case step s in colu m n s, on e colu m n for each actor an d a secon d colu m n for th e system . Figu re 6 -3 p resen ts th e basic cou rse of action for Figu re 6 -4 rewritten u sin g th is 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 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 stereotype Also known as a “ uses” or a “ has-a” relationship.

Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis

Name: Enroll in Seminar Identifier: UC 17 Description: Enroll an existing student in a seminar for which he is eligible. 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 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 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 Summary Report.” 18. The use case ends when the student takes the printed statement. continued on page 90

187

Figure 6-2. “ Enroll in seminar” written in narrative style

188

The Object Prim er

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 seminar 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 referen ces to oth er cou rses of action . Th e style you ch oose is a m atter of p referen 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 recon 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 recon 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.

Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis

189

Student

System

1. The student wants to enroll in a seminar.

3. The system verifies the student is eligible to enroll in seminars at the university, according to business rule “ BR129 Determine Eligibility to Enroll.”

2. The student inputs his name and student number into the system via “ UI23 Security Login Screen.”

4. The system displays “ UI32 Seminar Selection Screen,” which indicates the list of available seminars. 5. The student indicates the seminar in which she 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 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 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 she wants a printed statement of the enrollment.

16. The student indicates she wants a printed statement.

17. The system prints the enrollment 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

190

The Object Prim er

6.1.2 Reuse in Use Ca se Mod els: , , a nd Inherit a nce You ca n ind ica t e p ot ent ia l op p ort unit ies for reuse on your use ca se m od els

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 for reu se, a goal you can work toward as you are d evelop in g you r u se case m od el. Poten tial reu se can be m od eled th rou gh fou r gen eralization relation sh ip s su p p orted by th e UML u se case m od els: exten d relation sh ip s 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 st ereot ype is used t o ind ica t e a n ext end a ssocia t ion.

Extending use ca ses a re often introd uced to resolve com plexities of a lterna te courses.

Ext ension p oint s a re p la ced in ba se use ca ses t o ind ica t e where t he logic of t he ext end ing use ca se rep la ces t ha t of t he ba se use ca se.

An exten d association , form erly called an exten d s relation sh ip in th e UML v1.2 an d earlier, is a gen eralization relation sh ip wh ere an exten d in g 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 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 rop 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 . 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. An exten d in g u se case is, effectively, an altern ate cou rse of th e base u se case. In fact, a good ru le of th u m b is you sh ou ld in trod u ce an exten d in g u se case wh en ever th e logic for an altern ate cou rse of action is at a com p lexity level sim ilar to th at of you r basic cou rse of action . I also 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 association 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 iversity,” th e base u se case, in its “Exten d s” list. Ju st as you in dicate th e p oin t at wh ich th e logic of an altern ate cou rse rep laces th e logic of a p ortion of th e basic cou rse of action for a u se case, 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 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 m arker in th e logic of a base u se case in dicatin g wh ere exten sion is allowed. Figu re 6 -5 p resen ts an exam p le of h ow an exten sion p oin t wou ld be in dicated in th e basic cou rse of action of th e “En roll in Un iversity” u se

Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis

191

Figure 6-4. The opportunities for reuse in use case models

Registrar

Enroll in University

Enroll in Seminar

Student

Enroll International Student in University

Enroll Family Member in 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 ediately 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 th e form of in clu de association s. An in clu de association , form erly kn own as a u ses relation sh ip in th e UML v1.2 an d earlier, is a gen eralization relation sh ip den otin g th e in clu sion of th e beh avior described by an oth er u se case. Th e best way to th in k of an in clu de association is th at it is th e in vocation 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

4. The system displays “ UI43 Student Information Entry.” [Extension Point: UC34 Enroll International Student In University.] 5. The student…

An includ e a ssocia t ion is t he eq uiva lent of a funct ion ca ll.

Figure 6-5. Documenting an extension point within a use case

192

The Object Prim er

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 otation for doin g so is sim p ly a n orm al u se case association with th e stereotyp e of . 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 avior 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 inclusion of a use case

8. The student indicates the seminar(s) she wants to take via the use case UC 17 Enroll in Seminar. 9. The student…

Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis

193

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 in dicate p oten tial reu se. Figu re 6 -4 dep icts an exam p le of th is, sh owin g th at “En roll Fam ily Mem ber in Un iversity” in h erits from th e “En roll In 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 dition , in th is case, th e studen t is a fam ily m em ber of a professor, would result in th e defin ition of several altern ate courses. With out th e option to defin e an in h eritin g use case, you n eed to in troduce an altern ate course to rework 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 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 m odels occurs between actors: An actor on a use case diagram can in h erit 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 studen 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 eritan 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.

Use ca ses m a y inherit from ot her use ca ses.

Ap p ly inherit a nce bet ween use ca ses when a single cond it ion would result in severa l a lt erna t e courses.

Act ors m a y inherit from ot her a ct ors.

6.1.3 Good Things t o Know About Use Ca se Mod eling 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 association s between actors an d u se cases in d icate th e n eed for in terfaces. W h en th e actor is a p erson , th en to su p p ort th e association , you n eed to d evelop u ser in terface com p on en ts, su ch as screen s an d rep orts. W h en

Associa t ions bet ween a ct ors a nd use ca ses im p ly t he need for int erfa ces.

194

You should be a ble t o exit from a use ca se a t a ny t im e.

Bewa re of t he “use ca se d riven” hyp e of consult a nt s a nd t ool vend ors.

Includ e, ext end , a nd inherit a nce a ssocia t ions bet ween use ca ses ca n lea d t o funct iona l d ecom p osit ion if you a re not ca reful.

The Object Prim er

th e actor is an extern al system , th en you n eed to d evelop a system in terface, 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 on en ts, p articu larly “UI23 Secu rity Login Screen ,” “UI32 Sem in ar Selection 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.” Secon d , u se cases are often written u n d er th e assu m p tion th at you can 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” 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 system 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 . Th ird , in m y op in ion , u se case m od elin g h as received far m ore atten 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 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 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 ltan 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. Fou rth , alth ou gh th e reu se tech n iq u es— exten d association s, in clu d e association s, an d in h eritan ce —are u sefu l, d on ’t overu se th em . In clu d e association s an d , to a lesser d egree, exten d association s, lead to fu n ction al d ecom p osition with in you r u se case m od el. Th e p roblem is u se cases are n ot m ean t to d escribe fu n ction s with in you r sou rce cod e; th ey are m ean t to d escribe series of action s th at offer valu e to actors. A good 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 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.

Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis

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 rp 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 system 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 specificatio 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 in 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.

195

196

The Object Prim er

6. Organ ize yo ur use case diagram s co n sisten tly. Com m on p ractice 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 easier 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 teraction 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 raged 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 an d asso ciatio 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 Modelin 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 odelin 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 an d stereotyp 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 agreem 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 system . 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

Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis

197

“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, resultin 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 valuable 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 m odel th e logic of usage scen arios. A usage scen ario is exactly wh at its n am e in dicates—th e description of a poten tial way your system is used. Th e logic of a usage scen ario m ay be part of a use case, perh aps an altern ate course. It 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 in stan ces, typ ically u se cases, objects, classes, or actors. Becau se you can sen d m essages to both objects an d classes, objects resp on d to m essages th rou gh th e in vocation of an op eration , an d classes d o so th rou gh th e 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, HTM L 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 uence d ia gra m s ena ble you t o visua lly m od el t he logic of your syst em .

Object s, cla sses, a nd a ct ors a re d ep ict ed in seq uence d ia gra m s.

198

Messa ges a re ind ica t ed by la beled a rrows, a nd ret urn va lues by d a shed a nd la beled a rrows.

The Object Prim er

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 iagram 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 . 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 . 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 ywh 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, represen 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 dicatin 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, typically th e result of receivin g a m essage with th e stereotype of . Messages are in dicated as labeled arrows, wh en th e sou rce an d target of a m essage is an object or class th e label is th e sign atu re of th e m eth od in voked in resp on se to th e m essage. However, if eith er th e sou rce or target is a h u m an actor, th en th e m essage is labeled with brief text describin g th e in form ation bein g com m u n icated. For exam p le, th e “:En rollIn Sem in 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 tter m y seq u en ce diagram s (as you can see, seq u en ce diagram s get com p licated fairly q u ickly).

A UM L sequence diagram for the basic course of action for Figure 6-2

Figure 6-7.

12. System enrolls student in seminar

11. Students indicates yes.

10. System verifies student wishes to enroll

9. System displays fees

8. System calculates fees

7. System determines schedule fit

6. System determines eligibility to enroll

5. Students picks seminar

4. System displays seminar list

3. System verifies student

2. Student inputs name and number

1. Student indicates wish to enroll

SD #: UC17-01

Basic Course of Action

Enroll In Seminar

A Student

wish to enroll

name

theStudent

:SeminarSelector

selection

X



theStudent

X

:SecurityLogon

student number

:EnrollInSeminar

Student

verification

X

enrollStudent(theStudent)

getSchedule()

schedule :StudentSchedule

:StudentFees

calculateFees(seminar, theStudent)

determineFit(seminar)

Note: Need to flesh this message out more.

theStudent :Student

qualifications()

seminar:Seminar

isEligibleToEnroll(theStudent)

isEligible(name, studentNumber)

:FeeDisplay

200

St ereot yp es m a y be a p p lied t o a ct ors, object s, cla sses, a nd m essa ges on seq uence d ia gra m s.

The Object Prim er

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 . Notice th e u se of stereotyp es th rou gh ou t th e d iagram . For th e boxes, I ap p lied th e stereotyp es , , an d in d icatin g th at th ey rep resen t an actor, a con troller class, or a u ser in terface (UI) class, resp ectively. For n ow, a con troller class is a p laceh old er for on e or m ore classes th at wou ld be flesh ed ou t d u rin g d esign (Ch ap ter 7) to im p lem en t th e bu sin ess logic of you r system . As you see in Ch ap ter 7, you wan t to layer you r system , sep aratin g you r u ser in terface logic, bu sin 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 iagram s is to in d icate creation an d d estru ction m essages with th e stereotyp es of an d , 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. Classifiers 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 UM L in a consistent manner.

Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis

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 constructors, 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 p laced on an y UML d iagram , to p rovid e a h ead er for th e d iagram , in d icatin g its title an d id en tifier (as you m ay h ave n oticed , I give u n iq u e 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 decision s th at cou ld p oten tially affect m y oth er m odels. For exam p le, as I m odeled Step 10, I m ade th e assu m p tion (argu ably, a design decision ) th at 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 diagram 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 realization 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 rp 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 ortu 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 essages goin g from left-to-righ t an d retu rn valu es from righ t-to-left, alth ou gh th at d oesn ’t always work with com p lex objects/ classes. I ju stify th e label on m essages an d retu rn valu es, so th ey are closest to th e arrowh 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

201

Not es ca n be used t o a d d free-form t ext t o a ny UML d ia gra m .

Verify m od eling d ecisions wit h your SMEs.

Und erst a nd t he ba sic logic d uring a na lysis, flesh out t he d et a ils d uring d esign.

202

The Object Prim er

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 several 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 UM L 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 in 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 diagram for each altern ate course, as you see depicted in Figure 6-8. Th is diagram 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.

Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis

You may have heard terms such as dynamic modeling and static modeling bantered about by other developers familiar with object-oriented modeling techniques. You may even have heard arguments about the merits of each style. Dynamic modeling techniques focus on identifying the behavior within your system. These techniques include sequence diagramming and activity 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 isites 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 an op p ortu n ity for both reu se an d an overall sim p lification of th e p oten -

203

TIP Seq uence Dia gra m s Are Dyna m ic

Fig ure 6 -8 . A UM L 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

SD #: UC17-01B

isEligibleToEnroll(theStudent)

B.6. System determines ineligibility to enroll false

B.7. System informs the student of ineligibility B.8. System informs the student of prerequisites B.9. Use case resumes at step 4



204

The Object Prim er

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 develop 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 tifyin 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 icatin 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 ation 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 resen 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 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 oesn ’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 stereotyp e.

Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis

5. In tro duce a bo x fo r each m ajo r UI elem en t. Major u ser in terface 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 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 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 . 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 in stead of on th e Class Resp on sibility Collaborator (CRC) card s. I d id th is for two reason 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 or as a stereotyp e is barely relevan t wh en th e big p ictu re is taken in to con sid eration .

205

206

The Object Prim er

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 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 essages 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 erfect 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.

Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis

207

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 forem ost, seq u en ce d iagram s are a great way to valid ate an d flesh ou t you r logic (n ot th at th is sh ou ld stop you from u se case scen ario testin g, as d escribed in Ch ap ter 4). Secon d , seq u en ce d iagram s are a great way to 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 bottlen 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 lication 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 iagram 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.

Seq uence d ia gra m s a re used t o t est your d esign a nd t o d ocum ent use ca ses.

208

The Object Prim er

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 ologies 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 terrelation 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 Collaborator (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 rovid 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.

Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis

209

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 real world). Notice h ow th e n am es stayed th e sam e (spaces were rem oved

Fig ure 6 -9 . A CRC model for the university

Professor

Transcript Student

Provide information about self Request to enroll in seminar Request Transcript

Enroll in Seminar Transcript

**See the prototype** Get student info Get seminars student took Determine average mark Output self

Enroll in Seminar

Seminar Professor

.

Name Seminar number Fees Waiting list Enrolled students Instructor Add student Drop student

Student Professor

Student

**See the prototype** Request identifying info for student

Seminar

Seminar

**See the prototype** Enable seminar search Display seminar list Display seminar fees Display professor info

SecurityLogon

Student Seminar Professor Enrollment Record

Name Address Phone number Email address Salary Provide information Seminars instructing

Student

Name Address Phone number Email address Student number Average mark received Validate identifying info Provide list of seminars taken

Enrollment Record

Enrollment Record Mark(s) received Average to date Final grade Student Seminar

Seminar

210

The Object Prim er

EnrollmentRecord marksReceived SecurityLogon

acceptStudentID() acceptStudentName() validateStudent() Transcript

getStudent() getSeminars() determineAverage() output()

enrolled in

Student name address phoneNumber emailAddress studentNumber averageMark isEligible (name, studentNumber) getSeminarsTaken()

getAverageToDate() getFinalMark() enrolled in

on waiting list

addStudent(student) dropStudent(student)

EnrollInSeminar

searchForSeminar() displaySeminarList() displaySeminarFees() displayProfessor()

Fig ure 6 -1 0 .

Seminar name seminarNumber fees waitingList

instructs

Professor name address phoneNumber emailAddress salary getInformation()

A UM L 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 colCollaborations 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 association s m ay, in fact, prove to be aggregation association s but, for n ow, it from business/ is good en ough sim ply to h ave m odeled th e lin e. dom ain cla sses Con sid er th e association s m od eled in Figu re 6 -10. Th e “waitin g list” im ply either 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 lem 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

Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis

211

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 resp on sibility in d icate th at th e “Stu d en t” card h ad kn owled ge of bein g on a waitin g list. I m od eled an “en rolled in ” association between th e “Stu d en t” an d “En rollm en tRecord ” classes to su p p ort th e sim ilarly 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 ” association between “En rollm en tRecord ” an d “Sem in ar” to su p p ort th e cap ability 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 irection 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 th e CRC card s were m od eled eith er as attribu tes or m eth od s of th e corresp on d in g classes. Th e “Stu d en t” class is in terestin g becau se I ch ose to m od el th e “Average m ark received ” resp on sibility as an attribu te an d n ot 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 eterNam 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

Associa t ions a re bid irect iona l only if t hey need t o be t ra versed in bot h d irect ions.

Resp onsibilit ies a re usua lly m od eled a s a t t ribut es or m et hod s.

212

The Object Prim er

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 interfa ce cla sses on cla ss d ia gra m s often a d d s a lot of clutter without a d d ing m uch useful inform a tion.

Mod el com p lex or im p ort a nt concep t s on your UML d ia gra m s using OCL.

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 system ad eq u ately, rarely to d escribe it th orou gh ly. Yes, I cou ld create d etailed classes for each UI class in m y m od el, bu t wh at valu e wou ld th at be? It sou n d s like a lot of work for little retu rn , p articu larly wh en m ore th an en ou gh d etails are in th e u ser in terface m od el alread y. Also, as you 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 iagram , 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 ifican 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 sin 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 erin 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. In Figu re 6 -11, I also m od eled a UML con strain t, in th is case “{ord ered FIFO},” on th e association between “Sem in ar” an d “Stu d en t.” Th e basic 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 (FIFO) basis. In oth er word s, th e stu d en ts are p u t on th e waitin g list in 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 erstan 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.

Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis

213

EnrollmentRecord Student name address phoneNumber emailAddress studentNumber averageMark isEligible (name, studentNumber) getSeminarsTaken()

1

enrolled in

1..*

marksReceived

1..*

getAverageToDate() getFinalMark() 0..*

{ordered, FIFO}

on waiting list

Professor name address phoneNumber emailAddress salary getInformation()

enrolled in

1

Seminar name seminarNumber fees 0..* waitingList addStudent(student) 0..* dropStudent(student)

instructs 0..1

?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 m od el in to an in itial UML class m od el, you are th en read y to con tin u e 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 represen tation of an object an d, in m an y ways, it is sim ply a tem plate from

The revised class diagram

214

The Object Prim er

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 collection 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 attributes 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 studen 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 studen 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 appropriate 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 avior. 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 erm 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 an en t m ailin g address, such as a dorm —th is is in form ation th e system m ay

TIP Use t he Term inology of Your Users

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 artificial, technical terms on them. Remember, they’re the experts, not you. In short, avoid geek-speak.

Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis

Student name phoneNumber emailAddress studentNumber averageMark

Address

1

lives at

street city 1 state postalCode country

isEligible (name, studentNumber) getSeminarsTaken()

215

Figure 6-12. The “ Student” and “ Address” classes

validate() outputAsLabel()

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 caten 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.

Seminar

0..*

offering of

1

Course

seminarNumber waitingList

name courseNumber fees

addStudent(student) dropStudent(student)

getFullName()

Figure 6-13. Normalizing the “ Seminar” class

216

The Object Prim er

Figure 6-14.

Course

“ Seminar” with all its getter and setter methods modeled

name courseNumber 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

Id ent ifying t he m ult ip licit ies of a n a ssocia t ion is a n im p ort a nt p a rt of m od eling it .

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 . Wh en you m odel association s in UML class diagram s, you sh ow th em as a th in lin e con n ectin g two classes, wh ich was illustrated in Figure 5-9. Association s can becom e quite com plex; con sequen tly, you can depict som e th in gs about th em on your diagram s. Figure 5-9 dem on strated th e com m on item s 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 “Professor” 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.

isEligible (name, studentNumber) getSeminarsTaken() purchaseParkingPass()

name phoneNumber emailAddress studentNumber averageMark

Student

enrolled in

1

1..*

validate() outputAsLabel()

street city state postalCode country

Address

{ordered, FIFO}

lives at

0..1

0..*

1

EnrollmentRecord

1

enrolled in

Professor

1..*

getInformation() purchaseParkingPass()

name phoneNumber 0..1 emailAddress salary

lives at

on waiting list

getAverageToDate() getFinalMark()

marksReceived seminarNumber waitingList

Seminar

0..1

instructs

0..* addStudent(student) dropStudent(student)

0..*

1

0..* offering of

Course

getFullName()

name courseNumber fees

Combined class diagram

Figure 6-15.

1

218

The Object Prim er

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 minimizing 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 better 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 in 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 possible 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 Alwa ys Ind ica t e t he Mult ip licit y

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 person may be President of the United States at any given time), then it is 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.

Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis

219

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 with in th e association , m ay also be in dicated. My style is to m odel th e role on ly wh en th e in form ation adds valu e, for exam p le, kn owin g th e role of th e “Stu den t” class is “en rolled stu den t” in th e “en rolled in ” association doesn ’t add an yth in g to th e m odel. I in dicate roles wh en it isn ’t 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 Figu 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 in 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 odeled 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 icate 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 .”

Mod el roles when a n a ssocia tion is recursive or when severa l a ssocia tions exist between two cla sses.

220

The Object Prim er

Professor name associate phoneNumber 0..* emailAddress salary getInformation() 0..1 advisor mentors

Seminar 0..1 assistant

0..* seminarNumber waitingList {NAND} addStudent(student) 0..* dropStudent(student)

0..1 instructor

Figure 6-16.

6.3.3 Mod eling Dep end encies

M odeling roles in associations

Depen den cy relation sh ips are used to m odel tran sitory association s between 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 fulfill 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 UM L 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.

Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis

221

Figure 6-17.

EnrollInSeminar

Seminar

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 eritan 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 eritan 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 tin 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 “Person ” 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 “Person ” an d “Ad d ress.” First, th is association was p u sh ed u p to “Person ” 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.

M odeling dependencies between classes

Associa t ions a re inherit ed .

222

The Object Prim er

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 benefit 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, association 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 irection 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 “Professor” 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 ifican 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 m od els “is p a rt of” a ssocia t ions.

Som etim es an object is m ade u p of oth er objects. For exam p le, an airp lan e 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 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

Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis

Person

223

Address

name phoneNumber emailAddress

0..1

purchaseParkingPass()

lives at

street city 1 state postalCode country validate() outputAsLabel()

Student studentNumber averageMark

Professor salary getInformation()

isEligible (name, studentNumber) getSeminarsTaken()

Figure 6-18. Applying the concept of inheritance in a class diagram

association s. In Figure 6-19, you see a sim ple class m odel depictin g th e relation 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 program 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 recom 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 relation 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 these attributes in both classes: “ name,” “ emailAddress,” and “ phoneNumber,” respectively. However, you will often find situations where one class has an attribute called “ name,” whereas another one has “ firstName,” “ middleInitial,” and “ lastName.” You then need to decide whether these are, in fact, the same thing and, if they are, be prepared to refactor your existing model, and perhaps even code to reflect whichever approach to storing a person’s name you accept. A similar issue can also occur with methods and associations.

TIP Som et im es Op p ort unit ies for Inherit a nce Are Not So Obvious

224

The Object Prim er

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 completely 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 erally ap p licable wh en ever both classes rep resen t p h ysical item s an d aggregation m akes sen se.

6.3.6 Mod eling Associa t ion Cla sses Associa t ion cla sses m a y be useful d uring a na lysis, but need t o be resolved d uring d esign.

Association classes, also called link classes, are u sed to m od el association s th at h ave m eth od s an d attribu tes. “En rollm en tRecord ” is m od eled as an associative class in Figu re 6 -21, in stead of bein g m od eled as a “n orm al” class as in Figu re 6 -15. Associative classes are typ ically m od eled d u rin g an alysis, as you see in Figu re 6 -21, an d th en refactored in to th e origin al ap p roach you see in Figu re 6 -15 d u rin g d esign . Th e reason th is occu rs is,

0..*

Figure 6-19. A course is part of a program

Program

Figure 6-20. M odeling composition

Product

0..*

0..*

1..* recommended for

1..*

0..*

Component 0..* assembly

Course

0..* subassembly

Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis

One of the following sentences should make sense: “ A subclass IS A superclass” 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 student is a vehicle or is like a vehicle, so the class “ Student” likely shouldn’t inherit from “ Vehicle.”

225

TIP Ap p ly t he Sent ence Rule

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()

Student

1..*

1..* enrolled in

Figure 6-21.

Seminar

An example of an associative class

226

TIP If In Doubt , Lea ve It Out

The Object Prim er

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 many modelers will agonize over when to use aggregation even though little 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 ersisten 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 lorries? 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 association 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 .

Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis

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 Collaborator (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 ortan t in form ation th at is relevan t to you r con cep tu al m od el, p rovid 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 critical 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.

227

228

The Object Prim er

4. Focus on th e problem space. Th e purpose of an alysis is to un derstan 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 existin 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.

Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis

229

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 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 th e flow of logic of a bu sin ess p rocess. In m an y ways, activity d iagram s are th e object-orien ted eq u ivalen t of flow ch arts an d d ata-flow d iagram s (DFDs) from stru ctu red d evelop m en t (Gan e an d Sarson , 1978). Th e activity 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 reason ably closely to u se cases, alth ou gh you will n otice th e “En roll in Sem in 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 articu 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 roceed 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 correct, 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.

Act ivit y d ia gra m s a re used t o m od el t he logic of a business p rocess, use ca se, or m et hod .

230

The Object Prim er

Figure 6-22. A UM L activity diagram for enrolling in school for the first time

Fill out Enrollment Forms

[incorrect]

Enrolling in the University for the first time

Obtain Help to Fill Out Forms

AD #: 007

[correct]

Enroll in University

Attend University Overview Presentation [accepted] [rejected] Enroll In Seminar(s)

Make Initial Tuition 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 tifyin 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 icatin 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 startin 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.

Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis

D EFIN ITION S Act ivit y d ia gra m . A UM L 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). 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 UM L 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 Figu 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.

231

232

TIP Act ivit ies Ha ve Ent ry a nd Exit Tra nsit ions

The Object Prim er

Every activity has at least one entry transition—otherwise, you would never perform the activity, and at least one exit transition—otherwise you would never stop performing it. For each activity, I always ask myself: From where could I get into this and where can I go from here? By asking this question, it 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 iagram . 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

Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis

233

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. Th is im plies th at you con vert your h an ddrawin gs, flip-ch art paper, an d sticky n otes in to som eth in g a little m ore substan tial. You begin th is process 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 dowsbased 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 differen 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 terface 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 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 (Section 6.1) an d you r essen tial u ser in terface p rototyp e (Ch ap ter 3). You are also likely to d iscover th at in form ation is m issin g from you r d om ain 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.

You begin by choosing t he user int erfa ce p la t form .

You d iscover t he need t o up d a t e ot her m od els a s your UI p rot ot yp e evolves.

234

TIP User Int erfa ce Prot ot yp ing Is Not a Subst it ut e for Ana lysis a nd Design

The Object Prim er

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 communicate adequately how they will be used (that is what use case models are good for). Furthermore, UI prototypes don’t provide much indication as to the details of the business logic behind the screens, which is what sequence and activity diagrams are good at. And they aren’t good at depicting the static 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.

Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis

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 roblem 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 tiate 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.

235

236

The Object Prim er

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 ristm 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 ction 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 carefu 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 lem 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

Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis

237

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 supplem en tary specification . Th is in cludes flesh in g out th e con strain ts, busin ess rules, an d n on fun ction al requirem en ts you iden tified durin g th e requirem en ts defin ition . As you evolve your oth er m odels, such as your activity diagram s an d your con ceptual class m odel, you are likely to discover th at th e 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 .

You will a p p ly t he inform a t ion cont a ined in your sup p lem ent a ry sp ecifica t ion in your ot her m od els.

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 En glish , used to express side-effect-free con strain ts with in Un ified Modelin g Lan guage m odels. OCL can appear on an y UML diagram or in th e supportin g docum en tation describin g a diagram . OCL can be used for a wide variety of purposes, in cludin g specifyin g th e in varian ts of classes, precon dition s an d postcon dition s on operation s, an d con strain ts on operation s. Th e reality is th at a graph ical m odel, such as a UML class diagram , isn ’t sufficien t for a precise 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 supplem 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 form 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 association 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 -

OCL is used t o d ep ict const ra int s, p recond it ions, p ost cond it ions, a nd inva ria nt s wit hin your UML m od els.

238

The Object Prim er

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 Ent it y a na lysis p a t t ern d escribes t he d ifferent t yp es of p eop le a nd orga niza t ions wit h whom you int era ct .

Every organ ization h as to d eal eith er with oth er organ ization s or p eop le, u su ally both . As a resu lt, you n eed to keep track of th em . Th e solu tion for th e Bu sin ess En tity an alysis p attern (Am bler, 1998a), sim ilar to Fowler’s (1997) Party p attern , is p resen ted in Figu re 6 -24. Th is p attern is a sp ecialization of Peter Coad ’s Roles Played p attern (Coad , 1992; Am bler, 1998a) to m od el th e d ifferen t typ es of organ ization s an d p eop le with wh om you r com p an y in teracts.

Figure 6-24. The Business Entity analysis pattern

BusinessEntity

Person salutation firstName middleInitial surname

EntityRole 1..* start end

1

Organization

CustomerRole 0..1

name 0..*

customerID

SupplierRole placeOrder()

EmployeeRole employeeID hire() promote() demote() transfer() fire() endEmployment()

Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis

239

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 structured English, to express side-effect-free constraints within UM L 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 tityRole” 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 itive 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 wh ich is d ep icted in Figu re 6 -25, d escribes an ap p roach for keep in g track of th e variou s m ean s by wh ich you in teract with bu sin ess en tities. You r organ ization m ost likely sen d s in form ation an d bills to, as well as sh ip s p rod u cts to, th e su rface ad d resses of you r cu stom ers. Perh ap s it em ails in form ation to cu stom ers an d em p loyees, or faxes in form ation to th em . It also p robably n eed s to keep track of th e con tact p h on e n u m ber for an yon e with wh om it in teracts. Th e Con tact Poin t p attern m od els an 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

The Cont a ct Point a na lysis p a t t ern d escribes a n a p p roa ch for keep ing t ra ck of t he wa y your orga niza t ion int era ct s wit h business ent it ies.

240

The Object Prim er

TIP How t o Use Ana lysis Pa t t erns Effect ively

You ca n use p a t t erns t oget her t o solve d ifficult p roblem s.

The real value of analysis patterns is the thinking behind them. A pattern might not be the total solution to your problem, but it might provide enough insight to help save you several hours or 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 form ation on labels, letterh ead , an d rep orts. To d o so, con tact p oin ts collaborate 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. I ap p lied th e Item -Item Descrip tion p attern (Coad , 1992; Am bler, 1998a) wh en m od elin g th e “Con tactPoin t” an d “Con tactPoin tTyp e” classes. Th is d em on strates an im p ortan t p rin cip le of object-orien ted p attern 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 objectorien 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 evelop 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. Pattern 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 erstan d an d m ain tain . W h en you r ap p lication s are d evelop ed in a

Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis

BusinessEntity

1

contacted through

ContactPoint 1..* {ordered} sendTo() asLabel()

0..*

describes

241

ContactPointType 1..* name description

Phone

ShippingAddress

number

0..*

call() sendTo() asLabel()

ElectronicAddress email sendTo() asLabel()

SurfaceAddress street city state postalCode sendTo() asLabel()

Country

1 0..*

name phoneCode

Figure 6-25.

con sisten t m an n er, it’s th at m u ch easier to d o tech n ical walkth rou gh s th at en able you to im p rove th e q u ality of you r d evelop m en t efforts.

The Contact Point analysis pattern

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 erefore, 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, 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 online, including sites specializing in analysis patterns.

TIP Visit t he Process Pa t t erns Resource Pa ge

242

The Object Prim er

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 is required for m ost m od ern system s.

Mayh ew (1992) believes th e u ser d ocu m en tation is p art of th e u ser in terface for an ap p lication an d th at well-written u ser d ocu m en tation is n o 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

Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis

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 u ser m an u al for in term ediate u sers, an d a referen ce m an u al for exp ert u sers. Tou rn iaire an d Farrell (1997) also recom m en d th at you develop a 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 com m u n ity, a docu m en t th at is typ ically less th an a p age in len gth . W h en ap p rop riate, you r u ser docu m en tation sh ou ld in clu de a descrip tion of th e skills n eeded to u se you r system . For exam p le, you r u sers m ay req u ire train in g in you r bu sin ess dom ain or in basic com p u ter skills, su ch 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.

243

The user d ocum ent a t ion for your application includ es a t ut oria l m anual, a reference m a nua l, a user m a nua l, a nd a sup p ort user’s guid e.

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? You were likely tryin g to d eterm in e h ow to accom p lish a task, a task th at p robably wou ld be d escribed via a u se case or activity d iagram in you r an alysis m od el. My exp erien ce is th at th e easiest way to write you r u ser d ocu m en tation is to start with th e m od els th at d escribe h ow you r u sers 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 community. 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.

Your use ca ses a nd a ct ivit y d ia gra m s d rive t he d evelop m ent of your user d ocum ent a t ion.

244

Your use ca ses, a ct ivit y d ia gra m s, a nd UI p rot ot yp e d rive t he d evelop m ent of your user m a nua l a nd t ut oria l.

Your user int erfa ce m od el oft en d rives t he d evelop m ent of your reference m a nua l.

TIP Hire a Technica l W rit er

The Object Prim er

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 readable. 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 referen 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 tation , it really is a m odel-driven approach because your use cases sim ply aren ’t sufficien t for th is purpose. 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 few d ifferen ces exist. First, tu torials focu s on th e m ost critical u ses of th e system , wh ereas a u ser m an u al sh ou ld focu s on th e en tire system . Secon d , tu torials sh ou ld h ave a m ore exp licit focu s on learn in g a p rod 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 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. You r referen ce m an u al, becau se it h as a sligh tly d ifferen t p u rp ose, is gen erally d riven by you r u ser in terface m od el, in stead of you r u se cases an d activity d iagram s. I gen erally in clu d e an overview of th e system , section s for each m ajor p ortion of you r system , an d su bsection s d escribin g 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

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 have. If possible, hire a technical writer to work with you to produce your user 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.

Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis

good practice, wh y do people give th is advice? I believe th e m otivation is th at writin g user docum en tation first forces you to th in k about h ow your system will be used before you start to build it. My advice is differen t: 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.

245

Mod el before you writ e your user d ocum ent a t ion a nd source cod e.

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 erstan 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 iagram 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 ristic 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 obligation 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 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 short, descriptive name. If you can’t, then you may have put several unrelated things into the package.

TIP Pa cka ges Should Be Cohesive

246

The Object Prim er

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 eritan 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 iagram 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 odelin 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 UM L construct that enables you to organize model elements into groups.

Ch a pter 6 • Determ in in g Wh a t to Bu ild: Object-Orien ted An a lysis

between classes an d th e resu ltin g op p ortu n ities for ap p lyin g in h eritan 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 osition 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 conceptual 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 designate it as such.

247

248

The Object Prim er

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 discu ss th e advan tages an d disadvan tages of h avin g differen t ap p roach es available to you .